Closed xaverdh closed 6 months ago
Generally iwd is in many (all?) ways superior
I disagree on that: I'm actually considering switching back to wpa_supplicant for two reasons:
iwd
disconnects itself for a brief moment from a wifi.* WPA2 enterprise auth is broken.
In what way exactly / can you elaborate on that? I have been using iwd
with eduroam
quite successfully for a long time..
* I frequently have a weird issue where `iwd` disconnects itself for a brief moment from a wifi.
sounds more like a hardware or driver issue, but I may be mistaken; you don't have these disconnects with wpa_supplicant
?
and are you using iwd
standalone, or as backend for networkmanager
?
edit: I did some digging, and it appears that networkmanager + iwd
indeed does not support WPA2 enterprise auth
out of the box. This is not in any way a limitation of iwd
but of the networkmanager integration. You can simply drop a config file in /var/lib/iwd/
as described e.g. in the arch wiki. Also won't be a problem for the minimal image, because we don't ship networkmanager
there anyway..
I also disagree with this proposed changed. From my experience iwd does not work well with systemd-networkd when it comes to interface naming and therefore matching, and I'd much rather have the latter as a default.
[..] From my experience iwd does not work well with systemd-networkd when it comes to interface naming and therefore matching, and I'd much rather have the latter as a default.
Can you elaborate on what issues precisely you are having with interface naming?
They are race conditions, because both tools would like to have ultimate control over the interface name.
Also there is also the size argument to be had, where wpa_supplicant
comes in at just 3M from what I can tell.
❯ nix path-info -s /nix/store/1lv02j5dc9h8x889k4rhqqhx3d8clg6j-wpa_supplicant-2.9
/nix/store/1lv02j5dc9h8x889k4rhqqhx3d8clg6j-wpa_supplicant-2.9 3172864
They are race conditions, because both tools would like to have ultimate control over the interface name.
According to the arch wiki (https://wiki.archlinux.org/index.php/Iwd):
Since version 1.0, iwd disables predictable renaming of wireless device. It installs the following systemd network link configuration file which prevents udev from renaming the interface to wlp#s#`
So the race condition should be gone. At first sight it does look like we don't package iwd
properly in this regard though (at least on my system it looks the drop in config file is not present), will investigate / fix that..
Also there is also the size argument to be had, where
wpa_supplicant
comes in at just 3M from what I can tell.❯ nix path-info -s /nix/store/1lv02j5dc9h8x889k4rhqqhx3d8clg6j-wpa_supplicant-2.9 /nix/store/1lv02j5dc9h8x889k4rhqqhx3d8clg6j-wpa_supplicant-2.9 3172864
nix path-info -s nixpkgs#iwd
gives me
/nix/store/6h52jc4c9x40smf5nsqfv3ybwha9z48w-iwd-1.9 1974072
which is 1.9M..
But that's without libs, so not a very good comparison anyway.
iwd
was meant to be used on embedded systems and generally tries to reuse kernel features and introduce as few dependencies on external libraries as possible.
This is the runtime closure of iwd
after #105559 #105666
an this is the list for wpa_supplicant
:
opened https://github.com/NixOS/nixpkgs/issues/105775 concerning the race condition between iwd
and udev
Generally iwd is in many (all?) ways superior
I disagree on that: I'm actually considering switching back to wpa_supplicant for two reasons:
* WPA2 enterprise auth is broken.
What is specifically broken there. I used to have issues with ssl certificate pinning. However this was resolved some versions ago.
* I frequently have a weird issue where `iwd` disconnects itself for a brief moment from a wifi.
I cannot reproduce this issue. Is this maybe related to your wifi driver?
Issue description
Replacing
wpa_supplicant
byiwd
in the minimal iso image would slightly reduce size (assuming that something like #105559 get merged), while improving general user experience while installing. Generallyiwd
is in many (all?) ways superior to the old wpa_supplicant based infrastructure these days..
The ncurses ui is a lot more user friendly than what wpa_supplicant offers.
Generally, I'd be in favor of having iwd
as well. However, just like @Ma27, I've also found issues with iwd
dropping connectivity for a very brief but noticeable moment, and my university recently changed something in their 802.1X authentication, so that now, even if I add the cert manually in my eduroam.8021x
config file, the connection still fails saying that the cert is invalid. The weird thing is, this happens even if I actively choose to ignore the cert.
So yes, it would seem that iwd
802.1X auth is broken, or perhaps the packaging in NixOS isn't right, since I don't have those issues with wpa_supplicant
.
Generally, I'd be in favor of having
iwd
as well. However, just like @Ma27, I've also found issues withiwd
dropping connectivity for a very brief but noticeable moment, and my university recently changed something in their 802.1X authentication, so that now, even if I add the cert manually in myeduroam.8021x
config file, the connection still fails saying that the cert is invalid. The weird thing is, this happens even if I actively choose to ignore the cert.So yes, it would seem that
iwd
802.1X auth is broken, or perhaps the packaging in NixOS isn't right, since I don't have those issues withwpa_supplicant
.
blind shot: do you have EAP-PEAP-ServerDomainMask
(or the equivalent for your setup, i.e. EAP-TLS-*
, EAP-TTLS-*
) set (and to the correct value)?
and also are you using iwd
standalone or with networkmanager?
Also for ppl with those short disconnects, you might want to play with RoamThreshold
, DisableRoamingScan
and BandModifier5Ghz
(see man iwd.config
for their meaning), and see if that improves things. This sounds like it could be caused by a scan triggered for roaming by weak signal strength (perhaps in combination with driver specific issues?). I think roaming is also one of those areas where wpa_supplicant might be a lot more conservative?
blind shot: do you have
EAP-PEAP-ServerDomainMask
(or the equivalent for your setup, i.e.EAP-TLS-*
,EAP-TTLS-*
) set (and to the correct value)? and also are you usingiwd
standalone or with networkmanager?
Thanks for the helpful info. I believe I had it set, but I'm happy to try again. My setup is without Networkmanager in both cases, iwd and wpa_sup.
I'll come back with results, probably around the middle of next week.
Also for ppl with those short disconnects, you might want to play with
RoamThreshold
,DisableRoamingScan
andBandModifier5Ghz
(seeman iwd.config
for their meaning), and see if that improves things. This sounds like it could be caused by a scan triggered for roaming by weak signal strength (perhaps in combination with driver specific issues?). I think roaming is also one of those areas where wpa_supplicant might be a lot more conservative?
Again, thank you. I'll check it out and report back. ☺️
@xaverdh, sorry for the delay, I've only now managed to test this. I've added EAP-PEAP-ServerDomainMask
again, as you suggested, no luck unfortunately. The answer is always the same: bad_certificate :(
@xaverdh, sorry for the delay, I've only now managed to test this. I've added
EAP-PEAP-ServerDomainMask
again, as you suggested, no luck unfortunately. The answer is always the same: bad_certificate :(
Did you put the right domain in there? I had to load for example:
EAP-TTLS-ServerDomainMask=radius01.is.ed.ac.uk
instead of just ed.ac.uk
.
Did you put the right domain in there? I had to load for example:
EAP-TTLS-ServerDomainMask=radius01.is.ed.ac.uk
instead of just
ed.ac.uk
.
Yes, I did, with my Uni's equivalent (wifi.xxx.ac.uk
). Here's what I've found so far, which makes me think that perhaps something isn't quite right with either iwd
or the way we package iwd
:
When using wpa_supplicant
, I don't give it a certificate and this is what the configuration looks like:
network={
ssid="eduroam"
key_mgmt=WPA-EAP
identity="xxx@xxx.ac.uk"
password="xxx"
phase2="auth=MSCHAPV2"
}
That's all that's needed for wpa_supplicant
to connect.
With iwd
, one of the configurations looks like this:
[Security]
EAP-Method=PEAP
EAP-Identity=anonymous@xxx.ac.uk
EAP-PEAP-CACert=embed:xxx_eduroam_cert
EAP-PEAP-Phase2-Method=MSCHAPV2
EAP-PEAP-Phase2-Identity=xxx@xxx.ac.uk
EAP-PEAP-Phase2-Password=xxx
EAP-PEAP-ServerDomainMask=wifi.xxx.ac.uk
[Settings]
AutoConnect=false
[@pem@xxx_eduroam_cert]
-----BEGIN CERTIFICATE-----
xxxxxxxxxxx
-----END CERTIFICATE-----
I've tried variations with and without the cert. According to the manual page (iwd.network) omitting EAP-PEAP-CACert
will make iwd
not verify the certificate. However, even with this line omitted, iwd
will still report bad_certificate
in dmesg
.
I think I also had some cases where iwd could not reconnect that went away after switching back to wpa_supplicant. I have not tried to change RoamThreshold, DisableRoamingScan or BandModifier5Ghz, but I also don't know what values I would choose there.
Perhaps we could add both, wpa_supplicant
and iwd
? The impact of iwd
on the image's size is probably negligible, no?
Reagarding roaming, after scavenging the wpa_supplicant mailing list I discovered 802.11r (fast transition between APs) is not enable by default, even if the support is compiled in. Basically, the default protocol choices are key_mgmt=WPA-PSK WPA-EAP
, so to enable 802.11r you have to add FT-PSK
manually to each network
block in the configuration file.
Also from the mailing list, they are saying there isn't any downside to enable it, even if the network doesn't support it.
So, I think I'm going to open a PR to make the networking.wireless.networks
a bit more structured and set key_mgmt=WPA-PSK WPA-EAP FT-PSK
by default.
Another idea I have to improve the roaming is to add option like networking.wireless.scanOnLowSignal
, which configures a network scan when the signal drops below -70. This drastically improves the roaming, because by default wpa_supplicant only rescan when the signal is lost.
With these two settings roaming with wpa_supplicant is working perfectly for me.
Another idea I have to improve the roaming is to add option like
networking.wireless.scanOnLowSignal
, which configures a network scan when the signal drops below -70. This drastically improves the roaming, because by default wpa_supplicant only rescan when the signal is lost.
Thank you! Those changes make sense. I'll try them out too since I experience these issues a lot. Your proposed enhancements sound fantastic!
Hmm, setting key_mgmt=FT-PSK
results in wpa_supplicant just saying Successfully initialized wpa_supplicant
, but no connection or anything else happening. Odd.
@devhell: try this:
networking.wireless.networks.mynetwork.auth = ''
key_mgmt=WPA-PSK FT-PSK
psk="secret"
'';
networking.wireless.extraConfig = ''
# scan when signal is low
bgscan="simple:30:-70:3600"
'';
Thanks @rnhmjoj, I successfully tested it now. The issue was with my old router, which was a leftover cheap piece of junk from my previous ISP. Using the new router FT-PSK
works just fine. Thank you for expanding wpa_supplicant
:smile:
This issue has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/better-wifi-ux-on-the-non-graphical-installer/23030/24
To follow this ticket
@Neustradamus: You don't have to comment to subscribe, there's a Subscribe button on the page for that.
To add to the two good posts in the beginning, I am going to add that it is a lot easier for us if all ISO variants have the same underlying stack and as far as I know the plasma applet only really works great with wpa_supplicant.
You can always build a custom ISO with iwd instead of wpa_supplicant without much effort.
Closing as wont fox.
Issue description
Replacing
wpa_supplicant
byiwd
in the minimal iso image would slightly reduce size (assuming that something like https://github.com/NixOS/nixpkgs/pull/105559 get merged), while improving general user experience while installing. Generallyiwd
is in many (all?) ways superior to the old wpa_supplicant based infrastructure these days..