[SOLVED] systemd network predictable device names not so predictable?

kokoko3k · 2019-04-03 10:10:41

Since last upgrade, my boot now hangs because
the wifi interface i defined in a netctl profile has been renamed from wlp0s29u1u6 to wlp0s26u1u2
Is there something i am missing?
What's the point of leaving standard names like wlan0 and eth0 if the names i'll get changes?

Thanks.

Last edited by kokoko3k (2019-04-04 11:13:30)

amish · 2019-04-03 11:23:08

Such things have happened in past too.

Easiest way to fix such things forever is to have udev rule.

File: /etc/udev/rules.d/10-network.rules

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="00:11:22:33:44:55", NAME="mywlan0"

Do not rename to eth0 or wlan0 as it sometimes creates conflict in case there is already another card named the same by kernel.

Hence the prefix "my" will make sure that there is never a conflict.

seth · 2019-04-03 11:40:32

Or disable the renaming, https://wiki.archlinux.org/index.php/Ne … face_names

The effect is often caused by UEFI updates altering the bus numbers (or if you plug in a new PCI device)

kokoko3k · 2019-04-03 14:40:55

Yep, i was aware that it is possible to disable this "feature", but i would like to understand why it happened.
What does it mean UEFI update? my "bios" firmware is the same.
Also, i've no new usb peripherials attached.

progandy · 2019-04-03 14:49:36

kokoko3k wrote:

What's the point of leaving standard names like wlan0 and eth0 if the names i'll get changes?

The "predictable" names try to make sure you'll always get the same name with the same hardware and software setup. If you have multiple network interfaces, the standard kernel names could change each time you boot the systems depending on the order devices are probed and found by the kernel. This is more relevant for servers or other devicees with multiple network cards than personal machines.
Edit: ewaller has some good points that might make even the "predictable" names non-deterministic.

Is this an USB wifi device? Maybe you put it in a different usb port?

Last edited by progandy (2019-04-03 15:17:57)

ewaller · 2019-04-03 14:49:47

Then, perhaps the order in which your peripherals are enumerated is non-deterministic. If, on some boots, a device is slow to come up, it may be enumerated out of order. Or, perhaps if you do a warm boot vs a cold boot -- perhaps from a different OS -- things could be enumerated differently at the bus level. You might look at the journal can compare the results for the two different configuration states.

seth · 2019-04-03 14:52:13

wlp0s29u1u6
wlp0s26u1u2

The first number derives from the USB's pci slot, so there must have been *some* change itr.
If it's not a BIOS/UEFI updated and you didn't tamper w/ the HW (added/removed a PCI card etc), maybe you deactivated some device in the UEFI?

Edit:
+1 on progandy's edit: on a desktop system (let alone notebook) you're far better off by disabling this feature.

Last edited by seth (2019-04-03 14:55:11)

kokoko3k · 2019-04-04 11:13:04

Ok, sorry my fault; someone just unplugged my wifi card and replugged in another usb slot.
I'll make the device name static by using an udev rule based on the mac address.
Anyway, I can think at several ways to prevent this from happening, but this probably has to be implemented in systemd;
Complicated from the implementation point of view, but simple for the user: keep track of what has been assigned to a given device and use that for that mac address... forever!
Another one: for example the device name could be based on the mac address? A CRC-16 maybe? 0087240000ee -> WLAN-AA4B

I imagine systemd uses udev rules to rename interfaces, i'll try to find where it does to see if i can hack another naming scheme...

schard · 2019-04-04 11:29:39

kokoko3k wrote:

Another one: for example the device name could be based on the mac address? A CRC-16 maybe? 0087240000ee -> WLAN-AA4B

Systemd can do this but since MAC addresses are changeable, this also might not be "predictable".

progandy · 2019-04-04 11:38:34

schard wrote:

since MAC addresses are changeable, this also might not be "predictable".

That is only the case if some network manager catches the device before systemd can perform it's name change.

Last edited by progandy (2019-04-04 11:44:25)

kokoko3k · 2019-04-04 11:48:16

I second progandy.
I'm also learning about what can do systemd, and yes, it would write the whole mac address in the device name, but this is too much for me.
What i've found is this, see: http://reactivated.net/writing_udev_rul … nal-naming
Seems really powerful.

