From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kay Sievers Date: Mon, 19 Nov 2007 11:55:09 +0000 Subject: Re: locally-administered MAC addresses create stupid rules Message-Id: <1195473309.2661.8.camel@lov.site> List-Id: References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On Mon, 2007-11-19 at 16:31 +0500, Alexander E. Patrakov wrote: > 2007/11/19, Kay Sievers : > > On Nov 19, 2007 5:45 AM, Alexander E. Patrakov 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