Provide wpa_supplicant.conf to NetworkManager to disable 5Ghz

snapd
1

Hi everyone,

We try to limit the usage of WiFi-bands to only 2.4ghz. The network configuration on our devices is steered by the NetworkManager snap. Wifi-connections will be made via the NetworkManagers DBUS interface. As we do own a brand account we’re in close contact with Canonical itself, namely @bugraaydogar.

In cooperation we figured different approaches to achieve locking out 5ghz.

1. Manipulate the drive in the kernel to only enable the 2.4ghz antenna.

We do not see this as a viable option as this would mean to maintain our own kernel. Maybe it easier to achieve by unloading modules after the initial boot.

2. Connecting via BSSID instead of SSID.

This of course would be one of the easier/saver approaches. However, this would decrease UX significantly as roaming between APs would not be possible. Also, users would need to reconfigure the device as soon the change APs even if the keep the SSID/password.

3. Leveraging the wpa_supplicant and it’s wpa_supplicant.conf option of the freq_list.

This is the much preferred option as this would not break current software. Also, UX would not be affected, neglecting the fact of not be able to use 5ghz.

So, @bugraaydogar suggested to change the start option of the wpa_supplicant.service file under /var/systemd/system/wpa_supplicant.conf to use the -c option were it would be possible to use a wpa_supplicant.conf file. As we tried to achieve the desired behavior for the wifi of only using listed frequencies in the given freq_list of the provided wpa_supplicant.conf, we unfortunately did not get the expected configuration. In advance we replaced the symlink of /etc/systemd/system/wpa_supplicant.conf to /lib/systemd/system/wpa_supplicant.conf and directly created a wpa_supplicant.service file. We reloaded daemon and rebooted. So it was ensured the wpa_supplicant service systemd is using was using the correct service-file.

The service file ended up looking like,

[Unit]
Description=WPA supplicant
Before=network.target
After=dbus.service
Wants=network.target
IgnoreOnIsolate=true

[Service]
Type=dbus
BusName=fi.w1.wpa_supplicant1
ExecStart=/sbin/wpa_supplicant -u -s -c /var/snap/my-snap/common/wpa_supplicant.conf -O  /run/wpa_supplicant

[Install]
WantedBy=multi-user.target
Alias=dbus-fi.w1.wpa_supplicant1.service

The provided wpa_supplicant.conf had the following content,

ctrl_interface=/run/wpa_supplicant
ctrl_interface_group=0
update_config=0
freq_list=2457

We would be happy to receive suggestions how to achieve the disablement of 5ghz through the wpa_supplicant. If this can configured differently we would be happy to know about this. :slight_smile: As long it is possible we would like to disable the 5ghz per configuration and not by filtering a scanned list or connecting through BSSID.

In appreciation of your help,

Reto

2

Hi @retob,

Thanks for moving the topic to the forum. By this way, we could also have a chance to help others who have similar problems.

I’m quite surprised that 3rd option (hack) did not work. I believe, it might be due to the missing freq_list variables. I made a quick check on my machine by using the wpa_cli tool. E.g.

sudo wpa_cli
> interface wlan0
> scan
wait a little bit since the request is async.
> scan_results

As a result, I got something like that;

bssid / frequency / signal level / flags / ssid
68:a0:3e:93:47:2f	5260	-38	[WPA2-PSK-CCMP][WPS][ESS]	SUPERBOX_Wi-Fi_472B
6a:a0:3e:93:47:21	5260	-38	[WPA2-PSK-CCMP][ESS]	\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
68:a0:3e:93:47:2b	2432	-31	[WPA2-PSK-CCMP][WPS][ESS]	SUPERBOX_Wi-Fi_472B
74:45:2d:ce:dc:d0	2437	-76	[WPA2-PSK-CCMP][WPS][ESS]	JONNYLE\xc5\x9e
88:41:fc:31:da:6e	2412	-82	[WPA-PSK-CCMP+TKIP][WPA2-PSK-CCMP+TKIP][WPS][ESS]	AirTies_Air5750_D66Y
08:26:97:1c:46:a2	2417	-83	[WPA-PSK-CCMP+TKIP][WPA2-PSK-CCMP+TKIP][WPS][ESS]	TurkTelekom_ZMR4N
6a:54:4b:63:69:29	2447	-66	[WPA2-PSK-CCMP+TKIP][ESS]	ZyXEL_3
c8:54:4b:63:69:2b	2447	-67	[WPA2-PSK-CCMP+TKIP][WPS][ESS]	BugraAydogar
6a:54:4b:63:69:2a	2447	-69	[WPA2-PSK-CCMP+TKIP][ESS]	ZyXEL_4
6a:54:4b:63:69:28	2447	-46	[WPA2-PSK-CCMP+TKIP][ESS]	ZyXEL_2
60:14:66:fc:29:72	2462	-75	[WPA2-PSK-CCMP][WPS][ESS]	turkcellWifi_1411

