Hello Radxa community,
I am experiencing a persistent and highly frustrating issue with my Radxa ROCK 5B where it loses Internet connectivity intermittently. I’ve managed to isolate that the trigger is the startup of the Docker service . I would greatly appreciate any insights or assistance regarding this behavior.
My Configuration:
- Hardware: Radxa ROCK 5B
-
Operating System: Debian Bookworm (Radxa official, kernel
6.1.84-6-rk2410
). -
Ethernet Driver:
r8125
(version 9.015.00-NAPI, compiled out-of-tree ). First I also tried the stock driver version that came with the kernel before compiling this one. -
Network: Connected via Ethernet cable to an OpenWrt router (BPI-R4) on the LAN (
192.168.1.0/24
). Rock 5B’s static IP:192.168.1.246
. - Services: I run multiple Docker containers using Docker Compose (ARRs, Jellyfin, etc.).
The Problem: The Rock 5B loses Internet connectivity. Pings to 8.8.8.8
or google.com
result in From 169.254.x.x icmp_seq=X Destination Host Unreachable
. This indicates that traffic is attempting to route via an APIPA address ( 169.254.x.x
) instead of the correct gateway ( 192.168.1.1
).
Isolated Behavior (Key Tests & Conclusions):
I performed extensive tests to isolate the cause:
- BPI-R4 Router Excluded:
- Other devices on the same LAN (
192.168.1.0/24
) connected to the BPI-R4 have normal connectivity . - The
fw4
firewall configuration on the BPI-R4 (/etc/config/firewall
) is correct, andnft list ruleset
confirms that forwarding and NAT rules are active and functional for both LAN segments, allowing traffic to the WAN. - Conclusion: The issue is NOT the BPI-R4 or its firewall. Connectivity breaks on the Rock 5B.
- Problem Isolated to Docker on the Rock 5B:
- Test 1 (24 hours without Docker): I rebooted the Rock 5B and let it run for 24 hours without starting the Docker service . Throughout this period, the Rock 5B maintained Internet connectivity without any issues .
-
Test 2 (Starting Docker): Immediately after starting the Docker service (
sudo systemctl start docker
), the Rock 5B lost Internet connectivity , with pings showingFrom 169.254.x.x Destination Host Unreachable
. - Conclusion: Docker service startup is the direct trigger for the loss of connectivity.
Details of Connectivity Loss on Rock 5B upon Docker Startup:
When Docker starts, I observe the following behavior on the Rock 5B:
-
Network Interfaces:
- The main
enP4p65s0
interface maintains its correct IP (192.168.1.246/24
) and remainsUP, LOWER_UP
. - Multiple virtual
veth
interfaces (created by Docker for containers) appearUP
and receive APIPA addresses (169.254.x.x/16
) instead of valid IPs from Docker networks (172.x.x.x
).
- The main
-
Routing Table (
ip r
):- A new default route appears:
default dev vethXXXXX scope link
. - This APIPA-backed route takes precedence over the correct default route (
default via 192.168.1.1 dev enP4p65s0
), redirecting all Internet traffic through a non-functional interface.
- A new default route appears:
-
Docker Daemon:
- The Docker daemon sometimes manages to start (
active (running)
), but host connectivity is lost. - Other times, the Docker daemon fails to start (
failed (Result: exit-code)
) , with messages likeStart request repeated too quickly
. - Crucially, I haven’t been able to obtain detailed Docker daemon debug logs (
journalctl -xeu docker.service
shows-- No entries --
, andlog-driver
configuration indaemon.json
hasn’t produced visible logs), which hinders explicit root cause identification for Docker’s internal failure.
- The Docker daemon sometimes manages to start (
Mitigation Attempts (Unsuccessful so far in preventing the core issue):
I have attempted various configurations in /etc/docker/daemon.json
and sysctl
, without success in preventing the core problem:
-
"ip-forward": false
and"iptables": false
: Prevented Docker from starting, but host connectivity was maintained (confirming Docker was the trigger). -
"bip": "172.23.0.1/16"
: To change the defaultdocker0
network range. -
net.ipv4.conf.all.accept_local = 0
insysctl
: To try and prevent the kernel from assigning routes to APIPA IPs. -
systemd
configurations fordocker.service
(After=network-online.target
,Wants=network-online.target
). - UFW has been disabled, confirming it’s not interfering.
- Attempted Docker
data-root
reset, which allowed Docker to start, but the connectivity issue then reappeared upon Docker’s successful startup.
Final Conclusion:
The problem is a critical, low-level interaction between Docker’s startup (specifically the creation/manipulation of veth
interfaces and bridges), the r8125
Ethernet driver (compiled out-of-tree ), and the Debian kernel version on the Rock 5B. This combination appears to lead to a race condition or incompatibility causing the kernel to erroneously prioritize routes through APIPA-assigned veth
interfaces.
Has anyone else experienced this behavior with Rock 5B, Debian Bookworm, the r8125
driver, and Docker? Are there specific kernel versions or r8125
driver versions recommended that resolve network stability issues with Docker? Are there any advanced nftables
(for OpenWrt) or iptables
(for Debian) configurations that can prevent the kernel from creating or prioritizing these default dev veth...
routes?
Thanks in advance for your help.