Subject: FIN_WAIT_1
To: None <>
From: Wolfgang Rupprecht <>
List: tech-net
Date: 01/31/1999 16:19:16
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 <>
Get DGPS signals over IP.