DRIVER=="*?" in network udev rules breaks for some cards

[alexander@…]

This is a collective duplicate of ​http://bugs.debian.org/376589, ​http://bugs.debian.org/368845, ​http://bugs.debian.org/364320, ​http://bugs.debian.org/364311, and ​http://bugs.debian.org/365248. Short summary: there is currently no way to write udev rules for persistent network interface names without breaking vlans, bridges, or certain cards.

[alexander@…]

Proposed action:

• In the example rules, remove DRIVER=="?*" part
• Remove the paragraph starting with "The DRIVER=="?*" key prevents Udev"
• Add the following at the end of Section 7.13.1 "Creating stable names for network interfaces":

---

The example rules above don't work for every setup. For example, MAC-based rules break when ​bridges or ​VLANs are used, because bridges and VLANs have the same MAC address as the network card. One wants to rename only the network card interface, not the bridge or VLAN interface, but the example rule matches both. If you use such virtual interfaces, you have two potential solutions. One is to add the DRIVER=="?*" key after SUBSYSTEM=="net" in MAC-based rules, so that they stop matching the virtual interfaces (but this is known not to work with some older Ethernet cards because they don't have the DRIVER variable in the uevent and thus the rule matches nothing with such cards). Another solution is to switch to the rules that use the bus position as a key.

The second known non-working case is with wireless cards using the ​MadWifi driver, because it creates at least two interfaces (athX and wifiX, where X is a digit) with the same MAC address and bus position. To disambiguate, add SYSFS{type}=="zzz" after SUBSYSTEM=="net" for each interface that is handled by that driver, where zzz is the output of "cat /sys/class/net/interface_name/type".

There may be other cases where the rules above don't work. Currently, bugs on this topic are still being reported to Linux distributions, and no 100% bullet proof solution is known.

---

[alexander@…]

​http://bugs.debian.org/376589 suggests that it might be a better idea to write the following instead of the long sentence in the previous comment starting with "One is to add":

One is to add the ENV{PHYSDEVDRIVER}=="?*" key after SUBSYSTEM=="net" in MAC-based rules, so that they stop matching the virtual interfaces.

TODO: test with any ISA card.

[alexander@…]

Hm, the ISA ne2000 card still doesn't have ENV{PHYSDEVDRIVER}. So please ignore my comment from 07/24/06 22:14:29 for now. I still have to do some tests on ENV{PHYSDEVDRIVER} vs DRIVER, though.

[alexander@…]

Ignore my comments about PHYSDEVDRIVER. It would be needed only in Debian-like setup:

ENV{PHYSDEVDRIVER}!="?*", GOTO="net_end"
ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:e0:4c:12:34:56", NAME="realtek"
ACTION=="add", SUBSYSTEM=="net", SYSFS{address}=="00:a0:c9:78:9a:bc", NAME="intel"
LABEL="net_end"

which is not what is used in LFS. My comment dated 07/24/06 21:46:14 represents the recommended solution.

[alexander@…]

In that comment, replace "MadWifi" with "MadWifi or HostAP".

[alexander@…]

And, "athX" with "athX or hostapX, depending on the driver"

[alexander@…]

sorry, I meant:

replace "athX" with "athX or wlanX, depending on the driver"

[bdubbs@…]

I'm working on this and making a commit for evaluation a revision

7711. This is in the 6.2 branch, but the book is not yet

rendered on belgarath. I do have a question about the comment using:

cat /sys/class/net/<interface_name>/type

I have a Madwifi based card and get:

$ cat /sys/class/net/wifi0/type
1
$ cat /sys/class/net/ath0/type
1

The type does not seem to diferentiate. Is there something else to try.

[alexander@…]

Indeed, that's bad. This also means that Debian (where I borrowed this "solution" from) is buggy. What happens if you add KERNEL=="ath*" and KERNEL=="wifi*" instead of SYSFS{type}? What is the output of the following commands?

udevinfo -a -p /class/net/ath0
udevinfo -a -p /class/net/wifi0

[bdubbs@…]

Fixed at revision 7720.

Used KERNEL=="ath*" as an example.