From owner-freebsd-questions@FreeBSD.ORG Tue Oct 13 22:33:13 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5005106568F for ; Tue, 13 Oct 2009 22:33:12 +0000 (UTC) (envelope-from wtf.jlaine@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 6F5B28FC19 for ; Tue, 13 Oct 2009 22:33:12 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 22so62935fge.13 for ; Tue, 13 Oct 2009 15:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:received:date:from:to:cc :subject:message-id:mail-followup-to:references:mime-version :content-type:content-disposition:in-reply-to:user-agent :x-operating-system; bh=GagDg6kJnWQm2b4JG1y7rh2oe0K5Re02iVlsk3IGO1c=; b=tt2SQYtPrsVqUS84XTTYzYp3EsqlTeyawyUCx4CW4LmVOOSPdrKquoXCnBDDhKXpF7 /EhiYIOXlmMgBFcjlj0l98t2UvdIO7TR7k17VZpiHkoQYX2Cs29Kco3q4phxKUPOfXrg 0mHtC/2A+kI0FimV5tKsZCT7u1Ek6vv99wRrQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-type:content-disposition:in-reply-to :user-agent:x-operating-system; b=BM4/QxOwkuTva9CvsGtxfQVM6hPkkTmbY7Np+SaFzbAlBMF9DGLLPiF3xKz5asXOSA 2HwPBeOGTRGbue3WSMkytBmc3650pEJO9qW2Kaa5VGcwdR1M123kXOpcU6bckhtbdZKb o/wTMpfhHjfc8GbBxODytH8mBbr8RKJWZflMc= Received: by 10.86.228.3 with SMTP id a3mr2486188fgh.51.1255473191527; Tue, 13 Oct 2009 15:33:11 -0700 (PDT) Received: from aperture_lab ([77.66.145.99]) by mx.google.com with ESMTPS id d6sm698836fga.20.2009.10.13.15.33.09 (version=SSLv3 cipher=RC4-MD5); Tue, 13 Oct 2009 15:33:10 -0700 (PDT) Received: by aperture_lab (sSMTP sendmail emulation); Wed, 14 Oct 2009 02:33:08 +0400 Date: Wed, 14 Oct 2009 02:33:08 +0400 From: Jeff Laine To: Michael Powell Message-ID: <20091013223307.GA70023@free.bsd.loc> Mail-Followup-To: Jeff Laine , Michael Powell , freebsd-questions@freebsd.org References: <4AD4B9EA.5070304@optiksecurite.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 8.0-BETA2 i386 Cc: freebsd-questions@freebsd.org Subject: Re: How can I get >100 connections in FIN_WAIT_2 state from the same IP? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Oct 2009 22:33:13 -0000 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) |