Date: Mon, 05 Apr 2004 13:32:49 -0600 From: Brandon Erhart <berhart@ErhartGroup.COM> To: Eli Dart <dart@nersc.gov> Cc: freebsd-net@freebsd.org Subject: Re: FIN_WAIT_[1,2] and LAST_ACK Message-ID: <6.0.2.0.2.20040405133109.01c755c8@mx1.erhartgroup.com> In-Reply-To: <20040405171756.90E3BF8F2@gemini.nersc.gov> References: <20040405171756.90E3BF8F2@gemini.nersc.gov>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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 > > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?6.0.2.0.2.20040405133109.01c755c8>