Arch Linux

This might be related to https://bugs.archlinux.org/task/61367 but I'm not sure since the workaround posted there does not affect the symptoms here.

I did not notice this bug till I read it here. Because I use MAC address based systemd-networkd profile instead of interface name.

[Match]
MACAddress=00:11:22:33:44:55

So my Wifi or systemd-networkd didnt break.

But since my firewall rules are based on interface names. Those rules broke.

I've mitigated it by basing the network file on the network type:

[Match]
Type=wlan

which works since I only have one wireless connection.

There are some very interesting changes in iwd 0.18 (in particular phy vs dev) and they point out a race condition impacting device renaming via udev.
I have no idea where iwd bugs are reported, but there are no "bugs/patches" noted on the mailing lists.

It is definitely worthwhile to read:

https://iwd.wiki.kernel.org/interface_lifecycle

I note that on the laptop i'm using right now the "dev" name is wlan0.
Running: iw dev
shows 1 physical device phy#0 and 1 "dev" device (wlan0) associated with the physical device. iwd now supports multiple "dev" devices being associated with each physical device (phy). This is actually very cool.

On upgrading iwd, my system lost wifi - rebooting it worked fine - network manager seems content and iwd is working fine behind the scenes.

It does look like there is a udev rename bug which we are now being more exposed to than previously. I have not yet searched for udev race bugs.

Also - i see in kernel log that iwlwifi says "wlp2s0: renamed from wlan0" - there are no errors this failed - however all further references in log file refer to wlan0 - so the rename failed silently best I can tell.

It looks like there is an iwd dev mailing list at https://lists.01.org/mailman/listinfo/iwd and there are upstream patches added in the past day or so at https://kernel.googlesource.com/pub/scm/network/wireless/iwd/

Additionally this report is directly relevant: https://github.com/systemd/systemd/issues/12561 which refers to the interface lifecycle link too.

In my case the workaround with the MACAddress match in the systemd-networkd .network file allowed the wireless interface to start up and work for some period but it then died after some period - the log for this configuration contained:

