Re: FIN_WAIT_[1,2] and LAST_ACK

From: Brandon Erhart (berhart_at_ErhartGroup.COM)
Date: 04/06/04

  • Next message: B: "Re: SOCK_RAW sockets and IPPROTO_AH" 
    Date: Mon, 05 Apr 2004 18:11:41 -0600
To: Andre Oppermann <andre@freebsd.org>

    Hello,

    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. However, not ALL of
    them stick around for a "long time"(more on this in a sec) -- e.g., after I
    kill my program, and say I've got 6,000 connections sitting in
    FIN_WAIT_[1,2] or LAST_ACK, about a minute afterwards 90% of them have
    disappeared. There seem to be a few stick around for as long as 30 minutes
    or more, and in fact, a few of them stuck around until I rebooted the computer.

    Is this bad? :)

    Brandon

    At 04:09 PM 4/5/2004, you wrote:
    >Brandon Erhart wrote:
    > >
    > > Well, I responded to the group that I had taken one of the fellows advice
    > > posting here, and modified the tcp_usrclosed in netinet/tcp_usrreq.c.
    > >
    > > So all is well -- it gets TCPS_CLOSED state and the tcps_close() function
    > > called on the tuple IMMEDIATELY. It doesn't switch states depending on
    > > which state the connection is currently in. I also made a sysctl variable
    > > for it (to turn the "feature" on or off), and will post the small patch
    > > along w/ some other small changes I have made soon.
    >
    >As far as I am aware (I was looking through and testing the FIN_WAIT states
    >in 5.2 around last christmas) our TCP stack is behaving correctly.
    >
    >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.
    >
    >But I suspect you are just running out of the small space of local ports
    >with your application as I said in the previous email.
    >
    >--
    >Andre
    >
    >
    > > Thanks,
    > >
    > > Brandon
    > >
    > > At 11:17 AM 4/5/2004, you wrote:
    > >
    > > >In reply to Brandon Erhart <berhart@ErhartGroup.COM> :
    > > >
    > > > > Hello everyone,
    > > >
    > > > > However, I have run into a new problem. I am getting a good amount of
    > > > > blocks stuck in FIN_WAIT_1, FIN_WAIT_2 or LAST_ACK that stick
    > around for a
    > > > > long while.
    > > >
    > > >Could you define "long" in this case? Are we talking about 60
    > > >seconds, or 60 minutes? I get the feeling that your requirements
    > > >might make your perception of "long" different from others' notion of
    > > >"long."
    > > >
    > > >The reason I ask is that there was a bug once upon a time that made
    > > >some connections stick in LAST_ACK forever....
    > > >
    > > > --eli
    > > >
    > > >
    > > >
    > >
    > > _______________________________________________
    > > 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"
    >_______________________________________________
    >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"

    _______________________________________________
    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: B: "Re: SOCK_RAW sockets and IPPROTO_AH"

    Relevant Pages

    • Re: *help* error on NGs
      ... Too Many Connections ... You sit and wait "forever" for the highlighted message to appear. ... means is that your NNTP server is swamped, ...
      (sci.electronics.design)
    • Re: FIN_WAIT_[1,2] and LAST_ACK
      ... > setting as to make TIME_WAIT connections disappear. ... capture" TCP connections "forever" by responding with a zero window size. ... It might be interesting to retest one of these stuck connections by hand and ... see whether the remote machine generates a normal response. ...
      (freebsd-net)
    • Re: Transfer of files with a wireless router
      ... > wireless card in the 2nd pc in the next room. ... > wise and no dropped connections beteween the 2 computers. ... > the 2 computers it seems to take forever. ...
      (microsoft.public.windowsxp.hardware)
    • network connections disappearing in my network places
      ... connections disappear in my network places. ... former students has experienced this in the field, ...
      (microsoft.public.win2000.general)