Bug 211441 - incorrect handling of TCPS_SYN_SENT and TCPS_SYN_RECEIVED in API tcp_usrclosed() in file tcp_usrreq.c
Summary: incorrect handling of TCPS_SYN_SENT and TCPS_SYN_RECEIVED in API tcp_usrclose...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Michael Tuexen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-29 13:30 UTC by Prabhat
Modified: 2016-12-23 07:42 UTC (History)
2 users (show)

See Also:


Attachments
tcp state diagram for quick reference (19.72 KB, image/gif)
2016-07-29 13:30 UTC, Prabhat
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Prabhat 2016-07-29 13:30:14 UTC
Created attachment 173093 [details]
tcp state diagram for quick reference

1) For TCPS_SYN_SENT:

As per TCP state diagram, TCPS_SYN_SENT should switch to TCPS_CLOSED state on appl:close call or timeout. In current code, at SYN_SENT state, a FIN message is initiated instead of call to tcp_close() to release PCB and TCP control block, which leads to incorrect states.

To fix the issue, "case TCPS_SYN_SENT:" must be shifted with the case "case TCPS_LISTEN:".


2) For TCPS_SYN_RECEIVED:

As per TCP state diagram, on appl:close call, if we are at TCPS_SYN_RECEIVED state then we just need to send FIN and switch to FIN_WAIT_1 state. In current code, we are not switching to TCPS_FIN_WAIT_1 state.

To fix this issue, "break;" statement should be removed in the case "case TCPS_SYN_RECEIVED:" so that it falls through "case TCPS_ESTABLISHED:" where we are changing state to TCPS_FIN_WAIT_1.

Code fix:
	case TCPS_SYN_RECEIVED:
		tp->t_flags |= TF_NEEDFIN;
		//break;
Comment 1 Hiren Panchasara freebsd_committer 2016-12-23 06:49:44 UTC
CCing Michael as he has fixed some state transition bugs in TCP lately.

Michael, would you be able to take a look? If not, let me know and I'll try to do it.
Comment 2 Michael Tuexen freebsd_committer 2016-12-23 07:42:16 UTC
Hi Hiren,

I can take care of it.

Best regards
Michael