Excluding this, as I have tried all methods listed on this site. And excluding this and this, they are in the aforementioned site. What are possible causes for a software based slowdown of internet.


  • Booting in Windows or other live-boot disk makes Internet work, pings anything 0% loss.
  • Router can be pinged by the PC in question, while running Ubuntu, with 0% loss as well as anything in the same network 0% loss.
  • Pinging or mtr, by the PC in question to anything outside the network(on the other side of the router) results in 100% loss.
  • If the Router or other devices on the network try to ping the computer in question, they have 80% to 95% loss.

What could possibly be the cause of this kind of network failure on Ubuntu?

Ubuntu PCs with this problem have responses to lspci -knn | grep Eth -A2:

02:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8131 Gigabit Ethernet [1969:1063] (rev c0)
    Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7599]
    Kernel driver in use: atl1c

This one has under 80% loss ~50% using a USB to Cat5 network port

00:13.2 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 USB EHCI Controller [1002:4396]
    Kernel driver in use: ehci-pci
  • Is "Internet" a cable connection? – Pilot6 Apr 17 '16 at 21:08
  • You think disconnecting the internet from the router would eliminate the 90% packet loss of pings sent to the Ubuntu PC? I'll give it a try, simply because you intuition about "cable" is correct. – Luke Burgess Apr 17 '16 at 21:47
  • I do not think anything. I just asked. Please edit your question and add output of lspci -knn | grep Eth -A2 terminal command. – Pilot6 Apr 17 '16 at 21:58
  • 02:00.0 Ethernet controller [0200]: Qualcomm Atheros AR8131 Gigabit Ethernet [1969:1063] (rev c0) Subsystem: Micro-Star International Co., Ltd. [MSI] Device [1462:7599] Kernel driver in use: atl1c – Luke Burgess Apr 17 '16 at 23:28
  • I think I understand what your problem is, but it is not clear. Please could you add something like: "I have 2 Ubuntu 14.04 computers that can ping out to the local network and internet, but when I try to ping the 2 Ubuntu systems from other hosts on the local network, then I see large amounts of packet loss." – David Apr 24 '16 at 13:23

This is and always will be a will guess without being on-site, but there here are some reasons that might prevent Ethernet to function properly. Windows driver for the card might be able to do some automagic to degrade the settings of your card. Or the card needs some poke to do the autonegotiation.

  1. The most obvious might be duplicate MAC addressed. List the MAC addresses on the affected PC, then shut it down and then try arping the MAC addresses from different machine.

  2. Your router might be a real deal and block some default IP settings. If you could try using some other generic router on the network, then do so to rule out this possibility.

  3. Crooked or old cabling that prevent the card to function at higher speeds. You might try setting the link mode to 10M or 100M manually using either mii-tool or ethtool.

  4. Similar with full-duplex or half-duplex settings on the card.

Here's an article on mii-tool/ethtool that goes there in more detail.

One more idea how to debug the issue:

  • You can try sniffing the network interface using tcpdump or wireshark and observe the differences between pings initiated at the PC in question and pings initiated elsewhere.
  • The same can be done on the router if it's f.e. running embedded Linux, or you can plug a "sniffer" consisting of two network cards bridged together between router and the inside network.
| improve this answer | |

Another tool that you might want to employ is iperf. You can use this to determine if the local networking is killing your throughput. A reference is located at: https://iperf.fr/. You can simply generate high bandwidth loads and then check what that actual reported throughput is. If you have two nodes you can do the following check. First run

sudo lshw -c network

on both machines. Find your interface and note the reported link speed, should be something of the form:

size: 100Mbit/s
capacity: 100Mbit/s
capabilities: ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation

This interface reports 100Mbit/s, check this on both devices and determine the minimum you expect. Next use iperf to push a large ammount of traffic to determine what the actual throughput is

On node 1 run:

iperf -s -i 2

On node 2 run:

iperf -n 1000M -i 2 -c <SERVER IP>

This will generate a report on the client side of the form:

Client connecting to <SERVER IP>, TCP port 5001
TCP window size: 85.0 KByte (default)
[  3] local <CLIENT IP> port 36114 connected with <SERVER IP> port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0- 2.0 sec  22.5 MBytes  94.4 Mbits/sec
[  3]  2.0- 4.0 sec  22.2 MBytes  93.3 Mbits/sec
[  3]  4.0- 6.0 sec  22.5 MBytes  94.4 Mbits/sec
[  3]  6.0- 8.0 sec  22.4 MBytes  93.8 Mbits/sec

and something similar on the server side (the -s node). You'll note that in this case the throughput is pretty close to the reported ideal. You should expect to loose a couple of Mbits/sec to TCP overhead, but if this value is far off, you can blame something inside your network. If this number is within some tolerance (say 5-7% of reported), you're problem lies beyond your gateway.

At that point one can ask if your service provider is proxing, or doing some flavor of traffic shaping that gives preferential treatment to certain types of traffic?

| improve this answer | |
  • I like your answer, I'll give it an upvote but not the bounty oerdnj not only gave a good possible explanation "Windows driver for the card might be able to do some automagic to degrade the settings of your card." but also provided a unbiased source. The iPerf looks like a nice application, ill get it. :) – Luke Burgess May 6 '16 at 1:11
  • Glad I could help, iperf + tcpdump are my go to tools when I can't seem to get packets where they should be. Another useful item in the bag of tricks is scapy (secdev.org/projects/scapy). It basically gives you the ability to "hand craft" packets which allows you to determine if what you expect is reasonable. – James S. May 11 '16 at 20:45

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.