iwd 1.5-1 on Ubuntu 20.04.1 with current updates works great on multiple WPA2 networks I have tried, and across suspend/resume cycling on my Qualcomm Atheros QCA6174 (ath10k) hardware on x86.
iwd has a Resident Set Size of 4628kB (47%) of wpa_supplicant’s 9680kB; a good step for embedded systems.
The only issue I have noted is iwconfig reports the correct 5GHz channel information for the BSSID, whereas ‘nmcli dev wifi’ shows the BSSID and other SSIDs on 2.4GHz channels only.
I’ve just tested on Ubuntu 20.04.1 LTS with iwd 1.5-1. It works well on my 2.4 GHz network. The only issue I found is what others already mentioned earlier: it created a new network and added “1” to its name.
I just installed iwd 1.5-1 on Ubuntu 20.04.1. It works very well with WPA2 home WiFi (I am connecting to a range extender indeed, no problem so far right now): browsing the web for studying activities and Netflix or Disney+ viewing. Fast connecting, stable and effectively less energy consumption.
After I typed sudo apt install iwd in the terminal I went offline, but after just clicking on the icon in the tray, I was able to reconnect without any problems. Actually without even doing the next setup steps. I didn’t really realize it, I did them later anyway.
If your connection shows the “1” already mentioned above at name ending, just go to Settings -> WiFi -> Click on the gear near the name of the connection and forget them both. And then reconnect.
This is great. I’ve been testing this on my personal laptop and work laptop today. I’ve come across numerous issues. Where do we raise bugs? What details do you want? How do we debug the issues ourselves?
Most of my issues may be with Gnome Network Manager, although I don’t know if that’s the case.
Hey @psiphi75 thanks for helping with those early tests. For now we’re mostly interested in a higher level overview of what is working and what is not (see “Testplan” from above), also it would be great if you could explain how you ended up in a state where something isn’t working, so that it can be reproduced later.
If you traced down some specific issues, you could also report those to the upstream developers:
WPA3 Personal does not work. New connection is not choosing WPA3 and when I edit the profile, it either silently create a new profile with WPA2 or sometimes I get an error message when trying to use it:
Connextion XXX is not available on device wlan0 because
profile is not compatible with device (connection authentication type
not supported by IWD backend
Upon reboot, it took a very long time (+1min) for the wifi list to populate - in fact, nm-applet did not show any networks until I opened gnome-settings wifi separately. This could be a coincidence, but in any case a long time.
It would not connect to my wifi (Schmilblick 5GHz on the logs) - did not connect automatically upon login nor did it connect when I selected the network manually (either in gnome-settings or nm-applet)
journalctl -U NetworkManager --> you probably want to look at the last entries after the last reboot at “Aug 13 12:52:13” as the first reboot has dirty logs with me enabling/disabling NM and the second reboot is back to wpa_supplicant to look at this post.
I have testing this on both Ubuntu 20.04 and 20.10. I used the same laptop and wireless network.
2 Issues:
After connecting to my home network, 2 appear. IE: “network_name” AND “network_name 1”. I tried to connect to the normal one, but ended up connecting to the “1” network.
I have a 5GHz network, but I connect to the 2.4GHz network instead.
Well, that’s not unexpected. NetworkManager stores passwords in plain text too. A system-wide connection needs to store its credentials in plain text, as you can’t have encryption without a key, and it seems pointless to prompt the user during boot for some credential storage password when they can use full disk encryption and get prompted for that.
Now yes, you could store the key in the user’s password store which is encrypted with the user’s login password. But: That means you need the user to login before you can establish a connection, and you can’t login as another user. Which is suboptimal.
In Xubuntu 20.04 NM not duplicate connection, only after switch to iwd ask for password while connect firstime to before stored wifi, with prefilled password, then is need only accept.
2: I went in to my router and checked, it is actually a 2.4 GHz connection not 5 GHz. If I revert and reboot it will display 5 GHz in network manager and on the router.
I also tested the up/down speeds and I was getting ~50 Mbps down ~19 Mbps up with it was saying 2.4 GHz and ~280 Mbps down and ~19 Mbps up on 5 GHz.
From what I can see it looks like I am really connecting to the 2.4 GHz network. It is not just a UI glitch.
Using full disk encryption doesn’t solve anything, as soon as the disk is unlocked the file is there, open to anyone with access to the computer. There’s a reason if most guidelines discourage or prohibit saving passwords on disk if they can’t be protected with another passphrase, even if the disk is encrypted.
And some computers are not single user machines, multiple users may login onto them regularly or they may be used temporarily by another person, so no, global credentials on disk just don’t cut it.
Keep in mind that iwd runs as root and, if configured correctly, the settings are not normal-user readable. The settings are currently global and there is no per-user store at this time. This is similar to how other daemons operate, bluetoothd for example.
There is no need to store passwords (or user names) in clear text for EAP networks. iwd will ask for these if they’re missing via its D-Bus Agent framework and will forget them once the network goes out of range. Refer to ‘man iwd.settings’ for more details. This does of course imply that you will need to provide EAP credentials whenever iwd is restarted.
Thanks for a focused effort in making sure IWD is ready for prime time.
I have been experimenting with IWD as a wpa_supplicant replacement several times, because it fixes a bunch of AP bouncing issues, that wpa_supplicant seems suffer from. My experience seems to match that of @woutervb, mentioned earlier.
For me - for now - the current need for manually maintained IWD provisioning files outweighs the problems I have with wpa_supplicant, so I always end up having to switch back.
I just ran a fresh test, to see if any recent updated might have changed that, but alas. Connection through Network Manager still fails:
reason="Connection 'MyPEAPNetwork' is not available on device wlan0 because profile is not compatible with device (802.1x connections must have IWD provisioning files)
This is on a fully updated 20.04, so I will perform the same test on 20.10 in a few moments (as soon as my machine is done updating).
I use Mint which is based on 20.04 LTS which would be iwd 1.5-1, testing iwd on a simple PSK 2.4/5G network has been going well.
I did encounter a segfault in iwd though when trying to restart a seemingly crashed stack resulting in ‘unavailable’ in the Network Manager wireless system tray.