From owner-freebsd-stable@FreeBSD.ORG Fri May 30 14:42:41 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 378F81065678 for ; Fri, 30 May 2008 14:42:41 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by mx1.freebsd.org (Postfix) with ESMTP id CCED68FC0C for ; Fri, 30 May 2008 14:42:40 +0000 (UTC) (envelope-from max@love2party.net) Received: from vampire.homelinux.org (dslb-088-064-185-208.pools.arcor-ip.net [88.64.185.208]) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis) id 0MKxQS-1K25cK0soF-0007bc; Fri, 30 May 2008 16:30:04 +0200 Received: (qmail 64836 invoked from network); 30 May 2008 14:28:12 -0000 Received: from myhost.laiers.local (192.168.4.151) by router.laiers.local with SMTP; 30 May 2008 14:28:12 -0000 From: Max Laier Organization: FreeBSD To: freebsd-stable@freebsd.org Date: Fri, 30 May 2008 16:29:54 +0200 User-Agent: KMail/1.9.9 References: <483EA513.4070409@earthlink.net> <20080530084724.GA37672@walton.maths.tcd.ie> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200805301629.54542.max@love2party.net> X-Provags-ID: V01U2FsdGVkX1/BsmQlJw6bAh8GHwF4icsgEWFXEtec9QQnBRV wn/RAig39CTFRk5mqusBDzewefSzfdwutN3AkVJXZaCC5VTPVw YlpFytA0beqm8cKosEcTQ== Cc: David Malone , Robert Blayzor Subject: Re: Sockets stuck in FIN_WAIT_1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 May 2008 14:42:41 -0000 On Friday 30 May 2008 11:35:56 Robert Blayzor wrote: > On May 30, 2008, at 4:47 AM, David Malone wrote: > > There has been some talk about this sort of problem on the IETF TCP > > Maintainers list. I don't think any good conclusion was reached - > > whatever the solution was certainly needs to be tunable per-socket > > because this behaviour is perfectly valid in some situations but a > > bit of a pain in others. > > A timeout value would be fine. Obviously if the client keeps sending > back packets with a 0 size, there should be some option or work around > to tell the stack to drop the connection. There than to have the > server lock up resources on a "dead connection". Unfortunately we're > talking about the internet here, we can't insure that every one of the > clients connecting to our servers behaves correctly! ;-) > > On a side note, I could easily fix this problem by frontending the > server with a Cisco PIX or ASA. I believe they have "half closed" > timers just for this purpose... Perhaps a kernel tunable knob would be > a nice option/fix/hack also. pf does that, too. -- /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News