Bug#812575: udev: predictable network device names fails for USB devices without a permanent hw address

[Michael Biebl]

Hi Bjørn,

On Mon, 25 Jan 2016 09:27:31 +0100 =?utf-8?q?Bj=C3=B8rn_Mork?=
<bj...@mork.no> wrote:
> I just noticed that the new "predictable" network device names logic
> fails in a most ugly way with USB devices with no permanent mac
> address:
>
> [ 10.989584] qmi_wwan 6-4:1.10 wwx2ac56637bccb: renamed from wwan1
> [ 11.019362] qmi_wwan 6-4:1.8 rename4: renamed from wwan0
>
>
> There are two issues here:
>
> 1) the name is derived from a random mac address, which is regenerated
> on each boot. Note that the address does have the 'local' bit set:
> 2a:c5:66:37:bc:cb
>
> 2) there are two such network interfaces present. The 'usbnet' driver
> infrastructure will generate an address on module init and reuse
> the very same address for every USB device needing one. Naturally,
> trying to name more than one interface after the same address fails,
> and you end up with an even uglier 'rename4' device name...

That sounds like a bug in the driver to me.


> The old persistent network device logic used to avoid mapping against
> locally administered mac addresses. This logic needs to be kept for
> the new "predictable" names too. Anything else is a regression.

Is there a way to detect such "locally administered mac addresses"?

> But even with this in place, the new logic should be prepared for
> duplicate mac addresses. There are plenty of USB devices with non-
> unique mac addresses out there. It's more of a rule than an exception
> for GSM/LTE modem devices...

Please consider raising this issue upstream and filing a bug at
https://github.com/systemd/systemd/issues/new


Regards,
Michael



--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?

[Bjørn Mork]

Michael Biebl <bi...@debian.org> writes:

> Hi Bjørn,
>
> On Mon, 25 Jan 2016 09:27:31 +0100 =?utf-8?q?Bj=C3=B8rn_Mork?=
> <bj...@mork.no> wrote:
>> I just noticed that the new "predictable" network device names logic
>> fails in a most ugly way with USB devices with no permanent mac
>> address:
>>
>> [ 10.989584] qmi_wwan 6-4:1.10 wwx2ac56637bccb: renamed from wwan1
>> [ 11.019362] qmi_wwan 6-4:1.8 rename4: renamed from wwan0
>>
>>
>> There are two issues here:
>>
>> 1) the name is derived from a random mac address, which is regenerated
>> on each boot. Note that the address does have the 'local' bit set:
>> 2a:c5:66:37:bc:cb
>>
>> 2) there are two such network interfaces present. The 'usbnet' driver
>> infrastructure will generate an address on module init and reuse
>> the very same address for every USB device needing one. Naturally,
>> trying to name more than one interface after the same address fails,
>> and you end up with an even uglier 'rename4' device name...
>
> That sounds like a bug in the driver to me.

Why? There is no way you can have more than two devices connected to
each link, so the actual addresses don't really matter. And even if you
could connect this to a switch or whatever, I thought Sun had educated
the masses by now.

>> The old persistent network device logic used to avoid mapping against
>> locally administered mac addresses. This logic needs to be kept for
>> the new "predictable" names too. Anything else is a regression.
>
> Is there a way to detect such "locally administered mac addresses"?

Of course there is. The 75-persistent-net-generator.rules of the past
did this just fine with a simple glob match:

ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""

Which is why this bug is a regression.

>> But even with this in place, the new logic should be prepared for
>> duplicate mac addresses. There are plenty of USB devices with non-
>> unique mac addresses out there. It's more of a rule than an exception
>> for GSM/LTE modem devices...
>
> Please consider raising this issue upstream and filing a bug at
> https://github.com/systemd/systemd/issues/new

Sorry. I don't really care about systemd. Just thought it would be
nice to document this bug for the next user hitting it.


Bjørn

[Bjørn Mork]

