Subject: Simultaneous Open - Reg

From: "Udaya kumar" <[email-masked]>
Date: Mon, 22 Apr 2002 10:13:26 +0530

Hi

    I have a query regarding simultaneous open in TCP.

    The response to a SYN segment in the SYN_SENT state is to send a SYN,ACK carrying the old sequence number(i.e seq. no of the SYN segment sent earlier). Ref -> rfc793 &&  rfc1122. If the response is such,  then the SYN,ACK segment would be dropped at the receving side due to sequence number check. Hence connection cannot be established.

In our imlpementation it is noted that the TCP stack sends a simple ACK segment with the next sequence number instead of the SYN,ACK mentioned above. This simple ACK with incremented seq. number would definetly be accepted at the other end and the two sides will go to established state.

I request for a clarification in this regard as to which approach is correct and is there any reference to this issue in the rfcs other than 793 and 1122.

thanks
uday

---

From: Neil Spring <[email-masked]>
Date: Mon, 22 Apr 2002 00:20:06 -0700

On Mon, Apr 22, 2002 at 10:13:26AM +0530, Udaya kumar wrote:
>     The response to a SYN segment in the SYN_SENT state
> is to send a SYN,ACK carrying the old sequence number(i.e
> seq. no of the SYN segment sent earlier). Ref -> rfc793 &&
> rfc1122. If the response is such,  then the SYN,ACK segment
> would be dropped at the receving side due to sequence
> number check. Hence connection cannot be established.

which sequence number check?  it seems like a receiver
that would discard the syn/ack packet it needs to make
progress is not correct.  The syn/ack packet looks just
like a retransmitted syn, with the extra ack information,
so I'm surprised it would be dropped.

The only relevant sequence number check I found in linux:
  if (th->syn && !before(TCP_SKB_CB(skb)->seq, tp->rcv_nxt)) {
    tcp_reset(sk);
    return 1;
  }
seems like it should let such a syn/ack (syn as in the
previous packet, is before the next byte expected) through,
unless I misread the code.

-neil