🚀 go-pugleaf

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.