Date: Fri, 30 May 2008 16:29:54 +0200 From: Max Laier <max@love2party.net> To: freebsd-stable@freebsd.org Cc: David Malone <dwmalone@maths.tcd.ie>, Robert Blayzor <rblayzor.bulk@inoc.net> Subject: Re: Sockets stuck in FIN_WAIT_1 Message-ID: <200805301629.54542.max@love2party.net> In-Reply-To: <A1459A8E-3615-4C26-A622-AE068B638373@inoc.net> References: <483EA513.4070409@earthlink.net> <20080530084724.GA37672@walton.maths.tcd.ie> <A1459A8E-3615-4C26-A622-AE068B638373@inoc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200805301629.54542.max>