systemd, eth0 renamed as enxb827eb84edc9: why? - Page 1
Forum section: electronics / general

author: DiTBho
author_rank: Super Contributor
timestamp: April 20, 2022, 03:53:20 pm
content: I am becoming crazy, a friend bought a RPI-3, which comes with a systemd-GNU/Linux image, and there is systemd, and I don't know why, the eth0 is renamed "enxb827eb84edc9"annoying ...any idea?

author: ataradov
author_rank: Super Contributor
timestamp: April 20, 2022, 04:56:04 pm
content: https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/

author: golden_labels
author_rank: Super Contributor
timestamp: April 20, 2022, 05:57:50 pm
content: Also note that this is udev’s doing, not systemd’s. While udev has been incorporated into systemd, the latter as a whole is not responsible for the situation. And udev daemon may be provided by other software packages, likeeudev.The renaming is in full described in ataradov’s link, but shortly: it’s the network devices equivalent of UUIDs and “by-*” paths for storage media. A less annoying and reliable way to specify the device.Out of curiosity: what was the friend using earlier? That change is like 2014 if not earlier.

author: DiTBho
author_rank: Super Contributor
timestamp: April 20, 2022, 06:37:32 pm
content: Quote from: golden_labels on April 20, 2022, 05:57:50 pmGentoo-2011. Static dev-name, so there is no udev running.I am studying systmed because I don't know it well.Thanks guys, problem solvedCode:# ifconfig -aeth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500inet 192.168.1.101 netmask 255.255.255.0 broadcast 192.168.1.255inet6 fe80::ba27:ebff:fe84:edc9 prefixlen 64 scopeid 0x20<link>inet6 2001:b07:5d37:d900:ba27:ebff:fe84:edc9 prefixlen 64 scopeid 0x0<global>ether b8:27:eb:84:ed:c9 txqueuelen 1000 (Ethernet)RX packets 7564 bytes 578980 (565.4 KiB)RX errors 0 dropped 0 overruns 0 frame 0TX packets 4480 bytes 489060 (477.5 KiB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536inet 127.0.0.1 netmask 255.0.0.0inet6 ::1 prefixlen 128 scopeid 0x10<host>loop txqueuelen 1000 (Local Loopback)RX packets 13 bytes 1823 (1.7 KiB)RX errors 0 dropped 0 overruns 0 frame 0TX packets 13 bytes 1823 (1.7 KiB)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0wlan0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500ether b8:27:eb:d1:b8:9c txqueuelen 1000 (Ethernet)RX packets 0 bytes 0 (0.0 B)RX errors 0 dropped 0 overruns 0 frame 0TX packets 0 bytes 0 (0.0 B)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0wlan1: flags=4098<BROADCAST,MULTICAST> mtu 1500ether 00:1d:0f:b1:b1:a6 txqueuelen 1000 (Ethernet)RX packets 0 bytes 0 (0.0 B)RX errors 0 dropped 0 overruns 0 frame 0TX packets 0 bytes 0 (0.0 B)TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

author: Monkeh
author_rank: Super Contributor
timestamp: April 20, 2022, 06:43:42 pm
content: Quote from: golden_labels on April 20, 2022, 05:57:50 pmBut despite the name, not readily predictable across varying hardware, which is incredibly annoying.Also their default scheme can be easily proven broken, but they're entirely uninterested in feedback or improvement. Their way is perfect as implemented.

author: madires
author_rank: Super Contributor
timestamp: April 20, 2022, 06:54:24 pm
content: Create /etc/systemd/network/10-eth0.link:Code:MACAddress=11:22:33:44:55:66Name=eth0

author: golden_labels
author_rank: Super Contributor
timestamp: April 20, 2022, 09:23:27 pm
content: Quote from: DiTBho on April 20, 2022, 06:37:32 pmThough in this case you will not learn much about systemd,(1)as that’s not related. Coincidently systemd, the project, adopted udev shortly before the introduction of predictable names. But the change is a part of a much wider movement to make Linux ecosystem more reliable and has nothing to do with udev being under the umbrella of a particular project.Quote from: Monkeh on April 20, 2022, 06:43:42 pmAcross varying hardware? How can a device name, that makes sense only on a single machine, be predictable across multiple of them? That’s not even specific to udev: old naming scheme was not having that property either.Quote from: Monkeh on April 20, 2022, 06:43:42 pmPerhaps… anything concrete?(1)Madires has proven above thatsomethingcan still be learned.

