Trouble with udev rule for network interace naming

battlepanic · 2012-08-10 20:09:27

I've been occasionally having problems with my system assigning the wrong names to my network interfaces. My system has both a wired and wireless network card; the wired network card is usually assigned the name "eth0" whereas the wireless card gets named "eth1". However, while booting, my system sometimes reverses the naming and this screws up the network initialization.

I'm not exactly sure what is going on, but it looks like each card's respective network driver, e100 (wired card) and ipw2200 (wireless card) are both asking for the name "eth0". Usually, the wired card gets "eth0" but this is not always the case and my understanding is that this is because the order in which devices are initalized is not guaranteed.

In a previous post I was advised that a simple udev rule mapping an interface name to a specific MAC address would fix things. So, I created a file named /etc/udev/rules.d/10-network.rules with the following:

SUBSYSTEM=="net", ATTR{address}=="00:13:cd:0c:25:55", NAME="wlan0"
SUBSYSTEM=="net", ATTR{address}=="00:01:4a:77:12:25", NAME="eth0"

The above udev rules identify each card based on their respective MAC addresses and explicity assign a name to each. I gave the wireless card the name "wlan0" to make it easy to distinguish the two. Despite the above rules, the wired network card is still sometimes being named "eth1" which then causes my network initialization to fail.

I don't understand why the wired device is sometimes being named "eth1" despite the above rules. Can anyone provide a means keeping the network device naming straight?

Last edited by battlepanic (2012-08-10 21:22:43)

alphaniner · 2012-08-10 21:06:48

Check out this thread.

My two cents: your rules file would work just fine if udev was working right. I have four nics and used 10-network.rules on Arch for years with no problems until recently. Now, instead of using the names eth[0-3] I have to use net[0-3]. It seems that using any of the names which would be used by the system causes problems.

It seems the best solution right now is to change the name of your wired device to... well basically anything other than eth[0-1]. And of course, you'll need to modify any configs/scripts/etc which referenced eth0.

Last edited by alphaniner (2012-08-10 21:07:40)

battlepanic · 2012-08-11 14:24:20

alphaniner wrote:

It seems the best solution right now is to change the name of your wired device to... well basically anything other than eth[0-1]. And of course, you'll need to modify any configs/scripts/etc which referenced eth0.

Thanks for the tip. I've changed the udev rule to name the wired interface to "net0". I've also updated any configuration files referencing the interface by name. This seems like it should do the trick until a proper fix comes along.

battlepanic · 2012-08-11 14:37:16

It occured to me that if this is indeed a problem with udev a bug report should probably be filed. I had a look at http://bugs.archlinux.org but couldn't find anything relevant. Does anyone know if this issue has been reported?

tomegun · 2012-08-11 16:05:09

This is a known limitation, and cannot be fixed. Changing the kernel names is fundamentally racy (if you rename eth0 to wlan0 and another card with name wlan0 appears in the middle of this, you get trouble, etc).

What can work is to rename everything to names outside of the kernel's namespace (i.e. avoid ethX and wlanY, and use netZ or something like that).

battlepanic · 2012-08-11 19:32:35

I feel a bit stupid. I use my wired network adapter now, but in hindsight I think this may explain why Arch was occasionally unable to bring up my wireless connection. Man, that problem plagued my system for well over a year. During boot, I was sometimes getting ioctl errors related to the network interface, probably because the system was trying to do wireless stuff on a wired device. Being the ignorant fool that I am, I didn't know what was wrong, I just knew that rebooting usually fixed things. I chalked it up to old hardware and a crappy wireless driver. The fact that I didn't have this problem with other distros on the same hardware should have been my first clue that this was probably not the cause.

Picking a safe name that is outside of the kernel's namespace (eth*, wlan*, any others?) is easy enough. I don't care what things are named so long as those names are persistent, or, at the very least, consistent with whatever my network configuration references.

In any event, I finally have a network connection that should be able to work reliably even after rebooting. In the past, I could never reboot the system remotely and be sure that I could log back in.

Out of curiosity, does anyone know the details behind why can't this can't be fixed? Is the limitation unique to Arch or to udev itself?

KimTjik · 2012-08-11 19:55:59

