Dual ethernet ports problem

Hi,

the carrierboard supports two ethernet ports. From time to time the ethernet names change after (re)boot. Normally, it is ethernet0 and ethernet1. But sometimes it is eth0 and ethernet0.
My software uses the ethernet name for detection, so it sometimes cannot identify one of ports.

Is this a known issue? How to solve?


Software summary

Bootloader: U-Boot
Kernel version: 5.15.148-6.8.1+git.1cbf48124747 #1-TorizonCore SMP PREEMPT Fri Dec 20 08:57:54 UTC 2024
Kernel command line: root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/9e09d9a4bf833bb9395b54b58df511bc3463a0c8c4b7c56fe8d82cebc9575507/0 clk-imx8mp.mcore_booted=1
Distro name: NAME=“TorizonCore”
Distro version: VERSION_ID=6.8.1-build.25
Distro variant: VARIANT=“Docker”
Hostname: verdin-imx8mp-14748092

Hardware info

HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0058 V1.1A
Serial number: 14748092
Processor arch: aarch64

Hi, I’m the Toradex AI Assistant.

I might make mistakes. Our support team will step in if needed. If I answered your question, please tick the “Solution” checkbox. For follow-up questions to me, please use @ToradexAI in your post.

Did you like my answer? :+1: :-1:


Hello,

This is a known issue that can occur on Linux-based systems, including TorizonCore, when multiple Ethernet interfaces are present. The interface names (e.g., eth0, ethernet0, etc.) may change nondeterministically between reboots due to timing and driver probe order during boot. This can impact software that relies on consistent network interface names.

Why does this happen?

Linux uses udev rules to assign network interface names. By default, the names can be based on enumeration order or device properties, which may not always be stable.

Solution: Assign Persistent Names

To ensure that your Ethernet interfaces always have consistent names, you can create custom udev rules based on unique identifiers such as MAC addresses. Here’s how to do it:

1. Identify Ethernet MAC Addresses

Run the following command to list current network interfaces and their MAC addresses:

ip link show

Example output:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:14:2d:ff:01:23 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 00:14:2d:ff:01:24 brd ff:ff:ff:ff:ff:ff

2. Create a Custom udev Rule

Create (or edit) a file called /etc/udev/rules.d/10-network-names.rules with the following content (replace the MAC addresses with yours):

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:14:2d:ff:01:23", NAME="ethernet0"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:14:2d:ff:01:24", NAME="ethernet1"

This means:

  • The interface with MAC address 00:14:2d:ff:01:23 will always be named ethernet0
  • The interface with MAC address 00:14:2d:ff:01:24 will always be named ethernet1

3. Apply the udev Rules

Reload udev rules and trigger them with:

udevadm control --reload
udevadm trigger

On the next reboot, the names will remain persistent.


By implementing this, your software can reliably depend on the assigned network interface names regardless of boot order.

Useful further reading and discussions:

Best regards,
Toradex AI Assistant.

Hi @Lars.ceta!

The answer provided by Toradex AI seems reasonable and may help resolve your issue. Were you able to test it?

Best regards.

Hi @lucas_az.tx ,

this means in production release I have to set the MAC-addresses for every board by hand?! Soon we will build hundreds of devices. I think this is not an option.

Best regards.

You could try a rule selecting by bus instead of mac address. Have a look at the output of:
udevadm info -a -p /sys/class/net/eth0
or whatever path you have for ethernet and compare it with your second interface. Then you can use these values in the rule, e.g. KERNELS==“20b4000.ethernet” contains the bus id of one of my custom boards I have at hand at the moment.

Hi @Crede,

thanks for your suggestion, I will try that.

Best regards.

@Crede, I have tested the output of udevadm on other boards and it is identical. I will go with your solution. Thank you.

Best regards.

As long as you have the same device tree where this is defined I see no issue. Good luck!