Re: FIN_WAIT_[1,2] and LAST_ACK

From: Richard Wendland (richard_at_starburst.demon.co.uk)
Date: 04/07/04

  • Next message: hugle: "got two GATEWAYS!" 
    To: berhart@ErhartGroup.COM (Brandon Erhart)
Date: Tue, 6 Apr 2004 23:56:53 +0100 (BST)

    > 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"
  • Next message: hugle: "got two GATEWAYS!"

    Relevant Pages

    • Re: The dreadful CLOSE_WAIT
      ... The other end is not there, it has sent us a FIN. ... Thanks, Markus:) ... of connections ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Redhat Enterprise 4 and 15 second delays with NFS via TCP
      ... >Can't send a FIN unless you already have a connection. ... all us NFS server implementors are obvious ... >fools for not doing it :-), it has no connections. ... should do when you get a message related to a connexion that you ...
      (comp.protocols.nfs)
    • Re: TCP tuning
      ... connections, it would be better to go the SO_REUSEADDR route. ... FIN_WAIT_2 is the state where TCP has sent the FIN and gotten the ACK ... If however the client app is stupid and ignored the ...
      (comp.sys.hp.hpux)