From owner-freebsd-questions@FreeBSD.ORG Wed Aug 20 19:42:00 2008 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 793651065673 for ; Wed, 20 Aug 2008 19:42:00 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id 369918FC0C for ; Wed, 20 Aug 2008 19:41:59 +0000 (UTC) (envelope-from freebsd-questions@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KVtZ6-00066T-5x for freebsd-questions@freebsd.org; Wed, 20 Aug 2008 19:41:56 +0000 Received: from pool-141-156-180-91.esr.east.verizon.net ([141.156.180.91]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Aug 2008 19:41:56 +0000 Received: from nightrecon by pool-141-156-180-91.esr.east.verizon.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 20 Aug 2008 19:41:56 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-questions@freebsd.org From: Michael Powell Date: Wed, 20 Aug 2008 15:43:45 -0400 Lines: 38 Message-ID: References: <002501c90262$8e302420$3f83a8c0@neusofteaf5839> <48AB7A6A.7000100@mahan.org> <006c01c9026a$6d7a2480$3e83a8c0@neusofteaf5839> <48AB984C.6010607@mahan.org> <011d01c9027e$c8629ad0$3e83a8c0@neusofteaf5839> <48AC5E80.4000206@mahan.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pool-141-156-180-91.esr.east.verizon.net Sender: news Subject: Re: How to set TCP parameter? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: nightrecon@verizon.net List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2008 19:42:00 -0000 Patrick Mahan wrote: [snip] > > There is no TCP variable in the FreeBSD implementation to change this > (that I know of). There is this: net.inet.tcp.finwait2_timeout: 60000 > I have seen this happen at times when there is a buggy NAT firewall > between you and the > server that causes the FIN from the server to get dropped. If you have > control of both sides, you can do packet traces using tcpdump to see if > the FIN from the server is ever sent or > receive. It is possible that your client is dropping the packet itself. > [snip] IMHO I do not think that manipulating this value via the sysctl is the proper response to the problem. I concur with Patrick's concept that the correct thing to do is locate or eliminate any potential networking problem which may be the cause. If the network path is not actually causing the problem by dropping or mismanaging packets and this is an Apache web server we're talking about I do seem to recall something in the Apache docs about this. http://httpd.apache.org/docs/2.2/misc/perf-tuning.html See the "Lingering Close" section for some historical background, but please note this information is somewhat dated and may not actually be pertinent. In any case, what I do first with a problem like this is fire up Wireshark and/or tcpdump and examine the packets. Many times it is a source of clue as to what to look at next. Just my $.02 here... -Mike