From owner-freebsd-net@FreeBSD.ORG Tue Apr 3 15:38:48 2012 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 82733106564A for ; Tue, 3 Apr 2012 15:38:48 +0000 (UTC) (envelope-from darrenr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id 48A898FC0A for ; Tue, 3 Apr 2012 15:38:48 +0000 (UTC) Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A16B621795 for ; Tue, 3 Apr 2012 11:38:47 -0400 (EDT) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute1.internal (MEProxy); Tue, 03 Apr 2012 11:38:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:reply-to :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=jCXgeyaFG/fdwGMUJzmLC8 2z/vE=; b=bZvrjxxHbZkJ+BjWQw5INBtVjttht8TObwHlQVf0xzicJvkn/i/qRH Nykv0uCtehWWde2ccABUrFmH1Xb8iOSk5FxvmgUCY1hiQHGjteIijS26fF/k4cR6 l+LQtgJw3HSw34cAYuMHzzHDE+7LsuBA7dmwR9yrZuW7+YTj2+2yo= X-Sasl-enc: g5Fpsna5nowLPVhjajIxW9pZa8R8RQN7IUhz2KFl1Q1y 1333467527 Received: from [192.168.1.124] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id A105A482590; Tue, 3 Apr 2012 11:38:46 -0400 (EDT) Message-ID: <4F7B1981.1050009@freebsd.org> Date: Wed, 04 Apr 2012 01:38:41 +1000 From: Darren Reed Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-AU; rv:1.9.2.28) Gecko/20120306 Thunderbird/3.1.20 MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F780373.6030107@freebsd.org> <4F7AFEEF.60708@freebsd.org> In-Reply-To: <4F7AFEEF.60708@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org Subject: Re: FreeBSD TCP ignores zero window size X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: darrenr@freebsd.org List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Apr 2012 15:38:48 -0000 On 3/04/2012 11:45 PM, Andre Oppermann wrote: > On 01.04.2012 09:27, Darren Reed wrote: >> Andre, >> >> Your changes bring it closer to working correctly with a >> small change: rather than "tiwin > tp->snd_wnd", it should >> be "tiwin != tp->snd_wnd". In this trace, the remote end >> has set a window scale factor of 5 during connection >> establishment. >> >> The same change should be made in the if() a few lines down. > > Window updates are a tricky thing by that we must not accept > old and outdated segments to update our window. Hence we have > to test for freshness while at the same time be open enough > to handle weird cases like bidirectional data transfers on > lossy links with data waiting in reassembly queues on both > sides. > > There are two clear cut cases we can accept a window update: > > a) the incoming segment ACK'ed new data (moved snd_una). > b) the incoming segment carries new data (moved rcv_nxt). > > The latter gets tricky already with the addition of the > reassembly queue. Here only segments that have a higher SEQ > than highest already present in the reassembly queue are OK. > > And then we have a window probe where we'll get an answer > that neither moves our ACK (zero byte probes) nor carries > any data. Here the window update is vital for the future > progress of the session. Hmmm, what about retransmitted data that fills a response in response to a TCP packet with SACK present? So that would be (b) from above but rcv_nxt does not get moved? So remote sends 4 packets with 1440 data bytes, freebsd82 receives pkts 1, 3 & 4, ACK's 1, uses SACK to repsond to 3 & 4, new data arrives from remote at freebsd82 but with the TCP window set to 0. >> The problem here is that it only tracks the window size as >> it grows, not as it shrinks. Thus the remote end setting its >> window size to 0 is ignored. > > My patch is wrong as the acked count is already integrated > by the time we reach this spot. I'm working on a better > implementation. Ok, I'll look forward to seeing and testing it. > It's the other way around. remote.ssh is sending old data > which freebsd82.62922 has already ack'ed. The sessions seems > to be de-synchronized, perhaps some middle box mucking with > the segments trying to modulate something? I suspect that the ISP is dropping packets and/or applying some other means of throttling the connection. So, yes. Darren