netdev - Re: TCP stack gets into state of continually advertising “silly window” size of 1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5cb85634-1c74-bcd2-3fe2-0e9ef61993b2@gmail.com>
Date:   Fri, 8 Apr 2022 15:44:31 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Erin MacNeil <emacneil@...iper.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: TCP stack gets into state of continually advertising “silly window” size of 1


On 4/7/22 18:10, Erin MacNeil wrote:
>
>
> On 2022-04-07 4:31 p.m., Eric Dumazet wrote:
>> [External Email. Be cautious of content]
>>
>>
>> On 4/7/22 10:57, Erin MacNeil wrote:
>>> In-Reply-To: 
>>> <BY3PR05MB80023CD8700DA1B1F203A975D0E79@...PR05MB8002.namprd05.prod.outlook.com> 
>>>
>>>
>>>> On 4/6/22 10:40, Eric Dumazet wrote:
>>>>> On 4/6/22 07:19, Erin MacNeil wrote:
>>>>> This issue has been observed with the  4.8.28 kernel, I am 
>>>>> wondering if it may be a known issue with an available fix?
>>>>>
> ...
>>>
>>>> Presumably 16k buffers while MTU is 9000 is not correct.
>>>>
>>>> Kernel has some logic to ensure a minimal value, based on standard MTU
>>>> sizes.
>>>>
>>>>
>>>> Have you tried not using setsockopt() SO_RCVBUF & SO_SNDBUF ?
>>> Yes, a temporary workaround for the issue is to increase the value 
>>> of SO_SNDBUF which reduces the likelihood of device A’s receive 
>>> window dropping to 0, and hence device B sending problematic TCP 
>>> window probes.
>>>
>>
>> Not sure how 'temporary' it is.
>>
>> For ABI reason, and the fact that setsockopt() can be performed
>> _before_  the connect() or accept() is done, thus before knowing MTU
>> size, we can not after the MTU is known increase buffers, as it might
>>
>> break some applications expecting getsockopt() to return a stable value
>> (if a prior setsockopt() has set a value)
>>
>> If we chose to increase minimal limits, I think some users might 
>> complain.
>>
>
> Is this not a TCP bug though?  The stream was initially working "ok" 
> until the window closed.  There is no data the in the socket queue 
> should the window not re-open to where it had been.


We do not want to deal with user forcing TCP stack into a stupid 
ping-pong mode, one packet at a time.

If you have a patch that is reasonable, please let us know, but I bet  
this will break some applications.

Adding code in linux TCP fast path, testing for conditions that will 
never trigger in 99.9999999% of the time makes little sense.

MTU=9000 is 6 times bigger than MTU=1500, make sure you have increased 
SO_XXX values by 6x.