$ sudo journalctl -b -1 -u systemd-networkd --no-pager
-- Logs begin at Tue 2019-05-07 20:33:38 BST, end at Tue 2019-05-14 19:28:58 BST. --
May 14 18:44:58 lenovo1 systemd[1]: Starting Network Service...
May 14 18:44:59 lenovo1 systemd-networkd[530]: Enumeration completed
May 14 18:44:59 lenovo1 systemd[1]: Started Network Service.
May 14 18:44:59 lenovo1 systemd-networkd[530]: enp3s0: Interface name change detected, enp3s0 has been renamed to eth0.
May 14 18:44:59 lenovo1 systemd-networkd[530]: eth0: Interface name change detected, eth0 has been renamed to enp3s0.
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlan0: Could not find device: No such device
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlan0: Failed
May 14 18:44:59 lenovo1 systemd-networkd[530]: Could not add new link, ignoring: No such device
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlan0: Interface name change detected, wlan0 has been renamed to wlp4s0.
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlp4s0: Could not find device: No such device
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlp4s0: Failed
May 14 18:44:59 lenovo1 systemd-networkd[530]: Could not update link, ignoring: No such device
May 14 18:44:59 lenovo1 systemd-networkd[530]: enp3s0: Could not bring up interface: Invalid argument
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlan0: Gained carrier
May 14 18:44:59 lenovo1 systemd-networkd[530]: wlan0: DHCPv4 address 10.0.0.94/24 via 10.0.0.135
May 14 18:45:00 lenovo1 systemd-networkd[530]: wlan0: Gained IPv6LL
May 14 18:45:02 lenovo1 systemd-networkd[530]: wlan0: Configured
May 14 19:00:35 lenovo1 systemd[1]: Stopping Network Service...
May 14 19:00:35 lenovo1 systemd[1]: systemd-networkd.service: Succeeded.
May 14 19:00:35 lenovo1 systemd[1]: Stopped Network Service.
May 14 19:00:35 lenovo1 systemd[1]: Starting Network Service...
May 14 19:00:36 lenovo1 systemd-networkd[2193]: wlan0: Gained IPv6LL
May 14 19:00:36 lenovo1 systemd-networkd[2193]: Enumeration completed
May 14 19:00:36 lenovo1 systemd[1]: Started Network Service.
May 14 19:00:36 lenovo1 systemd-networkd[2193]: wlan0: DHCPv4 address 10.0.0.94/24 via 10.0.0.135
May 14 19:00:38 lenovo1 systemd-networkd[2193]: wlan0: Configured
May 14 19:01:04 lenovo1 systemd[1]: Stopping Network Service...
May 14 19:01:04 lenovo1 systemd[1]: systemd-networkd.service: Succeeded.
May 14 19:01:04 lenovo1 systemd[1]: Stopped Network Service.
May 14 19:01:04 lenovo1 systemd[1]: Starting Network Service...
May 14 19:01:04 lenovo1 systemd-networkd[2211]: wlan0: Gained IPv6LL
May 14 19:01:04 lenovo1 systemd-networkd[2211]: Enumeration completed
May 14 19:01:04 lenovo1 systemd[1]: Started Network Service.
May 14 19:01:04 lenovo1 systemd-networkd[2211]: wlan0: DHCPv4 address 10.0.0.94/24 via 10.0.0.135
May 14 19:01:06 lenovo1 systemd-networkd[2211]: wlan0: Configured
May 14 19:02:07 lenovo1 systemd-networkd[2211]: wlan0: Lost carrier
May 14 19:02:07 lenovo1 systemd-networkd[2211]: wlan0: DHCP lease lost
May 14 19:02:07 lenovo1 systemd-networkd[2211]: wlan0: DHCPv6 lease lost
May 14 19:02:07 lenovo1 systemd-networkd[2211]: Could not emit changed OperationalState: Transport endpoint is not connected
May 14 19:02:08 lenovo1 systemd[1]: Stopping Network Service...
May 14 19:02:08 lenovo1 systemd[1]: systemd-networkd.service: Succeeded.
May 14 19:02:08 lenovo1 systemd[1]: Stopped Network Service.

At the same time in the log there is an iwd entry:

iwd[488]: MLME notification is missing ifindex attribute

I believe this is a 4-way handshake problem - and due to the loss of connection.

The only stable wireless operation could be obtained by downgrading iwd back to 0.71-1

This bug (or a new feature?) also breaks nftables rules which work on interface numbers.

So make sure that your firewall rules are not getting bypassed (depending on what exactly the rule is)

For example:
iif wlan0 ct state new drop
iif ct state new tcp dport { 22, 80 } accept

If you are dropping all SYN on wireless connectivity but accepting otherwise then this protection will break.

Details here: https://lists.01.org/pipermail/iwd/2019-May/006320.html

I realised from the comment above concerning firewalls that I might be affected with my iptables firewall - I had restricted the interface to wlp4s0 - so I altered the firewall rules to include wlan0 - and it now works with iwd 0.81-1 - so it is a workaround but it is still necessary to wait and see if there is any change to the upstream package that allows the new interface names to be used in the MATCH section and not just the name wlan0 or MACAddress.

I also note Poettering's comment in the report at https://github.com/systemd/systemd/issues/12561

On my side, I see the following error when iwd starts:

[ 16.732326] A link change request failed with some changes committed already. Interface wlp2s0 may have been left with an inconsistent configuration, please check.

After that, the interface is gone (no wlp2s0 nor wlan0). Downgrading to 0.17 solves the issue. I didn't investigate the issue further than that.

If this is going to be closed because not a bug, then how would a user get to make iwd 0.18 work again? Is the wiki being updated?

@pescepalla by changing systemd-networkd config or iwd config. Feel free to update the wiki.