How can I get >100 connections in FIN_WAIT_2 state from the same IP?

[Jeff Laine]

On Tue,13-10-2009 [17:50:00], Michael Powell wrote:
> Chuck Swiger wrote:
> 
> > On Oct 13, 2009, at 10:33 AM, Martin Turgeon wrote:
> >> I would like to know if anyone knows the reason why I get a lot of
> >> connections (more than 100) from the same IP in FIN_WAIT_2 state.
> > 
> > That IP is probably running a web proxy or possibly some kind of
> > spider.  It could also be malicious, trying to exploit webserver
> > vulnerabilities, etc-- search your logs for that IP and see what it is
> > doing.
> > 
> >> In this case the connections are on port 80. Is it a problem with the
> >> client's browser or OS? Is it possible that some mobile devices
> >> doesn't
> >> close their connections correctly to save bandwidth and battery?
> > 
> > Yes, it's not uncommon for various platforms to simply drop
> > connections rather than closing them properly.  You can run tcpdrop to
> > forcibly get rid of them, but they should time out within a few
> > minutes anyway.  If you believe the remote IP is being abusive,
> > consider firewalling it....
> > 
> 
> This is also common from the differences in TCP/IP stacks across various 
> platforms. Windows, Linux, Solaris, etc are all slightly different in this 
> regard.
> 
> If you're running a web server you can set the following in /etc/sysctl.conf 
> in an attempt to mitigate. Don't know if the timeout period can be altered.
> 
> net.inet.tcp.fast_finwait2_recycle=1
> 
> This won't stop it from happening but it will trim the pool down some.


Hi,

maybe you'll find this info useful as well:


>From man pf.conf:


[...]
 Options
           tcp.finwait
                 The state after both FINs have been exchanged and the connec-
                 tion is closed.  Some hosts (notably web servers on Solaris)
                 send TCP packets even after closing the connection.  Increas-
                 ing tcp.finwait (and possibly tcp.closing) can prevent block-
                 ing of such packets.
[...]


It looks like  this pf tunable has a 45s default value:

#pfctl -st
[...]

tcp.finwait                  45s

[...]

Setting pf optimization to 'aggressive' changes it to 30s value.




-- 
Best regards,
Jeff

| "Nobody wants to say how this works.	|
|  Maybe nobody knows ..."		|
|  			Xorg.conf(5)	|