Date: Wed, 14 Oct 2009 02:33:08 +0400 From: Jeff Laine <wtf.jlaine@gmail.com> To: Michael Powell <nightrecon@hotmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: How can I get >100 connections in FIN_WAIT_2 state from the same IP? Message-ID: <20091013223307.GA70023@free.bsd.loc> In-Reply-To: <hb2skn$scs$1@ger.gmane.org> References: <4AD4B9EA.5070304@optiksecurite.com> <B20ABCEA-21D4-47D6-8465-1C82D3F4EAA3@mac.com> <hb2skn$scs$1@ger.gmane.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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) |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20091013223307.GA70023>