TUI for Managing WiFi on Linux(github.com)
github.com
TUI for Managing WiFi on Linux
https://github.com/pythops/impala
58 comments
> 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.)
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.
> 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.
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.
The base system comes with systemd, which comes with systemd-networkd. It’s disabled by default, though, but it’s there.
[deleted]
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:
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
> 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.
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.
Yeah :) It's actually netctl. I haven't used it for so long, I forgot what it's called.
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.
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.
Past the edit deadline, that should be 'nmtui'
> 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...
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.
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.
Seems similar:
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...
iwctl station wlan0 connect "essid" --passphrase "itsasecret"
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.
Welcome to the dark side :)
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.
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.
I highly recommend nm-applet in arch and sway. Its just so much less pain having a small ui to use
[deleted]
Lol sorry for my comment interrupting the circle jerk of arch users.
You're right, learning a bunch of bespoke commands you have to run on every new install is super based.
You're right, learning a bunch of bespoke commands you have to run on every new install is super based.
Doesn't nmtui come installed by default?
Only if your distro uses network manager
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
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.
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
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
iwd does not wrap wpa_supplicant, it's a from-scratch implementation and a much nicer one at that.
It looks like it wraps NetworkManager or ConnMann - both of which wrap around wpa_supplicant for wifi. So yep, iwd wraps wpa_supplicant.
Architecture diagram on home page: https://iwd.wiki.kernel.org/
Architecture diagram on home page: https://iwd.wiki.kernel.org/
You're reading that diagram backwards.
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
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
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.
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.
Oh ok, so I misread the arch diagram. I thought that iwd was talking to the iwd backend, which would then delegate to NM or CM.
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.
[0] https://iwd.wiki.kernel.org/networkmanager
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.
[0] https://iwd.wiki.kernel.org/networkmanager
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.
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.
Alright, thanks for the information! :)
> 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.
W Linux
Supported Hardware
W Linux Solving problems
W Linux Solving problems
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...
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").
Is that adapter on the motherboard, PCI, or Usb? I'm starting to suspect that the problem is with the USB connection.
It's a PCIe card. Bought in 2016, seems to be this: https://www.tp-link.com/us/home-networking/pci-adapter/tl-wd...
Perfect, thank you.
> wifi disconnects
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?
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?
Thanks, I'll try to find a good USB or PCI Intel wifi modem. Good idea.
iwd is an alternative to wpa_supplicant, not NetworkManager.
NM has support for iwd.
NM has support for iwd.
> 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.
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.
Well, I showed off my ignorance of iwd quite effectively :)
TIL it is a wpa_supplicant replacement. Sorry for the misinformed comment!
TIL it is a wpa_supplicant replacement. Sorry for the misinformed comment!
wpa_supplicant is a buggy hot mess with very little effort in the way of accepting patches, from me or anyone else.
Iwd is a separate program and actually works.
Try it out. It doesn't suck
Iwd is a separate program and actually works.
Try it out. It doesn't suck
What does this do that `nmtui` doesn't?
https://www.computernetworkingnotes.com/linux-tutorials/the-...
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.
https://www.computernetworkingnotes.com/linux-tutorials/the-...
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.
This is awesome, I'm going to try this out because the first thing I do on an Alpine Linux desktop/laptop install is replace nm with iwd.
The number of times I have accidentally broken the wifi/Internet GUI on my os during updates, this could actually come in handy.
iwctl would be the built-in way (built-in in the sense that this already needs iwd, iwctl is the frontend that comes with).
This is an alternative that gives it TUI vs just the interactive console. Not something I use enough to care what it looks, personally.
This is an alternative that gives it TUI vs just the interactive console. Not something I use enough to care what it looks, personally.
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.
Beautiful
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.