[tcpm] Sequence number checking for incoming RST segments

"Indraneel Ghosh" <ighosh@Brocade.COM> Sun, 23 October 2005 13:51 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETgFk-0001qr-Ll; Sun, 23 Oct 2005 09:51:12 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ETgFj-0001qj-Ts; Sun, 23 Oct 2005 09:51:11 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05482; Sun, 23 Oct 2005 09:50:59 -0400 (EDT)
Received: from f112.brocade.com ([] helo=blasphemy.brocade.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ETgSH-0002FT-E9; Sun, 23 Oct 2005 10:04:10 -0400
Received: from hq-e2k3-1.corp.brocade.com (hq-e2k3-1 []) by blasphemy.brocade.com (Postfix) with ESMTP id 581E8142C7; Sun, 23 Oct 2005 06:50:54 -0700 (PDT)
Received: from hq-ex-6.corp.brocade.com ([]) by hq-e2k3-1.corp.brocade.com with Microsoft SMTPSVC(5.0.2195.6713); Sun, 23 Oct 2005 06:50:54 -0700
x-mimeole: Produced By Microsoft Exchange V6.0.6487.1
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 23 Oct 2005 06:50:53 -0700
Message-ID: <447BB19E14004A4388CB9A864D2BA7630DB0FB@hq-ex-6.brocade.com>
Thread-Topic: [tcpm] a different scheme for reacting to spurious RTOs
Thread-Index: AcXVZ6JRUuw9jOOQTFqwq3wB5nxqtQCb9Ycg
From: Indraneel Ghosh <ighosh@Brocade.COM>
To: tcpm@ietf.org
X-OriginalArrivalTime: 23 Oct 2005 13:50:54.0233 (UTC) FILETIME=[C96F0090:01C5D7D8]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c1c65599517f9ac32519d043c37c5336
Content-Transfer-Encoding: quoted-printable
Cc: tcpm-bounces@ietf.org, Indraneel Ghosh <ighosh@Brocade.COM>
Subject: [tcpm] Sequence number checking for incoming RST segments
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Sender: tcpm-bounces@ietf.org
Errors-To: tcpm-bounces@ietf.org


 I had a question regarding the sequence-number check for acceptance of incoming RST segments. It seems that some TCP stacks (e.g. the Linux stack shown below) apply a different sequence number check to RST segments, than what is specified in RFC793 i.e. the {RCV.NXT, RCV.NXT+RCV.WND} check 

 If someone is familiar with this, could you pls send me an email mentioning what RCV.WUP means exactly (I was guessing that it was the last ACK sent by the local i.e. receiving device).
 Also, what is the commonly-accepted sequence-number check for incoming RST segments, in case the check in RFC793 is seen as inappropriate for RST segments (is there any RFC/other-doc that discusses this) ?

 Sorry for asking this question here, in case this is not the appropriate forum.

 Thanks in advance for any help,



/* Check segment sequence number for validity.
 * Segment controls are considered valid, if the segment
 * fits to the window after truncation to the window. Acceptability
 * of data (and SYN, FIN, of course) is checked separately.
 * See tcp_data_queue(), for example.
 * Also, controls (RST is main one) are accepted using RCV.WUP instead
 * of RCV.NXT. Peer still did not advance his SND.UNA when we
 * delayed ACK, so that hisSND.UNA<=ourRCV.WUP.
 * (borrowed from freebsd)

static inline int tcp_sequence(struct tcp_opt *tp, u32 seq, u32 end_seq)
	return	!before(end_seq, tp->rcv_wup) &&
		!after(seq, tp->rcv_nxt + tcp_receive_window(tp));

tcpm mailing list