Raspberry Pi 4 high packet loss over ethernet

[Shadiko19]

Describe the bug
Ethernet connection on RPi4 have high packet loss (about 15%). I have the same issue as in this thread https://www.raspberrypi.org/forums/viewtopic.php?t=253337, because I have the same router. But I doubt that this is the router fault, because my laptop, Playstation 4 and Synology NAS server are connected over ethernet and they are working perfectly fine.

Actual behaviour
Ping RPi4 from laptop:
https://pastebin.com/YeKuNdUA

Ping 1.1.1.1 on RPi4:
https://pastebin.com/265rcDPf

Ping 1.1.1.1 on laptop (I have used the same cable in every test):
https://pastebin.com/n4icACmL

Expected behaviour
I think that there should be about 0% packet loss.

System
Results of the raspinfo command:
https://pastebin.com/5KHh996q

Additional context
I have tested different cables, updating kernel with rpi-update and the problem is still present.

[JamesH65]

From reading that thread, it's completely down to a problem router, since putting a switch between the Pi and the router fixes the problem. What is the specific model of router you are using? Does google show up problems in the field with that type of router?

[Shadiko19]

My router is Compal CH7465LG (UPC Connect Box). I have searched google and I found this forum topic with similar problem to mine https://www.raspberrypi.org/forums/viewtopic.php?t=249112 and also on reddit https://www.reddit.com/r/linuxquestions/comments/cwigt7/raspberry_pi_4_packet_loss_in_home_network/

[JamesH65]

So clearly something about that particular router, since we have no other reports on most the other ones out there. Don't appear to be available in the UK, so difficult for us to test. What sort of settings are available on the router that you can play with to see if any make a difference?

[graysky2]

Cannot reproduce on several RPi4 models connected to an R7800 routers and gigaswitch. Anything of note in systemctl or dmesg?

[fgrsnau]

I have a similar problem and my Raspberry Pi 4 is connected to an UPC Connect Box too. (Interesting to here that the Connect Box seems to be the culprit. Again. The quality of this device is so poor. My Connect Box even routes local IPv6 traffic to the uplink port which is clogging my Internet connection. I have to provision static routing rules to override this behaviour.)

It somehow seems that the Raspberry is not able to handle all incoming packets. I haven't checked but maybe the Raspberry is sending flow control commands on the ethernet link and the Connect Box is ignoring these?

My current workaround is simply to set the ethernet interface to 100Mbit/s (ethtool -s eth0 speed 100 duplex full in /etc/rc.local). This results in 0% packet loss which is much more important than link speed for me (dns resolution via unbound running on the Pi, ssh latency, etc).

[hurda]

There's a known "bug" in cable-modems using Intel's Puma-6-platform, which causes latency- and ping-issues at least on out- and inbound connections, even when the device is set to bridge-(modem-only)-mode.
The "Connect Box" (a rebranded Compal CH7465* (CH7465LG, ...MT, depending on ISP) is one of those.
There's been several firmware-updates to lessen the impact of the bug, but Intel dropped support for it a couple of months ago, afaik. Most recent version should be something like CH7465LG-NCIP-6.12.18.25-2p6-NOSH.
Maybe the bug (or fixes for it) also affects LAN-side traffic somehow in combination with whatever the RPi does.

[JamesH65]

I don't think we will be able to spend any time on this. The router is end of line, and clearly not very good.

Closing as a Won't Fix. This means that although the issue is acknowledged, it is felt that no further action is likely. This may be down to a bad benefit vs cost analysis, or it may actually not be possible to fix.

[bog-dan-ro]

I had the same problem (I saw high packet loss) .
The problem ended-up to be related to the 5.5-y branch. Just switching to 4.19-y fixed the problem (I kept the same switch with the same cable).
I tested again with both kernel on a different switch with a different cable. The results were the same: 5.5-y kernel had +10% packet loss, while the 4.19-y kernel not a single one.

IMHO you should re-open this issue and check again the 5.5-y branch.

[pelwell]

There was a problem with the PHY declaration, but it should be good now.

[bog-dan-ro]

@pelwell I built 4.19-y & 5.5-y branches today :) .
The logs says that the last change in 5.5-y branch was 15 days ago.

[bog-dan-ro]

I forgot the mention that I'm using the dtbs from 4.19 branch as the ones from 5.5. branch are not working (the device doesn't boot).

[pieter-groeneweg]

