FIN_WAIT_[1,2] and LAST_ACK

Eli Dart dart at nersc.gov
Mon Apr 5 13:10:56 PDT 2004


In reply to Brandon Erhart <berhart at ErhartGroup.COM> :

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


I understand that -- I was trying to discover if you'd come across 
something that needed a more general fix (see note from Mike 
Silbersack).  If your application can't wait for whatever the 
standard timeout is, that's fine -- you've got your fix, and you're 
good to go.  However, if there is a problem with connections hanging 
out forever in the process of closing, that something that might be 
good to look at independently.

So, do you remember how long the "problem connections" were sticking 
around in FIN_WAIT_? or LAST_ACK?  Are we talking seconds, minutes, 
hours, days?

Thanks,
		--eli


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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 224 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-net/attachments/20040405/d7045ed5/attachment.bin


More information about the freebsd-net mailing list