As you can see, I never get a 2457 as a fundamental frequency. Please see the following link for the details. Maybe, this is somehow related with your issue. Also, please provide the logs of the wpa_supplicant by using sudo journalctl -u wpa_supplicant.service --no-pager. https://en.wikipedia.org/wiki/List_of_WLAN_channels#2.4_GHz_(802.11b/g/n/ax)

Alternatively, there are two additional potential solutions;

These are the all options that I can think of currently. Do you guys have any suggestions @ogra, @abeato?

3

Hi @retob,

I can confirm that freq_list does not work. I also have found the following thread in wpa_supplicant’s mailing list. Basically, people are questioning what is the intention of the freq_list parameter and if it ever worked. It seems like freq_list is misleading.

http://lists.infradead.org/pipermail/hostap/2021-September/039881.html

Maybe you could consider snapping iwd? => https://iwd.wiki.kernel.org/ It seems like it allows you to scan specific frequency with sudo iw dev wlp0s20f3 scan freq 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 2484

But I’m not sure how it will integrate with network-manager.

4

I can confirm that we do have WiFis with frequency 2457 available in our environment. I can see them with the wpa_cli and the scan_results. So probably just no WiFi with this channel near you. As we limited the list to 2457 I would expect to only see WiFis in this channel, but this was not the case.

However, your statement of the wpa_supplicant not actually implementing the freq_list-feature correctly this would explain this outcome.

The alternatives are not an options as,

  • NM_WIFI_DEVICE_CAP_FREQ_5GH just describes whether the device/driver is capable of 5ghz. It does not seem to be a configurable option, its more a set-bit from the driver.

  • The scanning would only limit the results to non 5ghz. It does no solve the problem of roaming from 2.4ghz to 5ghz due to having the same SSID / credentials.

  • Option of snapping iwd and make network-manager use it seems to be to complex and is a extensive implementation to test and verify.

Currently I do not see a option to avoid this by configuring wpa_supplicant or NetworkManager. Solutions still available / possible would need extensive implementation like iwd with NetworkManager. Or they are not feasible as it only would limit scan results and not limiting the device actually emitting/connecting 5ghz band.

5

Hi @retob ,

The scanning would only limit the results to non 5ghz. It does no solve the problem of roaming from 2.4ghz to 5ghz due to having the same SSID / credentials.

There is band parameter in the NetworkManager’s documentation. => https://developer-old.gnome.org/NetworkManager/stable/settings-802-11-wireless.html

Unfortunately, this is not a system-wide configuration. It is a per-connection basis. So once you connect to a wifi , a netplan yaml file will be created under /etc/netplan/ directory. If you can add band parameter in your netplan.yaml configuration file, then it would help you to stick with 2.4 GHz even if the SSID/credentials are the same. Please refer to the => https://netplan.io/reference

I think you can programmatically modify the file and then use netplan apply to stick with 2.4 GHz. You might wonder how such a configuration is possible considering it should be supported in the wpa_applicant, I assume that freq_list is not a system wide configuration, it is per connection.

Option of snapping iwd and make network-manager use it seems to be to complex and is a extensive implementation to test and verify.

Technically network-manager can also use iwd as a backend. However, this also requires some changes in the network-manager snap.

In summary, you can filter the scanning results and only show 2.4 GHz Wifi Routers. In addition to that, you can use band parameter to limit connecting to the 2.4 GHz only. Unfortunately, there is no kernel or system-wide configuration that would completely disable 5 GHz band.

