FIN_WAIT_[1,2] and LAST_ACK

[Andre Oppermann]

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