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 <wolfgang@wsrcc.com> 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
> certain.
> 
> 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
> time.
> 
> 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
> -- 
>        Wolfgang Rupprecht <wolfgang+gnus@dailyplanet.wsrcc.com>
> 		    http://www.wsrcc.com/wolfgang/
> Get DGPS signals over IP.  http://www.wsrcc.com/wolfgang/gps/dgps-ip.html