[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <200d9a12e9f2f5791d4c5ce2d47a1239@vsen.dk>
Date: Wed, 26 Jul 2017 13:07:27 +0200
From: Klavs Klavsen <kl@...n.dk>
To: netdev@...r.kernel.org
Subject: TCP fast retransmit issues
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.
--
Regards,
Klavs Klavsen, GSEC - kl@...n.dk - http://blog.klavsen.info - Tlf.
61281200
"Those who do not understand Unix are condemned to reinvent it, poorly."
--Henry Spencer
Download attachment "fast-retransmit-not-happening.png" of type "image/png" (323591 bytes)
Powered by blists - more mailing lists