Re: locally-administered MAC addresses create stupid rules

["Alexander E. Patrakov" <patrakov@gmail.com>]

2007/11/19, Kay Sievers <kay.sievers@vrfy.org>:
> On Nov 19, 2007 5:45 AM, Alexander E. Patrakov <patrakov@gmail.com> wrote:
> > 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:
>
> +# 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.

-- 
Alexander E. Patrakov

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel