From owner-freebsd-net@FreeBSD.ORG Fri Jun 19 21:56:39 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 BD294106566C; Fri, 19 Jun 2009 21:56:39 +0000 (UTC) (envelope-from cswiger@mac.com) Received: from asmtpout012.mac.com (asmtpout012.mac.com [17.148.16.87]) by mx1.freebsd.org (Postfix) with ESMTP id A7C9C8FC12; Fri, 19 Jun 2009 21:56:39 +0000 (UTC) (envelope-from cswiger@mac.com) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Received: from cswiger1.apple.com ([17.227.140.124]) by asmtp012.mac.com (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTPSA id <0KLI001HLAAEQS30@asmtp012.mac.com>; Fri, 19 Jun 2009 14:56:39 -0700 (PDT) Message-id: <670B545A-71FD-4591-B466-96B0B8BA046B@mac.com> From: Chuck Swiger To: Harti Brandt In-reply-to: <20090619220901.Y970@beagle.kn.op.dlr.de> Date: Fri, 19 Jun 2009 14:56:38 -0700 References: <20090619191756.R581@beagle.kn.op.dlr.de> <82A6C509-6141-4226-B145-1DE6801256B1@mac.com> <20090619220901.Y970@beagle.kn.op.dlr.de> X-Mailer: Apple Mail (2.935.3) Cc: "freebsd-net@freebsd.org Net" 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 21:56:40 -0000 Hi-- On Jun 19, 2009, at 1:15 PM, Harti Brandt wrote: > 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. Well, perhaps you're right that it would be drastic. I'll agree that the start of the segment falls within the window, at least if the window size is greater than 0. If you decide that the incoming segment is "possibly valid", then the conclusion that you should move to ESTABLISHED, accept and ACK the data which lies within the valid window, and drop/ignore the rest including the FIN seems to be a sensible consequence. Moving to CLOSE_WAIT state is not appropriate until you actually accept and process the sequence # which includes that FIN. > 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. If the window size is 0, only acks without any data are acceptable, but your test case seems to have a non-0 initial window size, so we don't need to belabor that point too much. -- -Chuck