Bug 48601

Summary:	Pauses while downloading
Product:	Networking	Reporter:	colbec
Component:	IPV4	Assignee:	Stephen Hemminger (stephen)
Status:	RESOLVED UNREPRODUCIBLE
Severity:	normal	CC:	alan, jan.oravec, linux.kernel, xerofoify
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	3.6	Subsystem:
Regression:	Yes	Bisected commit-id:

Description colbec 2012-10-08 09:12:16 UTC

Using OpenSUSE 12.2, Gnome 3.6 with Network Manager.
Recently upgraded from kernel 3.5 to 3.6, at which point the issue began.

Observed symptoms: while downloading, the stream will stop at random points for 5 to 120+ seconds, and then resume the download.
Example 1: while browsing, click on a link one time in 10 (approx) will fail to get the page, and a second click is successful. Sometimes it will begin to get the page, then stop, use back button to get previous page back, click link again and the page is fetched successfully.
Example 2: try to test download speed using speedtest.net, one test in two shows a normal start to the download side of the test, during the test the process stops, then recommences after a varying period 5 to 120+ seconds. Pauses happen one or multiple times.
Example 3: attempt to download a 20MB mp4 using Firefox. Process begins correctly, but during the download the process stops, again for 5-120 sec, and resumes. Downloads take a long time, but will eventually complete. If I kick it (pause, resume in download manager) it will complete faster.

I have replaced cables, NIC; return to kernel 3.5 eliminates the issue.

.config file was copied from a 3.4.2 kernel version, worked well for 3.5, and also seemed to be good for 3.6 with the exception of failed webcam which needed V4L reinstated.

Comment 1 Alan 2012-10-08 15:03:59 UTC

Please provide detailed information on the hardware or network setup. Without that it's hard to do anything.

Comment 2 colbec 2012-10-08 15:43:58 UTC

OK, first to note is that two Windows machines on the same network using the same wireless route to the WAN do not show this issue. Since kernel 3.5 is clear and only 3.6 is the problem this seems to rule out the network components, but anyway I am connecting to the WAN through two Linksys WRT4GL running DD-WRT. Route continues to WAN through a wireless high speed connection via Motorola Canopy technology.

I have replaced the cabling with identical results.
I have added a PCI NIC (Realtek) which behaves the same way as the onboard NIC (Atheros AR8131).

Memory 3.8 GiB, Intel Core 2 Quad Q8300 @ 2.5 GHz x 4
Graphics Intel G41 64 bit OS, Disk 500 GB.
Correction to Gnome version 3.4.2. (not stated 3.6)

I have a ream of further hardware info from Yast, please specify what detail would be helpful.

Comment 3 colbec 2012-10-10 10:42:43 UTC

 FWIW:
Patched up from 3.6 -> 3.6.1; sporadic download problem persists.

Comment 4 colbec 2012-10-11 12:22:21 UTC

Downloaded and installed latest 3.6.1 kernel from OpenSUSE kernel repo.
Problem persists.

Comment 5 Jan Oravec 2012-10-12 04:27:08 UTC

I noticed similar thing happening on 3.6.1 with forwarding fix applied used as a home router. Packets with TOS 0x20 were sometimes dropped; tcpdump shows them on the output interface (iwlwifi in my case), but the client side does not receive them.

Adding an iptables rule to mangle TOS to 0x00 fixed the issue for me.

Comment 6 colbec 2012-10-12 19:21:47 UTC

I wish I knew more about the situation to make a comment, Jan. However, intuitively, since the process in my case will resume if given long enough I don't think any packets are being dropped, just temporarily parked or ignored and then reactivated.

Comment 7 colbec 2012-10-13 19:59:57 UTC

Identical issue with 3.6.2.

Comment 8 colbec 2012-10-16 09:30:19 UTC

I bit the bullet and wiped my system partition to reinstall OpenSUSE 12.2 fresh.
After an online update and adding in the Kernels repo I added in kernel-default of 3.6.2, now networking is behaving the same as 3.4.11, that is, with brief interruptions on the download side which are able to recover quickly.

I'm putting this issue down to a minor but inconvenient incompatibility in the upgrade process on my previous installation.
Now to work on the rest of my system to get it back to working condition.

Comment 9 colbec 2012-10-17 20:36:51 UTC

My apologies, I am reopening this issue, but with more information. It seems to be related to fixed / dynamic IP.
If I run under traditional method with DHCP, my speed tests are fine, with very brief interruptions, downloads appear continuous.
If I run under a fixed ip, I get the long interruptions.
When everything looked clear, I was still under DHCP during the reinstall. Normally I need to run this machine under a fixed IP so that other machines can query it.
My workaround is to live with the dynamic IP.
I have changed the priority on this to normal, since the dynamic/static info seems to point more directly to a bug.

Comment 10 colbec 2012-10-30 16:24:00 UTC

Yet more information.
My network configuration for this station was not quite correct. 
On the dynamic IP setting, this computer was getting both IP and DNS from the router immediately after the radio to the WAN. 
When I set my fixed IP, I mistakenly pointed the DNS to a different router inside the LAN and the hesitation appears. The routing appears to work ok, but there is this pausing during a download. 
While using a fixed IP, when I point the computer's network DNS to the same router as the dynamic IP would come from, then the download does not hesitate for long periods.

I might be tempted to think there is something wrong with the settings on the routers involved, but please recall that in kernels 3.5.0 and before, the hesitations did not occur.

Comment 11 xerofoify 2014-06-25 02:06:55 UTC

This bug needs to be tested against a newer kernel to see if it's
fixed as of 2014.
Thanks Nick

Comment 12 colbec 2014-06-25 07:16:44 UTC

Thanks for the reminder.
At this point I am using kernel 3.15 and do not notice this issue.
I am closing this as unreproducible at this time with this kernel.
Causes of the original problem are unknown; hardware and local network setup is unchanged, however ISP is outside my control.