From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 10:39:51 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 1AD02106564A for ; Sat, 31 Mar 2012 10:39:51 +0000 (UTC) (envelope-from andre@freebsd.org) Received: from c00l3r.networx.ch (c00l3r.networx.ch [62.48.2.2]) by mx1.freebsd.org (Postfix) with ESMTP id 7F1A88FC0C for ; Sat, 31 Mar 2012 10:39:50 +0000 (UTC) Received: (qmail 58524 invoked from network); 31 Mar 2012 10:38:41 -0000 Received: from c00l3r.networx.ch (HELO [127.0.0.1]) ([62.48.2.2]) (envelope-sender ) by c00l3r.networx.ch (qmail-ldap-1.03) with SMTP for ; 31 Mar 2012 10:38:41 -0000 Message-ID: <4F76DEF1.8080600@freebsd.org> Date: Sat, 31 Mar 2012 12:39:45 +0200 From: Andre Oppermann User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Darren Reed References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F76C929.5080400@freebsd.org> <4F76DF39.7080807@freebsd.org> In-Reply-To: <4F76DF39.7080807@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2012 10:39:51 -0000 On 31.03.2012 12:40, Darren Reed wrote: > Darren Reed wrote: >> Andre Oppermann wrote: >>> On 30.03.2012 16:22, Darren Reed wrote: >>>> I've been tracking down some problems with FreeBSD's sending >>>> of TCP packets and seem to have come to the conclusion that >>>> in FreeBSD 8.2-RELEASE, when the system is working with a >>>> TCP connection that has a moderate delay in it, FreeBSD's >>>> TCP ignores the other end telling it that the window size >>>> is now 0 and continues to send data. I suspect that this is >>>> meant to make sense because it is expecting that the ACK >>>> that will open up the window is already in transit. But that >>>> only accounts for the condition where the TCP on FreeBSD can >>>> compute and decide that the remote TCP will have its buffer >>>> full. What I find harder to accept is that when FreeBSD's >>>> TCP receives a TCP packet from the remote end advertising >>>> a window of 0, FreeBSD's response is to send more data and >>>> not a window probe or is that now the expected behaviour? >>>> And whilst you might say "ok" for a packet of data, I'm >>>> somewhat hard pressed to explain why FreeBSD's TCP sends >>>> multiple packets with data in them after receiving a TCP >>>> packet from the other end advertising a zero window size. >>>> >>>> However this causes a problem with firewalls (;_) that are >>>> close to the FreeBSD end because for them, it appears that >>>> FreeBSD is sending data outside of its window. >>>> >>>> Is this a known problem? >>>> If so, has it been fixed in a later version of FreeBSD? >>>> (No, I haven't tested anything other than 8.2) >>> >>> The window update acceptance test is too restrictive. In your case >>> the last updated seq# tracking gets it wrong and prevents the update. >>> >>> The code hasn't changed for a long time and newer versions behave the >>> same. >>> >>> The concept patch below simplifies the logic, better tracks the seq# >>> and is a bit more permissive. >>> >> >> This patch does not apply cleanly against 8.2 (BYTES_THIS_ACK >> is not present in 8.2.) >> >> I'll add in the obvious missing #defines and see how I go. > > This patch does not resolve the problem either. Is there a way to "easily" reproduce the traffic pattern that causes this problem? -- Andre