You find that Fedora (I don't know about others) have changed the naming scheme to ease the work for system administrators. Hence it looks like we anyway are moving away from ethX and the reason looks sane.

I don't know the answer on your question. The only reason I can see is that it would demand total control of boot events to exclude collisions between kernel space names and udev rules. It's only a guess though.

tomegun · 2012-08-12 00:24:52

The reason it can't be fixed is that it is a race between udev and the kernel. You never know when "all the network devices are ready, so we can start renaming them".

Btw, "modern" network management daemons (NetworkManager, wicd, connman,...) should not care about the name of your interfaces, as far as I know, so if you use something like that this can be ignored.

alphaniner · 2012-08-13 13:24:05

@tomegun

The fact that it worked flawlessly for me (not a single exception) with four to six devices for a combined 6+ years on Arch, Ubuntu, and CentOS, then broke catastrophically with one update (Arch), makes me a bit suspicious of your explanation. I find it hard to believe that "You never know when all the devices are ready." For goodness sake, I can tell when all devices are ready, and all I have is the information presented to me by the system. So how is it that the system can't make the same determination?

I understand this isn't a problem the Arch Devs can solve, and if you're talking solely from that perspective then I apoligize. This is clearly an upstream problem; I just can't believe it's insoluble.

KimTjik · 2012-08-13 18:26:56

Do you dislike the new naming scheme? The difference though might be that others, like Fedora, implement it automatically while we'll do it manually. I don't know which.

I've had the same experience, but not with that many network devices as you, and for approximately 2 years. I also had to change the rule. I doubt however that it will be viewed as a problem upstream since ethX naming gets dropped all together.

alphaniner · 2012-08-13 18:48:02

KimTjik wrote:

Do you dislike the new naming scheme?

I don't see it as 'new' so much as broken. All things considered, having to modify my scripts, configs and - worst of all - habits is not a big deal. But I also have to deal with the other (non-Arch) systems I manage which aren't broken (yet?). Do I modify my scripts to accommodate both "schemes", or do I proactively break <shudder> the scheme on the other systems? Sure, all this is peanuts comapred to the work it would take upstream to unbreak things. But multiplied over all the users who have to accommodate this change, I think that balance changes.

Ah well, I guess that's the price of open source.

tomegun · 2012-08-13 19:15:26

alphaniner wrote:

The fact that it worked flawlessly for me (not a single exception) with four to six devices for a combined 6+ years on Arch, Ubuntu, and CentOS,

The plural of "anecdote" is not "data" ;-P Sure in almost all cases this will work just fine. However, it can never work in all cases, so it is being fixed it in such a way that (once configured correctly) it will always work for everyone.

then broke catastrophically with one update (Arch), makes me a bit suspicious of your explanation.

We are not doing anything non-standard here. This change will trickle down to the other distros once they update their software.

I find it hard to believe that "You never know when all the devices are ready." For goodness sake, I can tell when all devices are ready, and all I have is the information presented to me by the system. So how is it that the system can't make the same determination?

You can only know that if you know how many devices you are waiting for. These things can be hotplugged, and that is essentially what happens during boot. The devices appear as soon as they are "found" by the kernel, and there is no notion of "finished looking for devices, nothing more can ever appear".

Don't take my word for any of this though, I'm not an expert. However, there has been plenty of discussions on the hotplug/udev and lkml mailinglists that you could look to if you are interested.

alphaniner · 2012-08-13 19:48:55

tomegun wrote:

You can only know that if you know how many devices you are waiting for.

At the very least, waiting (with a timeout) for all the devices in the rules file seems logical...

We are not doing anything non-standard here. This change will trickle down to the other distros once they update their software.

I understand and didn't mean to suggest otherwise.

it is being fixed it in such a way that (once configured correctly) it will always work for everyone.

If this means I'll be able to go back to ethX naming at some point, that's all that really matters to me.

tomegun · 2012-08-14 13:48:20

alphaniner wrote:

If this means I'll be able to go back to ethX naming at some point, that's all that really matters to me.

It does not. The ethX namespace is owned by the kernel so udev won't touch it. If you name your devices something else lanY for instance, and configure the rest of your system accordingly, then everything will work as it should.

Alternatively there is some work underway by RedHat (if I remember correctly) which will automatically configure reliable names without you having to write any rules (but also these will not be in the ethX namespace).

bachtiar · 2013-01-15 12:00:29

I am also unable to rename network interface via /etc/udev.d/10-network.rules.

I followed the instructions on wiki, but my devices are still called eth0 and eth1. It seems like udev is ignoring the rules.

Has this problem been solved perhaps by anyone reading this?

alphaniner · 2013-01-15 14:03:13

You have to choose another naming scheme, like netX. That's what I ended up doing:

$ ethall

[net0]
 10.10.1.2
 100Mb/s
 264.64K / 47.71K

[net1]
 192.168.1.110

[net3]
 199.200.1.110
 1000Mb/s
 35.10K / 63.26K

Note the device names in [ ].

Last edited by alphaniner (2013-01-15 14:06:34)

Leonid.I · 2013-01-15 16:44:39

Remember, there is no practical limitation on the iface name length, so mnemonic names such as "external_nic" are OK On a multihomed system I usually call interfaces as "wan", "lan" or "wap" (for wireless AP)...

However, if you prefer confusing numbered names, with the next systemd release it will be done automatically: https://mailman.archlinux.org/pipermail … 24223.html

bachtiar · 2013-01-15 17:07:45

I was trying to rename eth0 to lan0 and eth1 to lan1. As said, eth0 is still eth0 and eth1 is still eth1 - my rules are being ignored.

Leonid.I · 2013-01-15 17:33:06

bachtiar wrote:

I was trying to rename eth0 to lan0 and eth1 to lan1. As said, eth0 is still eth0 and eth1 is still eth1 - my rules are being ignored.

Can you post your ruleset? For reference, here is mine (which works)

% cat /etc/udev/rules.d/10-network.rules
SUBSYSTEM=="net", ATTR{address}=="XX:XX:XX:XX:XX:XX", NAME="wan"
SUBSYSTEM=="net", ATTR{address}=="XX:XX:XX:XX:XX:XX", DRIVERS=="ath9k", KERNEL!="mon.wap", NAME="wap"
SUBSYSTEM=="net", ATTR{address}=="XX:XX:XX:XX:XX:XX", NAME="elan0"
SUBSYSTEM=="net", ATTR{address}=="XX:XX:XX:XX:XX:XX", NAME="elan1"

where "XX:XX:XX:XX:XX:XX" are MACs of different cards. The second line is for the wifi interface.

bachtiar · 2013-01-17 09:04:35

It turned out that I had a typo - I was using round brackets instead of curly brackets. Thank you.

Arch Linux

#1 2012-08-10 20:09:27

Trouble with udev rule for network interace naming

#2 2012-08-10 21:06:48

Re: Trouble with udev rule for network interace naming

#3 2012-08-11 14:24:20

Re: Trouble with udev rule for network interace naming

#4 2012-08-11 14:37:16

Re: Trouble with udev rule for network interace naming

#5 2012-08-11 16:05:09

Re: Trouble with udev rule for network interace naming

#6 2012-08-11 19:32:35

Re: Trouble with udev rule for network interace naming

#7 2012-08-11 19:55:59

Re: Trouble with udev rule for network interace naming

#8 2012-08-12 00:24:52

Re: Trouble with udev rule for network interace naming

#9 2012-08-13 13:24:05

Re: Trouble with udev rule for network interace naming

#10 2012-08-13 18:26:56

Re: Trouble with udev rule for network interace naming

#11 2012-08-13 18:48:02

Re: Trouble with udev rule for network interace naming

#12 2012-08-13 19:15:26

Re: Trouble with udev rule for network interace naming

#13 2012-08-13 19:48:55

Re: Trouble with udev rule for network interace naming

#14 2012-08-14 13:48:20

Re: Trouble with udev rule for network interace naming

#15 2013-01-15 12:00:29

Re: Trouble with udev rule for network interace naming

#16 2013-01-15 14:03:13

Re: Trouble with udev rule for network interace naming

#17 2013-01-15 16:44:39

Re: Trouble with udev rule for network interace naming

#18 2013-01-15 17:07:45

Re: Trouble with udev rule for network interace naming

#19 2013-01-15 17:33:06

Re: Trouble with udev rule for network interace naming

#20 2013-01-17 09:04:35

Re: Trouble with udev rule for network interace naming

Board footer