Data coming from the network is only partially transfered on Asus EEE 1001HA, Ubuntu 10.4 Lucid

Question

My wife's netbook started behaving strangely lately. I dug around and found the following symptoms:

• web browsing: painfully slow (keeps "loading" pages; it might show something like half the Google logo, and then it's stuck on "transferring..")
• apt-get: will transfer the first 5k packets and then get stuck; upon relaunch, it will go up to 10k; then circa 16k.

Monitoring the network with a tcpdump I noticed that, after the initial burst of activity, nothing happens although the web page has not been loaded completely and the browser is still waiting for it. The last received packets look like this:

01:18:48.672286 IP 192.168.2.3.48010 > 72.14.234.104.80: Flags [P.], seq 618:1271, ack 5751, win 360, options [nop,nop,TS val 666336 ecr 2373881974], length 653
01:18:48.730567 IP 72.14.234.104.80 > 192.168.2.3.48010: Flags [.], ack 1271, win 129, options [nop,nop,TS val 2373882338 ecr 666336,nop,nop,sack 1 {618:1271}], length 0

Noteworthy things to know, in order of priority:

• I tried both via Wi-Fi (through the Realtek custom driver for Asus 1001HA) and Ethernet, "sharing Internet connection" from my Mac
• also tried a live Ubuntu Netbook (10.4) edition: same behaviour
• it works under Windows (sigh..)
• ping localhost works
• pings in the local LAN work
• we moved apartment; everything works fine on my Mac and her other PC, though
• no updates were done in the past months on Linux
• dmesg shows no unusual activity
• several DNS servers have been tried, all with same result
• there are no proxy system-wide
• there are no proxy browser-wide, and caches/cookies have been cleared
• diskspace is OK
• CPU usage is low as usual
• no extra default routes

---

Update Incidentally, I tried Ubuntu on her PC and it behaves EXACTLY the same. I wonder if it is the access point (D-Link) that messes up with Linux.

---

Notes from the first version of this post

--I added this notes since I received an answer on this topic already, but things have changed since then--

Regarding the behavior of ping; every packet was sent/received, but with huge latencies:

root@katies:~# !ping
ping www.google.com
PING www.l.google.com (66.249.92.104) 56(84) bytes of data.
64 bytes from 66.249.92.104: icmp_seq=1 ttl=51 time=57.7 ms
64 bytes from 66.249.92.104: icmp_seq=2 ttl=51 time=82.4 ms
64 bytes from 66.249.92.104: icmp_seq=3 ttl=51 time=77.1 ms
64 bytes from 66.249.92.104: icmp_seq=4 ttl=51 time=82.9 ms
64 bytes from 66.249.92.104: icmp_seq=5 ttl=51 time=79.5 ms
^C64 bytes from 66.249.92.104: icmp_seq=6 ttl=51 time=78.8 ms

--- www.l.google.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 25704ms
rtt min/avg/max/mdev = 57.772/76.438/82.947/8.595 ms

The last two lines say: it took 25 seconds to send 6 PINGs. However, each ping should be sent within 1 sec from each other, not 5. Furthermore, the round-trip time is quite low, as it should be.

Answer 1

1. Is the latency just with web browsing? Have you tried other apps?
2. Which browser is she using? How many tabs does she have open?

I have seen similar latency on my Debian laptop if I have too many tabs open in Iceweasel. I have also seen references to a mySQL bug that causes similar issues.

Answer 2

Which exact ping(1) command arguments do you use? It's not shown.

If you add each single ICMP packets time spent:

57.7 ms + 82.4 ms + 77.1 ms + 82.9 ms + 79.5 ms + 78.8 ms

It's 458.40 ms. By default ping(1) put an interval of 1 sec between each pings. Usualy, it would take 1000 ms * 5 (because there is only 5 intervals between each 6 pings) + 458.40 ms = 5458.40 ms, not 25704 ms. And ping do not report any packet loss.

Maybe in your ping(1) arguments you have something like "-i 5".

That add 5 seconds between each ICMP request. And it make more sense, 5000 ms * 5 + 458 ms = 25458 ms

Which is near the 25704 ms total in your output.

Answer 3

The problem turned out to be a very, very, very bad access point/wireless router: a D-Link G604T. Apparently, due to some major bug with DNS proxying or packet forwarding and IPv6 it does not work in Linux (Ubuntu).

The solution was to take the thingy down and replace it with something more decent.

UPDATE, 2011-09-25

A similar version of this problem affected also my Mac even after substituting the old router. This problem was affecting all UNIX based devices (basically, every friend of mine who owned a mac that came visiting).

Some details on the behaviour:

• can't upload large files via web (would transfer 49,152 bytes then hang)
• odd behavior vua ssh (would transfer files of sizes 49,150 49,151 and 49,153 but not 49,152
• would transfer (via ssh) files as big as 100k but hang randomly after that
• very oscillating download/upload speeds when transferring files in small chunks via bittorrent protocol

Fix: TCP window scaling, or

sudo sysctl -w net.inet.tcp.rfc1323=0