jdarcy@encore.UUCP (Jeff d'Arcy) (10/12/89)
I came across an interesting TCP bug in our BSD-based OS (we try to stay current with regard to BSD releases), and I was wondering if anyone else has any comments or insight to offer. The problem occurs when a segment with FIN set is received out of order (i.e. some prior packet has not yet arrived). It seems that tcp_input() calls tcp_reass() to put the segment on the TCP reassembly queue, but then the connection is put into CLOSE_WAIT state. This results in the missing segment being dropped when it arrives, among other less drastic side effects (e.g. duplicate FIN processing). Obviously, this loss of data is not a good thing. The problem was fixed quite easily, by "forgetting" that FIN was set until the reassembly queue is emptied, but I'm surprised that it ever existed. By looking at Tahoe and Network Release sources it seems (can't be 100% certain) that the bug would exist in stock distributions also. Has anyone else seen it? Interestingly, the bug first showed up when fingering a remote machine, most commonly when going through a gateway or to a Sun. Even then the symptoms only appeared about 1/6 of the time.