Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-unix!sri-spam!ames!ucbcad!ucbvax!FALINE.BELLCORE.COM!karn
From: karn@FALINE.BELLCORE.COM (Phil R. Karn)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  FIN_WAIT_2 problem ?
Message-ID: <8706161809.AA26691@faline.bellcore.com>
Date: Tue, 16-Jun-87 14:09:05 EDT
Article-I.D.: faline.8706161809.AA26691
Posted: Tue Jun 16 14:09:05 1987
Date-Received: Sun, 21-Jun-87 09:58:49 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 17

No! FIN_WAIT_2 state is supposed to be a "stable" state in TCP. That is, one
end of the connection may close while the other end may continue to send for
as long as it likes. In this situation, the end that closed first will be
in FIN_WAIT_2 state (assuming its FIN has been ACKed) and the other end will
be in CLOSE_WAIT state.

As for connections getting hung up in LAST_ACK state, this must be a bug
in the TCP implementation (I've noticed it myself on BSD machines). In that
state you are waiting for an ACK to your FIN; since there is "data" (the
FIN is considered to be data for sequence numbering and acknowledgement
purposes) the retransmission timer should be running.  Enough
unsuccessful attempts to get an ACK for the last FIN will eventually cause
TCP to go to the closed state -- if the TCP is working properly.  There
is no need to make incompatible changes to the protocol -- fix the bugs
instead!

Phil