kfl at xiplink.com
Fri Jun 19 19:55:37 UTC 2009
Looking at Steven's book TCP/IP Volume 2 (1995 edition) page 988
(Processing and Received Data) they call TCP_REASS(tp, ti, m, so,
tiflags) where tiflags is thflags and inside the TCP_REASS macro (page
908), this code is used (where ti is the tcpiphdr pointer):
flags = (ti)->ti_flags & TH_FIN; \
Same problem there as well ...
Also, looking at tcp_reass(), the same approach of using the header
version is used there:
flags = q->tqe_th->th_flags & TH_FIN;
This seems to work since the data was kept inside the reassembly queue
and not dropped
If this problem is confirmed you've probably found an original
implementation bug. Can you describe better the test condition to
reproduce this problem?
Harti Brandt wrote:
> 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
> 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
> 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
> FIN use the cached copy.
> Index: tcp_input.c
> --- tcp_input.c (revision 194499)
> +++ tcp_input.c (working copy)
> @@ -2587,7 +2587,7 @@
> tp->t_flags |= TF_ACKNOW;
> tp->rcv_nxt += tlen;
> - thflags = th->th_flags & TH_FIN;
> + thflags &= TH_FIN;
> TCPSTAT_ADD(tcps_rcvbyte, tlen);
> I wonder, though, why the code is as it is, i.e. why it takes the
> FIN flag. Any idea?
> freebsd-net at freebsd.org mailing list
> To unsubscribe, send any mail to "freebsd-net-unsubscribe at freebsd.org"
More information about the freebsd-net