Re: FIN_WAIT_[1,2] and LAST_ACK

From: Rene de Vries (rene+fbsd_at_canyon.xs4all.nl)
Date: 04/14/04

  • Next message: Mónica Domingues: "pim6sd Installation" 
    Date: Wed, 14 Apr 2004 17:52:25 +0200
To: Brandon Erhart <berhart@ErhartGroup.COM>

    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@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"
    > 

    -- 
René de Vries <rene@tunix.nl>
Tunix Internet Security & Training
_______________________________________________
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"
  • Next message: Mónica Domingues: "pim6sd Installation"