Date: Fri, 1 Nov 1996 02:10:02 -0800 (PST) From: Peter Wemm <peter@spinner.DIALix.COM> To: freebsd-bugs Subject: Re: kern/1940: TCP doesn't time out of FIN_WAIT_1 and floods packets. Message-ID: <199611011010.CAA14999@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611011010.CAA14999>