Bpi-r4: stops responding to ARP after some traffic

Installing and Using OpenWrt
1

After a while of working quite nicely, networking on by BPI-R4 seems to die pretty quickly. This seems to have been after an update, but I'm unsure which version worked and which didn't.

I have a fresh install of OpenWRT snapshot

DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='SNAPSHOT'
DISTRIB_REVISION='r28406-d1e9c50d06'
DISTRIB_TARGET='mediatek/filogic'
DISTRIB_ARCH='aarch64_cortex-a53'
DISTRIB_DESCRIPTION='OpenWrt SNAPSHOT r28406-d1e9c50d06'
DISTRIB_TAINTS=''

with fresh configs (I did sysupgrade to that version then ran firstboot). I also tested 24.10.0-rc4, which has the same behavior.

When I boot the router (this is a hard power-on, but repros on soft reboot as well), my laptop gets an IP address properly and can connect to the internet (can ping google.com, for example).

But after any significant traffic (originally repro'd with firefox, these logs are repro'd by running while true; do curl https://www.google.com/ ; done on my laptop), networking stops to work at all. I show this by having a ping 192.168.1.1 running in a termainal, and it stops responding. Pinging the internet (1.1.1.1) from the router works immediately after failure, but after the laptop puts the interface down and back up I can't ping 1.1.1.1 from the router anymore.

When it fails, I get these logs on my laptop:

[ 4849.298877] r8152 6-2.4:1.0 enp6s0u2u4: NETDEV WATCHDOG: CPU: 9: transmit queue 0 timed out 5627 ms
[ 4849.298884] r8152 6-2.4:1.0 enp6s0u2u4: Tx timeout
[ 4849.301402] r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
[ 4849.301440] r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
[ 4849.301520] r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
[ 4849.301599] r8152 6-2.4:1.0 enp6s0u2u4: Tx status -2
[ 4849.382762] r8152-cfgselector 6-2.4: reset SuperSpeed USB device number 7 using xhci_hcd
[ 4849.397912] r8152 6-2.4:1.0 enp6s0u2u4: Using pass-thru MAC addr a0:29:19:e5:28:e2
[ 4849.751017] r8152 6-2.4:1.0 enp6s0u2u4: carrier off
[ 4852.722589] r8152 6-2.4:1.0 enp6s0u2u4: carrier on
[ 4852.755341] r8152 6-2.4:1.0 enp6s0u2u4: carrier off
[ 4856.145926] r8152 6-2.4:1.0 enp6s0u2u4: carrier on
[ 4897.906804] r8152 6-2.4:1.0 enp6s0u2u4: carrier off
[ 4901.330804] r8152 6-2.4:1.0 enp6s0u2u4: carrier on

I've attached (with google drive links/gist, I can't see how to attach files that aren't pictures to this fourm, maybe I'm missing something?) a video of me reproducing the issue, as well as the pcap from the wireshark running on my laptop, and the openwrt logs.

Let me know if there is any extra info I can provide!

logs from openwrt: https://gist.github.com/russelltg/8a0a026cf6ee4041864c86ec09038f0f
video: https://drive.google.com/file/d/1fuAZrqgugbOByoYXeeUm6psKV5BThc7b/view?usp=sharing
pacp: https://drive.google.com/file/d/13_UBaaSVHMlgNcyOIXftGyDyqJozaURW/view?usp=sharing

2

I unplugged all other ethernet from the system and it's working now, so must be related to one of my other devices....

Will dig more later.

3

If you have a usb-c docking hub with Ethernet, that could be responsible for the issue when the host computer goes to sleep or is disconnected. If you have one of these buggy devices, it will typically take down the whole network with broadcast storms, so if you aren’t experiencing that symptom, it may not be one of these hubs.

4

I think it's probably related to https://discussion.fedoraproject.org/t/putting-mac-studio-to-sleep-makes-other-devices-on-lan-not-able-to-use-ethernet/95041

One of the devices I unplugged was a suspended mac studio running linux (I recently reinstalled and forgot to disable suspend)

5

That does sound a lot like what I'm describing with the USB-C docking hubs, although in my experience, TB docking hubs have not had this same bug (simply based on the firmware).

However, are you using the Mac Studio's built-in ethernet or that of the TB docking station?