In article <local.mail.freebsd-net/20011129043524$[EMAIL PROTECTED]> you write:
>-=-=-=-=-=-
>
>Hi, I am tracing the FreeBSD 4.4 kernel and I found that its TCP seems
>NOT be able to do simultaneous open according to the source code. In
>tcp_input.c, even though code near line #1750,
>
>case TCPS_SYN_RECEIVED:
> .....
> if (tp->t_flags & TF_NEEDFIN) {
> tp->t_state = TCPS_FIN_WAIT_1;
> tp->t_flags &= ~TF_NEEDFIN;
> } else {
> tp->t_state = TCPS_ESTABLISHED;
> callout_reset(tp->tt_keep, tcp_keepidle,
> tcp_timer_keep, tp);
> }
>
>do change state from SYN_RCVD state to ESTABLISHED, however, near line
>1700 , the code fragment
>
>if (thflags & TH_SYN) {
> tp = tcp_drop(tp, ECONNRESET);
> rstreason = BANDLIM_UNLIMITED;
> goto dropwithreset;
> }
>
>
> drops a packet with SYN bit set in SYN_RCVD state. I think this would
>break TCP's simultaneous open.
>
>Since upon receiving a SYN segment in SYN_SENT state, TCP switches to
>SYN_RCVD state and sends a (ACK,SYN) segment to the peer, if the peer
>drops segments with SYN bit set during SYN_RCVD state, the simultaneous
>open mechanism of TCP would break.
>
>Am I correct?
No. In this case, there are 3 distinct state transitions:
A. send SYN. CLOSED -> SYN_SENT
B. recv SYN. SYN_SENT -> SYN_RECEIVED
C. recv ACK. SYN_RECIEVED -> ESTABLISHED
So dropping a connection when receiving a SYN packet in the SYN_RECEIVED
state is the correct thing to do; this is would be a duplicate SYN. For
a simultaneous open, the peer's SYN is received when the local state is
SYN_SENT.
The error in your logic above is that in step B, only an ACK is sent to
the peer, the SYN is not retransmitted as well.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