author: Monkeh
author_rank: Super Contributor
timestamp: April 20, 2022, 11:27:49 pm
content: Quote from: golden_labels on April 20, 2022, 09:23:27 pmOld scheme, single NIC: 'eth0'. New scheme, single NIC: 'fuck knows'.QuoteAny NIC with two or more ports on the same PCI function will break it.

author: BrokenYugo
author_rank: Super Contributor
timestamp: April 21, 2022, 02:30:27 am
content: Quote from: Monkeh on April 20, 2022, 11:27:49 pmThis, it might make sense in a datacenter, but in my living room it's just another string of alphabet soup I have to deal with.

author: ve7xen
author_rank: Super Contributor
timestamp: April 21, 2022, 02:35:33 am
content: In your living room you don't need to know or care what the kernel's name for the device is... You click 'Wired Network Connection' and it comes up.systemd-networkd at least allows configuring NICs either by type or by wildcarded names, or by MAC address if for some reason you need a machine-portable configuration or your hardware changes often.

author: golden_labels
author_rank: Super Contributor
timestamp: April 21, 2022, 04:04:59 am
content: Quote from: Monkeh on April 20, 2022, 11:27:49 pmExcept… no? In the old scheme even on a single machine the name was random and could be eth1 on one boot and eth4 on another. Across multiple machines there was no predictability at all.Quote from: Monkeh on April 20, 2022, 06:43:42 pmNo? They will get a different f-index. Which may still be unpredictable, if the adapter reports ports in random order, but that’s nothing that can be solved in a general manner and the old naming could not deal with that either.Quote from: BrokenYugo on April 21, 2022, 02:30:27 amSo… a bug should be introduced to “living-room implementations” that makes the names broken, because it’s not a datacenter? For… actually what, considering that to you it’s just “alphabet soup” anyway? Will you also oppose UUIDs or “by-*” hierarchy for mass storage, because your laptop only has a single device of that kind?

author: Monkeh
author_rank: Super Contributor
timestamp: April 21, 2022, 04:22:49 am
content: Quote from: golden_labels on April 21, 2022, 04:04:59 amErr? No, it wasn't random, they're allocated sequentially. If only one ethernet device is present, it will be eth0.QuoteThere's no 'f' to index - f is function, if there is only one PCI function then both interfaces will get assigned the same name, which will break and leave the second interface with its original name. It's possible they've revised the scheme to resolve this in the years since I last wasted my time with it, of course..

author: golden_labels
author_rank: Super Contributor
timestamp: April 21, 2022, 04:50:44 am
content: Quote from: Monkeh on April 21, 2022, 04:22:49 amIf there is only a single device present, then this is not even a subject of the discussion about naming interfaces. Why do you bring that up?Quote from: Monkeh on April 21, 2022, 04:22:49 amNo indices, but functions? And “function” is expressed in the name as…

author: Monkeh
author_rank: Super Contributor
timestamp: April 21, 2022, 05:05:11 am
content: Quote from: golden_labels on April 21, 2022, 04:50:44 am.. how many ethernet interfaces does a Raspberry Pi have? Whether there is one interface or many, this naming scheme is used - and the outcome is not predictable even with only a single device.QuoteWhen it's '0', it isn't.Maybe I should fire up one of my example devices to demonstrate the flaw if it's still present.

author: Ed.Kloonk
author_rank: Super Contributor
timestamp: April 21, 2022, 05:06:01 am
content: Quote from: Monkeh on April 20, 2022, 11:27:49 pm

author: magic
author_rank: Super Contributor
timestamp: April 21, 2022, 06:04:33 am
content: Quote from: golden_labels on April 20, 2022, 09:23:27 pmQuote from: golden_labels on April 20, 2022, 09:23:27 pmThis word is a well known far-right dog whistle and the whole paragraph sounds an awful lot like you are not a sincere supporter of LinuxⓇ on the Desktop™ but a troll mocking systemd's heroic effort and denying them credit for their work. I'm considering reporting this post for hate speech, just so you know that you can't get away with it here.Quote from: madires on April 20, 2022, 06:54:24 pmHere's a much faster solution that has been working for me since forever:Code:ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

