Date: Fri, 1 Nov 1996 01:40:02 -0800 (PST) From: David Greenman <dg@root.com> To: freebsd-bugs Subject: Re: kern/1940: TCP doesn't time out of FIN_WAIT_1 and floods packets. Message-ID: <199611010940.BAA13040@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: David Greenman <dg@root.com> To: peter@spinner.DIALix.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 01:35:02 -0800 >I am not sure of the sequence of events that lead to this getting in this >state, but it was running this sequence of packets, even after squid had >closed the connection (and even after having been killed): > >peter@fermi[8:27am]/home/squid-125# tcpdump -s 1500 -N >tcpdump: listening on ed0 >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) >08:28:26.426922 kaos.http > fermi.29485: . ack 1 win 9112 (DF) >08:28:26.427038 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 <nop,nop,timestamp 371690 324020,nop,nop,cc 21426> (DF) >08:28:26.435747 kaos.http > fermi.29485: . ack 1 win 9112 (DF) >08:28:26.435877 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 <nop,nop,timestamp 371690 324020,nop,nop,cc 21426> (DF) >08:28:26.445638 kaos.http > fermi.29485: . ack 1 win 9112 (DF) >08:28:26.445750 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 <nop,nop,timestamp 371690 324020,nop,nop,cc 21426> (DF) >08:28:26.454399 kaos.http > fermi.29485: . ack 1 win 9112 (DF) >08:28:26.454548 fermi.29485 > kaos.http: F 0:0(0) ack 4294967090 win 17280 <nop,nop,timestamp 371690 324020,nop,nop,cc 21426> (DF) >[...] > >I presume this is a half-close, what is meant to happen here? > >>How-To-Repeat: > >Unknown, but I hope it doesn't.. :-] > >>Fix: > >It seems that the tcp connection managed to get into a state where both >ends were out of sync. I don't know my tcp states well enough to >understand what is meant to happen here, but hanging in FIN_WAIT_1 forever >doesn't seem nice. 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 David Greenman Core-team/Principal Architect, The FreeBSD Project
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199611010940.BAA13040>