NanoPC-T6 two Ethernet I/F sometimes swap + weird behavior of synaptic

Troubleshooting
1

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=9
    G_DIETPI_VERSION_RC=0
    G_GITBRANCH=‘master’
    G_GITOWNER=‘MichaIng’
    G_LIVE_PATCH_STATUS[0]=‘applied’
    G_LIVE_PATCH_STATUS[1]=‘applied’
    G_LIVE_PATCH_STATUS[2]=‘not applicable’
    G_LIVE_PATCH_STATUS[3]=‘not applicable’

  • Distro version | echo $G_DISTRO_NAME $G_RASPBIAN
    bookworm

  • Kernel version | uname --all
    Linux t62.FQDN 6.1.84-vendor-rk35xx #1 SMP Tue Dec 24 13:36:04 UTC 2024 aarch64 GNU/Linux

  • Architecture | dpkg --print-architecture
    arm64

  • SBC model | echo $G_HW_MODEL_NAME or (EG: RPi3)
    NanoPi 6 series (aarch64)

  • Power supply used | (EG: 5V 1A RAVpower)
    Mean Well LRS-50-12 (50W/12V)

  • SD card used | (EG: SanDisk ultra)
    System is running from the eMMC

Additional Information (if applicable)

  • Software title | (EG: Nextcloud)
  • Was the software title installed freshly or updated/migrated?
  • Can this issue be replicated on a fresh installation of DietPi?
    ← If you sent a “dietpi-bugreport”, please paste the ID here →
  • Bug report ID | echo $G_HW_UUID

Steps to reproduce

Reboot the SBC, either savagely, with “reboot” or with “shutdown -r now”.

Expected behaviour

eth0 and eth1 should always use the right socket.

Actual behaviour

The SBC has 2 RJ-45 sockets : ETH1 & ETH2 (yeah bad names :/)

Most of the time, eth1 (static IP - eth0 is down) is using the “ETH2” socket, which is normal as it is the 2nd I/F, but sometimes after a reboot, it moves to the “ETH1” one, which is a concern, as I can’t be sure if it will be the case after each reboot/power shortage - very bad thing for a machine that is also a server.

I did not have had the choice as dietpi-config only showed me eth1.

Extra details

I’ve 2 other (same) SBC installed with bullseye Debian (FriendlyElec image) that never have had this problem.

I also created /etc/network/interfaces.d/eth1, just in case, but it does not change this behavior.

What might be confusing DietPi is both I/F have the same MAC address (which can be easily circumvented with the “macchanger” PKG if needed).

May be using invariable Ethernet I/F names would help ? And if so, how to do that in DietPi ?

Also, synaptic is hyper slow, and after check, it only uses one core that is almost 100% of the time @100% - it is in fact unusable as it take ~10s to react to whatever order (even a mouse scroll).

2

I found a (terrible) hack.

As trying to fix the I/F order to their respective ethN using their PCI address with a udev rule did not work (if using ‘add’, can’t rename because I/F name already exists, if using ‘change’, doesn’t change anything when they’re inverted), I change their designation to ‘eth10’ and ‘eth11’ tying them to their PCI address with a udev rule and copying the eth1 definition to eth11 into /etc/network/interfaces.

This is very baaad (but it works ferpectly).

3

You can check the existent rules for a specific interface (for eth0 e.g.) with

udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null

Or for general rules that apply to the network with

ls /etc/udev/rules.d/*net*.rules
ls /lib/udev/rules.d/*net*.rules

You can get also a more detailed output of applied rules per interface with

udevadm info -a -p /sys/class/net/eth0

Maybe it helps to troubleshot your problem

4

Thanks but nope and the kernel unique names returned by the 1st command are terrible (eth0 == enP4p65s0 & eth1 == enP2p33s0) - sooo, I’ll keep them eth10 & eth11 for the time being and will see if that is fixed in the next release.

5

Hmm usually predictable interface names should work using udav rules :thinking: