On May 29, 2008, at 8:55 PM, Matthew Dillon wrote:
It's got to a be a bug on the client(s) in question. I can't think
of anything else. You may have to resort to injecting a TCP RST
packet (e.g. via a TUN device) to clear the connections.
That would be most unpleasant... and also seems like some sort of
exploit if a client and run a server out of socket buffers so easily.
On a side note, I may be onto something... The server traffic right
now is calming down, but it picks up... I made a change to the IPFW
rules which basically went from something like:
100 permit tcp from any to any established
200 permit tcp from any to me 80 setup
300 deny log ip from any to me
to:
100 check-state
150 deny tcp from any to any established
200 permit tcp from any to me 80 setup keep-state
300 deny log ip from any to me
While the traffic is lower now, I don't see the FIN_WAIT_1's going up
like I did before. At least I'm not going to count my chickens before
they hatch. I'm going to watch this over the next 24 hours and see
what comes up. Unfortunately if it doesn't end up being part of the
solution I may have to resort to running some flavor of Linux 2.6
(*sob*).
--
Robert Blayzor, BOFH
INOC, LLC
[EMAIL PROTECTED]
http://www.inoc.net/~rblayzor/
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"