From owner-freebsd-net Wed Nov 24 7:44: 5 1999 Delivered-To: freebsd-net@freebsd.org Received: from ausmail2.austin.ibm.com (ausmail2.austin.ibm.com [192.35.232.11]) by hub.freebsd.org (Postfix) with ESMTP id E068D152A4 for ; Wed, 24 Nov 1999 07:43:31 -0800 (PST) (envelope-from venkats@austin.ibm.com) Received: from netmail1.austin.ibm.com (netmail1.austin.ibm.com [9.53.250.96]) by ausmail2.austin.ibm.com (8.9.1/8.8.5) with ESMTP id JAA44410 for ; Wed, 24 Nov 1999 09:39:33 -0600 Received: from austin.ibm.com (ambika.austin.ibm.com [9.53.150.77]) by netmail1.austin.ibm.com (8.8.5/8.8.5) with ESMTP id JAA29876; Wed, 24 Nov 1999 09:42:44 -0600 Message-ID: <383C0773.21E99C6D@austin.ibm.com> Date: Wed, 24 Nov 1999 09:42:43 -0600 From: venkat venkatsubra Organization: IBM X-Mailer: Mozilla 4.61 [en] (X11; U; AIX 4.3) X-Accept-Language: en MIME-Version: 1.0 To: jayanth Cc: freebsd-net@FreeBSD.ORG Subject: Re: peculiar tcp behavior References: <383B2F08.5B2B4D38@yahoo-inc.com> Content-Type: multipart/mixed; boundary="------------83BAB6521073EDFB9822F331" Sender: owner-freebsd-net@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------83BAB6521073EDFB9822F331 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit jayanth wrote: > hi, > I have a tcpdump below. If a Reset segment is received that is greater > than "last_ack_sent" the FreeBSD 2.2.8 tcpip stack does not process the > segment and drop the connection. Is the sender(a.b.c.d) of the Reset > wrong in > sending a Reset that is within the window but greater than our > "last_ack_sent "? > Since the connection is not dropped the x.y.z.w host has retransmit > timeouts. > What is the correct behavior ? > > tcpdump > -------- > 13:54:45.130913 a.b.c.d.1038 > x.y.z.w.http: S 2478243840:2478243840(0) > win 2048 (DF) > 13:54:45.130969 x.y.z.w.http > a.b.c.d.1038: S 876676280:876676280(0) > ack 2478243841 win 17520 (DF) > 13:54:45.131869 a.b.c.d.1038 > x.y.z.w.http: P 1:78(77) ack 1 win 2048 > (DF) > 13:54:45.161755 x.y.z.w.http > a.b.c.d.1038: . ack 78 win 17520 (DF) > 13:54:45.352783 x.y.z.w.http > a.b.c.d.1038: P 1:210(209) ack 78 win > 17520 (DF) > 13:54:45.353055 x.y.z.w.http > a.b.c.d.1038: F 210:210(0) ack 78 win > 17520 (DF) > > ???????????? > 13:54:45.353119 a.b.c.d.1038 > x.y.z.w.http: R 2478261437:2478261437(0) > > ^^^^^^^^^^^^^^^^^^^^^ > win 1 (DF) > ??????????? > > 13:54:46.561619 x.y.z.w.http > a.b.c.d.1038: FP 1:210(209) ack 78 win > 17520 (DF) > 13:54:49.561403 x.y.z.w.http > a.b.c.d.1038: FP 1:210(209) ack 78 win > 17520 (DF) > 13:54:55.560988 x.y.z.w.http > a.b.c.d.1038: FP 1:210(209) ack 78 win > 17520 (DF) > .................. > > thanks > jayanth > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-net" in the body of the message --------------83BAB6521073EDFB9822F331 Content-Type: text/plain; charset=us-ascii; name="xx1" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="xx1" Jayanth, Looking at RFC 793, the RST from a.b.c.d seems a valid RST since it is within the window. I haven't seen the freebsd code lately, but i recall that they had added the code from Page 960 of TCP/IP Illustrated Vol.2 long time back. That introduces a problem where a RST to a previous incarnation of the same connection could get accepted by the current connection and get terminated. Is the check about 'last_ack_sent' as you mentioned is to fix that problem ? By the way, doesn't RST mostly take the ACK number of the received segment for the sequence number ? In that case checking with last_ack_sent will work. But what if the RST is generated due to retransmission timer connection timeout or the linger period has expired SO_LINGER), etc. and some of the packets ahead were dropped ? Then the sequence number in RST segment and the last_ack_sent won't match. What platform is a.b.c.d that generates the RST with the sequence number set to the right edge of the window ? Venkat --------------83BAB6521073EDFB9822F331-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message