netdev - Re: tcp hang when socket fills up ?

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <863dc88d-bc91-d3b6-70c6-5e279451f66d@gmail.com>
Date:   Fri, 13 Apr 2018 18:39:07 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Dominique Martinet <asmadeus@...ewreck.org>,
        Michal Kubecek <mkubecek@...e.cz>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     netdev@...r.kernel.org
Subject: Re: tcp hang when socket fills up ?



On 04/13/2018 06:09 PM, Dominique Martinet wrote:
> Thank you for the replies,
> 
> Eric Dumazet wrote on Fri, Apr 13, 2018:
>> There is no way a regular TCP stack (including linux) could send the following frame.
>>
>>> 16:49:27.048760 IP <server local ip>.13317 > <client public ip>.31872: Flags [.], seq 32004:33378, ack 4190, win 307, options [nop,nop,TS val 1313937955 ecr 1617129473], length 1374
>>
>> So something is mangling the packet, maybe NAT or something.
> 
> 
> The pcap was produced on the server which emitted the frame, so it
> should be exactly as the server intended it to be without any mangling
> involved?
> If you could point at what strikes you as odd I can check if the same
> happened on other hang traces I might still have. Is it just that it
> replays a very old seq?
> (if it's odd wrt client packets, the same trace as captured on client is
> at the end of this mail)
> 

Ah sorry, your trace was truncated, we need more packets _before_ the excerpt.

That might be caused by some TS val/ecr breakage :

Many acks were received by the server tcpdump,
but none of them was accepted by TCP stack, for some reason.

Try to disable TCP timestamps, it will give some hint if bug does not reproduce.