locally-administered MAC addresses create stupid rules

the default persistent network rules generator in udev-117 creates this stupid rule for a network card with a locally-administered MAC address:

SUBSYSTEM="net", ACTION="add", ATTR{type}="1", NAME="eth0"

(to reproduce: kvm -net nic,macaddr#:45:67:89:ab:cd -hda hda.dsk)

This generated rule is stupid, because it matches every ethernet card. The logic that strips out locally-administered MAC addresses from the match should be revised, but I don't know how to do it properly.

Quoted 10 lines

the default persistent network rules generator in udev-117 creates this stupid rule for a network card with a locally-administered MAC address:

SUBSYSTEM="net", ACTION="add", ATTR{type}="1", NAME="eth0"

(to reproduce: kvm -net nic,macaddr#:45:67:89:ab:cd -hda hda.dsk)

This generated rule is stupid, because it matches every ethernet card. The logic that strips out locally-administered MAC addresses from the match should be revised, but I don't know how to do it properly.

Yeah, right, that looks broken. We should add something like this, I guess:

(quoted diff) +2 -0

+# see if we got enough data to create a rule
+ENV{MATCHADDR}="", ENV{MATCHID}="", ENV{INTERFACE_NAME}="",

GOTO="persistent_net_generator_end"
+

2007/11/19, Kay Sievers <[email protected]>:

Quoted 16 lines · Alexander E. Patrakov

Quoted 10 lines

the default persistent network rules generator in udev-117 creates this stupid rule for a network card with a locally-administered MAC address:

SUBSYSTEM="net", ACTION="add", ATTR{type}="1", NAME="eth0"

(to reproduce: kvm -net nic,macaddr#:45:67:89:ab:cd -hda hda.dsk)

This generated rule is stupid, because it matches every ethernet card. The logic that strips out locally-administered MAC addresses from the match should be revised, but I don't know how to do it properly.

Yeah, right, that looks broken. We should add something like this, I guess:

(quoted diff) +2 -0

+# see if we got enough data to create a rule
+ENV{MATCHADDR}="", ENV{MATCHID}="", ENV{INTERFACE_NAME}="",

Quoted 2 lines

GOTO="persistent_net_generator_end"
+

No, this won't work. Suppose that there is one "weird" NIC with a locally-administered MAC address, and one "normal" NIC, and the race between them is significant enough for the initial kernel names to be unpredictable (i.e., udev needs to swap them in 50% of cases). When the generator patched with the above change runs, it writes a rule for the "normal" NIC. Let's suppose that the written rule ends up setting the name for a "normal" NIC to eth0.

Now imagine that, after rebooting the box, the kernel has assigned eth0 to the "weird" NIC and eth1 to the "normal" NIC, so that udev has to swap them. But there is no rule to rename the "weird" NIC. The end result is that there is only one rule that tells udev to rename the normal NIC to eth0. It tries to do this, notices that eth0 already exists, renames eth1 to eth?_rename, and fruitlessly waits for eth0 to disappear.

Quoted 16 lines

2007/11/19, Kay Sievers <[email protected]>:

Quoted 6 lines

Yeah, right, that looks broken. We should add something like this, I guess:

(quoted diff) +2 -0

+# see if we got enough data to create a rule
+ENV{MATCHADDR}="", ENV{MATCHID}="", ENV{INTERFACE_NAME}="",

GOTO="persistent_net_generator_end"
+

No, this won't work. Suppose that there is one "weird" NIC with a locally-administered MAC address, and one "normal" NIC, and the race between them is significant enough for the initial kernel names to be unpredictable (i.e., udev needs to swap them in 50% of cases). When the generator patched with the above change runs, it writes a rule for the "normal" NIC. Let's suppose that the written rule ends up setting the name for a "normal" NIC to eth0.

Quoted 7 lines

Now imagine that, after rebooting the box, the kernel has assigned eth0 to the "weird" NIC and eth1 to the "normal" NIC, so that udev has to swap them. But there is no rule to rename the "weird" NIC. The end result is that there is only one rule that tells udev to rename the normal NIC to eth0. It tries to do this, notices that eth0 already exists, renames eth1 to eth?_rename, and fruitlessly waits for eth0 to disappear.

Yes, that's true, but it's the original behavior, and was never covered by the current persistent rules.

The stupid rule you see is a bug that didn't happen before, and should be fixed first, if we have no proper solution now, for the problem you describe.

2007/11/19, Kay Sievers <[email protected]>:

Quoted 25 lines · Alexander E. Patrakov

Quoted 23 lines

2007/11/19, Kay Sievers <[email protected]>:

Quoted 6 lines

Yeah, right, that looks broken. We should add something like this, I guess:

(quoted diff) +2 -0

+# see if we got enough data to create a rule
+ENV{MATCHADDR}="", ENV{MATCHID}="", ENV{INTERFACE_NAME}="",

GOTO="persistent_net_generator_end"
+

No, this won't work. Suppose that there is one "weird" NIC with a locally-administered MAC address, and one "normal" NIC, and the race between them is significant enough for the initial kernel names to be unpredictable (i.e., udev needs to swap them in 50% of cases). When the generator patched with the above change runs, it writes a rule for the "normal" NIC. Let's suppose that the written rule ends up setting the name for a "normal" NIC to eth0.

Now imagine that, after rebooting the box, the kernel has assigned eth0 to the "weird" NIC and eth1 to the "normal" NIC, so that udev has to swap them. But there is no rule to rename the "weird" NIC. The end result is that there is only one rule that tells udev to rename the normal NIC to eth0. It tries to do this, notices that eth0 already exists, renames eth1 to eth?_rename, and fruitlessly waits for eth0 to disappear.

Quoted 2 lines

Yes, that's true, but it's the original behavior, and was never covered by the current persistent rules.

What you propose is not the same as the original behavior (the original behavior from udev-113 is to write the rule for the weird MAC anyway and rename the interface accordingly).

Quoted 3 lines

What you propose is not the same as the original behavior (the original behavior from udev-113 is to write the rule for the weird MAC anyway and rename the interface accordingly).

True, but it had other bugs, like adding a new rule with every reboot, because the "local" address is just a random address in a lot of cases, and it changes with
every bootup. See: include/linux/etherdevice.h :: random_ether_addr().

Not sure right now, how a proper fix for this would look like.