From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 20:15:42 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 82AFB106564A for ; Fri, 19 Jun 2009 20:15:42 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp1.dlr.de (smtp1.dlr.de [129.247.252.32]) by mx1.freebsd.org (Postfix) with ESMTP id 171608FC18 for ; Fri, 19 Jun 2009 20:15:41 +0000 (UTC) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.178.136]) by smtp1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 22:15:40 +0200 Date: Fri, 19 Jun 2009 22:15:55 +0200 (CEST) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: Chuck Swiger In-Reply-To: <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> Message-ID: <20090619220901.Y970@beagle.kn.op.dlr.de> References: <20090619191756.R581@beagle.kn.op.dlr.de> <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> X-OpenPGP-Key: harti@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 19 Jun 2009 20:15:40.0729 (UTC) FILETIME=[B786FA90:01C9F11A] Cc: "freebsd-net@freebsd.org Net" Subject: Re: TCP bug? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt 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 20:15:42 -0000 Hi, On Fri, 19 Jun 2009, Chuck Swiger wrote: CS>On Jun 19, 2009, at 10:44 AM, Harti Brandt wrote: CS>> When the TCP is in SYN-SENT state (the user has called connect()) and the CS>> peer answers with an almost-lamp test packet which has SYN, FIN, ACK and CS>> data larger than the window, TCP ACKs a window full of data, drops the CS>> rest, but processes the FIN - it goes into CLOSE_WAIT. This looks wrong to CS>> me. When dropping the data that is outside the window, it should also drop CS>> the FIN. CS> CS>Clearly, you shouldn't process a FIN which happens outside of the current CS>window: "For sequence number purposes, the SYN is considered to occur before CS>the first actual data octet of the segment in which it occurs, while the FIN CS>is considered to occur after the last actual data octet in a segment in which CS>it occurs." CS> CS>If the socket was in a synchronized state, RFC-793 pg 37 says: CS> CS>"3. If the connection is in a synchronized state (ESTABLISHED, CS> FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), CS> any unacceptable segment (out of window sequence number or CS> unacceptible acknowledgment number) must elicit only an empty CS> acknowledgment segment containing the current send-sequence number CS> and an acknowledgment indicating the next sequence number expected CS> to be received, and the connection remains in the same state." CS> CS>...if it's before the connection is fully setup, ie, in SYN-SENT state as you CS>say, then the fact that the packet contains data which does not fit in the CS>window suggests it should be handled by the rules for half-open connections: CS> CS> "As a general rule, reset (RST) must be sent whenever a segment arrives CS> which apparently is not intended for the current connection. A reset CS> must not be sent if it is not clear that this is the case." CS> CS>See figure 12-- I think you should be sending a RST back.... I think this is too drastic. A segment is unacceptable only if it is completly out of the window. Here part is in the window. Also conceptually TCP enters the ESTABLISHED state as soon as it finds that the ACK in the SYN,ACK is correct before it starts to process the data and the FIN (p.68 of RFC793 - first you enter ESTABLISHED and ACK, then you goto step 6). So taking into account the explanation at top of page 70 (which logically belongs to step 6) you just drop everything outside the window - part of the data and the FIN in our case - and proceed. Note, that the data in the SYN,ACK is always partly in the window because this segment contains the IRS, except if the window is 0 and the segment contains data or FIN. harti