Category Archives: systemd

Using IWD instead of wpa_supplicant

I always feel like I am a few years behind. Here is another example. Here at nearly the end of 2021 I have learned about IWD (iNet Wireless Daemon), which is a replacement for wpa_supplicant.

This is just to record a few facts about experiences over the last couple of days, subsequent to receiving and setting up a new frame.work laptop. I install Arch on this laptop, and initially followed what I had previously done in the earlier post: Switching to systemd-networkd.

One of the problems described in that post is that if one follows what it says, a side-effect is the loss of any very good “graphical” way to switch a laptop from one SSID to another. I detail there how I used a downloaded package called wpa_gui to do that, but while it is a good step forward, it is a bit clunky. Maybe I’m not using it exactly right… I mean no disrespect to its authors, and am glad it exists; but I went looking for something else. And I discovered the IWD package.

When I downloaded and installed IWD, in ignorance, I managed to completely eliminate my wireless device and spent a good deal of time recovering. Following are some things I learned. But there are two different changes in my environment going on here, and while they are related I’m not claiming that one requires the other. One of the changes is the substitution of IWD for wpa_supplicant as the party responsible for interacting with wireless radios, selecting one, authenticating to it, and making it available as a device. The second change is that I have begun to use NetworkManager again, in conjunction with systemd-networkd.

IWD is a systemd service, as is wpa_supplicant, NetworkManager, and systemd-networkd, and it is possible to create a great deal of confusion when all of these bits are installed on the same system. If one desires to have more confusion, one has only to do all this on an ubuntu system, where the presence of Canonical’s netplan software adds another order of magnitude increase in complexity, and additional opportunities for foot target practice.

One of the big opportunities for confusion arises when IWD renames network devices. If one has “.network” files (for steering systemd-networkd) which rely upon matches on the device names, surprise! the device names (like wlp11S0) get changed to (e.g.) wlan0 by IWD.

I probably don’t understand all this well enough to attempt to explain it, and will probably only look foolish if I try, so instead I will just detail where I ended up on two of my laptops.

I have enabled the services IWD, systemd-networkd and NetworkManager. In /etc/NetworkManager/NetworkManager.conf I have a [device] section containing the setting “wifi.backend=iwd” which instructs NetworkManager to rely on IWD rather than wpa_supplicant, and prevents NetworkManager from trying to start a wpa_supplicant. I have removed the local service file /etc/systemd/system/wpa_supplicant/wpa_supplicant@wlp11s0 (which I had described in my previous blog post), and have stopped and disabled (and even masked) the associated wpa_supplicant@wlp11s0 service as well as the plain wpa_supplicant service.

In /etc/systemd/network I have a .network file for 09_<laptop>_wireless.network containing the networkd description, same as before, except that the [match] now says “name=wl*” instead of the previous “name=wlp*” (because of IWD changing the name from wlp11s0 to wlan0).

Finally, one of these laptops is still ubuntu, so one gets the additional joy of netplan. There, in the /etc/netplan directory I went back to a yaml file which names the “renderer” as NetworkManager instead of systemd-networkd. My current, perhaps flawed understanding of this setting in netplan is that when netplan runs at boot time it uses the (collected and merged) yaml files to build at boot time the files for either systemd-networkd (in /run/systemd/network/), or for NetworkManager (in /run/NetworkManager/). These generated files will then get combined with similar files from /lib and from /etc (the latter having greatest priority, the former having least, and /run in the middle).

Going back to NetworkManager has one downside for me, the thing which drove me earlier to abandon NetworkManager in favor of systemd-networkd, and that is the specification of the IPv6 DUID to be used when soliciting an IPv6 address from DHCPv6. I can’t find information about how to stipulate the DUID to be used (for example in this nm_connection documentation). What I have done is develop better tools to figure out what NetworkManager decided to send, so I can arrange for the DHCPDv6 server to assign a static address to that DUID.

Waiting for system online with systemd

I had previously used the NetworkManager utility nm-online in my startup script as described in Waiting for networks, but now that I have moved to systemd-networkd that isn’t available anymore.

There is a fair amount of stuff on the net about the systemd service called systemd-networkd-wait-online.service. And indeed, that is a useful service, if one wants other services to wait for the network to be online. But somehow most of it seems to miss the point somehow, or at least one big point. I found various statements on the net that systemd doesn’t have the equivalent of nm-online. The only way in which that is true is if one means by it that systemd doesn’t have something as primitive. In truth what systemd has is much better, and much more powerful.

Continue reading Waiting for system online with systemd

Switching to systemd-networkd

Since moving to IPv6 I have had two recurrent problem: one with some conflict between systemd and the kernel over the /proc/sys/net/ipv6/conf/*/accept_ra, and the second with losing the static ipv6 address assignments on some boxes. I believe the former problem to have something to do with systemd wanting to have control of the sysctl variables, such as accept_ra.

The latter problem is due to the various bits of software that want to have a say in the control of the network. In part some of this is my own fault, as I do have these various bits installed – and if they weren’t installed they could not be causing trouble.

I installed NetworkManager in some places, even when it hadn’t been installed by default, because I wanted to be able to control things with the network applet in gnome. I installed dhclient even though it wasn’t installed, because I wanted better ability to see and control the dhcpv6 leases, particularly the DUID, and network manager made that difficult (and astonishingly, in some cases simply didn’t work).

Continue reading Switching to systemd-networkd