Wireless networking using spartan system managers such as Debian’s /etc/network or Arch’s netctl is one of those typical Linux things where if you haven’t done it in a while you can spend hours either just getting set up or, arguably worse, reconstructing how the whole thing has fallen apart when you don’t recall making any substantial changes that stopped your networking from, well, working. It’s worth investing a bit of time learning how these systems work, however, because the user-friendly GUI alternatives rely in part on the same backends, so roughing it will help you understand the system.
With wireless networking, you’ll typically want your system to autoselect the strongest registered network in range, which is done using wpa_supplicant. Your network manager will be communicating with this utility. In Debian, this means your wireless profiles are configured in /etc/wpa_supplicant/wpa_supplicant.conf and given ID strings there (using the field id_str) that are then recalled in /etc/network/interfaces. Instructions on the Debian Wiki are helpful, only rather than reproducing the id_str field in /etc/network/interfaces it says to reproduce the SSID and PSK fields generated into /etc/wpa_supplicant/wpa_supplicant.conf. In Arch, wpa_supplicant is used behind the scenes only, by netctl-auto; all configuration takes place in files in /etc/netctl/.
When running into issues with Arch’s netctl, of course the first step is to consult https://wiki.archlinux.org/index.php/Netctl. I find that some things are more prominently there listed than others, so here’s a few pointers to keep in mind:
- Step one when troubleshooting is to make sure that you have one and only one wireless network manager running, as competing managers (e.g. Network Manager and netctl) will cause fatal conflicts simply for being installed concurrently, given that each installs its own systemd services. Check for manager conflicts by scrutinizing the output of systemctl --type=service.
- netctl-auto implicitly relies on wpa_supplicant, but rather than reading a static /etc/(wpa_supplicant/)wpa_supplicant.conf as you would find on Debian or elsewhere, it dynamically creates /run/network/wpa_supplicant_wlan.conf or similar on the basis of the profiles in /etc/netctl/, then has wpa_supplicant read that configuration file. However, if any one of the profiles defined in /etc/netctl/ has an error in it, netctl-auto (or the corresponding command systemctl start firstname.lastname@example.org) will throw an error suggesting something is wrong with the .conf, which indeed won’t exist; and it does not matter whether the erroneous profile is active, in range, or neither. Sometimes in fact I get the error that a certain email address is not listed in the password store, a reference to the pass program, which confuses me in a number of ways: I’m not sure where it is sourcing that password, and the error will appear whether or not I have pass installed and an entry for the relevant email address set up for it. But the solution here is simply to return the contents of /etc/netctl/ to a configuration that has previously worked, or to start from scratch by removing all profiles if no such earlier state can be reconstructed. wifi-menu is helpful for setting up basic profiles, only systems like Eduroam are more complex and call for manual setup. Remember to use wifi-menu with the -o switch to ensure passphrase hashing.
- I often forget the syntax for resetting all the relevant network states so I can try a configuration just tweaked, but it really is defeat to have to restart the system. The most important commands in this context are:
- ip link set wlan down (substitute your own adapter name for wlan)
- killall wpa_supplicant (or how does one go about this step?)
- After this you are hopefully able to run systemctl start email@example.com.
- Other important commands include:
- List physical interfaces using iwconfig
- Scan for routers within range using iwlist scan or, more conveniently, wifi-menu.