kokoko3k · 2019-04-04 12:04:42

Ok, i'm satisfied, look:

# cat /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", KERNEL=="wlan*", PROGRAM="/tmp/try.sh $attr{address}", NAME="wlan%c{1}"

#cat /tmp/try.sh
#!/bin/bash
echo "$1" |tr -d ':'

I issued udevadm control --reload-rules, replugged my interface, and now it is named as the mac address, it works.
Now i'm free to write my own predictable rules, i'm happy, at last!

--EDIT--
Found this: https://raw.githubusercontent.com/onsla … 6-table.sh and modified it a bit to just output the CRC; now my interface looks exactly as i wanted:
wlan-13bc

I know there may be collisions, but probably i won't see one in my entire life

-EDIT-
https://aur.archlinux.org/packages/net-names-crc16/

Last edited by kokoko3k (2019-04-04 13:09:41)

amish · 2019-04-05 08:24:26

Why run the program? If MAC is fixed - output of program will always be fixed too.

So udev rule as I suggested is faster without additional fork and exec.

SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="YO:UR:0M:AC:HE:RE", NAME="wlan-13bc"

I would not suggest "KERNEL="wlan*" in my udev rule above. Because if in future kernel naming changes and name does not start with "wlan", your rule will not get triggered.

Last edited by amish (2019-04-05 08:28:02)

kokoko3k · 2019-04-05 11:28:15

amish wrote:

Why run the program? If MAC is fixed - output of program will always be fixed too.

The new interface name will be auto-based on the nic mac address, no need to hand write any additional udev rule.
I find more convenient to just install the aur package i made and reboot, all set (and forget).

As a side note, IMHO this is far more "predicatable", but, most important, persistent!

amish wrote:

So udev rule as I suggested is faster without additional fork and exec.

Of course, this is true, but not enough for me to even notice it.

Last edited by kokoko3k (2019-04-05 11:32:11)

amish · 2019-04-05 14:14:02

Yes but when a have new wifi card, you will still have to change wifi name in netctl profile (because new CRC will not be same). And if you have iptables rules based on wifi interface names, you will have to change those rules too. (and any other place where u have specified wifi adapter name having CRC based number)

So either you change netctl profile (and iptables rules and other files) OR u just change MAC address in udev rule when you get a new wifi card, keeping the name same. (so no need to change the name anywhere else)

In my opinion second is more easy to do and persistent logically.

Last edited by amish (2019-04-05 14:15:09)

kokoko3k · 2019-04-06 06:07:18

Good point.

Arch Linux

#1 2019-04-03 10:10:41

[SOLVED] systemd network predictable device names not so predictable?

#2 2019-04-03 11:23:08

Re: [SOLVED] systemd network predictable device names not so predictable?

#3 2019-04-03 11:40:32

Re: [SOLVED] systemd network predictable device names not so predictable?

#4 2019-04-03 14:40:55

Re: [SOLVED] systemd network predictable device names not so predictable?

#5 2019-04-03 14:49:36

Re: [SOLVED] systemd network predictable device names not so predictable?

#6 2019-04-03 14:49:47

Re: [SOLVED] systemd network predictable device names not so predictable?

#7 2019-04-03 14:52:13

Re: [SOLVED] systemd network predictable device names not so predictable?

#8 2019-04-04 11:13:04

Re: [SOLVED] systemd network predictable device names not so predictable?

#9 2019-04-04 11:29:39

Re: [SOLVED] systemd network predictable device names not so predictable?

#10 2019-04-04 11:38:34

Re: [SOLVED] systemd network predictable device names not so predictable?

#11 2019-04-04 11:48:16

Re: [SOLVED] systemd network predictable device names not so predictable?

#12 2019-04-04 12:04:42

Re: [SOLVED] systemd network predictable device names not so predictable?

#13 2019-04-05 08:24:26

Re: [SOLVED] systemd network predictable device names not so predictable?

#14 2019-04-05 11:28:15

Re: [SOLVED] systemd network predictable device names not so predictable?

#15 2019-04-05 14:14:02

Re: [SOLVED] systemd network predictable device names not so predictable?

#16 2019-04-06 06:07:18

Re: [SOLVED] systemd network predictable device names not so predictable?

Board footer