I am also seeing this with iwd on Ubuntu 20.04
1 Like
Hello,
On my side, my experience with iwd on Ubuntu 20.10 was globally positive regarding the connection to APs! Just a shame I had to copy-paste passwords to connect to known APs the first time.
After suspend, it was fine, it had time to reconnect while I was still typing my password to log-in.
After a reboot, I sometimes had to restart iwd service.
But I had to revert back to wpa_supplicant: I noticed that every ~25 or 30 seconds, the delay increased up to 1500ms for 3 to 4 seconds:
64 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=12.6 ms
64 bytes from 192.168.178.1: icmp_seq=2 ttl=64 time=2.04 ms
64 bytes from 192.168.178.1: icmp_seq=3 ttl=64 time=2.13 ms
64 bytes from 192.168.178.1: icmp_seq=4 ttl=64 time=9.10 ms
64 bytes from 192.168.178.1: icmp_seq=5 ttl=64 time=2.28 ms
64 bytes from 192.168.178.1: icmp_seq=6 ttl=64 time=68.9 ms
64 bytes from 192.168.178.1: icmp_seq=7 ttl=64 time=4.89 ms
64 bytes from 192.168.178.1: icmp_seq=8 ttl=64 time=1106 ms
64 bytes from 192.168.178.1: icmp_seq=9 ttl=64 time=1583 ms
64 bytes from 192.168.178.1: icmp_seq=10 ttl=64 time=1297 ms
64 bytes from 192.168.178.1: icmp_seq=11 ttl=64 time=362 ms
64 bytes from 192.168.178.1: icmp_seq=12 ttl=64 time=2.13 ms
64 bytes from 192.168.178.1: icmp_seq=13 ttl=64 time=2.03 ms
64 bytes from 192.168.178.1: icmp_seq=14 ttl=64 time=2.07 ms
64 bytes from 192.168.178.1: icmp_seq=15 ttl=64 time=2.10 ms
64 bytes from 192.168.178.1: icmp_seq=16 ttl=64 time=2.09 ms
64 bytes from 192.168.178.1: icmp_seq=17 ttl=64 time=3.97 ms
64 bytes from 192.168.178.1: icmp_seq=18 ttl=64 time=3.65 ms
64 bytes from 192.168.178.1: icmp_seq=19 ttl=64 time=2.09 ms
64 bytes from 192.168.178.1: icmp_seq=20 ttl=64 time=1.96 ms
64 bytes from 192.168.178.1: icmp_seq=21 ttl=64 time=2.51 ms
64 bytes from 192.168.178.1: icmp_seq=22 ttl=64 time=2.06 ms
64 bytes from 192.168.178.1: icmp_seq=23 ttl=64 time=2.40 ms
64 bytes from 192.168.178.1: icmp_seq=24 ttl=64 time=2.24 ms
64 bytes from 192.168.178.1: icmp_seq=25 ttl=64 time=2.39 ms
64 bytes from 192.168.178.1: icmp_seq=26 ttl=64 time=2.25 ms
64 bytes from 192.168.178.1: icmp_seq=27 ttl=64 time=12.9 ms
64 bytes from 192.168.178.1: icmp_seq=28 ttl=64 time=2.13 ms
64 bytes from 192.168.178.1: icmp_seq=29 ttl=64 time=2.12 ms
64 bytes from 192.168.178.1: icmp_seq=30 ttl=64 time=7.94 ms
64 bytes from 192.168.178.1: icmp_seq=31 ttl=64 time=2.46 ms
64 bytes from 192.168.178.1: icmp_seq=32 ttl=64 time=27.1 ms
64 bytes from 192.168.178.1: icmp_seq=33 ttl=64 time=208 ms
64 bytes from 192.168.178.1: icmp_seq=34 ttl=64 time=284 ms
64 bytes from 192.168.178.1: icmp_seq=35 ttl=64 time=279 ms
64 bytes from 192.168.178.1: icmp_seq=36 ttl=64 time=310 ms
64 bytes from 192.168.178.1: icmp_seq=37 ttl=64 time=203 ms
64 bytes from 192.168.178.1: icmp_seq=38 ttl=64 time=2.11 ms
64 bytes from 192.168.178.1: icmp_seq=39 ttl=64 time=2.11 ms
64 bytes from 192.168.178.1: icmp_seq=40 ttl=64 time=2.95 ms
64 bytes from 192.168.178.1: icmp_seq=41 ttl=64 time=2.01 ms
64 bytes from 192.168.178.1: icmp_seq=42 ttl=64 time=2.52 ms
64 bytes from 192.168.178.1: icmp_seq=43 ttl=64 time=2.04 ms
64 bytes from 192.168.178.1: icmp_seq=44 ttl=64 time=2.06 ms
64 bytes from 192.168.178.1: icmp_seq=45 ttl=64 time=2.10 ms
64 bytes from 192.168.178.1: icmp_seq=46 ttl=64 time=2.09 ms
64 bytes from 192.168.178.1: icmp_seq=47 ttl=64 time=2.11 ms
64 bytes from 192.168.178.1: icmp_seq=48 ttl=64 time=1.55 ms
64 bytes from 192.168.178.1: icmp_seq=49 ttl=64 time=2.06 ms
64 bytes from 192.168.178.1: icmp_seq=50 ttl=64 time=2.00 ms
64 bytes from 192.168.178.1: icmp_seq=51 ttl=64 time=2.35 ms
64 bytes from 192.168.178.1: icmp_seq=52 ttl=64 time=2.07 ms
64 bytes from 192.168.178.1: icmp_seq=53 ttl=64 time=2.20 ms
64 bytes from 192.168.178.1: icmp_seq=54 ttl=64 time=2.08 ms
64 bytes from 192.168.178.1: icmp_seq=55 ttl=64 time=2.22 ms
64 bytes from 192.168.178.1: icmp_seq=56 ttl=64 time=1.55 ms
64 bytes from 192.168.178.1: icmp_seq=57 ttl=64 time=2.10 ms
64 bytes from 192.168.178.1: icmp_seq=58 ttl=64 time=19.0 ms
64 bytes from 192.168.178.1: icmp_seq=59 ttl=64 time=221 ms
64 bytes from 192.168.178.1: icmp_seq=60 ttl=64 time=1091 ms
64 bytes from 192.168.178.1: icmp_seq=61 ttl=64 time=1100 ms
64 bytes from 192.168.178.1: icmp_seq=62 ttl=64 time=1123 ms
64 bytes from 192.168.178.1: icmp_seq=63 ttl=64 time=272 ms
64 bytes from 192.168.178.1: icmp_seq=64 ttl=64 time=2.43 ms
64 bytes from 192.168.178.1: icmp_seq=65 ttl=64 time=2.09 ms
64 bytes from 192.168.178.1: icmp_seq=66 ttl=64 time=18.4 ms
64 bytes from 192.168.178.1: icmp_seq=67 ttl=64 time=2.01 ms
64 bytes from 192.168.178.1: icmp_seq=68 ttl=64 time=2.70 ms
64 bytes from 192.168.178.1: icmp_seq=69 ttl=64 time=4.13 ms
64 bytes from 192.168.178.1: icmp_seq=70 ttl=64 time=2.26 ms
64 bytes from 192.168.178.1: icmp_seq=71 ttl=64 time=2.06 ms
64 bytes from 192.168.178.1: icmp_seq=72 ttl=64 time=2.24 ms
(...)
This is quite problematic during meetings. I reverted back to wpa_supplicant and I no longer have these big delays.
I suspect a scan is periodically done and cause these delays. I didn’t investigate why I have this with iwd only. Am I the only one with the issue? Where is the best place to report?
Cheers,
Matt
I have been running iwd on Ubuntu 20.04 for 2 weeks and so far, it’s been superb.
Oh that is interesting - I can also see that too (with iwd on Ubuntu 20.04) now that I look for it:
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=1.41 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.29 ms
64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=5 ttl=64 time=1.56 ms
64 bytes from 192.168.1.1: icmp_seq=6 ttl=64 time=1.43 ms
64 bytes from 192.168.1.1: icmp_seq=7 ttl=64 time=1.80 ms
64 bytes from 192.168.1.1: icmp_seq=8 ttl=64 time=1.58 ms
64 bytes from 192.168.1.1: icmp_seq=9 ttl=64 time=1.60 ms
64 bytes from 192.168.1.1: icmp_seq=10 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_seq=11 ttl=64 time=1.44 ms
64 bytes from 192.168.1.1: icmp_seq=12 ttl=64 time=1.51 ms
64 bytes from 192.168.1.1: icmp_seq=13 ttl=64 time=1.05 ms
64 bytes from 192.168.1.1: icmp_seq=14 ttl=64 time=1.30 ms
64 bytes from 192.168.1.1: icmp_seq=15 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=16 ttl=64 time=1.52 ms
64 bytes from 192.168.1.1: icmp_seq=17 ttl=64 time=1.62 ms
64 bytes from 192.168.1.1: icmp_seq=18 ttl=64 time=1.43 ms
64 bytes from 192.168.1.1: icmp_seq=19 ttl=64 time=1.27 ms
64 bytes from 192.168.1.1: icmp_seq=20 ttl=64 time=0.997 ms
64 bytes from 192.168.1.1: icmp_seq=21 ttl=64 time=59.9 ms
64 bytes from 192.168.1.1: icmp_seq=22 ttl=64 time=44.1 ms
64 bytes from 192.168.1.1: icmp_seq=23 ttl=64 time=1.40 ms
64 bytes from 192.168.1.1: icmp_seq=24 ttl=64 time=1.55 ms
64 bytes from 192.168.1.1: icmp_seq=25 ttl=64 time=1.87 ms
64 bytes from 192.168.1.1: icmp_seq=26 ttl=64 time=1.87 ms
64 bytes from 192.168.1.1: icmp_seq=27 ttl=64 time=1.36 ms
64 bytes from 192.168.1.1: icmp_seq=28 ttl=64 time=1.28 ms
64 bytes from 192.168.1.1: icmp_seq=29 ttl=64 time=1.61 ms
64 bytes from 192.168.1.1: icmp_seq=30 ttl=64 time=1.64 ms
64 bytes from 192.168.1.1: icmp_seq=31 ttl=64 time=1.52 ms
64 bytes from 192.168.1.1: icmp_seq=32 ttl=64 time=1.42 ms
64 bytes from 192.168.1.1: icmp_seq=33 ttl=64 time=1.52 ms
64 bytes from 192.168.1.1: icmp_seq=35 ttl=64 time=1.28 ms
64 bytes from 192.168.1.1: icmp_seq=36 ttl=64 time=1.46 ms
64 bytes from 192.168.1.1: icmp_seq=37 ttl=64 time=1.70 ms
64 bytes from 192.168.1.1: icmp_seq=38 ttl=64 time=1.51 ms
64 bytes from 192.168.1.1: icmp_seq=39 ttl=64 time=1.21 ms
64 bytes from 192.168.1.1: icmp_seq=40 ttl=64 time=1.53 ms
64 bytes from 192.168.1.1: icmp_seq=41 ttl=64 time=1.62 ms
64 bytes from 192.168.1.1: icmp_seq=42 ttl=64 time=1.49 ms
64 bytes from 192.168.1.1: icmp_seq=43 ttl=64 time=88.9 ms
64 bytes from 192.168.1.1: icmp_seq=45 ttl=64 time=0.931 ms
64 bytes from 192.168.1.1: icmp_seq=46 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=47 ttl=64 time=1.42 ms
64 bytes from 192.168.1.1: icmp_seq=48 ttl=64 time=1.68 ms
64 bytes from 192.168.1.1: icmp_seq=49 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=50 ttl=64 time=1.12 ms
64 bytes from 192.168.1.1: icmp_seq=51 ttl=64 time=1.89 ms
64 bytes from 192.168.1.1: icmp_seq=52 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_seq=53 ttl=64 time=2.52 ms
64 bytes from 192.168.1.1: icmp_seq=54 ttl=64 time=2.13 ms
64 bytes from 192.168.1.1: icmp_seq=55 ttl=64 time=1.71 ms
64 bytes from 192.168.1.1: icmp_seq=56 ttl=64 time=1.14 ms
64 bytes from 192.168.1.1: icmp_seq=57 ttl=64 time=1.85 ms
64 bytes from 192.168.1.1: icmp_seq=58 ttl=64 time=1.51 ms
64 bytes from 192.168.1.1: icmp_seq=59 ttl=64 time=1.14 ms
64 bytes from 192.168.1.1: icmp_seq=60 ttl=64 time=1.56 ms
64 bytes from 192.168.1.1: icmp_seq=61 ttl=64 time=1.57 ms
64 bytes from 192.168.1.1: icmp_seq=62 ttl=64 time=1.22 ms
64 bytes from 192.168.1.1: icmp_seq=63 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=64 ttl=64 time=1.48 ms
64 bytes from 192.168.1.1: icmp_seq=65 ttl=64 time=1.47 ms
64 bytes from 192.168.1.1: icmp_seq=66 ttl=64 time=11.8 ms
64 bytes from 192.168.1.1: icmp_seq=67 ttl=64 time=44.8 ms
64 bytes from 192.168.1.1: icmp_seq=68 ttl=64 time=80.5 ms
64 bytes from 192.168.1.1: icmp_seq=69 ttl=64 time=117 ms
64 bytes from 192.168.1.1: icmp_seq=70 ttl=64 time=1.79 ms
64 bytes from 192.168.1.1: icmp_seq=71 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_seq=72 ttl=64 time=1.54 ms
64 bytes from 192.168.1.1: icmp_seq=73 ttl=64 time=1.33 ms
64 bytes from 192.168.1.1: icmp_seq=74 ttl=64 time=1.53 ms
64 bytes from 192.168.1.1: icmp_seq=75 ttl=64 time=1.45 ms
64 bytes from 192.168.1.1: icmp_seq=76 ttl=64 time=1.14 ms
64 bytes from 192.168.1.1: icmp_seq=77 ttl=64 time=1.61 ms
64 bytes from 192.168.1.1: icmp_seq=78 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_seq=79 ttl=64 time=1.60 ms
64 bytes from 192.168.1.1: icmp_seq=80 ttl=64 time=1.26 ms
64 bytes from 192.168.1.1: icmp_seq=81 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_seq=82 ttl=64 time=1.14 ms
64 bytes from 192.168.1.1: icmp_seq=83 ttl=64 time=1.47 ms
64 bytes from 192.168.1.1: icmp_seq=84 ttl=64 time=1.47 ms
64 bytes from 192.168.1.1: icmp_seq=85 ttl=64 time=1.50 ms
64 bytes from 192.168.1.1: icmp_seq=86 ttl=64 time=1.34 ms
64 bytes from 192.168.1.1: icmp_seq=87 ttl=64 time=1.62 ms
64 bytes from 192.168.1.1: icmp_seq=88 ttl=64 time=1.40 ms
64 bytes from 192.168.1.1: icmp_seq=89 ttl=64 time=1.20 ms
64 bytes from 192.168.1.1: icmp_seq=90 ttl=64 time=1.24 ms
64 bytes from 192.168.1.1: icmp_seq=91 ttl=64 time=1.39 ms
64 bytes from 192.168.1.1: icmp_seq=92 ttl=64 time=8.76 ms
64 bytes from 192.168.1.1: icmp_seq=93 ttl=64 time=1.15 ms
64 bytes from 192.168.1.1: icmp_seq=94 ttl=64 time=1.23 ms
64 bytes from 192.168.1.1: icmp_seq=95 ttl=64 time=1.58 ms
64 bytes from 192.168.1.1: icmp_seq=96 ttl=64 time=1.88 ms
64 bytes from 192.168.1.1: icmp_seq=97 ttl=64 time=1.54 ms
This should probably be reported via https://bugs.launchpad.net/ubuntu/+source/iwd/+filebug
Previously this was at 54 Mb/s on two different devices and now both are 65 Mb/s
however sometimes it wont show any networks after sleep or occasionally after a reboot.
1 Like
Thank you all for examining the current NetworkManager/iwd integration!
This helps a lot in evaluating the feasibility of this new WiFi stack in many different use cases!
I’d like to write down a short summary of the results so far. But still encourage everybody to continue testing this improved WiFi setup, especially as the Ubuntu Groovy Gorilla (20.10) beta is slowly approaching and more and more people are using its updated software stack (esp. iwd 1.8 + NetworkManager 1.26). Also, I’ve added a poll to the initial post, where you can vote/submit you experience of using iwd on Ubuntu.
So far we got feedback from 35 individual testers of which 9 reported a positive experience (mostly on WPA2 personal networks), 14 reported a neutral experience and 12 reported a negative experience. A summary of the issues reported up to now, which should be investigated before making the switch to iwd, can be found here:
- NM shows duplicate SSIDs (e.g.”SSID” & “SSID 1”) for every connection
- NM displays 2.4GHz while real connection & iwconfig is 5GHz
- Fails to connect to hidden networks (on old 19.04!)
- WPA Enterprise PEAP (eduroam) needs provisioning files
- No connections listed after some reboots/resume (iwd restart fixes it)
- Network credentials requested twice
- WPA3 Personal does not work
- Prefers 2.4 GHz network over same 5GHz SSID
- Connection not stable, disconnects and (most of the time) quickly reconnects
- Device not detected (Linksys WUSB 6300 (rtl8812au) and a Panda PAU 08)
- Increased delay after ~25-30 sec (ping 1500ms for 3-4 sec)
Thanks!
Lukas
4 Likes
I am running iwd for 14 days + some now without any problems. I have an Intel Wi-Fi 6 pci express Wi-Fi card and mostly run on 5Ghz (FritzBox). It seems to me connecting to the Wi-Fi is faster, especially after boot. It did not notice anything special apart from that. Thanks for running this experiment and gathering feedback.
Kernel: 5.4.0-45-generic
Network controller: Intel Corporation Wi-Fi 6 AX200 (rev 1a)
1 Like
So what’s the next steps? Have we escalated the feedback to iwd? How can we engage with them to ensure the negatives are address and resolved?
I wonder for example, if increased delay is due to our NM configuration putting the wifi card into powersave mode, thus potentially operating the wifi card slower than possible.
Your installation notes above are very brief and I would think that they are inadequate to deal with the issues that people are going to run up against. I put iNet Wireless Daemon in yesterday after reading an article in Linux Magazine and following (often correcting!) the instructions there.
Overall, it’s working fine now. (For the record, I use iwd 1.5-1 on a Dell Inspiron 7xxx laptop with Ubuntu 20.04LTS with a 16 GB RAM and a 12 GB swapspace. ) But I had a number of issues during and after installation of the package.
-
It’s best to just disable the existing WPA Supplicant service before installing and enabling iwd.
-
Do not remove wpa_supplicant package as you may have issues during changeover that require re-engaging it to browse the web.
-
After installing and enabling iwd, enter the iwctl command, you are then within the [iwd] environment.
You find your device name via the command, device list. This is usually wlan0 and you can see more details on it via the command, device wlan0 show.
Now you can scan for available wifi networks via: station wlan0 scan. Then display available wifi networks via: station wlan0 get-networks.
The resulting list of available networks should include your own home (or office) wifi. It will be named by its SSID string. Previous posters have seen that where an ISP provides both a 2.4 GHz and 5 GHz speed service, it is important to distinguish between the two: they must be given separate SSID strings. More importantly, the SSID strings must not have spaces, e.g. VM545A32E 5ghz. If an SSID has a space, it will trigger a non-acceptance of that network SSID when the iwd selection command is entered:
station wlan0 connect VM545A32E 5ghz
This is because the iwd response parser stops at the first space in the SSID string.
So if you have a space in your network SSID, you must phone your network provider and ask them to change the SSID by removing the space(s) or else inserting a hyphen.
Once spaces are removed, the connect command shown above is readily accepted and iwd will prompt you for the passphrase (= password) that accompanies the SSID submitted. This is usually set by the network provider (and shown on a sticker or card on the modem) but may be changed by the user if they so wish. After you enter your passphrase, it is stored at /var/lib/iwd directory for future connections to that network at PC startup.
-
DNS Resolution
Create a /etc/iwd/main.conf file with the listing below
[General]
EnableNetworkConfiguratio=true
[Network]
NameResolvingService=systemd
- Integration With Network Manager
First stop the existing Network Manager service via: $ sudo systemctl stop NetworkManager.service
Then edit the Network Manager configuration file at /etc/NetworkManager/NetworkManager.conf with the lines:
[device]
wifi.backend=iwd
Now reboot your Ubuntu machine.
- Small iwd GUI Client (Optional)
Go to https://github.com/J-Lentz/iwgtk and download the zip folder for the project.
Check that packages, libgtk-3-dev and libglib2.0-dev-bin are installed on your PC. If not, install them.
Unzip the iwgtk-master folder, and use the README.md file to install the package.
Verify the presence of the iwgtk icon on your desktop’s Show Applications menu.
Click on the icon to open the iwd GUI client and explore its functions.
- WPS (Optional)
If you have a WPS button on your modem, this option may interest you.
Check WPS compatibility with your device via:
[iwd] wsc list
If this shows your wifi device (e.g. wlan0), then you may use WPS.
Then you can enter:
wsc wlan0 push-button
and press the modem’s WPS button.
If a PIN is needed, enter:
wsc wlan0 start-user-pin
followed by an 8 digit PIN.
As said earlier, I have just installed iwd yesterday so my experience is limited.
Clearly, the DNS resolution is now being done by systemd, so the previous DNS configuration I had applied to my WiFi configurations for DNS (i.e. on IPv4 tab, turn off the default “automatic” and enter the Google IPs 8.8.8.8,8.8.4.4) are now overwritten.
I observe no slowing of the domain name resolution.
Like others here, I also saw the SSID and SSID1 connections issue. But this was resolved by removing the old SSID connection that was created by wpa_supplicant. On rebooting, there was only SSID connection - and that was the one created by iwd.
If any useful observations emerge over the next month, I’ll report them here, if this page is still open.
3 Likes
I am trying use iwd in 18.04, use rtl 8812au usb dongle
and success to installed it (by manually add focal’s repository).
after following the instruction,
no SSID shown in NetworkManager
try restarting iwd few times, but still no SSID shown up…
Using 18.04 is most probably too old and many integration bits have not been implemented there. This guide was intended to be used with 20.04 or newer.
it cannot connect to an already same name network that was defined by wpa_supplicant since wpa_supplicant is now masked - hence the 1 for the iwd connection - you can delete both if you want then reboot and connect again and only one connection will be there or you can remove the original connection without the 1
I would argue that the description you used here illustrates a “works fine on my machine” response from a developer to a “user” when their expectations are unmet. This leads to very poor User Experience IMO.
1 Like
Have you tried installing with the procedure I gave above, diddledan ?
It’s 6 months since I installed Intel WiFi Daemon and there are no problems to report.
It works fine and seems quicker to respond that the predecessor, wpa_supplicant.
The only “odd event” was lately when trying to install Wine (a Windows interfacing suite for applications that only run on Windows) when the installer removed a load of apps and drivers that were not 32-bit compatible. Not suspecting any such effect, I found my web access gone along with some browsers and other major apps including Java.
Eventually I restored the system with Timeshift, then slow-motioned forward again to discover the nature of the problem. Standard Wine insists on 32-bit and 64-bit compatibility. So I dumped the Wine idea and used VirtualBox instead for evaluating Windows only apps like Affinity Designer.
So, good performance so far from iwd.
1 Like
Thank you very much @tamjk for this long-term test! It’s good to hear that the setup works as expected for you.
We’ve been in touch with Intel/iwd about some of the issues reported in this thread and we recently got the feedback that most of the problems reported here are supposed to be fixed in an iwd/1.15 & NetworkManager/1.32 setup.
Both of those packages/versions are currently on their way landing in the Ubuntu development release (Impish Indri, 21.10). And we should soon be able to kick-off a 2nd evaluation, checking those new version.
2 Likes
Good to hear. 
I’m on an LTS version of Ubuntu and have to stay on that as I’ll be coding for a server running the same version.
Would the new iwd and NetworkManager versions be available separately from 21.10 so we can test on 20.04 LTS ?
A good link on iwd not visible here is
https://wiki.archlinux.org/title/Iwd
P.S. Why does this forum not allow edits after a certain period ?
I would have liked to add this link to the list of info hyperlinks after the starting post from Lukas Märdian . . .
Hello there! I was using iwd on Ubuntu 20.04, and it was working great. Since the last update with kernel 5.11 when suddenly iwd had stopped working. I’ve tried to reinstall it but it didn’t help. Quick google search showed that this is actually a wide spread problem since kernel 5.9. So i wish to ask is there going to be a solution of some kind?
Hellion,
More details on your iwd version please.
$ iwctl
[iwd] # version
????????
Myself, I changed to version 1.15 about 3 weeks ago.
My neofetch system profile below:
OS: Ubuntu 20.04.2 LTS x86_64
Host: Inspiron 5567
Kernel: 5.11.0-25-generic
Uptime: 48 mins
Packages: 2596 (dpkg), 19 (snap)
Shell: bash 5.0.17
Resolution: 1280x1024
DE: GNOME
WM: Mutter
WM Theme: Adwaita
Theme: Yaru [GTK2/3]
Icons: Yaru [GTK2/3]
Terminal: gnome-terminal
CPU: Intel i5-7200U (4) @ 3.100GHz
GPU: Intel HD Graphics 620
GPU: AMD ATI Radeon R7 M260/M265 / M
Memory: 2611MiB / 15909MiB
If you are on a higher kernel version we should be worried about updates . . .