1

Given this kernel problem awaiting to be fixed and that randomly assign mac address to this usb3 lan adapters: Debian 12 - All of sudden my USB3 Lan adapter get assigned random mac address each reboot

I'm trying to find a workaround aside custom recompiling kernel with a patch or use an old kernel version.

Basically all my interfaces configuration is based on custom names obtained by using a udev config file 70-persistent-net.rules (certain interfaces are renamed based on their mac address, but given the above bug this doesn't work anymore).

By looking the syntax of udev files /etc/udev/rules.d/70-persistent-net.rules

My conf have various lines like:

SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{address}="00:....", ATTR{dev_id}="0x0", ATTR{type}="1", KERNEL="eth*", NAME="lan1"

Now what I have discovered by calling the command:

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

and the same with eth2, eth3, eth4, eth5...

is that there's an ATTR interesting to identify uniquely the interfaces.

It's an attr called "serial" but is not available for eth1, eth2... but for their direct parent dev.

Indeed the command starts by saying looking at device ... but after it says looking at parent device ...

So I'm wondering if I can do something like:

SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{parent>serial}="00000003", ATTR{dev_id}="0x0", ATTR{type}="1", KERNEL="eth*", NAME="lan1"

using the parent serial instead of base the config on the mac address to rename the lan interface.

DO a syntax like this exists?

Thanks

1 Answer 1

1

It seems that I've found an answer to that by this post: How are USB devices uniquely distinguished?

Reading this ref: https://www.reactivated.net/writing_udev_rules.html

It seems that you can mix single parent ones with the actual level by using ATTRS, so using ATTRS{serial} instead of ATTR{address} and using the serial provided by udevadm info -a -p /sys/class/net/eth1 do the job.

Example:

SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTRS{serial}=="00000000000094", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="lan1"

So I reverted using the latest Linux kernel while waiting that debian developers will put the patch in upstream channel so that the mac in the eeprom can be read. A workaround for now, but a solid one.

The only fun part is that if the devices have no attached cables both lan1 and eth0 will be present in my case, lan1 active and "weirdly" getting the correct mac address and the eth0 still down with the random mac address one.

EDIT: This worked until I found that some devices shares the same serial ¯_(ツ)_/¯ sooo I started using directly the usb root bus number and device number for uniquely identifying the adapters, given the fact I always leave them in place without moving them. Check for this the question: Use usb path of an usb nic address in udev rules in order to assign an interface name instead of mac address

3
  • Good idea. Personally I also set back the original MAC address (using RUN+="/bin/ip ...". Many such devices are multi-NICs devices (mine is dual), and without setting the MAC address, they will all have the same value, possibly causing other problems. Also the ("net") attribute ATTR{addr_assign_type}=="1" can be checked: it means a random (instead of permanent) address was chosen. So when the bug is not present, the rule will do nothing.
    – A.B
    Commented Apr 17 at 18:59
  • 1
    Thanks, I used the double equal and it works now! My bad, I was focused on the content and missed the equal and double equal checks. Commented Apr 18 at 21:30
  • I fixed it in the answer.
    – A.B
    Commented Apr 18 at 23:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .