netdev - Re: TCP receive failure

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 for Android: free password hash cracker in your pocket

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

Date:   Tue, 10 Mar 2020 17:00:39 +0100
From:   Willy Tarreau <w@....eu>
To:     Stephen Hemminger <stephen@...workplumber.org>
Cc:     David Woodhouse <dwmw2@...radead.org>, netdev@...r.kernel.org,
        Martin Pohlack <mpohlack@...zon.de>
Subject: Re: TCP receive failure

On Tue, Mar 10, 2020 at 08:26:25AM -0700, Stephen Hemminger wrote:
> > Yeah, spot on. Thanks. Will stare accusingly at nf_conntrack, and
> > perhaps also at the server side which is sending the later sequence
> > numbers and presumably confusing it.
> > 
> 
> There were cases in the past of busted middle boxes that ignored TCP window scaling.
> 
> These were boxes based on old (buggy) version of FreeBSD firewall code that did
> not remember the window scaling from the handshake and would then see packets as
> out of window.

I've seen quite a bunch of these for a long time, and using various
stacks. And even when this got fixed, many still had issues with PAWS,
and a number of others used to randomize sequence numbers "for your
safety" except that they would do this with random values which could
actually make your ISN go backwards from the previous connection if
they forgot it in the mean time, resulting in failures to establish new
connections from the same port. Bah, I hate products which break end to
end transparency.

> You could try turning TCP window scaling off to see if that changes it.

The thing is that it's different here as the trace was taken on the
receiving side so the packets were dropped between tcpdump and the
TCP stack, hence my suspicion that some packets were considered as
invalid for whatever reason. And apparently David found them in the
local logs, which does fuel the suspicion over conntrack. Note that
it might also be caused by too short a timeout on the client's
conntrack!

Willy