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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <414afd70d2b864234a829aa71bc66bf9d519645e.camel@infradead.org>
Date:   Tue, 10 Mar 2020 17:32:14 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Neal Cardwell <ncardwell@...gle.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Cc:     Netdev <netdev@...r.kernel.org>,
        Martin Pohlack <mpohlack@...zon.de>
Subject: Re: TCP receive failure

On Tue, 2020-03-10 at 12:36 -0400, Neal Cardwell wrote:
> 
> 
> On Tue, Mar 10, 2020 at 12:19 PM Eric Dumazet <eric.dumazet@...il.com
> > wrote:
> > 
> > On 3/10/20 2:40 AM, David Woodhouse wrote:
> > > I'm chasing a problem which was reported to me as an OpenConnect
> > packet
> > > loss, with downloads stalling until curl times out and aborts.
> > > 
> > > I can't see a transport problem though; I think I see TCP on the
> > > receive side misbehaving. This is an Ubuntu 5.3.x client kernel
> > > (5.3.0-40-generic #32~18.04.1-Ubuntu) which I think is 5.3.18?
> > > 
> > > The test is just downloading a large file full of zeroes. The
> > problem
> > > starts with a bit of packet loss and a 40ms time warp:
> 
> David, would you be able to post a binary tcpdump pcap file
> (including SYN/SYNACK, to get the wscale option) at a public HTTP/S
> URL somewhere? A time/sequence plot may shed some light on this, but
> the tools that generate those generally want a pcap file as input.
> 
> I also like Eric's idea to reproduce and take periodic
> ss/nstat dumps. That might be extremely informative.

Thanks. I do have the nstat part of that, taken each second during
Martin's last repro. But Willy was right — it was conntrack dropping
those packets, locally, before TCP ever saw them.

I've suggested that Martin set nf_conntrack_log_invalid so we get a
better look at why. And also perhaps nf_conntrack_tcp_be_liberal to see
if it goes away.


Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5174 bytes)