Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 31 Mar 2012 12:39:45 +0200
From:      Andre Oppermann <andre@freebsd.org>
To:        Darren Reed <darernr@freebsd.org>
Cc:        freebsd-net@freebsd.org
Subject:   Re: FreeBSD TCP ignores zero window size
Message-ID:  <4F76DEF1.8080600@freebsd.org>
In-Reply-To: <4F76DF39.7080807@freebsd.org>
References:  <4F75C1A3.4030401@freebsd.org> <4F75D9ED.7080707@freebsd.org> <4F76C929.5080400@freebsd.org> <4F76DF39.7080807@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F76DEF1.8080600>