FWIW there's also wpa_cli which tends to work almost always (since everything wraps wpa_supplicant in the end), but it's a CLI rather than a TUI, and not a particularly usable one.
Even if that were true (and ignoring the fact that they aren't alternatives to each other, like other comments point out)
If you're on a distro with iwd you might still want a TUI without having NetworkManager installed. A tool doesn't need to be universally needed to be useful
Architecture diagram on home page: https://iwd.wiki.kernel.org/
It looks like you're right [0], so I stand corrected.
It also looks like it can't fully replace wpa_supplicant though:
> IWD and the NM backend are work in progress and the capabilities are still limited.
Distros like Ubuntu have defaulted to iwd as the NM backend for Wi-Fi for a couple years (and now in the LTS version). It really is a quite popular and stable replacement to wpa_supplicant.
NetworkManager and ConnMan can optionally _USE_ iwd as a backend _INSTEAD OF_ wpa_supplicant.
iwd does _NOT_ use NetworkManager/ConnMan
Source: gentoo user who explicitly avoids the buggy disaster that is NetworkManager+wpa_supplicant whenever possible
Or maybe that's a diagram technique I'm just not used to.
> everything wraps wpa_supplicant in the end
I'm on Kubuntu, and have been suffering wifi disconnects for years across multiple computers with multiple USB wifi dongles and multiple access points. Literally not a bit of hardware shared, not even the access points. I suspect that Kubuntu shuts down USB wifi dongles after a period of time, as the only reliable way to get back online is to simply disconnect then reconnect the USB dongle. I forget what dmesg says (on mobile now) but it's something to the effect of a voluntary disconnect.
The AP runs OpenWrt. We worked around it by changing the reauthentication interval to 8 hours. Those working longer have to deal with it... Yeah, it's probably a weaker security now...
This is more likely to be a driver issue than management issue.
I think, this was posted to HN before, but I cannot find the article right now, but the gist of it is: both WiFi h/w vendors and Linux driver authors are to blame for the dismal state of events. On the h/w vendor side everything as per usual: no drivers, or broken drivers, incorrect product labeling or self-identification, false or imprecise advertisement of available features. On Linux side: slow inclusion of community-provided drivers for various WiFi modems, no real effort at cataloging and unification / systematization of available drivers.
My experience so far is this: Intel h/w is the one that has best Linux support. So, if you are on Realtec or Mediatec, you are getting the short end of the stick.
Another universal problem: WiFi protocol keeps iterating at a relatively high speed. Which means that you are often in a situation where either your modem or your router don't speak the same protocol at a good level, and the middle-ground that they find is not well-supported or, sometimes will only be found after lengthy unsuccessful attempts by both sides to do the handshake. This is often also exacerbated by the management software which may misidentify these "handshake problems" and "solve" them by restarting something in the network stack, essentially sending you into an infinite loop of trying to connect.
In my unfortunate case with my latest PC build, I had to swap three WiFi modems before I found one that worked satisfactory with the router I have. So, if you have some extra $ to throw at your problem: maybe try getting another WiFi modem?
W Linux Solving problems
NM has support for iwd.
It doesn't matter what the default is, though. Some people don't use NM, and this tool is for them.
> (since everything wraps wpa_supplicant in the end)
That's not true. IWD doesn't require wpa_supplicant.
TIL it is a wpa_supplicant replacement. Sorry for the misinformed comment!
Iwd is a separate program and actually works.
Try it out. It doesn't suck