FIN_WAIT_[1,2] and LAST_ACK

[Rene de Vries]

Brandon,

Maybe I am missing something, but why not set SO_LINGER to 0 (zero). 
This should have the effect of instantaniously cleaning up after a 
close. With the disadvantage that there will be no FIN but a simple 
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 
>> 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
> _______________________________________________
> freebsd-net at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-net
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
>
-- 
René de Vries <rene at tunix.nl>
Tunix Internet Security & Training