Subject: Re: FIN_WAIT_1
To: Wolfgang Rupprecht <firstname.lastname@example.org>
From: Michael Graff <email@example.com>
Date: 01/31/1999 23:40:14
What version of NetBSD? 1.3.1 and lower had problems with this, I
believe, but either 1.3.2 or 1.3.3 fixed it.
Wolfgang Rupprecht <firstname.lastname@example.org> writes:
> Ever since I started offering dgps correction signals over the net
> I've been seeing quite a few persistent FIN_WAIT_1's. In some cases
> they stayed in this state for hours.
> tcp 0 15488 capsicum.rtcm-sc1 XXX.XXX.XXX..1051 FIN_WAIT_1
> In this case I know that the remote side is a M$ machine. I suspect
> that the connection was broken via the "three-finger-salute", and
> possibly a disconnect from the net, although I don't know that for
> Now I do understand that the RFC's want one to stay in FIN_WAIT_1 till
> the cows come home. This doesn't really seem workable in a world
> where the other side goes off the network for an extended period of
> In the same spirit that keep-alives will clean up long-term breakage,
> would it be terribly offensive to folks RFC ethics if FIN_WAIT_1 had
> an optional sysconfigurable long-term timeout too?
> Wolfgang Rupprecht <email@example.com>
> Get DGPS signals over IP. http://www.wsrcc.com/wolfgang/gps/dgps-ip.html