Something seems to be very wrong with my network stack right now. Not sure where to start debugging. I have Ubuntu 18.10 running a windows 10 VM with QEMU/KVM. The network is bridged together so both Ubuntu and Windows show up on the same subnet. The computer itself is directly connected to the modem/router through ethernet.

Running a ping overnight on Ubuntu 18.10:

--- ping statistics ---
47870 packets transmitted, 45768 received, 4.39106% packet loss, time 48161ms
rtt min/avg/max/mdev = 7.666/26.841/1089.663/29.587 ms, pipe 2

Running the same command at the same time on the Windows VM:

Ping statistics for
    Packets: Sent = 47466, Received = 47453, Lost = 13 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 8ms, Maximum = 521ms, Average = 26ms

Linux side network configuration:

bridge0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet  netmask  broadcast
        inet6 fe80::5f60:4c3c:6e7d:fe0d  prefixlen 64  scopeid 0x20<link>
        inet6 2607:f2c0:e00a:6fb:909a:d129:4ca4:5178  prefixlen 64  scopeid 0x0<global>
        inet6 2607:f2c0:e00a:6fb::4  prefixlen 128  scopeid 0x0<global>
        ether 62:e1:cd:28:fc:23  txqueuelen 1000  (Ethernet)
        RX packets 1156702  bytes 266528351 (266.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1321781  bytes 148373341 (148.3 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether ac:1f:6b:77:45:68  txqueuelen 1000  (Ethernet)
        RX packets 1141435  bytes 826615245 (826.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1136699  bytes 175653093 (175.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 16  memory 0x52300000-52320000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet  netmask
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 5990  bytes 445099 (445.0 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 5990  bytes 445099 (445.0 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vmtap0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::60e1:cdff:fe28:fc23  prefixlen 64  scopeid 0x20<link>
        ether 62:e1:cd:28:fc:23  txqueuelen 1000  (Ethernet)
        RX packets 1182468  bytes 136243741 (136.2 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1480981  bytes 686427281 (686.4 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

0) context. when you are testing, remember what you noticed that made you run the overnight test, as best you can. writing it down could help. edit it into the question. At least I assume there is a reason; it's unusual to run commands overnight for fun :-).

0a) bayes theorem. i confirm this "seems to be very wrong". this is not a well-known problem. So remember there are good chances your surprise is caused by you misunderstanding or making a mistake in your test method.

And in general, you could have written much more detail into your question. To start with you did not say what are the OS's are, the VM software, your LAN connection to your router, the type of ISP your router is connected to. Or if every 100 minutes, your internet connection stops working for 4 minutes :-).

(But to be honest, I could also say I am not sure where to start, apart from strictly interrogating your test method.)

1) time. if you graphed it, would there always be packet loss, or is there heavy packet loss at certain times?

You can also decrease the ping interval to get a faster statistic ("flood ping" or so), but you should not do that to Google (unless you were paying them for it :-). Instead use traceroute to find the first or second IPv4 address inside your ISP. (The first inside your ISP is probably the line numbered with a 3. The ping times can also be a clue). Beware of being confused by traceroute results; it is a tool for experts.

2) confirm specifically how weird this is, by seeing if the problem also applies to pinging your local router, or not. Run both tests at the same time, so you have a good comparison. (Although, remember that this could potentially be a different result v.s. running one at a time)

Since you did not say you were using straight Ethernet, the above is a very important question. Usually you want to rule out either Wi-Fi weirdness or ISP weirdness (or at least try to rule out that it is the only cause of the problem). Those are the top two sources of problems in home network usage, so ruling one of them out is really valuable.

Technically you show eno1 which is probably Ethernet, but you could still be using something weird like powerline networking.

if possible, get someone else to ping your router. I like https://www.thinkbroadband.com/broadband/monitoring/quality I.e. if your line shows a clear packet loss on a well-used tool - then it's probably because there is packet loss on your line :-). this depends on your router's firewall allowing itself to be pinged; there may be a setting for it.

3) Packet capture i.e. Wireshark. Does Windows generate ping packets that look different, compared to Linux? (Might need to run Wireshark inside Windows, depending). We already expect the source IPv4 address and source MAC address will look different. If they do - you may be able to adjust Linux ping packets a little using various options.

  • It's not on wifi, so that rules out a lot of problems. That tool you linked was helpful, I've signed up, so I'll see what it shows after it's had time to collect data. – Charliehorse May 19 at 18:38
  • I wasn't sure what details to put in the question, because I have literally no idea how to start debugging something like this. – Charliehorse May 19 at 18:44
  • 1
    @Charliehorse think e.g. if I visited the site but your PC was not available, how would I try to reproduce the problem? Linux distro & version is always good to quote. – sourcejedi May 19 at 18:51

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.