Re: Simultaneous Open

Re: Simultaneous Open - Reg

Neil Spring <nspring@cs.washington.edu> Mon, 22 April 2002 07:20 UTC

Date: Mon, 22 Apr 2002 00:20:06 -0700
From: Neil Spring <nspring@cs.washington.edu>
To: tcp-impl@grc.nasa.gov
Subject: Re: Simultaneous Open - Reg
Message-ID: <20020422071954.GA8098@cs.washington.edu>
References: <00ec01c1e9b8$52938b60$fc0f10ac@roc.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <00ec01c1e9b8$52938b60$fc0f10ac@roc.com>
User-Agent: Mutt/1.3.28i
Sender: owner-tcp-impl@grc.nasa.gov
Precedence: bulk
Status: RO
Content-Length: 984
Lines: 23

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