Date: Fri, 30 May 2008 18:41:42 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Robert Blayzor <rblayzor.bulk@inoc.net> Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 Message-ID: <Pine.BSF.3.96.1080530181243.25862A-100000@gaia.nimnet.asn.au> In-Reply-To: <EB975E1A-7995-4214-A2CC-AE2D789B19AB@inoc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 29 May 2008, Robert Blayzor wrote: > 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 I've just rescanned this thread, and noticed that your original ipfw rules (with your later correction including rule 100) were: 00100 allow tcp from any to any established 00200 allow tcp from any to me 80 setup 00200 allow icmp from any to me icmptype 0,3,8,11 00200 deny log ip from any to me Without debating your stateful alternative - either should work fine for TCP applications - this allowed inbound icmp packets for types 0,3,8,11 but no outbound icmp at all (assuming your firewall defaults to deny). I can't help wondering if allowing icmp outbound mightn't help, eg: 00300 allow icmp from me to any icmptype 0,3,8,11 but I know too little about the stack to be sure if TCP needs it, though suppose you'd want to negotiate MTU which needs icmptype 3 outbound .. and your later ruleset appears not to allow any icmp traffic at all. > 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*). I used to see quite a few FIN_WAIT_1 that never went away and built up over months on a 2.2.6 system, but not since, including 4.x systems. cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.1080530181243.25862A-100000>