FIN_WAIT_[1,2] and LAST_ACK
andre at freebsd.org
Mon Apr 5 15:09:41 PDT 2004
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
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.
> At 11:17 AM 4/5/2004, you wrote:
> >In reply to Brandon Erhart <berhart at 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
> >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 at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net