TCP bug?

[Harti Brandt]

Hi all,

one of my TCP test cases breaks in what one could call an edge case:

When the TCP is in SYN-SENT state (the user has called connect()) and the
peer answers with an almost-lamp test packet which has SYN, FIN, ACK and
data larger than the window, TCP ACKs a window full of data, drops the
rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to
me. When dropping the data that is outside the window, it should also drop
the FIN.

The problem seems to be very old - I found it alread in rev. 1.1
of tcp_input.c. In -CURRENT it is on line 2590: when the sequence number
of the incoming segment is the next expected one, the reassembly queue is
empty and we are in an established state, the segment data is added to the
socket buffer and all TCP header flags are cleared except for TH_FIN.
Unfortunately here the original header flags are taken instead of the
cached version in thflags. Earlier in the processing the out-of-window
data and the FIN in thflags were chopped off and now TH_FIN reappears.

The fix should be easy: instead of using the original flag byte to get the
FIN use the cached copy.

Index: tcp_input.c
===================================================================
--- tcp_input.c	(revision 194499)
+++ tcp_input.c	(working copy)
@@ -2587,7 +2587,7 @@
     			else
     				tp->t_flags |= TF_ACKNOW;
     			tp->rcv_nxt += tlen;
-			thflags = th->th_flags & TH_FIN;
+			thflags &= TH_FIN;
     			TCPSTAT_INC(tcps_rcvpack);
     			TCPSTAT_ADD(tcps_rcvbyte, tlen);
     			ND6_HINT(tp);

I wonder, though, why the code is as it is, i.e. why it takes the original
FIN flag. Any idea?

harti