From owner-freebsd-net@FreeBSD.ORG Wed Apr 14 08:52:27 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA32E16A4CE for ; Wed, 14 Apr 2004 08:52:27 -0700 (PDT) Received: from smtp-out4.xs4all.nl (smtp-out4.xs4all.nl [194.109.24.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 19FD743D4C for ; Wed, 14 Apr 2004 08:52:27 -0700 (PDT) (envelope-from rene+fbsd@canyon.xs4all.nl) Received: from zion.canyon.xs4all.nl (canyon.xs4all.nl [80.126.75.53]) by smtp-out4.xs4all.nl (8.12.10/8.12.10) with ESMTP id i3EFqNCY036181; Wed, 14 Apr 2004 17:52:23 +0200 (CEST) Received: from zion.canyon.xs4all.nl (localhost [127.0.0.1]) by localhost.canyon.xs4all.nl (Postfix) with ESMTP id 42AF88432; Wed, 14 Apr 2004 17:52:19 +0200 (CEST) Received: from [IPv6:2001:888:181b:1:230:65ff:fe1e:e03d] (meandrix.canyon.xs4all.nl [IPv6:2001:888:181b:1:230:65ff:fe1e:e03d]) by zion.canyon.xs4all.nl (Postfix) with ESMTP id 04CA98430; Wed, 14 Apr 2004 17:52:18 +0200 (CEST) In-Reply-To: <200404062256.XAA14667@starburst.demon.co.uk> References: <200404062256.XAA14667@starburst.demon.co.uk> Mime-Version: 1.0 (Apple Message framework v613) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Rene de Vries Date: Wed, 14 Apr 2004 17:52:25 +0200 To: Brandon Erhart X-Mailer: Apple Mail (2.613) cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2004 15:52:28 -0000 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 (DF) > 20:57:27.114442 novell.80 > fbsd.4613: S 4258048106:4258048106(0) ack=20= > 675591728 win 1460 (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 Tunix Internet Security & Training