Re: locally-administered MAC addresses create stupid rules

[Kay Sievers <kay.sievers@vrfy.org>]

On Mon, 2007-11-19 at 16:31 +0500, Alexander E. Patrakov wrote:
> 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.

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.

Kay


-------------------------------------------------------------------------
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