author: ve7xen
author_rank: Super Contributor
timestamp: April 21, 2022, 06:46:01 am
content: Quote from: Monkeh on April 21, 2022, 04:22:49 amThe kernel will allocate them sequentially by default during a single boot, but many *systems* will persistently save the 'eth0' name / MAC address binding and ensure it doesn't randomly change to a different interface if you e.g. plugged in a USB NIC since last boot or your multiple NICs come up in unpredictable order or whatever. This was pretty standard for many years until the udev scheme came along, and is pretty 'random' and 'unpredictable' if you don't know it's happening. It can easily lead to your only NIC being eth4 or something after you've done some upgrades.QuoteDon't have such a device to test, but the code suggests it will get an enp0s0f0dN identifier based on a kernel-provided port-id.Never mind that the OP question is about the MAC address format which doesn't suffer any of these complications...

author: magic
author_rank: Super Contributor
timestamp: April 21, 2022, 07:26:50 am
content: Quote from: ve7xen on April 21, 2022, 06:46:01 amEverything suffers complications with systemd.QuoteFor a machine with one or two onboard NICs and maybe an occasional USB dongle connected for 5 minutes it's a nobrainer to disable all that crap. I do it on all my home systems.

author: ve7xen
author_rank: Super Contributor
timestamp: April 21, 2022, 08:45:30 am
content: Quote from: magic on April 21, 2022, 07:26:50 amYou systemd haters really just can't leave the opportunity to troll un-trolled, can you?The name of your network interface doesn't matter at all in 99.9% of systems, and if it does, the predictable naming is probably what you want, so whatever configuration you have that depends on the name is always guaranteed to apply to the same interface regardless of driver loading order or whatever.If you want the naive and unpredictable ethN system for some reason, you would know this, because you'd have some specific reason, and know to disable it. Otherwise, who cares.QuoteFor such a machine it doesn't matter at all what the name of the NICs is, as long as it/you can identify them consistently to apply the correct configuration. Which the persistent naming only helps with. I really don't get you people, the problems with ethN are so obvious; something as trivial as a driver change in the kernel that changes initialization order or even fiddling with /etc/modules can mess it up (without the previously-used persistence hack at least), and this can lead to the machine being totally unreachable over the network which can be a serious problem. Most Linux desktop setups apply your network configuration to any available interface of the correct type anyway, and that's usually exactly the behaviour you want.

author: magic
author_rank: Super Contributor
timestamp: April 21, 2022, 08:54:04 am
content: So far I have seen more name changes due to systemd updates than due to kernel updates, that's the point.See the wiki somebody linked. They say that MAC addresses are not used by default. Now, apparently they are, perhaps as a fallback when all else fails. Next year, an update will come which fill find some "clever" name for RPi's built-in NICs and the name will change once again...

author: madires
author_rank: Super Contributor
timestamp: April 21, 2022, 11:11:28 am
content: Originally interface names were assigned when the kernel (or driver module) was looking for network interfaces. Based on the mainboard and BIOS the scan started at the top or bottom card slot. Later onboard ethernet added more naming fun. If you have just a single NIC/ethernet port this doesn't matter much. SInce there's only one ethernet port it always got eth0. But if you have more than one you'll have a naming problem when changing, adding or removing a NIC. Which NIC will get which name? Back then you would use driver modules with specific parameters to get some kind of persistent naming but It didn't work for all drivers. When udev came along it allowed a more simple solution for persistent naming (/etc/udev/rules.d/70-persistent-net.rules). After changing any NIC simply update the udev rule and you're done. However, the old eth naming scheme still has some drawbacks when using multiple NICs or NICs with multiple ports. Which port was eth7? To find out which port is eth7 or vice versa you have to check several things - it's cumbersome. Therefore we have now a new scheme for predictable interface names which supports several variants. Seehttps://systemd.io/PREDICTABLE_INTERFACE_NAMES/for a brief intro. One variant uses the physical location (like professional network elements do), e.g. enp2s5. Another uses the MAC address, like RasPi's new distri.

