From owner-freebsd-net@FreeBSD.ORG Tue Apr 6 15:55:59 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 7D8A916A4CE; Tue, 6 Apr 2004 15:55:59 -0700 (PDT) Received: from starburst.demon.co.uk (adsl-02-198.abel.net.uk [193.109.51.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3761743D66; Tue, 6 Apr 2004 15:55:58 -0700 (PDT) (envelope-from richard@starburst.demon.co.uk) Received: (from richard@localhost) by starburst.demon.co.uk (8.8.7/8.8.7) id XAA14667; Tue, 6 Apr 2004 23:56:54 +0100 From: Richard Wendland Message-Id: <200404062256.XAA14667@starburst.demon.co.uk> To: berhart@ErhartGroup.COM (Brandon Erhart) Date: Tue, 6 Apr 2004 23:56:53 +0100 (BST) In-Reply-To: <6.0.2.0.2.20040405180951.01c8d898@mx1.erhartgroup.com> from "Brandon Erhart" at Apr 05, 2004 06:11:41 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org cc: Andre Oppermann Subject: Re: FIN_WAIT_[1,2] and LAST_ACK X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: richard@wendland.org.uk List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2004 22:55:59 -0000 > They are not timing out after 2MSL. I set my MSL to the lowest possible > setting (10) as to make TIME_WAIT connections disappear. The 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 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 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 think), by connecting and closing immediately without sending a method request. This seems to confuse the web server thread, and it doesn't respond 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 32768 (DF) 20:57:27.114442 novell.80 > fbsd.4613: S 4258048106:4258048106(0) ack 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 -- Richard Wendland richard@wendland.org.uk