Just as a side note, there is a kernel configuration parameter /sys/module/cfg80211/parameters/cfg80211_disable_40mhz_24ghz that disables the 2.4 GHz. I tried but it does not work at all. It seems like a similar but working configuration option is also needed for 5 GHz.

Regards, Bugra

1 Like
6

Hi Bugra,

At this point you would like to state that the disablement of 5ghz is a new feature. We did not had this implemented.

I would like to limit the discuss to how we can disable 5ghz band on a low-level, driver-oriented way.

Ensuring the usage of only 2.4ghz with software-based approaches (limiting scans, filter, pin credentials to bands) are known to be possible. However, they are not considered to reach the goal of actually disabling the 5ghz. Thank you for the research you have done on this. Those software-based approaches will surely help others.

To conclude the discussions on disabling 5ghz with drivers such as wpa_supplicant.

wpa_supplicant.conf does know a setting freq_list which, stated by the documentation, should limit the usage of certain frequencies. This options is, per documentation, also available in the global block and not only limited to the network-block. In comparison to scan_freq which is limited to the network-block.

https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf

However, after test by @retob and @bugraaydogar this option does not seem to work. This is conclusion might also backed up by the mail-list of hostapd.

http://lists.infradead.org/pipermail/hostap/2021-September/039881.html

It is unknown if the usage of iwd instead of wpa_supplicant would provide the capability to achieve this.

To address unknowns uncovered by the research of @bugraaydogar,

I assume that freq_list is not a system wide configuration, it is per connection.

As documented in it can be used outside of network-blocks and should limit scanning. This is actually the exact feature which is looked for.

connect to a wifi , a netplan yaml file will be created under /etc/netplan/ directory. If you can add band parameter in your netplan.yaml configuration file, then it would help you to stick with 2.4 GHz even if the SSID/credentials are the same

This is considered a sophisticated software-based solution for the said problem.

/sys/module/cfg80211/parameters/cfg80211_disable_40mhz_24gh

Without researching / checking on this. The name of the parameter in my eyes does not suggest to disable 2.4ghz completely. Rather it suggest that the capability of the usage of 40mhz wide channels on the 2.4ghz band is disabled. Consult the wiki page of 2.4ghz (can only put 2 links in posts)

Thanks for the extensive research and the presented suggestions to achieve a solution on this.

Regards, Reto

7

can’t you actually mangle the CRDA database to limit the accessible frequencies like here ?

8

CRDA database is signed with a trusted public key, and thus one cannot mangle it easily.

1 Like
9

Do you have the control of the APs? And are you configuring different APs with different SSID names on 2.4GHz and 5GHz? Such that your desired AP SSID name on 2.4GHz is not reused and published on 5GHz as well?

Usually, those that do not want 5GHz connections, do not advertise such channels on the AP side.

10

We do not have control over the WiFi-Infrastructure(s).

11

can’t you actually mangle the CRDA database to limit the accessible frequencies like here ?

Interesting approach this might worth a try.

CRDA database is signed with a trusted public key, and thus one cannot mangle it easily.

Can we bypass the verification of valid signature somewhat? By whom is it done? wpa_supplicant, NetworkManager ?

12

Can we bypass the verification of valid signature somewhat? By whom is it done? wpa_supplicant , NetworkManager ?

Nope, there are kernel parameters called CONFIG_CFG80211_REQUIRE_SIGNED_REGDB and CONFIG_CFG80211_USE_KERNEL_REGDB_KEYS. Since they are enabled in the kernel, you would need to provide a valid signature.

The mentioned regulatory database is shipped with wireless-regdb package. => https://packages.ubuntu.com/focal/wireless-regdb

It is already available as part of your pi-kernel => https://git.launchpad.net/~canonical-kernel-snaps/+git/kernel-snaps-uc20/tree/snapcraft.yaml?h=pi#n13

So a potential solution would be building your own linux-kernel, disable the mentioned configurations so that you might have a chance to modify it. However, this is still a software oriented way and it does not help you to disable 5 GHZ support of the underlying hardware.

Currently, linux kernel does not provide any configuration or system call to disable 5 GHz support.