Date: Fri, 30 May 2008 18:11:43 +1000 From: Peter Jeremy <peterjeremy@optushome.com.au> To: Robert Blayzor <rblayzor.bulk@inoc.net> Cc: freebsd-stable@freebsd.org Subject: Re: Sockets stuck in FIN_WAIT_1 Message-ID: <20080530081143.GI1028@server.vk2pj.dyndns.org> In-Reply-To: <CCBAEE3E-35A5-4BF8-A0B7-321272533B62@inoc.net> References: <483E4657.9060906@FreeBSD.org> <483EA513.4070409@earthlink.net> <96AFE8D3-7EAC-4A4A-8EFF-35A5DCEC6426@inoc.net> <483EAED1.2050404@FreeBSD.org> <200805291912.m4TJCG56025525@apollo.backplane.com> <14DA211A-A9C5-483A-8CB9-886E5B19A840@inoc.net> <200805291930.m4TJUeGX025815@apollo.backplane.com> <0C827F66-09CE-476D-86E9-146AB255926B@inoc.net> <200805292132.m4TLWhCv026720@apollo.backplane.com> <CCBAEE3E-35A5-4BF8-A0B7-321272533B62@inoc.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--yudcn1FV7Hsu/q59 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2008-May-29 18:11:56 -0400, Robert Blayzor <rblayzor.bulk@inoc.net> wrot= e: >working. Only way to correct it seems to reboot the server... even under= =20 >RELENG_7_0.... so the upgrade from 4_11 did not fix the problem. Unfortunately, your issue is a bug in the client: The server is trying to send data and the client is continuously reporting that it is still around but can't accept the data right now. The server is behaving perfectly correctly. As a work-around, you could write a cronjob that scans "netstat" and temporarily creates an ipfw 'reset' rule that matches each FIN_WAIT_1 socket (possibly only if data is queued and/or matching packets that advertise a 0 windowsize). This rule would have to preceed any check-state rule. This is a hack but it will save you having to reboot the server. (Create them all with the same rule number and delete that rule number as the first step in the cronjob would handle rule cleanup). A real solution would require more thought. I suspect you need a mechanism similar to the keepalive timer that starts when there is data queued and is reset when (some) data is sent - this would catch your situation but I'm not sure if it's a general solution. I'm not sure if one of the existing TCP timers could be (ab)used to achieve this. --=20 Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. --yudcn1FV7Hsu/q59 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkg/tr8ACgkQ/opHv/APuIcQjQCfSXBGEFmmjlapdvMFO/ffnank UXEAoIoitdipH3k/+0H7aRoFIHJg89l/ =lMGg -----END PGP SIGNATURE----- --yudcn1FV7Hsu/q59--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080530081143.GI1028>