author: ve7xen
author_rank: Super Contributor
timestamp: April 21, 2022, 11:27:16 am
content: Quote from: magic on April 21, 2022, 08:54:04 amEh, I have definitely seen the opposite. Machines (routers) with multiple identical NICs have not had deterministic startup order in my experience. This was 'fixed' at some point with the previous persistence hacks, but it is definitely a problem. In addition to the unpredictability with adding/removing NICs and iding the ports.The systemd policies have changed over time, generally to add granularity where collisions are possible, but I have not seen them actually have an impact on real systems. You have multiple options to address this, if you deem it to be a problem. There are no ways to address the issues with the kernel ordering.Use the MAC naming policyFix the naming scheme based on whatever version of systemd you set the system up withDefine custom links for your interfaces and name them whatever you want, predictably based on whatever match parameters you want (path, driver, whatever)QuoteThe defaults from systemd don't use the MAC at all. But the 'default' is just shipped as a default policy '99-default.link' and gets included in the link policy at runtime. The distribution may change this shipped policy or add rules (e.g. debian adds 73-usb-net-by-mac.link which always uses the MAC policy for USB devices only, since many RPi boards have USB NICs, I assume that's what's happening here).If this policy changes frequently, you can take it up with your distribution. I'd expect enterprise-oriented distros might fix the default naming policy, at least within a major distro release, but I can't be bothered to check. If you really care, you can do this manually in your kernel command line, though.Canonical:https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html(the other link above is deprecated).

author: DiTBho
author_rank: Super Contributor
timestamp: April 21, 2022, 12:36:56 pm
content: bah, I have three routers hererb532, with two Korina 10/100Mbps Ethernet modules, plus the SoC built-in Lth* 10/100Mbps onersp, with thee Koz 10/100/1000Mbps Ethernet modules, plus the SoC built-in Ath* 10/100Mbps oneHelx+dual-QuadTulip, with eight Tulip 10/100/1000Mbps Ethernet modules, plus the SoC built-in Eth* 10/100Mbps oneSo, a lot of Ethernet interfacesThe Helx (also known as "Hell", there must be a good reason for this -> maybe too many ports?!?) has { eth0, eth1, eth2, eth3, eth4, eth5, eth6, eth7, eth9 }The only assigned IP is the one assigned to the bridge, which is br0, to which all the Ethernet ports are attached.This setup is for a lan-switch

author: bson
author_rank: Unknown
timestamp: May 02, 2022, 06:41:54 pm
content: A bigger problem is with USB ethernet adapters, where you set up firewall and DHCP rules. Then move it from one port to another, and now it's an entirely new interface...

author: Monkeh
author_rank: Super Contributor
timestamp: May 02, 2022, 08:00:54 pm
content: Code:2: enp2s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000link/ether 00:00:5a:74:2e:f2 brd ff:ff:ff:ff:ff:ff3: eth1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000link/ether 00:00:5a:74:2e:f3 brd ff:ff:ff:ff:ff:ff4: enp0s7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000link/ether 00:e0:4d:a0:7d:48 brd ff:ff:ff:ff:ff:ffOh no, what happen?Code:[root@localhost-live ~]# udevadm test-builtin net_id /sys/class/net/enp2s0...Using default interface naming scheme 'v249'.ID_NET_NAMING_SCHEME=v249ID_NET_NAME_MAC=enx00005a742ef2ID_OUI_FROM_DATABASE=SysKonnect GmbHID_NET_NAME_PATH=enp2s0...[root@localhost-live ~]# udevadm test-builtin net_id /sys/class/net/eth1...Using default interface naming scheme 'v249'.ID_NET_NAMING_SCHEME=v249ID_NET_NAME_MAC=enx00005a742ef3ID_OUI_FROM_DATABASE=SysKonnect GmbHID_NET_NAME_PATH=enp2s0...Oh no, is broke. If only someone could have told them 9 years ago this wouldn't work in the real world. Wait, we did.Legitimately a kernel bug today - but it wasn't then and it wouldn't be a bug if they didn't make it one.Quote from: bson on May 02, 2022, 06:41:54 pmThat would be why certain distros apparently use MAC-based names for USB devices.