kernel-packages team mailing list archive

[Uwe Schindler <1388786@xxxxxxxxxxxxxxxxxx>]

I can confirm this bug with the 3.13 kernel shipped with Ubuntu 14.04.
The 3.2 kernel shipped with Ubuntu 12.04 did not have the problem, all
download were succeeding. The problem started after upgrade to 14.04.
The problem also solved after downgrading the kernel to 3.2 by
downloading the latest 12.04 (Linux 3.2) one from the PPA.

Disabling TCP SACK also resolved the issue. I also tried newer PPA
kernels, at least the next one for release with next Ubuntu Update
(3.14) does not solve the problem yet.

In our case the problems happens mostly with far-away or slower DSL
connections, trying to download large files from our webserver. The
download starts fine, but suddenly slows down to 0 bytes/sec. It then
sometimes recovers, but fails again after a short while.

The tcpdump showed, that the client is sending SACKs over and over, but
the Ubuntu kernel does not understand them. In our case we also have
Cisco hardware inbetween.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1388786

Title:
  TCP stale transfer with erroneous SACK information

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Cisco PIX/FWSM changes TCP sequence numbers but doesn't change numbers
  in SACK TCP options.

  When this erroneous information comes to Linux server there is some
  corruption in TCP stack in some circunstances with CUBIC TCP
  congestion algorithm and transfer stales.

  Problem can be reproduced in Ubuntu Server 14.04 when a Cisco FWSM is
  changing sequence numbers (default configuration) and a big file
  (30MB, for example) is being transfered.

  Can be solved deactivating SACK:
  sysctl -w net.ipv4.tcp_sack=0

  We have solved it also with this configuration:
  sysctl -w net.ipv4.tcp_congestion_control=reno
  sysctl -w net.ipv4.tcp_frto=1
  sysctl -w net.ipv4.tcp_early_retrans=1

  We can also fix  it by changing firewall configuration.

  Find attached a wireshark capture where you can see at 16613 frame how
  client requests segment 853521869 and server (158.42.250.128) resends
  again a previous segment for 87 seconds until it stops transfer.

  Thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1388786/+subscriptions