adnan@sgtech.UUCP (Adnan Yaqub) (12/05/89)
When closing a connection which is busy sending data, Interactive's
386ix TCP (version 1.1.2) doesn't seem to send a FIN. For example, if
I telnet into a 386ix box and start a loop echoing data and then
escape back to my telnet client and issue a disconnect, the responding
FIN from the 386ix is never sent. I see something like this on the
network analyzer:
386ix telnet client comments
----- ------------- --------
data ->
<- ack (window = 0) I have escaped back to client.
data -> This is a window probe.
<- ack, FIN I disconnect.
ack -> My FIN is acked.
data -> Last gasp of data.
<- ack I ack it, no more traffic.
Now, this seems to me to be a bug in the 386ix TCP/IP code. Any
ideas?
A related topic is how should TCP recover from this situation. The
specification says nothing about starting a timer when the FIN is
sent. I did find this code in the Berkeley implementation:
/*
* In FIN_WAIT_1 STATE in addition to the processing
* for the ESTABLISHED state if our FIN is now acknowledged
* then enter FIN_WAIT_2.
*/
case TCPS_FIN_WAIT_1:
if (ourfinisacked) {
/*
* If we can't receive any more
* data, then closing user can proceed.
* Starting the timer is contrary to the
* specification, but if we don't get a FIN
* we'll hang forever.
*/
if (so->so_state & SS_CANTRCVMORE) {
soisdisconnected(so);
tp->t_timer[TCPT_2MSL] = tcp_maxidle;
}
tp->t_state = TCPS_FIN_WAIT_2;
}
break;
Is this the preferred method of dealing with this problem?
--
Adnan Yaqub
Star Gate Technologies, 29300 Aurora Rd., Solon, OH, USA, +1 216 349 1860
...cwjcc!ncoast!sgtech!adnan ...uunet!abvax!sgtech!adnan