Re: Sockets stuck in FIN_WAIT_1

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

_______________________________________________
freebsd-stable@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: jailed "system" needs IPV4 access
    ... see if the ACK flag is set on a tcp packet. ... the keep-state option just ... 00500 deny log ip from 192.160.1.0/24 to any in via dc1 ...
    (comp.unix.bsd.freebsd.misc)
  • Re: ipchains log
    ... >explain that the packet was DENYed on interface ppp0. ... >in the TCP header; mostly you can ignore them, ... Source IP of 216.190.255.225 is broadcast address but protocol is not ... Rejected boxes respond ICMP to 62.212.97.194. ...
    (comp.os.linux.security)
  • Re: can I use keep-state for icmp rules?
    ... The flags in TCP packets can affect ... 'established' matches packet with ACK flag set ... Establishing TCP connection involves the following handshake procedure: ... The problem with ICMP is that there's no 'state'; ...
    (FreeBSD-Security)
  • Re: Trouble with Net::Ping
    ... IIRC TCP lives on top of UDP (and thus it makes sense that UDP would ... ICMP although it is more tightly coupled to IP. ... That's a different protocol then HTTP. ... The ping command uses ICMP. ...
    (comp.lang.perl.misc)
  • Re: Trouble with Net::Ping
    ... IIRC TCP lives on top of UDP (and thus it makes sense that UDP would ... ICMP although it is more tightly coupled to IP. ... That's a different protocol then HTTP. ... connection has timed out but that the requested data is still being ...
    (comp.lang.perl.misc)