Date: Wed, 14 Apr 2004 17:52:25 +0200 From: Rene de Vries <rene+fbsd@canyon.xs4all.nl> To: Brandon Erhart <berhart@ErhartGroup.COM> Cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK Message-ID: <B99465F6-8E2B-11D8-B285-00039357FA7A@canyon.xs4all.nl> In-Reply-To: <200404062256.XAA14667@starburst.demon.co.uk> References: <200404062256.XAA14667@starburst.demon.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Brandon, Maybe I am missing something, but why not set SO_LINGER to 0 (zero).=20 This should have the effect of instantaniously cleaning up after a=20 close. With the disadvantage that there will be no FIN but a simple=20 RST. Rene On Apr 7, 2004, at 0:56, Richard Wendland wrote: >> They are not timing out after 2MSL. I set my MSL to the lowest=20 >> possible >> setting (10) as to make TIME_WAIT connections disappear. The=20 >> FIN_WAIT_[1,2] >> and LAST_ACK seem to be sticking around for a while. > >>> Do the FIN_WAIT_1|2 and LAST_ACK time out after 2MSL or do they = stick >>> around forever? If they stick around forever, then there is=20 >>> something >>> broken. > > I see quite a lot of connections `stuck' in FIN_WAIT_2 from talking > to some particular web servers/OSs, and can reproduce the problem. > The FreeBSD stack isn't broken, the far end is just acting strangely. > > In the cases I see it is simply that the remote web-server thread has > become confused or stuck and won't close the TCP connection after my > FreeBSD client has sent a FIN. My connection is stuck in FIN_WAIT_2 > awaiting a FIN from the server to go into CLOSING state, but the far=20= > TCP > (crazily) is sending keepalives about every 10 minutes. > > Essentially the problem is the strange server behaviour; I don't think > much can be done about this particular case in the FreeBSD client with > the socket API. > > FreeBSD has the traditional Berkeley non-standard TCP behaviour of > forcing idle FIN_WAIT_2 connections into the CLOSING state after 11m > 15sec, as described on page 246 of TCP Illus. Vol 1 (by setting the > tcp_timer_2msl timer in "case TCPS_FIN_WAIT_1:" in tcp_input.c and > later calling tcp_close() for idle connections in tcp_timer_2msl()). > The 10 mins keep-alive prevents this from happening. > > NB it doesn't matter that the FreeBSD client process has terminated, > the socket is already closed so process termination does nothing = extra. > > A possible improvement on the traditional Berkeley behaviour would be > to require some actual data transfer rather than simply non-idleness = to > prevent FIN_WAIT_2 being forced into CLOSING state. But I doubt this > problem is serious enough to make such a change. > > I can reproduce this with Novell-HTTP-Server (running on NetWare I=20 > think), > by connecting and closing immediately without sending a method = request. > This seems to confuse the web server thread, and it doesn't respond=20 > with > a FIN as you'd expect. This is probably not the only way to cause = this > confusion, but it serves for reproducing the problem. > > Here's a tcpdump of what happens on FreeBSD 4.9-PRERELEASE: > > 20:57:26.987078 fbsd.4613 > novell.80: S 675591727:675591727(0) win=20 > 32768 <mss 1460,nop,wscale 0,nop,nop,timestamp 1325730099 0> (DF) > 20:57:27.114442 novell.80 > fbsd.4613: S 4258048106:4258048106(0) ack=20= > 675591728 win 1460 <mss 1460,wscale 0,nop> (DF) > 20:57:27.114472 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 20:57:31.396853 fbsd.4613 > novell.80: F 1:1(0) ack 1 win 33580 (DF) > 20:57:31.521313 novell.80 > fbsd.4613: . ack 2 win 6143 (DF) > # novell.80 doesn't respond with a FIN as expected, > # instead sends a keep-alive ever 10 mins: > 21:07:24.883771 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:07:24.883786 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:17:20.404002 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:17:20.404014 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:27:15.357954 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:27:15.357966 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:37:14.357869 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:37:14.357881 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:47:06.875293 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:47:06.875318 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 21:57:02.118544 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 21:57:02.118556 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 22:06:53.237910 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 22:06:53.237930 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 22:16:45.884856 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 22:16:45.884871 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > 22:26:38.595193 novell.80 > fbsd.4613: . 0:1(1) ack 2 win 6143 (DF) > 22:26:38.595206 fbsd.4613 > novell.80: . ack 1 win 33580 (DF) > ... stuck in FIN_WAIT_2, usually until reboot > > Richard > --=20 > Richard Wendland richard@wendland.org.uk > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > --=20 Ren=E9 de Vries <rene@tunix.nl> Tunix Internet Security & Training
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B99465F6-8E2B-11D8-B285-00039357FA7A>