This looks really nice, I like the design, congrats.
I’ve been getting into Arch (with Sway) recently and resisted installing something like this initially since as they say, the manual install process is the tutorial.
Getting basic WiFi connected with DHCP on vanilla Arch requires enabling multiple services and conf file edits - you rage against the machine thinking why is it so hard but then realise you just learnt how to swap out any part of your network stack (or the other fun footgun of installing multiple conflicting network managers to intermittently and silently break your connection). Anyway, rant over, not going back to Ubuntu anytime soon.
> Getting basic WiFi connected with DHCP on vanilla Arch requires enabling multiple services and conf file edits - you rage against the machine thinking why is it so hard
It's not trivial, but it's not difficult either. I have been using iwd. It involves installing one package, editing one file, and enabling two services. There are no dependencies beyond the base package, partially because a DHCP client is built into iwd. It may be possible to get away with enabling only one service, but I haven't figured out how to get the glibc resolver working. Incidentally, this TUI appears to be a replacement connection manager for iwd's `iwctl` command.
Of course, installing a desktop environment may result in NetworkManager being installed and NetworkManager will install it's preferred network stack. That said: I don't recall Arch enabling NetworkManager by default, though it is definitely something people would enable when installing a desktop environment (leading to the dueling network managers situation).
(A similar lesson learned: systemd-boot is much easier to setup than traditional boot managers and it is installed on Arch by default. Like iwd, it is meant for common straight forward setups.)
What confuses me about the part of the article you quote is that wifi doesn't really stick out as one of the harder parts of installing Arch; having fine-grained control over how the system is set up and therefore configuring everything by hand is kind of the point! At least to me, it's more straightforward than manually partitioning/formatting the hard drive and manually populating /etc/fstap, especially when you want to involve things like LUKS and LVM. My standard practice if I need wifi is to start with `wpa_supplicant` and `dhcpcd`, and then I can swap to NetworkManager later when I get around to setting up the GUI (which will usually be "post install", after I've rebooted into the new installation). Setting them up sounds similar to iwd (editing one file and enabling two services), which is pretty run-of-the-mill for an Arch installation.
> Of course, installing a desktop environment may result in NetworkManager being installed and NetworkManager will install it's preferred network stack. That said: I don't recall Arch enabling NetworkManager by default, though it is definitely something people would enable when installing a desktop environment (leading to the dueling network managers situation).
It definitely doesn't enable it by default; I'm not really even sure what "default" would mean in this context because Arch doesn't really have an "installer" in the traditional sense. An Arch installation typically will comprise of partioning/formatting the hard drive, mounting the partitions, running `pacstrap` to install things directly to the mounted root rather than to the currently running system, and then chrooting in to manually configure anything else that's needed. I guess some people might consider what you get from the `base` set of packages to be "default", but IIRC that alone wouldn't come with _anything_ to configure wifi, let alone NetworkManager.
> What confuses me about the part of the article you quote is that wifi doesn't really stick out as one of the harder parts of installing Arch; having fine-grained control over how the system is set up and therefore configuring everything by hand is kind of the point!
Agreed. On the other hand, what you decide to spend your time tuning will bias what you think of as simple or complex. I tend to lean towards the "fewest moving parts" along with "tried and true" solutions, so partitioning is straightforward. It sounds like you have other needs, so partitioning is more complex.
> It definitely doesn't enable it by default; I'm not really even sure what "default" would mean in this context because Arch doesn't really have an "installer" in the traditional sense.
By default I mean any actions taken by hooks/scripts during package installation, or the configuration files installed with the package. Arch may take a light touch, but some decisions are made either by the package maintainers or the original software developers.
I had a similar experience back when I switched to Arch. For some reason, the default at the time for network configuration was netctl. Coming from a world where default = old, true and tried, I assumed that newtorkctl is going to be just that.
Fast-forward few years: I learned that no matter the Linux distro, true and tried is NetworkManager. It has various flaws, which is why there are plenty of complementary / alternative management solutions, but they usually come with more flaws than what they purport to replace / complement.
Also, it's worth learning several commands from nmcli family. Especially, when it comes to wifi:
nmcli d wifi list
nmcli d wifi connect $SSID password $PASSWORD
This will cover most of what you need when connecting to WiFi with your laptop wherever you need most of the time.
Network Manager also has 'mntui' -- which is a simple text ui for configuring Wifi.
As a systems guy, on Debian, the workflow that works for me is to have wired interfaces defined as 'manual' in /etc/network/interfaces, so NetworkManager skips them, and I can configure them using the typical linux tooling and leave wifi managed by NetworkManager, so it can easily manage the dance between WPA/DHCP/AP association.
> I assumed that newtorkctl is going to be just that.
My morning brain read that like "new torque sea tee ell" and didn't realize there was a typo. It was incredibly confused for several long seconds thinking that one through. Finally after being unable to understand it, I noticed it was a typo.
> you rage against the machine thinking why is it so hard but then realise you just learnt how to swap out any part of your network stack (or the other fun footgun of installing multiple conflicting network managers to intermittently and silently break your connection)
I achieved the first one (and at some point the last one) without achieving the middle one, I think...
Coming from openbsd, linux wifi management was a real disappointment. To be fair freebsd's wifi system was not very good ether. at a low level you needed to muck around with three different config programs to get it to work, and more often than not you did not want to touch any of that because it would interact badly with network manager, a 800 pound gorilla of a program containing more code and configuration options then most of openbsd. I am not ashamed to say that networkmanager always intimidated me.
The amount of care the openbsd team puts into keeping it's system simple is very under rated. If unfamiliar, all you usually need for openbsd wifi is.
ifconfig iwn0 join "essid" wpakey "itsasecret"
jam 'join "essid" wpakey "itsasecret"' into your /etc/hostname.iwn0 and you are good to go.
iwctl station wlan0 connect "essid" --passphrase "itsasecret"
The permanent config would be stuffed into /var/lib/iwd/essid.conf (different file per SSID)
The harder part for me is remembering it's "iwctl station wlan0 scan && iwctl station wlan0 get-networks" to see what's out there for a new connection. Of course I always cheat and make a wifi-scan wrapper script so maybe that's why I never remember...
Once you get rid of network manager it's not terrible. I think to part that felt less than satisfactory was first you have to get the interface up, so read the man page for "ip" and figure that out. then you have to get the wifi parameters set but you can't do the from "ip" (why not?) so you grab iwctl and get that going. then just to add insult to injury it still would not work and you had to figure out "wpaclient"(I have not set up wifi on linux in a while is this still needed?). whereas on openbsd it is one command and there is never a management utility you have to watch out for unless you put it there yourself, and you probably would not do that because the base does a decent job at this it is why they added the "join" command. openbsd may still need "wpaclient" but only if you want to connect to a .11x type network not for the more common psk ones.
"Wpa_supplicant" perhaps? That's wha iwctl replaced. You don't need anything else installed to connect to .1X networks just "iwctl station wlan0 connect examplessid" and follow the prompts.
I recently finally switched to NetworkManager after using Arch's netctl for years (since so long ago I don't remember why I picked it in the first place). It's been a nice experience so far and I don't have any reason to reach for something more minimal again for network management. That's the beauty of Arch—you will indeed learn a lot by default but all the options are there and well documented in the wiki of course.
Anyway, have fun, and remember, it's not a partial upgrade if you didn't sync your package lists (that one took me too long to figure out). Breaking stuff is part of the fun and learning for sure, but to be honest maintaining Arch becomes rather routine after the initial learning curve. In a way even less so than non rolling distros since there's never a jarring version bump with some big changes. My current install has been chugging along for over seven years across two different laptops.
This wraps iwd tools I think. Even though, to be fair to the spirit of your comment, I don't see anything in the readme offering significant more functionality than iwctl
The chances that your distro ships with network manager are multiple orders of magnitude higher than it shipping with iwd though… I don't think iwd is the default anywhere?
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.
> multiple orders of magnitude higher than it shipping with iwd though
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
I noticed my error. To be fair, I don't think I read the diagram backwards. I think the diagram is drawn backwards instead. In it, iwd seems to talk to the iwd backend via D-Bus as they're close together.
Or maybe that's a diagram technique I'm just not used to.
It reads as a fairly normal diagram to me; NetworkManager has an iwd backend component/plugin that talks over D-Bus to iwd, which in turn stands on top of ell which in turn stands on the kernel (which itself contains a bunch of components of interest).
NetworkManager can use iwd as a wifi backend instead of wpa_supplicant, but nm isn't needed as iwd can also manage the networks on its own. iwd should never run at the same time (on a single network interface) as wpa_supplicant, as wpa_supplicant is (almost?) entirely superseeded by it.
That paragraph of the article looks to be ~6 years out of date according to the network manager version number it lists, around the time of the initial iwd release, and the whole article seems to be at least 2-3 years out of date since then iwd is well into version 2.x now.
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.
What should I be reading to understand exactly how the pieces fit together?
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.
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?
We had disconnects in our office (so very different machines, different Linux distros and a Mac at least). Don't remember for sure, I believe the message was reauthentication successful and after that connection was lost.
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...
I've never had that problem on Kubuntu, so it's not a general Kubuntu issue. Multiple different access points, but just one PCIe wireless adapter (identified as "Qualcomm Atheros AR93xx Wireless Network Adapter").
> The chances that your distro ships with network manager are multiple orders of magnitude higher than it shipping with iwd though… I don't think iwd is the default anywhere?
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.
EDIT: OK, it doesn't need network-manager. But I suspect about 99% of Linux installations do have that installed already, and if you need to get online, it's more useful to know the existing tool than a clever alternative you don't have installed.
I wish they made a debian package that came with "iwd", to use after you installed Debian with a desktop, but NetworkManager is not installed for some reason!
While I tend to prefer gui, this seems really nice to have. I'd kind of like to see everything in the GTK Settings panel available in a friendly text ui form.
I’ve been getting into Arch (with Sway) recently and resisted installing something like this initially since as they say, the manual install process is the tutorial.
Getting basic WiFi connected with DHCP on vanilla Arch requires enabling multiple services and conf file edits - you rage against the machine thinking why is it so hard but then realise you just learnt how to swap out any part of your network stack (or the other fun footgun of installing multiple conflicting network managers to intermittently and silently break your connection). Anyway, rant over, not going back to Ubuntu anytime soon.