Date: Tue, 16 Sep 1997 09:06:24 PDT From: Bill Fenner <fenner@parc.xerox.com> To: joerg_wunsch@interface-business.de (Joerg Wunsch) Cc: freebsd-hackers@freebsd.org (FreeBSD hackers) Subject: Re: Any TCP expert around? Message-ID: <97Sep16.090625pdt.177486@crevenia.parc.xerox.com> In-Reply-To: Your message of "Tue, 16 Sep 97 07:35:25 PDT." <19970916163525.KH02502@ida.interface-business.de>
next in thread | previous in thread | raw e-mail | index | archive | help
Your server sends two different SYN/ACK replies back, both with different initial sequence numbers, and then starts sending data with a third different sequence number. FreeBSD ignores the second SYN/ACK because it's outside of the window, and it ignores all of the data packets because they're outside of the window. The reason you're getting the many pairs of FIN-ACK is because FreeBSD discards ACKs whose sequence number is outside the window (tcpdump doesn't print the sequence number of ack-only packets, so this is only a guess) so none of the ACKs of the FIN make it through the checks. If the server can make up its mind about what sequence number space to use, then the connection will look a little more normal. >What makes me a little nervous is the couple of packets sent by the >FreeBSD side at 15:39.54.132386 and 15:39:54.133176. Why are there >two packets? >15:39:54.132386 193.102.86.65.80 > 193.101.57.200.4315: . 2537005611:253700614 > 7(536) ack 302 win 9112 (DF) >15:39:54.133176 193.101.57.200.4315 > 193.102.86.65.80: . ack 2537005611 win 1 > 7280 <nop,nop,timestamp 3642261 3640510,nop,nop,[|tcp]> (DF) >15:40:19.392871 193.101.57.200.4315 > 193.102.86.65.80: F 302:302(0) ack 25370 > 05611 win 17280 <nop,nop,timestamp 3642311 3640510,nop,nop,[|tcp]> (DF) I'm confused - the two packets that you referenced were from different machines. But if you mean why isn't the FIN on the first packet from the client, it's because the packet at .133176 is an ACK-only reply to the out-of-sequence data packet at .132386, and the packet that looks similar but is actually 25 seconds later comes when the client decides to close the connection. I'm not absolutely sure that I think the sequence numbers in the client's ACK's are right - I think it should be ACKing the first byte it expects to get (which I think is 2661360185, not 2537005611). I'll have to look this one up. Bill
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97Sep16.090625pdt.177486>