I was supporting a user in #gentoo this morning who noted that ~arch NetworkManager (1.38.4) defaults the USE to `+iwd` and was confused about any potential migration steps in the absence of a news item. I ran through the NM update and switched to iwd with only minor issues: - PKCS8_PRIVATE_KEY_PARSER wasn't set in my kernel - the iwd ebuild warned me about that and it was a simple fix, probably not worth documenting. - NetworkManager does not recognise SSIDs that I have previously associated the interface with (They turn up as '«SSID Name» (wlan0)' instead). I suspect that this is related to iwd's interface renaming and the resolution is straightforward - I re-entered the WPA key. This may trip some users up but doesn't require specialist knowledge to fix however there is an edge case where the user may not have easy access to the PSK. The following command will retrieve the existing PSK: `$ cat /etc/NetworkManager/system-connections/«SSID Name».nmconnection | grep psk` After I reported success the user ran through the update; they had some issues with WPA3 that they were able to resolve by editing `/etc/NetworkManager/system-connections/«SSID Name».nmconnection` to manually configure. I'm not sure exactly what those issues were, will update the ticket if I get a response; I run WPA2+WPA3 on my APs and did not encounter any issues. Outside of that, feedback from the user was that the overall WiFi experience improved, especially in the case of associating with an AP. I've had my laptop going all morning and haven't noticed any issues; it's definitely past time to replace `wpa_supplicant` with `iwd`. Docs (wiki) for iwd look good, and cover off things like interface renaming. I don't feel like there will be a huge amount of confusion but given that the first request for support was ~20 hours after the package hit ~arch I thought it worth considering. It may be worth updating the Wiki/Handbook to offer iwd as an alternative (or the modern, preferred option) to wpa_supplicant in Networking/Wireless but it's also not critical - wpa_supplicant works and is well understood, and I'd just use `nmcli` until I had a GUI up anyway (which might actually be the better option for a 'handbook' install now that I think about it - backend agnostic).
yeah it tripped me up as well - until I remembered that NetworkManager was recently upgraded. At least a ewarn seems appropriate.
In my case, NetworkManager was unable to pull up the interface on laptop, so I needed to mess with manually setting it up through wpa_supplicant News that iwd is now default and minimum actions, like turning on the service for OpenRC would have been useful and saved me hour or two.
A migration guide would be nice.
I HIGHLY SECOND THIS! After a major system update today my Wi-Fi was broken. You know, the usual very helpful message "Device is not ready" that nm-applet shows. I spent an entire day rebuilding kernel & modules, trying different firmwares, rebuilding @world, replacing my Wi-Fi module with two other ones, going through different debugging steps until I realized that pure wpa_supplicant works fine. At this step I decided to look into NM a bit further and then realized that it doesn't use wpa_supplicant anymore but some new thingie. Of course I carefully read eselect news before upgrading, and there were nothing. I went to Bugzilla to report this in case anyone else hits the same thing, and found this bug. Sorry for my irritation, but I really want to shake the throat of the person who decided to change default USE in minor update - and, moreover, without any further notice. I understand that some stuff in ~arch is tend to break from time to time, but this is just unacceptable.
I ran into this issue this morning as well, though I had luckily noticed & remembered the change to the state of NetworkManager's "iwd" USE-flag during my most recent update run. It is not immediately clear to me what I would need to change in order to get NetworkManager with "iwd" enabled to actually work. Maybe (hopefully?) it's documented somewhere, but I certainly didn't see the sort of GIANT WARNING BANNER followed by a link to good documentation that this level of breakage would warrant. I did notice that I now had an /etc/init.d/iwd. There was no /etc/conf.d/iwd containing defaults I might want to adjust, so I went ahead and ran "/etc/init.d/iwd start" -- but nm-applet still said "No devices available". I then ran "/etc/init.d/NetworkManager restart" -- and nm-applet still said "No devices available". I then ran "ifconfig -a" and noticed that my usual "wlan0" interface was not just unconfigured but completely nonexistant. It had not simply been renamed to something else. I'm guessing that something - presumably iwd? - decided to be very helpful by executing "rmmod iwlwifi" as well. I haven't investigated enough to determine whether or not that's actually true, but if it is then I have some rather choice words for the developer who wrote those particular lines of code. I did have actual work I needed to do so at that point I just rebooted, re-emerged NetworkManager with USE="-iwd", and ran "/etc/init.d/NetworkManager restart". All was then well. (In reply to Alex from comment #4) > I understand that some stuff in ~arch is tend to break > from time to time, but this is just unacceptable. Aren't bug reports like this one of the major reasons that ~arch exists in the first place? Finding out due to bug reports from ~arch users surely beats unknowingly releasing a version containing a showstopper bug to the general masses (& much more widespread outcry) ;-)
(In reply to Will Simoneau from comment #5) > Aren't bug reports like this one of the major reasons that ~arch exists in > the first place? Finding out due to bug reports from ~arch users surely > beats unknowingly releasing a version containing a showstopper bug to the > general masses (& much more widespread outcry) ;-) Well, I certainly agree with you, but that doesn't matter that you can just throw a breaking change at users in minor update without even telling them that they probably may have issues and what may be the case. I always loved Gentoo for very thorough approach to updates and changes, that's why this incident shocked me really bad.
To anyone that ran into issues and then resolved them without switching back to wpa_supplicant: what did you need to do? All I've seen so far is - Pay attention to iwd's kernel config requirements - If using openrc, add iwd to the default runlevel Is that it? (I did not expect this change to break anyone's system; I was not aware that there was anything required)
> Is that it? Automatic association with my saved SSID didn't work until I went in and deleted the duplicate connection ["SSID" vs "SSID (wlan0)" for iwd] (using the KDE 'Connections - System Settings' panel). After I did this I was unable to start my system successfully; it would hang at the point of starting X. I'm unable to say with any certainty what caused that, however it was resolved by deleting the connection from `/etc/NetworkManager/system-connections/` via booting in rescue mode. The connection works and associates with known SSIDs again now. I can't say for sure that it was 100% caused by this migration, but this is a very fresh Gentoo install and is unlikely to be a 'non-standard configuration' thing. Journals for failed boots all end with NetworkManager logs, too. I note that I have a config at `/var/lib/iwd/SSID_name.psk`, I suspect that NetworkManager and iwd were both trying to set the adapter at the same time... Outside of these issues, though I haven't had much of an opportunity to use the laptop, it seems to authenticate very quickly and the WiFi connection has been stable. Upstream bug for iwd not re-using wpa_supplicant connection files: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/202 Kernel Wiki re: wpa_supplicant -> connection file conversion: https://iwd.wiki.kernel.org/networkmanager#converting_network_profiles
I was also surprised by the change and expected some udev and network interface naming related problem. When I found out what the root cause was, I manually started iwd, restarted NetworkManager and was quite surprised that the KDE NetworkManager applet asked me for the WiFi's password / PSK. The PSK is known to NetworkManager since it's stored in plaintext in /etc/NetworkManager/system-connections. However, it seems that it will re-ask the user after the switch to iwd for each WiFi-network already known. That's quite some effort if switching WiFis quite often (working from multiple locations).
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=38afc66020477751400387f6eca0739f4f5b50eb commit 38afc66020477751400387f6eca0739f4f5b50eb Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2022-09-01 00:57:46 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2022-09-01 01:20:22 +0000 net-misc/networkmanager: Disable USE=iwd by default in v1.38 Bug: https://bugs.gentoo.org/865017 Bug: https://bugs.gentoo.org/866695 Signed-off-by: Matt Turner <mattst88@gentoo.org> net-misc/networkmanager/networkmanager-1.38.4.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Sorry to jump in without carefully reading everything, it seems that there are few issues with `iwd` being default related to migration ... On my side, NetworkManager stopped working with my USB Wifi, in the end, solution was to USE="-iwd" for net-misc/networkmanager, which will revert back to use net-wireless/wpa_supplicant. In my case what I found online while trying to figure out why it doesn't work (I don't use wifi often, so I saw the change for `iwd` being default, but haven't tested it until I needed wifi on this system). My USB wifi adapter: ``` ID 0bda:8179 Realtek Semiconductor Corp. RTL8188EUS 802.11n Wireless Network Adapter ``` Uses a staging driver R8188EU which seems to still use `wext`[1] which iwd doesn't support. From NetworkManager log: ... wifi-wext: (wlan0): using WEXT for Wi-Fi device control ... also ... NetworkManager[944]: <info> [1663685604.8262] manager: (wlan0): new 802.11 Wi-Fi device (/org/freedesktop/NetworkManager/Devices/3) NetworkManager[944]: <info> [1663685604.8264] device (wlan0): state change: unmanaged -> unavailable (reason 'managed', sys-iface-state: 'external') ... I have tried various options to configure/force NetworkManager to use `iwd`, but no luck, also `iwctl` wasn't able to see any devices. [1] https://wireless.wiki.kernel.org/en/developers/documentation/wireless-extensions
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=12ccb64ad605095e47d65c575616341c218d64c3 commit 12ccb64ad605095e47d65c575616341c218d64c3 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2022-11-05 03:37:50 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2022-11-05 18:45:02 +0000 net-misc/networkmanager: Disable iwd by default Bug: https://bugs.gentoo.org/865017 Signed-off-by: Matt Turner <mattst88@gentoo.org> net-misc/networkmanager/networkmanager-1.40.0.ebuild | 2 +- net-misc/networkmanager/networkmanager-1.40.2.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)
There are also Problems with WPA Enterprise (e.g. eduroam) https://wiki.archlinux.org/title/NetworkManager#WPA_Enterprise_connection_with_iwd I didn't dig deep into it but just switched back to wpa_supplicant so I could get work done
Was this just changed *again* without a news item?
