From owner-freebsd-hackers  Tue Sep 16 09:07:12 1997
Return-Path: <owner-freebsd-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id JAA02460
          for hackers-outgoing; Tue, 16 Sep 1997 09:07:12 -0700 (PDT)
Received: from alpha.xerox.com (alpha.Xerox.COM [13.1.64.93])
          by hub.freebsd.org (8.8.7/8.8.7) with SMTP id JAA02455
          for <freebsd-hackers@freebsd.org>; Tue, 16 Sep 1997 09:07:08 -0700 (PDT)
Received: from crevenia.parc.xerox.com ([13.2.116.11]) by alpha.xerox.com with SMTP id <52290(5)>; Tue, 16 Sep 1997 09:06:36 PDT
Received: from localhost by crevenia.parc.xerox.com with SMTP id <177486>; Tue, 16 Sep 1997 09:06:25 -0700
To: joerg_wunsch@interface-business.de (Joerg Wunsch)
cc: freebsd-hackers@freebsd.org (FreeBSD hackers)
Subject: Re: Any TCP expert around? 
In-reply-to: Your message of "Tue, 16 Sep 97 07:35:25 PDT."
             <19970916163525.KH02502@ida.interface-business.de> 
Date: Tue, 16 Sep 1997 09:06:24 PDT
From: Bill Fenner <fenner@parc.xerox.com>
Message-Id: <97Sep16.090625pdt.177486@crevenia.parc.xerox.com>
Sender: owner-freebsd-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

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