Michael Biebl <bi...@debian.org> writes:

>> But even with this in place, the new logic should be prepared for
>> duplicate mac addresses. There are plenty of USB devices with non-
>> unique mac addresses out there. It's more of a rule than an exception
>> for GSM/LTE modem devices...
>
> Please consider raising this issue upstream and filing a bug at
> https://github.com/systemd/systemd/issues/new

Just FYI, I stumbled across the upstream systemd sources on my disk
(have a lof cruft laying around :) and noticed that this problem is not
present there. The "net_setup_link" builtin helper is very careful to
avoid basing its names on local mac addresses or random addresses. Both
which are true in the case I reported. usbnet based drivers will set
addr_assign_type to NET_ADDR_RANDOM when appropriate:

bjorn@nemi:~$ grep . /sys/class/net/wwan*/addr_assign_type
/sys/class/net/wwan0/addr_assign_type:1
/sys/class/net/wwan1/addr_assign_type:1


The bug was introduced by this commit, trying to work around the
upstream bogus assumption that USB bus numbers are stable:

commit 51009270be5da77a0e11b313190ef12ab401c007
Author: Martin Pitt <marti...@ubuntu.com>
Date: Wed Jun 3 12:48:42 2015 +0200

Add debian/extra/01-mac-for-usb.link: Use MAC based names for network interfaces which are (directly or indirectly) on USB

Path based names are inadequate for dynamic buses like USB.

See discussion on

https://lists.debian.org/debian-devel/2015/05/msg00170.html

and revised proposal on

https://lists.debian.org/debian-devel/2015/06/msg00018.html



And I recall even being part of that discussion. Obviously without
getting the message trough. So let me try again:

You CANNOT create a stable name for USB devices.

The reason is pretty simple and should be bloody obvious: You have no
stable and unique input parameteres. Every single attribute you have
access to is either shared with multiple devices or subject to change.

So if you insist on renaming these devices, then you will fail.



Bjørn

[Martin Pitt]

Control: tag -1 pending

Hello Bjørn,

Bjørn Mork [2016-01-25 9:27 +0100]:

> 1) the name is derived from a random mac address, which is regenerated
> on each boot. Note that the address does have the 'local' bit set:
> 2a:c5:66:37:bc:cb
>

> The old persistent network device logic used to avoid mapping against
> locally administered mac addresses. This logic needs to be kept for
> the new "predictable" names too. Anything else is a regression.

Argh, thanks for pointing this out! I fixed this in

https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=ec7e332

Now only devices with universally administered MACs will get a MAC
based name, for the locally administered ones we'll use the default
naming schema of all other types, i. e. location based.

For the record, I actually don't like the MAC based names very much;
these were a compromise from the discussion a year ago, and by and
large emulate what the old 75-persistent-net stuff used to do with
such USB devices. But I don't want to completely drop this without a
followup discussion (I started one for Ubuntu in
https://lists.ubuntu.com/archives/ubuntu-devel/2016-April/039302.html,
but we might need to have this on Debian again too).

Bjørn Mork [2016-02-02 14:08 +0100]:

> And I recall even being part of that discussion. Obviously without
> getting the message trough. So let me try again:
>
> You CANNOT create a stable name for USB devices.
>
> The reason is pretty simple and should be bloody obvious: You have no
> stable and unique input parameteres. Every single attribute you have
> access to is either shared with multiple devices or subject to change.

This isn't true for universally administered MAC addresses, like
commonly for USB ethernet adapters. We've used the MAC for identifying
those for many many years.

The locally administered ones indeed don't have any intrinsic property
to build a name from. As the kernel name for them is also
random/unstable, I believe having path based names is the best policy
for them: At least you get reliable names if you plug them into the
same port (which is rather intuitive for things like RasPi boards);
and if you change ports, then we don't have any stable property and
the name doesn't matter at all (you can't use it in /e/n/interfaces or
firewall scripts anyway).

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)