netdev - Re: TCP fast retransmit issues

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: <1501069756.12695.11.camel@edumazet-glaptop3.roam.corp.google.com>
Date:   Wed, 26 Jul 2017 04:49:16 -0700
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Klavs Klavsen <kl@...n.dk>
Cc:     netdev@...r.kernel.org
Subject: Re: TCP fast retransmit issues

On Wed, 2017-07-26 at 13:07 +0200, Klavs Klavsen wrote:
> Hi guys,
> 
> Me and my colleagues have an annoying issue with our Linux desktops and 
> the company's Junos VPN.
> 
> We connect with openconnect (some use the official Pulse client) - which 
> then opens up a tun0 device - and traffic runs through that.
> 
> If we try to scp a file of ~100MB (f.ex. linux-4.12.3.tar.xz :) - it 
> stalls after sending 20-30% typicly.. then starts again after some time, 
> and typicly dies before finishing. I've captured it with tcpdump (its a 
> large 77Mb file - thats how far it got before it died :) - 
> http://blog.klavsen.info/fast-retransmit-problem-junos-linux
> 
> I've attached an image of wireshark - where the (AFAIK) interesting part 
> starts.. Where my client starts getting DUP ACK's.. but my Linux client 
> does nothing :(
> I've tried to upgrade to latest Ubuntu-mainline kernel build (4.12.3) 
> and it changed nothing.
> 
> The problem goes away, if I do:
> sysctl -w net.ipv4.tcp_sack=0
> 
> I've tried specificly enabling net.ipv4.tcp_fack=1 - but that did not 
> help.
> 
> This is not an issue on Mac OSX or Windows clients.
> 
> None of the Linux users here figured, that could be a Linux kernel issue 
> - but the evidence seems to suggest it - and all my googleing and 
> reading does not lead me to any other conclusion.
> 
> It may ofcourse be that Junos has implemented the standard badly/wrongly 
> - and Windows/Mac has done a workaround for that?
> 
> I hope you can help me figure out whats going wrong.
> 

sack blocks returned by the remote peer are completely bogus.

Maybe a firewall is messing with them ?

I suspect ACK packets might be simply dropped because of invalid SACK
information.