systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

jernst · 2015-01-11 05:44:20

TL;DR:
Is there a way to run a single wpa_supplicant process that handles any kind of USB WiFi adapter in connection with systemd-networkd?

Long version:
I'm running systemd-networkd, which has made networking setup a lot easier for wired interfaces. I'd like to make it just as easy for WiFi interfaces, but it seems there's some kind of wildcard support missing for wpa_supplicant. My question is whether I got this right, or there is some trick somewhere I didn't think of.

Here's my /etc/systemd/network/wifi.network:

[Match]
Name=wlp*

[Network]
DHCP=v4

In addition, I'm running:

systemctl start wpa_supplicant@wlp0s2f1u10

because that's the interface that my current WiFi USB adapter comes up on. This goes with /etc/wpa_supplicant/wpa_supplicant-wlp0s2f1u10.conf:

ctrl_interface=/run/wpa_supplicant
eapol_version=1
ap_scan=1
fast_reauth=1

network={
	ssid="something"
	psk="else"
}

This all works fine, except that:

I have to plug my USB Wifi adapter into this exact USB port, otherwise the interface name changes and wpa_supplicant isn't running there
if I plug in a different USB WiFi adapter (I have a zoo; nothing exceptional I guess, but it's a pain to keep track of which goes with which computer), the interface name may be different and wpa_supplicant isn't running there

systemd-networkd solved that problem nicely with the wildcard in the interface name above (Name=wlp*). (Also, dhcpcd -- which I'm not using in this setup -- can be told to listen to "all interface" which is sort of similar)

My question: can I do something similar with wpa_supplicant, so I don't have to run a separate wpa_supplicant daemon on all possible interface names?

I'm guessing the answer is No (and I'd like confirmation on that).

Secondly, perhaps I can write one or more udev rules that will present all of those possible interfaces as wlan0, wlan1 or such. In which case I could presumably run wpa_supplicant@wlan0 only and be happy (assuming that wpa_supplicant is happy to run even as long as the interface does not exist. Does it?) Anybody have any hints how to go about this, I haven't done that.

Thirdly, if neither of those are viable, is this a reasonable-enough set of requirements so it would make sense to run this by the wpa_supplicant developers as a possible future feature?

Last edited by jernst (2015-01-11 05:54:31)

jasonwryan · 2015-01-11 06:04:16

I'd go for the udev rule, myself...

Note, don't use a name that the kernel may attempt to use: https://wiki.archlinux.org/index.php/Ne … evice_name

Head_on_a_Stick · 2015-01-11 12:45:47

As I understand it, you can just add more stanzas to wpa_supplicant.conf to account for any & all connections and remove any reference to the interface (ie, just run wpa_supplicant.service using /etc/wpa_supplicant/wpa_supplicant.conf).

However, I don't use systemd-networked so I may be wrong.

jernst · 2015-01-11 22:00:29

@Head_on_a_Stick: I did some experiments, and I can't get it to work as you suggest.

The main difference between wpa_supplicant.service and wpa_supplicant@.service is that the @ version specifies an interface as an argument, while the non-@ version specifies -u and no interface, which according to the man page, means "Enabled DBus control interface. If enabled, interface definitions may be omitted." So presumably it would do the right thing if it got the right DBus events, but somehow that does not seem to be happening.

WonderWoofy · 2015-01-12 04:54:18

jasonwryan wrote:

I'd go for the udev rule, myself...
Note, don't use a name that the kernel may attempt to use: https://wiki.archlinux.org/index.php/Ne … evice_name

I second this. Knowing how to write simple udev rules can be amazingly useful.

Leonid.I · 2015-01-12 19:00:12

jernst wrote:

systemd-networkd solved that problem nicely with the wildcard in the interface name above (Name=wlp*). (Also, dhcpcd -- which I'm not using in this setup -- can be told to listen to "all interface" which is sort of similar)
My question: can I do something similar with wpa_supplicant, so I don't have to run a separate wpa_supplicant daemon on all possible interface names?

networkd "solved" nothing here. This is a mere coincidence that the wlp* wildcard works. For instance, you might have an interface called "wls1". Also, wpa_supplicant doesn't "listen" because "listen" applies to the TCP/IP layer. wpa_supplicant works at the frame level, so I'm not sure what you mean. If you want software that _manages_ multiple wifi interfaces, use netctl.

jernst wrote:

I'm guessing the answer is No (and I'd like confirmation on that).

Correct.

jernst wrote:

Secondly, perhaps I can write one or more udev rules that will present all of those possible interfaces as wlan0, wlan1 or such. In which case I could presumably run wpa_supplicant@wlan0 only and be happy (assuming that wpa_supplicant is happy to run even as long as the interface does not exist. Does it?) Anybody have any hints how to go about this, I haven't done that.

For the udev part, do something like

: cat /etc/udev/rules.d/10-network.rules 
SUBSYSTEM=="net", ATTR{address}=="a1:b1:c1:d1:e1:f1", NAME="wl0"
SUBSYSTEM=="net", ATTR{address}=="a2:b2:c2:d2:e2:f2", NAME="wl1"

Then, modify wpa_supplicant@.service as

: diff usr/lib/systemd/system/wpa_supplicant-nl80211@.service{,.new}
+++ usr/lib/systemd/system/wpa_supplicant-nl80211@.service	2015-01-12 11:45:10.839852357 -0700
--- usr/lib/systemd/system/wpa_supplicant-nl80211@.service.new	2015-01-12 11:44:56.843027430 -0700
@@ -1,5 +1,6 @@
 [Unit]
 Description=WPA supplicant daemon (interface- and nl80211 driver-specific version)
-Requires=sys-subsystem-net-devices-%i.device
 After=sys-subsystem-net-devices-%i.device
 
 # NetworkManager users will probably want the dbus version instead.

so that the unit doesn't fail if the adapter is not plugged. However, this solution is suboptimal (Think what happens if you suddenly remove the adapter)... You can try to use "BindsTo=" instead of "Requires=" but I wonder if you get errors on startup if the adapter is absent...

jernst wrote:

Thirdly, if neither of those are viable, is this a reasonable-enough set of requirements so it would make sense to run this by the wpa_supplicant developers as a possible future feature?

No. wpa_supplicant is only supposed to to what it's told. It is not a canned network management solution.

Arch Linux

#1 2015-01-11 05:44:20

systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

#2 2015-01-11 06:04:16

Re: systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

#3 2015-01-11 12:45:47

Re: systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

#4 2015-01-11 22:00:29

Re: systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

#5 2015-01-12 04:54:18

Re: systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

#6 2015-01-12 19:00:12

Re: systemd-networkd, wpa_supplicant and multiple USB Wifi adapters

Board footer