locally-administered MAC addresses create stupid rules

locally-administered MAC addresses create stupid rules

[Alexander E. Patrakov]

Hello,

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. If we just remove the generated 
rule, we'll possibly end up with a random name (e.g., eth0) for this network 
card and a eth0_rename name for a conflicting interface that should really be 
eth0 according to the other rules.

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

Re: locally-administered MAC addresses create stupid rules

[Kay Sievers]

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"
+
 # default comment
 ENV{COMMENT}="", ENV{COMMENT}="$env{SUBSYSTEM} device"

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

Re: locally-administered MAC addresses create stupid rules

[Alexander E. Patrakov]

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

Re: locally-administered MAC addresses create stupid rules

[Kay Sievers]

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

Re: locally-administered MAC addresses create stupid rules

[Alexander E. Patrakov]

(forgot to send the copy to the list, sorry)

2007/11/19, 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>:
> > > 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.

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

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

Understood.

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

Re: locally-administered MAC addresses create stupid rules

[Kay Sievers]

On Nov 19, 2007 1:04 PM, Alexander E. Patrakov <patrakov@gmail.com> wrote:
> 2007/11/19, 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>:
> > > > 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.
>
> 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.

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

Re: locally-administered MAC addresses create stupid rules

[Alexander E. Patrakov]

2007/11/19, Kay Sievers <kay.sievers@vrfy.org>:
> On Nov 19, 2007 1:04 PM, Alexander E. Patrakov <patrakov@gmail.com> wrote:
> > 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.

IMHO, udev tries really hard to figure out a presistent set of
attributes that can be used to identify the card, and still fails.
Thus, some help from the kernel is needed, because a driver surely
knows more about its device and has access to really unique things
like, say, a non-standard chipset-specific serial number (and can say:
please use this sequecne of characters as a way to identify this card
in a unique way).

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