From owner-freebsd-bugs  Fri Nov  1 02:10:05 1996
Return-Path: owner-bugs
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA15005
          for bugs-outgoing; Fri, 1 Nov 1996 02:10:05 -0800 (PST)
Received: (from gnats@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id CAA14999;
          Fri, 1 Nov 1996 02:10:02 -0800 (PST)
Date: Fri, 1 Nov 1996 02:10:02 -0800 (PST)
Message-Id: <199611011010.CAA14999@freefall.freebsd.org>
To: freebsd-bugs
Cc: 
From: Peter Wemm <peter@spinner.DIALix.COM>
Subject: Re: kern/1940: TCP doesn't time out of FIN_WAIT_1 and floods 
 packets.
Reply-To: Peter Wemm <peter@spinner.DIALix.COM>
Sender: owner-bugs@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

The following reply was made to PR kern/1940; it has been noted by GNATS.

From: Peter Wemm <peter@spinner.DIALix.COM>
To: dg@root.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: kern/1940: TCP doesn't time out of FIN_WAIT_1 and floods 
 packets.
Date: Fri, 01 Nov 1996 18:08:03 +0800

 David Greenman wrote:
 
 > >08:28:26.419290 kaos.http > fermi.29485: . ack 2272139 504 win 9112 (DF)
 > >08:28:26.419459 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 <
     nop,nop,timestamp 371690 324020,nop,nop,cc 21426> (DF)
 [..]
 >   Looking at the sequence number in fermi's ack (being only 206 away from the
 > 32bit boundry), it looks like the sequence number wrapped around and the code
 > didn't deal with it correctly. Just a guess, but this might be a new bug
 > caused by the change of len from signed to unsigned.
 > 
 > -DG
 
 Hmm, isn't that the other way around?  The remote machine is the one with 
 the large sequence number, we're attempting to send a fin and acking at 
 their (2^32 - 206) sequence number..
 
 Interestingly, we're stuck with 366 un-acked bytes in the queue, but that 
 would be relative to our seqence number of 2272139504.  The remote server 
 is firewalled to the hilt, I can't tell what they are running, except that 
 it's something that runs Netscape's Enterprise server version 2.0a (at a 
 guess, NT).
 
 What bothers me is that we kept on trying and didn't time out, even though 
 we didn't seem to get an acceptable ack to our fin.  It's a little hard to 
 see for sure, since tcpdump had made the seq/ack's relative..
 
 Cheers,
 -Peter