Bug#982688: wireless interface name unstable across reboots

[Michael Biebl]

On Sat, 13 Feb 2021 15:28:24 +0100 Yuri D'Elia <wavexx at thregr.org>
wrote:
> Package: udev
> Version: 247.3-1
> Severity: normal
> 
> I recently switched to a different laptop which is marginally faster.
> Using this laptop, the wireless interface name changes from wlan0 to
> wlo1 seemingly randomly across reboots, breaking the network
> configuration.
> 
> This seems to be caused _indirectly_ by iwd, a similar case reported
in
> #944097, although I intentionally masked network/80-iwd.link to have
> stable interface names.

Unfortunately, it is not as simple as that.

> - depending on the startup sequence, iwd might be started before udev
>Â Â  has a chance to assign a new interface name
> - the first default policy is "keep"
> - udev as a result keeps the existing wlan0
> 
> If iwd happens to start late, then wlan0 is renamed as wlo1.
> 
> Changing NamePolicy to remove "keep" (by overriding
> network/99-default.link) fixes the issue in this case. If we cannot
> guarantee that udev runs before iwd, or conversely iwd after udev,
then
> "keep" should probably be removed, since having unstable interface
names
> breaks the configuration randomly.
> 
> IMHO this is a better policy than sequencing iwd after udev, since I
> believe this is a subtle issue that can creep up in other scenarios,
> leading to hard-to-debug configuration issues.
> 
> If I want to keep exiting interface names I'd rather have to do this
> configuration explicitly.

By masking 80-iwd.link, both udev and iwd race against each other.
Sometimes udev is fast enough to rename the interface, sometimes iwd is
quick enough and claims the interface and udev can't rename anymore,
because the interface is busy.

TTBOMK this is not really fixable, which is why iwd started to ship 80-
iwd.link in the first place, so no renaming is going to happen.

I'm not sure what udev can do about this, unfortunately.

I've CCed Andreas. Even though he is not its maintainer anymore, maybe
he has some insides to share.

Regards,
Michael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20210213/f9746f31/attachment.sig>