(Re)Enabling predictable network interface names

This forum is for topics dealing with problems with software specifically in the ARMv6h repo.

(Re)Enabling predictable network interface names

Postby Falkenber9 » Tue Jan 07, 2020 2:48 pm

Hello,

on my RaspberryPi, network interfaces are named in the classic (unpredictable) manner, such as ``eth0``, ``eth1`` or ``wlan0``, ``wlan1``.

Is it possible to enable the predictable interface naming convention, such as ``enp3s0``, ``enp3s1``?
This is especially important when using many external interfaces.

The topic was already mentioned in the following thread, however, with no solution: viewtopic.php?f=9&t=12689


What I have already tried with no success (only one at a time):


1) Added ``net.ifnames=1`` to ``/boot/cmdline.txt `` - Reverse the proposal from https://wiki.archlinux.org/index.php/Ne ... rface_name

2) Add null rule: ``ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules``

3) Copy template rule: ``cp /usr/lib/udev/rules.d/80-net-setup-link.rules /etc/udev/rules.d/80-net-setup-link.rules``



Has anyone any other suggestions?



Regards
RF
Falkenber9
 
Posts: 3
Joined: Tue Jan 07, 2020 2:20 pm

Re: (Re)Enabling predictable network interface names

Postby Falkenber9 » Sat Jan 11, 2020 10:09 pm

Hello,

after diving deeper into the naming of network interfaces, I finally found a solution.

TL;DR:

Copy the systemd's default network link configuration file into /etc
$this->bbcode_second_pass_code('', 'cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link')

Change the name policy list from
$this->bbcode_second_pass_code('', 'NamePolicy=keep kernel database onboard slot path')
to
$this->bbcode_second_pass_code('', 'NamePolicy=keep kernel database onboard slot path mac')

Afterwards, the RaspberryPi's network interfaces will be named according to their internal MAC addresses, i.e. enx########### or wlx############ where ############ being the MAC address (hex) without any separators.

Possible drawbacks(*):

1) Interface names are long and hard to remember.
2) Any hardware changes (e.g. migrate to other RaspberryPi or change external interfaces), interface names will change, too. Take care of your scripts.



Now a more detailed explanation:

First of all, predictable interface names are not disabled for RaspberryPi but have kind of limited support.
By default, udev assigns names to each interface according to the rules in
/lib/udev/rules.d/80-net-setup-link.rules
and the value of the variable $env{ID_NET_NAME}
That variable is part of systemd's builtin "net_setup_link" for network link configuration (https://www.freedesktop.org/software/systemd/man/systemd.link.html) which is triggered/called by the udev rule to fill the variable accordingly.

The builtin parses configuration files within /usr/lib/systemd/network/* , in particular defaults from /usr/lib/systemd/network/99-default.link
It includes a (space-separated) list of naming policies that shall be tried out sequentially to generate an interface name and set the varibale ID_NET_NAME (which is used by the udev rule afterwards).

The default policy list is "NamePolicy=keep kernel database onboard slot path"; the meaning of the values is described in the URL above.
This list is processed sequentially until an entry delivers a valid value.
However, the policies "slot" and "path" which are mostly responsible for the predictable interface names (e.g. enp3s0) on common PCs, don't work with RaspberryPi. (Maybe because that platform has no PCI bus, and the typical names are derived from PCI slots - but this is only an assumption, I haven't verified that)
In fact, generally, all of the listed policies fail on RaspberryPi and the name falls back to the "classic" unpredictable interface name like "eth0".

The default settings can be overridden by masking the default 99-default.link file with a customized file of the same name in /etc/systemd/network/

By appending the policy list with the "mac" policy as described above, systemd additionally tries to provide an interface name according to the internal MAC address (if available).

This works on all my RaspberryPi 3B and 3B+ with both, the builtin interfaces and several external USB network interfaces.

(*) Finally, it may be desired to overcome the two listed drawbacks for some explicit interfaces, e.g. naming the embedded Wifi interface "wifi" on any Pi (of the same model). The remaining interfaces will be named as specified before.
To achieve this for a RaspberryPi 3B+, add a new udev rule, e.g. in a new file /etc/udev/rules.d/10-net-embedded.rules with the following content:
$this->bbcode_second_pass_code('', 'SUBSYSTEM=="net", DEVPATH=="/devices/platform/soc/3f300000.mmcnr/mmc_host/mmc1/mmc1:0001/mmc1:0001:1/net/*", NAME="wifi"')
See https://wiki.archlinux.org/index.php/Network_configuration#Change_interface_name for more details about this explicit assignment.

Best Regards
RF
Falkenber9
 
Posts: 3
Joined: Tue Jan 07, 2020 2:20 pm

Re: (Re)Enabling predictable network interface names

Postby keithspg » Sat Feb 29, 2020 4:24 pm

This works perfectly... for the ethernet connection.

I am trying to move to connman from netctl and my scripts are all over the place. I am investigating converting to mac addresses as that
is what connman uses. The instructions here worked beautifully to get my ethernet to use its mac, but the WiFi still shows up as wlan0. How do I get it to use its MAC as well?

Regards,

Keith
keithspg
 
Posts: 221
Joined: Mon Feb 23, 2015 4:14 pm

Re: (Re)Enabling predictable network interface names

Postby Falkenber9 » Sun Mar 01, 2020 2:01 pm

Hi Keith,

I have just verified the steps above on another Raspberrypi 3B+ using Kernel "linux-rasperrypi 4.19.105-1" (system updated today).
It still works for both, ethernet and wlan, as well as for another usb wlan adapter.
All interfaces are enmumerated by their MAC and a corresponding prefix "enx" or "wlx".

Are you also on Raspberrpi 3B+, or on a different platform?

Depending on the platform and the interface, a MAC may be not available in the system stage when the naming policies are applied on that particular device. But this is only a guess.



You can validate your configuration by running

$this->bbcode_second_pass_code('', '$ udevadm --debug test /sys/class/net/<YOUR-INTERFACE-NAME>')

The output on my machine gives me the following line with the mac policy appended in 99-default.link (I changed the last four digits for privacy):
$this->bbcode_second_pass_code('', '...
eth0: Policy *mac* yields "enxb827ebe0ffff".
...
')


and without the mac entry:
$this->bbcode_second_pass_code('', '...
eth0: Policies didn't yield a name and Name= is not given, not renaming.
...
')


Furthermore, you can check the available values the builtin detects for the device:

$this->bbcode_second_pass_code('', '$ udevadm info /sys/class/net/<YOUR-INTERFACE-NAME>')



Hope this help you to find a clue...



Regards
RF
Falkenber9
 
Posts: 3
Joined: Tue Jan 07, 2020 2:20 pm


Return to ARMv6h

Who is online

Users browsing this forum: No registered users and 5 guests