interface old vs new naming

doc1623 · 2013-08-13 22:24:53

I'm new to arch. I installed 3.10.5-1-ARCH

Here
https://wiki.archlinux.org/index.php/Beginners'_Guide
it states
"Warning: As of v197, udev no longer assigns network interface names according to the wlanX and ethX naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named wlan0, or that your wired interface is named eth0. You can use the command ip link to discover the names of your interfaces."

and from here
https://wiki.archlinux.org/index.php/Ne … vice_names
"Device names
For motherboards that have integrated NICs, it is important to have fixed device name. Many configuration problems are caused by interface name changing.
Udev is responsible for which device gets which name. Systemd v197 introduced Predictable Network Interface Names, which automatically assigns static names to network devices. Interfaces are now prefixed with en (ethernet), wl (WLAN), or ww (WWAN) followed by an automatically generated identifier, creating an entry such as enp0s25.
This behavior may be disabled by adding a symlink:
# ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
Users upgrading from an earlier systemd version will have a blank rules file created automatically. So if you want to use persistent device names, just delete the file."

So I had a wireless interface wls2s0. New and different to me, but something I can get used to. But after reboot it all of the names changed back to the old names (well after two reboots, first the wireless was old but the regular nic was new). Old being eth0 wlan0.

I know from the same site above that I can manually make these persistant (below) but I would rather it be handled normally by the system without manual interference. Oh, and just in case you think I did something. The only net configuration that has been done was

systemctl enable dhcpcd.service

"Change device name
You can change the device name by defining the name manually with an udev-rule. For example:
/etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="net0"
A couple things to note:
To get the MAC address of each card, use this command: cat /sys/class/net/device-name/address
Make sure to use the lower-case hex values in your udev rules. It doesn't like upper-case.
Note: When choosing the static names it should be avoided to use names in the format of "ethX" and "wlanX", because this may lead to race conditions between the kernel and udev during boot. Instead, it is better to use interface names that are not used by the kernel as default, e.g.: net0, net1, wifi0, wifi1. For further details please see the systemd documentation."

on another note. Ifplugd sounds like it would be the best on a laptop? also on the live cd this worked

wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "ssid" "psk")

. So I guess I just need to set up a config file and I should be good?

Last edited by doc1623 (2013-08-13 22:37:08)

WonderWoofy · 2013-08-13 22:40:42

No, you did nothing wrong... I experience this sometimes too. There must be some kind of a race condition, and I have not been able to figure it out. I actually went the route of creating custom interface names, but even with that, this problem sometimes pops up. The system is still naming the interfaces by their old names upon boot. That is, they are still named "eth*" and "wlan*". It is just that with the /usr/lib/udev/rules.d/80-net-name-slot.rules, it renames them to something predicable. So it is not like this change brings about a totally different kernel namespace. It is really just udev putting this in action.

On one machine I use the new naming scheme, and it works fine. On another, I use the custom names because I have a broadcom wireless card, which shows up as an 'eth*' device. On another machine I use the old naming scheme because I have a wireless USB, and the name is something absolutely ridiculous at ~10 characters.

doc1623 · 2013-08-14 01:20:06

Ok. Thanks WonderWoffy

I know I'm new to Arch but that seems like something that should be fixed and on a fairly high priority.

Last edited by doc1623 (2013-08-14 01:20:29)

doc1623 · 2013-08-14 02:06:04

Looks like I did do something wrong. Or have yet to do something. The new rules obviously reside in the 80-net-name-slot.rules file or it wouldn't have you zero it out to revert. I have that file only in /usr/lib/udev/rules.d. It says it's in /etc/udev/rules.d/. I have the directory but nothing in it. Is there something I have yet to install that will fill that directory with files. The live cd has rule 81 in that directory but no other.

WonderWoofy · 2013-08-14 02:23:04

The things in /usr/lib (or /lib in other distributions) are meant to be handled by our package manager. That is, the admin *should* not need to touch that stuff. So in theory it should checksum the same from machine to machine if the same set of packages are installed with the same distribution.

