From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 19:55:36 2009 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CD9251065670 for ; Fri, 19 Jun 2009 19:55:36 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from smtp171.dfw.emailsrvr.com (smtp171.dfw.emailsrvr.com [67.192.241.171]) by mx1.freebsd.org (Postfix) with ESMTP id A21108FC08 for ; Fri, 19 Jun 2009 19:55:36 +0000 (UTC) (envelope-from kfl@xiplink.com) Received: from relay7.relay.dfw.mlsrvr.com (localhost [127.0.0.1]) by relay7.relay.dfw.mlsrvr.com (SMTP Server) with ESMTP id DB0D3CE4ECA for ; Fri, 19 Jun 2009 15:37:51 -0400 (EDT) Received: by relay7.relay.dfw.mlsrvr.com (Authenticated sender: kfodil-lemelin-AT-xiplink.com) with ESMTPSA id 63005CE5170; Fri, 19 Jun 2009 15:37:51 -0400 (EDT) Message-ID: <4A3BE910.6080502@xiplink.com> Date: Fri, 19 Jun 2009 15:37:52 -0400 From: Karim Fodil-Lemelin User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Harti Brandt References: <20090619194608.W697@beagle.kn.op.dlr.de> In-Reply-To: <20090619194608.W697@beagle.kn.op.dlr.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: net@freebsd.org Subject: Re: TCP bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 19:55:37 -0000 Hi There, 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? Cheers, Karim. 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 > 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 > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"