No network connectivity on NanoPi R5S on kernel 6.x

[adaszko]

Creating a bug report/issue

• I have searched the existing open and closed issues

Required Information

• DietPi version | cat /boot/dietpi/.version

G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=1
G_DIETPI_VERSION_RC=1
G_GITBRANCH='master'
G_GITOWNER='MichaIng'

• Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
• Kernel version | uname -a
• SBC model | NanoPi R5S/R5C (aarch64)

Steps to reproduce

1. Install DietPi_NanoPiR5S-ARMv8-Bullseye.img.xz on NanoPi R5S
2. Boot
3. Unable to connect on any of 3 Ethernet ports (none of the LEDs light up)

Expected behaviour

• NanoPi should be able to configure eth0 via DHCP and successfully ping 9.9.9.9

Actual behaviour

• No network connectivity on any of the 3 ethernet ports

Extra details

I actually have 2 installations of DietPi on one NanoPi R5S -- one on an SD card and one on a NVMe drive. The one on the SD card is older and works fine. I'm attaching two dmesg logs -- one good, one bad:

• dmesg-broken.txt
• dmesg-working.txt

The line I'm looking for is [ 14.593774] rk_gmac-dwmac fe2a0000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx. There's no such line in the broken case.

The installation on the SD card is an old one, and as dmesg states, it's on kernel Linux version 5.10.160 (ubuntu@670032f54a45). The NVMe one is at Linux version 6.6.15-current-rockchip64 (armbian@next). This is my primary suspect.

[MichaIng]

Many thanks for reporting.

Are the network interfaces detected at all?

ip l

[adaszko]

Many thanks for reporting.

My pleasure! Thanks for DietPi!

Are the network interfaces detected at all?

ip l

Yes, here's a "screenshot" (lol)

[MichaIng]

Interesting, eth0 is up but no cable connected, at least no carrier signal. eth0 should be the LAN1 port. When you connect a cable there, does it change, i.e. no NO-CARRIER flag anymore?

What should happen on the very first boot, is that all interfaces are set up to check for a carrier signal (connected cable), and the first one with a carrier signal is then configured for network access. If no cable is attached at all, eth0 is configured by default, but of course it fails without a connected cable. I need to test, but I think in this case, when you now attach a cable to another port, it is not used by dietpi-config OOTB, since eth0 is still set UP and preferred then. It should be possible to fix this by either disabling Ethernet network and re-enabling it, or setting eth0 down manually, before re-applying Ethernet settings:

ip link set down dev eth0

Otherwise it keeps trying to use eth0 instead of re-detecting the one with connected cable.

I really need to find time to finish reworking the network script, so that one can simply select the interface to setup, at best from a menu which also shows the current carrier signal state. The script was originally really designed for single Ethernet adapter cases in mind only.

[adaszko]

Hmm, so it looks like it's the middle port (of the three) that got configured as eth0 because the "NO-CARRIER" message disappears when I plug the cable in it and after a reboot I am actually able to access the network.

So far, I had the cable plugged into the WAN port which wasn't working.

[adaszko]

I really need to find time to finish reworking the network script, so that one can simply select the interface to setup, at best from a menu which also shows the current carrier signal state. The script was originally really designed for single Ethernet adapter cases in mind only.

Here's an idea: or it could come configured in bridge mode by default on all interfaces. It's simpler from an operational standpoint in a sense because it should work irrespective of which port the cable is plugged to. Bridging is my use case anyway for the little device (or IOW: I use it as a low-power software switch that I can run network services on). I'm not sure how people tend to use it.

So, in essence, it would boil down to this:

$ apt install bridge-utils

and inside /etc/network/interfaces:

auto br0
iface br0 inet dhcp
        bridge_ports all

[adaszko]

I also get this during DietPi installation:

W: Possible missing firmware /lib/firmware/rtl_nic/rtl8125a-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8107e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168fp-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168g-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8106e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8411-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8402-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168f-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8105e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-3.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168e-1.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-2.fw for module r8169
W: Possible missing firmware /lib/firmware/rtl_nic/rtl8168d-1.fw for module r8169

[MichaIng]

No worries about the firmware warnings on initramfs generation. Thia happens by times when recent Armbian kernel uses drivers which has no perfectly matching firmware in the armbian-firmware package. But since the Ethernet adapters generally work, I think this is not the issue. I'll however test on my R5S later today.

I just checked, and eth0 should be the LAN1 adapter, eth1 LAN2 and eth2 the WAN labelled adapter. The middle one is "LAN1" (I am currently not at home to check)?

Generally, on very first boot, a script loops through all network interfaces, enables them, and configures the first one which has a carrier signal, hence a cable attached. If no cable is attached yet, it configures eth0, hence the cable then needs to be plugged into the LAN1 adapter, indeed. Was this probably the case?

[MichaIng]

Can you check this issue: #6951

Are your symptoms the same, i.e. long boot times and timeouts of related systemd units?

journalctl -u ifup@eth0 -u ifup@eth1 -u ifup@eth2 -u networking