/etc on the other hand is meant for you, the andministrator, to make changes to and configure as you see fit. So there is a directory /usr/lib/udev in which the contents are provided by the package manager. This is meant to be given secondary priority to the things in /etc/udev. So that is why the pacman output is telling you to create a symlink to /dev/null called /etc/udev/rules.d/80-net-name-slot.rules, which is the same name as the file (with contents) in /usr/lib/udev/rules.d. This is called "masking" because yu are effectively using one file to mask the other of the same name.

This can also be used if you want to change the contents of the udev rule from the original. Just copy the file from /usr/lib/udev to /etc/udev and then edit the file. Only the one that is in /etc will be applied.

The udev rule in archiso is called 81-dhcpcd.rules. It uses udev to automatically launch the dhcpcd@.service with the right interface name after the interface is detected.

ipyakuza1911 · 2014-02-20 00:57:57

I am running into this issue right now as well (still trying to figure out the proper way to resolve it) but basically if you follow this policy as per the documentation:

/etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="aa:bb:cc:dd:ee:ff", NAME="net1"
SUBSYSTEM=="net", ACTION=="add", ATTR{address}=="ff:ee:dd:cc:bb:aa", NAME="net0"

It will properly name the NIC's. The problem is a race condition with the systemd DHCPCD service, that beats the udev rules to the punchline and essentially names (and locks) the interface before the udev rule is able to apply your custom naming scheme. You can test this out by simply assigning the udev network rules (as noted above) and disable your systemd dhcpcd service (#systemctl disable dhcpcd) and reboot. You should see both your NIC's have the aliases you specified but obviously no dynamic ip assigned to them.

The correct solution now is how can I change the order of DHCPCD to start so that it requests IP settings AFTER the udev rules have been applied. That should be the proper way to get everything I need/want (I think). I am trying to setup a test VM so I can build my new firewall/security gateway but this naming race condition issue is challenging. It basically will interfere with my iptables scripts.

progandy · 2014-02-20 01:11:20

ipyakuza1911 wrote:

The correct solution now is how can I change the order of DHCPCD to start so that it requests IP settings AFTER the udev rules have been applied. That should be the proper way to get everything I need/want (I think). I am trying to setup a test VM so I can build my new firewall/security gateway but this naming race condition issue is challenging. It basically will interfere with my iptables scripts.

I guess you should consider starting dhcpcd only for specific interface names, e.g. dhcpcd@net0.service. You can also try to disallow the old naming scheme in dhcpcd.conf:

denyinterfaces wlan* eth* ppp*

ipyakuza1911 · 2014-02-20 01:17:12

Actually I think I found the correct way to do this. Basically I just had to go into the default systemd dhcpcd.service file (located at /usr/lib/systemd/system/dhcpcd.service and add one AFTER= clause:

After=sys-subsystem-net-devices-net0.device

Then re-enable the service.

This changed the order of DHCPCD starting to wait until the first NIC was named by udev as net0. After a reboot both NIC's were named properly and both acquired IP addresses.

WonderWoofy · 2014-02-20 03:29:17

First of all, you shouldn't be editing the files in /usr/lib. These should be either copied to /etc/systemd/system and edited there or drop-in snippets should be used.

Second, the dhcpcd@.service should wait for the /sys/subsystem/net/devices/net0 anyway since it has a BindsTo=sys-subsystem-net-devices-%i.device in it. Thus, you should be enabling dhcpcd@net0.service rather than the generic dhcpcd.service (though recently, I saw the author of dhcpcd mention that it is meant to be used such that the daemon is running all the time).

Arch Linux

#1 2013-08-13 22:24:53

interface old vs new naming

#2 2013-08-13 22:40:42

Re: interface old vs new naming

#3 2013-08-14 01:20:06

Re: interface old vs new naming

#4 2013-08-14 02:06:04

Re: interface old vs new naming

#5 2013-08-14 02:23:04

Re: interface old vs new naming

#6 2014-02-20 00:57:57

Re: interface old vs new naming

#7 2014-02-20 01:11:20

Re: interface old vs new naming

#8 2014-02-20 01:17:12

Re: interface old vs new naming

#9 2014-02-20 03:29:17

Re: interface old vs new naming

Board footer