that may be an issue, but even though I have an Ziggo Connect Box (don't know what make this one is) I even have connect issues within my local network targeting the direct IP address of the RPI4. Connections are dropping.

connectbox in bridge, Nighthawk behind it as router and gateway.

RPI3 with same setup, no issues whatsoever..

[Alestrix]

Chiming in to note that I experience the same issue with a MikroTik CSS326 switch. So it not only happens with poor cable routers, but also with enterprise switches.

[smalltox]

After several months of searching a workaround for using the raspberry Pi4 at full speedwith my box (SFR Labox - France), i finally found it. I disable power saving on ethernet controller :
sudo ethtool --set-eee eth0 eee off

[pieter-groeneweg]

@smalltox. interesting, is there a config file where to set this also as thisis a command.. this needs done after each reboot, right?

[smalltox]

@pieter-groeneweg
I suppose that you can do something like this :
vi /etc/init.d/ethtool.sh
#!/bin/bash
ethtool --set-eee eth0 eee off

[manfromdownunder]

I tried this and it worked until reboot, then after reboot I manually ran it again and it no longer worked. Is there a hardware fault with the pi? If I replace it will it still happen on the next one?

[graysky2]

@manfromdownunder - You have to execute that on each boot. What init system is your distro running?

[manfromdownunder]

even if I execute this manually the problem still remains @graysky2 I'm just using the latest pi image

[graysky2]

OK. I missed that.

1. Is this particular pi4 the only wired device on your network experiencing these issues?
2. Have you ruled out the patch cable it uses if so?
3. Have you ruled out the physical port on your router/switch if so?

[manfromdownunder]

@graysky2 I have googled all of the above and tried them all. I have 3 x rpi 3B+ that work flawlessly. I spent a day tryiong all sorts of port configs to force duplex types, tried different power supplies, disabled bluetooth and wireless in the boot config. Even uninstalled some daemons that are also supposed to cause this issue however none of these things worked. I did see success temporarily with this fix however it didn't last. I run ubiquiti gear and have no other issues. I have seen suggestions about putting a switch in between the pi and the switch but to me this is just a stupid fix which I won't entertain given the 28 other devices on the network have zero issues. Really frustrating. I am trying to understand if this is a hardware fault, or a factory fault with the device. So do I RMA it or refund it as it is just a POS?

[graysky2]

If you ruled out cable, port, etc. Do you see the issue on a fresh install of RPiOS? Do you see the issue on a fresh install of another distro (Arch ARM is easy to install for testing purposes)? If so, I would think the body of evidence points to your specimen.

[psyke83]

I have a RPI 4B 4GB (revision c03111) model that exhibits the same issue - ~20% packet loss on a 1GBit/s link - when connected to a Virgin Media Hub 3.0 (software version CH7465LG-NCIP-6.12.18.26-3p7-1-NOSH), which appears to be a rebranded version of the same ConnectBox router.

I was able to avoid the packet loss by limiting the connection to 100Mbit/s, but it seems that @smalltox's suggested workaround also worked for me - thanks!

I would recommend invoking ethtool via interfaces.d so that you can be sure that the workaround applies each time there's a network state change. Example /etc/network/interfaces.d/eth0 file:

auto eth0
iface eth0 inet dhcp
#link-speed 100
#post-up /sbin/ethtool --set-eee eth0 eee off

Uncomment one of the last two lines, depending on which workaround you need to use.

[lambdaupb]

I observe the same problem with a rpi 4 B 1.1 and a CH7465LG router.

Interesting is that I also have packet loss at 100mbit, that workaround has worked in the past, but today it also showed significant packet loss.

ethtool --set-eee eth0 eee off does fix it however.

Hardware : BCM2711
Revision : b03111
Model : Raspberry Pi 4 Model B Rev 1.1

I must assume this is a problem with the rpi4, none of my other devices have this problem and the millions of customers using the router would notice. It is a poor device, but that amount of packet loss would make watching iptv etc. impossible.

[Wenri]

I also have the same problem with Raspberry Pi 4 Model B Rev 1.2. The pi is directly connected to an entry-level enterprise H3C ER3200G2. This packet loss is ranging from 6% to 15% over a 1000Base-T link.

Disabling the power saving on RPI4's ethernet controller using ethtool --set-eee eth0 eee off does fix the packet loss problem.

Since this problem occurred against a wide range of routers/switchers, I guess this is RPI4's issue rather than the routers.

[TheLevti]

Have the same issue. I had to replaced my old modem, which had a 100mb interface, with a new one that has a 1gb link. Since then I am facing constantly 10%-20% packet loss. Disabling eee solved it for me as well. It seems very much like an issue with rpi4. Any solution? eee is quite an old and robust tech, can't be that we have to disable this nowadays.