Date: Wed, 24 Nov 1999 09:42:43 -0600 From: venkat venkatsubra <venkats@austin.ibm.com> To: jayanth <jayanth@yahoo-inc.com> Cc: freebsd-net@FreeBSD.ORG Subject: Re: peculiar tcp behavior Message-ID: <383C0773.21E99C6D@austin.ibm.com> References: <383B2F08.5B2B4D38@yahoo-inc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <mss 1460> (DF) > 13:54:45.130969 x.y.z.w.http > a.b.c.d.1038: S 876676280:876676280(0) > ack 2478243841 win 17520 <mss 1460> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?383C0773.21E99C6D>