From owner-freebsd-net@FreeBSD.ORG Sat Mar 31 09:40:48 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0563C106566C for ; Sat, 31 Mar 2012 09:40:48 +0000 (UTC) (envelope-from darernr@freebsd.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id C39928FC19 for ; Sat, 31 Mar 2012 09:40:47 +0000 (UTC) Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 1CFA920CC9 for ; Sat, 31 Mar 2012 05:40:47 -0400 (EDT) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute6.internal (MEProxy); Sat, 31 Mar 2012 05:40:47 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=mmlxM3GfSaUNwt4VIua88y f9TfQ=; b=mYiNDSxMRaxyRU6yF+4fZSySIqCFV8JvUGbArqfmQvmtImovEsv+e9 UgNOdyNd4RlHRI0qqijAe4wY8UmgcT1/Pp4yPUOklKz7B5j9IJK12rxsV7Jv1C9G p2k4/j/V+6i1E+LdlaIZidkEN2MBLeo7xEJkuDSRXH26Pp/Szh1S4= X-Sasl-enc: DZ3+yZJfwz5UVOxMY8kCmAWTq/oNjiZgaAO1RYPmrhMA 1333186846 Received: from [192.168.1.23] (dsl-202-45-110-141-static.VIC.netspace.net.au [202.45.110.141]) by mail.messagingengine.com (Postfix) with ESMTPSA id E52568E0192; Sat, 31 Mar 2012 05:40:45 -0400 (EDT) Message-ID: <4F76DF39.7080807@freebsd.org> Date: Sat, 31 Mar 2012 21:40:57 +1100 From: Darren Reed User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Andre Oppermann References: <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F76C929.5080400@freebsd.org> In-Reply-To: <4F76C929.5080400@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 09:40:48 -0000 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. Darren