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 <[EMAIL PROTECTED]> : > > > > > 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 > > > > > > > > _______________________________________________ > [EMAIL PROTECTED] mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "[EMAIL PROTECTED]" _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "[EMAIL PROTECTED]"
