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