FIN_WAIT_[1,2] and LAST_ACK

[Richard Wendland]

> 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 <mss 1460,nop,wscale 0,nop,nop,timestamp 1325730099 0> (DF)
20:57:27.114442 novell.80 > fbsd.4613: S 4258048106:4258048106(0) ack 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
-- 
Richard Wendland				richard at wendland.org.uk