Compex wle900vx (qca988x) support in Linux kernels > 5.6 #189

chr0mag · 2020-12-20T02:03:51Z

Linux kernel v5.6 included a commit that effectively disables the ability to operate this card in AP mode on the 5GHz band -- unless the device is provisioned with settings specific to the region where it will operate.

There are ongoing discussions on the ath10k mailing list about this which can be reviewed for details. See here and here.

The country/regulatory domain for these devices seems to be set in firmware/EEPROM and I don't believe it is possible to override this in software.

Is PC Engines aware of this issue? Is there a way to reset or provision these cards so they are specific to my region (Canada in my case)?

It appears to be an open question whether or not this commit will be reverted -- thus solving the problem. It would help if PC Engines could add their support for this on the ath10k mailing list.

It would also be helpful to document this problem and any workarounds that may exist.

miczyg1 · 2020-12-21T09:36:05Z

@michaelsteinmann

chr0mag · 2021-02-17T04:37:16Z

The latest kernel, as well as 5.11 still includes the above mentioned patch that is causing issues. Currently, both the stable and most recent LTS kernels include this -- making both unable to operate in AP mode on the 5GHz band without compiling the kernel or ath10k module ourselves with this commit reverted.

The latest request to revert this patch can be found here. It would help if PC Engines could throw their weight behind this as numerous revert requests seem to just get ignored or lost in the shuffle.

Does PC Engines have instructions to reset the firmware on these WLE900VX cards?

pietrushnic · 2021-02-21T23:52:04Z

@miczyg1 let's contact @michaelsteinmann and PC Engines directly, so we can move that item forward.

johnjameswhitman · 2021-04-16T04:31:51Z

I'm running into this exact issue. The most annoying thing is that iw reg get shows I've set the regdomain to the desired country, but iw list shows that the entire 5Ghz band is either disabled or "No IR" (i.e. no AP). Here's a gist with some output.

johnjameswhitman · 2021-04-16T13:39:56Z

For what it's worth, it seems like some distributions apply their own patches to the ath10k driver to give users the ability to choose whether to ignore the EEPROM's restrictive regdomain. For example, NixOS borrows a patch from OpenWRT to do this. If you're running that distro, you can add this to your config (warning, this'll cause nix to recompile the kernel so you might need to use a remote builder -- it took 7h15m to compile a kernel on my APU4D4 😅):

networking.wireless.athUserRegulatoryDomain = true;

veehaitch · 2021-04-17T15:39:04Z

Glad to hear that this NixOS option helped!

You might want to consider to build the configuration on another, more powerful NixOS system and then copy it using nix-copy-closure. That's what I usually do. You also might want to pin the kernel package to avoid surprise-recompilations on nixpkgs updates. It's good to know, however, that it would roughly take 7h to complete on my APU2 😅

chr0mag · 2021-04-24T19:59:10Z

APU2 as kernel build machine - nice :)

FWIW - these are the steps I've been using on Arch to compile the ath10k module with the above mentioned patch reverted.

# suitable when running the same kernel on build host and APU
# on build host
pacman --verbose --sync --refresh --sysupgrade
curl --location --remote-name https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.10.16.tar.xz
tar --verbose --extract --xz --file=linux-5.10.16.tar.xz
cd linux-5.10.16
patch --strip=1 < ../Revert-ath-add-support-for-special-0x0-regulatory-domain.diff
make clean && make mrproper
cp /usr/lib/modules/$(uname -r)/build/Module.symvers ./ #requires linux-headers
zcat /proc/config.gz > .config
sed --in-place 's/^CONFIG_LOCALVERSION=\"\"$/CONFIG_LOCALVERSION=\"-1\"/' .config
make oldconfig && make EXTRAVERSION=-arch1 prepare
make scripts
cp /usr/lib/modules/$(uname -r)/build/scripts/module.lds scripts/. #provided by linux-headers
make M=drivers/net/wireless/ath
xz drivers/net/wireless/ath/ath.ko
scp drivers/net/wireless/ath/ath.ko.xz root@apu2c4:

#on apu2c4
pacman --verbose --sync --refresh --sysupgrade
cp /lib/modules/5.10.16-arch1-1/kernel/drivers/net/wireless/ath/ath.ko.xz /lib/modules/5.10.16-arch1-1/kernel/drivers/net/wireless/ath/ath.ko.xz.orig
cp ath.ko.xz /lib/modules/5.10.16-arch1-1/kernel/drivers/net/wireless/ath/.
systemctl reboot

This is reasonably quick and painless as it only builds the module and avoids the kernel compile. All of this is far from optimal however.

A more suitable solution would be some documented steps from PCEngines allowing us to program the EEPROM with the regulatory domain where our device is operating. Perhaps this is unlikely though as it allows end users to break local laws and transmit with different power and frequency settings that what is locally allowed.

Setting the ATH_USER_REGD config flag is unlikely to be adopted widely as a default by distributions for similar reasons.

Really, the patch should be reverted in the mainline kernel. The issue it was originally meant to fix has been solved in firmware (see above mailing list links). For some reason getting the ath10k maintainers' attention about this issue has proved next to impossible.

silentcreek · 2021-06-01T11:30:08Z

I think this discussion is a bit shortsighted. The commit in question did only break 5GHz AP operation for a specific group of users, namely those who use the US regulatory domain. People in different (restrictive) regulatory domains faced the same issues before as well. I've been using a Compex WLE600VX card in my APU2 for 3 years or so. In order to get it working in the German regulatory domain, I've always had to recompile the Debian kernel with the following additional options to be able to set the card to my regulatory domain and use channels that require DFS:
CONFIG_ATH_REG_DYNAMIC_USER_REG_HINTS=y CONFIG_ATH_REG_DYNAMIC_USER_CERT_TESTING=y CONFIG_ATH10K_DFS_CERTIFIED=y CONFIG_CFG80211_CERTIFICATION_ONUS=y

I've had to do this on kernel 4.9 (Debian Strech) and currently 4.19 (Debian Buster), so long before the commit in question was introduced.

Other options would be to use distributions that already compile their kernels with these options set – to my knowledge VyOS does so. OpenWrt would be another option which simply disables the enforcement of the vendor-set regulatory domain on the driver level. Or you could take the OpenWrt patches and apply them to your own kernel builds (I personally don't do this since that would require refreshing the patches whenever the kernel source changes; the configuration changes above are easier to deal with when it comes to automating the build process).

See: pcengines/apu2-documentation#189

iam-TJ · 2021-07-05T23:21:09Z

I found that although, with the options mentioned by @silentcreek, iw reg get reported ath had adopted the country code, that the frequencies and channels reported by iw list hadn't changed and hostpad was unable to operate on legal channels associated with the country code.

To get a Compex WLE600VX to work on APU2 with kernel v5.13 and Debian 11 Buster I had to modify wireless-regdb's db.txt with the country 00: worldwide frequencies replaced with those of the operating country; in my case GB, build, and replace /lib/firmware/regulatory.db with the altered settings.
Tested using an unsigned file initially and kernel's CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=n then created a key, signed the file, and added the key to the kernel's CONFIG_CFG80211_EXTRA_REGDB_KEYDIR=path/to/extra/keys/

silentcreek · 2021-07-06T01:04:23Z

I found that although, with the options mentioned by @silentcreek, iw reg get reported ath had adopted the country code, that the frequencies and channels reported by iw list hadn't changed and hostpad was unable to operate on legal channels associated with the country code.

Could you elaborate what your channel list looks like and which channel(s) you intended to use? It is important to know that the Linux kernel's default behavior when switching to a different regulatory domain than what is programmed in the eeprom is to intersect the allowed channels and transmit power levels. This means that if a specific channel is not allowed in the vendor's default regulatory domain, you won't be able to use it even after you switch to a different regulatory domain. But the options mentioned should allow you to use those channels that require DFS and are not usable in the default state. To give an example: My device defaults to the US regulatory domain (iirc), where channels 12 and 13 (2.4GHz band) cannot be used by wireless access points. I live in Germany, where they are allowed but even after switching to the German regulatory domain the kernel won't allow me to use those channels. So, no gain here. But what I gain by the changed kernel configuration is that I can now use channels that require DFS which are channels 52-140 of the 5GHz band here.

To get a Compex WLE600VX to work on APU2 with kernel v5.13 and Debian 11 Buster I had to modify wireless-regdb's db.txt with the country 00: worldwide frequencies replaced with those of the operating country

I have seen this approach in various places, but I would not recommend it because your access point will broadcast the regulatory domain setting. So, it is easy to determine for anyone in the vicinity of your access point that it is misconfigured, i.e. it broadcasts the world regulatory domain but uses channels that are not allowed in it.

If you really want to use channels or transmit power levels that are disabled in the default regulatory domain but would be allowed in your local regulatory domain, then I would suggest to actually combine those two approaches, i.e. reconfigure the kernel to allow changes of the regulatory domain and the use of DFS and patch your regulatory domain so the default matches your local regulatory domain. Then hostapd will broadcast the correct country code and operate on the channels you wish. The other option would be to use the OpenWrt patch to disable the regulatory domain enforcement entirely.

tomfitzhenry · 2021-08-09T23:09:58Z

The current ath10k behaviour seems consistent with https://wireless.wiki.kernel.org/en/developers/regulatory/statement, in particular:

Further, that document discusses CONFIG_CFG80211_CERTIFICATION_ONUS:

The CONFIG_CFG80211_CERTIFICATION_ONUS is available for features which require additional regulatory compliance testing and validation by the system integrator. This allows us to define 802.11 specific kernel features under a flag that is intended by design to be disabled by standard Linux distributions, and only enabled by system integrators or distributions that have done work to ensure regulatory certification on the system with the enabled features.

https://wireless.wiki.kernel.org/en/developers/regulatory has more info the on the regulatory considerations for wireless.

I don't know the right solution to this. Is it for PC Engines to check the certification status of the cards, and offer to flash the regulatory domain?

silentcreek · 2021-08-10T00:02:55Z

Is it for PC Engines to check the certification status of the cards, and offer to flash the regulatory domain?

I don't think so. I don't even know how this would be supposed to work. First of all, PC Engines is not the manufacturer of the wifi chips we're talking about, Qualcomm and Compex are. If at all, I would see the responsibility with Compex. However, wifi certification includes things that the module manufacturer doesn't have a say in. Compex doesn't know if I attach some super high-gain antenna to their module nor can they ensure that I really don't use channels and transmission powers that are for indoor use only on an outdoor access point. So, in the end I think it is up to the user (in this case the integrator) to guarantee this.

silentcreek · 2021-10-03T23:09:11Z

I'm sorry, I was wrong!

I upgraded my APU2 from Debian 10 (Kernel 4.19) to Debian 11 (Kernel 5.10) a few days ago and have noticed that the kernel configuration options mentioned above are not sufficient anymore to get the 5GHz midband working on my Compex WLE600VX card. I had to revert the offending commit [ath: add support for special 0x0 regulatory domain], indeed, on top of the kernel configuration changes. OpenWrt's patch works as well, but since reverting the offending patch is less intrusive it should also require fewer adjustments whenever the kernel source changes.

greearb · 2021-10-05T16:24:19Z

Our kernels, which include ath10k-ct patches (and optionally, ath10k-ct firmware) should work fine with WLE900VX and other ath10k radios in apu2 platforms. You can patch your own kernels too of course.

https://github.com/greearb?tab=repositories

https://www.candelatech.com/ath10k-10.4.php#config

jowrjowr · 2022-03-22T02:11:49Z

had to go the wireless.athUserRegulatoryDomain = true; route with my apu4d4 + compex wle900vx.

but once it was done building, AP mode finally stopped being janky and i could get appropriate power output and channel usage!

chr0mag · 2022-03-26T17:04:40Z

A revert to the commit causing this problem has been included in this kernel 5.18 PR. (CTRL-F "0x0" to find it).

Kernels < 5.6 and > 5.17 shouldn't have this problem. This is probably worth including in the PC Engines documentation.

silentcreek · 2022-03-26T19:22:17Z

A revert to the commit causing this problem has been included in this kernel 5.18 PR. (CTRL-F "0x0" to find it).

Kernels < 5.6 and > 5.17 shouldn't have this problem. This is probably worth including in the PC Engines documentation.

Interesting. The change in question was also sent to the stable kernel mailing list, so it should end up in affected versions that are still in support, such as the longterm kernels 5.10 or 5.15, sooner or later. Nice!

AndreySV · 2022-03-27T15:32:36Z

Great news. Finally, just in case someone needed. I've wrote small kernel module ath_regdm_patcher that uses kprobe to set country to US as before.

$ cat /lib/udev/rules.d/99-ath-regdm-patcher.rules 
SUBSYSTEM=="module", KERNEL=="ath", ACTION=="add", RUN+="/sbin/insmod -f /lib/modules/ath_regdm_patcher.ko"

silentcreek · 2022-03-29T23:43:32Z

So, the commit Revert "ath: add support for special 0x0 regulatory domain" has indeed landed in the stable branches, such as 5.10.109, which will eventually make it to distributions relying on these kernel branches. Debian 11 (Bullseye) is based on kernel 5.10, for example, so you can expect this change to land in the next stable point release 11.4 in a few weeks (and maybe even before that).

mkopec · 2022-05-10T09:41:35Z

I can confirm I could set up hostapd on channel 36 on a WLE900VX card on Debian 11 with the latest kernel 5.10.113:

root@debian:/etc/hostapd# iw dev wlp5s0 info
Interface wlp5s0
	ifindex 5
	wdev 0x100000001
	addr xx:xx:xx:xx:xx:xx
	ssid apu2_172
	type AP
	wiphy 1
	channel 36 (5180 MHz), width: 20 MHz, center1: 5180 MHz
	txpower 23.00 dBm
	multicast TXQ:
		qsz-byt	qsz-pkt	flows	drops	marks	overlmt	hashcol	tx-bytes	tx-packets
		0	0	0	0	0	0	0	0		0

mkopec · 2022-05-27T12:14:55Z

Closing as fixed in recent upstream kernel.

Gateworks · 2022-05-27T15:58:36Z

Can anyone confirm this is fixed i n 5.15? Revert "ath: add support for special 0x0 regulatory domain" is in 5.15.32+ but we still see no 5.8 channels on WLE900VX (compared to working on 5.4-stable and 5.10-stable)

gsustek · 2023-01-04T01:32:29Z

@Gateworks i confirm....
uname -a
Linux u1804 5.15.0-56-generic #62-Ubuntu

nevertheless, even now with this fix, changing the country from default US is not possible!!!
i have added

regulatory domain

country_code=PA

hostapd debug log shows:
phy: phy0
BSS count 1, BSSID mask 00:00:00:00:00:00 (0 bits)
wlp7s0: interface state UNINITIALIZED->COUNTRY_UPDATE
Previous country code 98, new country code PA
Continue interface setup after channel list update
ctrl_iface not configured!

but iw reg get, does not change it to phy0

root@xxxxx:~# iw reg get
global
country PA: DFS-FCC
(2400 - 2483 @ 40), (N/A, 36), (N/A)
(5150 - 5250 @ 80), (N/A, 36), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 30), (N/A), AUTO-BW
(5470 - 5725 @ 160), (N/A, 30), (N/A)
(5725 - 5850 @ 80), (N/A, 36), (N/A)
(57000 - 64000 @ 2160), (N/A, 43), (N/A)

phy#0
country US: DFS-FCC
(902 - 904 @ 2), (N/A, 30), (N/A)
(904 - 920 @ 16), (N/A, 30), (N/A)
(920 - 928 @ 8), (N/A, 30), (N/A)
(2400 - 2472 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 24), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 24), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A), AUTO-BW
(5850 - 5895 @ 40), (N/A, 27), (N/A), NO-OUTDOOR, AUTO-BW, PASSIVE-SCAN
(5925 - 7125 @ 320), (N/A, 12), (N/A), NO-OUTDOOR, PASSIVE-SCAN
(57240 - 71000 @ 2160), (N/A, 40), (N/A)

QCA9984,
@mkopec so how to change country?

Gateworks · 2023-01-10T17:54:57Z

Apparently these cards are considered mis-programmed and thus require special handling that nobody wants to accept into the kernel.

See OpenWrt's solution here: https://github.com/openwrt/openwrt/blob/master/package/kernel/mac80211/patches/ath/402-ath_regd_optional.patch

pinning kernel version: https://nixos.wiki/wiki/Linux_kernel#Pinning_a_kernel_version using ath patch: pcengines/apu2-documentation#189 (comment)

chris-liu · 2024-02-12T22:14:53Z

I found that although, with the options mentioned by @silentcreek, iw reg get reported ath had adopted the country code, that the frequencies and channels reported by iw list hadn't changed and hostpad was unable to operate on legal channels associated with the country code.

To get a Compex WLE600VX to work on APU2 with kernel v5.13 and Debian 11 Buster I had to modify wireless-regdb's db.txt with the country 00: worldwide frequencies replaced with those of the operating country; in my case GB, build, and replace /lib/firmware/regulatory.db with the altered settings. Tested using an unsigned file initially and kernel's CONFIG_CFG80211_REQUIRE_SIGNED_REGDB=n then created a key, signed the file, and added the key to the kernel's CONFIG_CFG80211_EXTRA_REGDB_KEYDIR=path/to/extra/keys/

Do you have procedure how to modify wireless-regdb's "db.txt" with my desired country code, then generate file regulatory.db? BTW, I don't have this file /lib/firmware/regulatory.db in my device at all, is it normal ?

iam-TJ · 2024-02-13T06:04:46Z

I now carry a kernel patch that adds a module parameter and is set to a default that suits me, but can be set at load-time with options ath country_default=XXX where XXX is a value from drivers/net/wireless/ath/regd.h::enum CountryCode

For some reason github refuses .patch diff files!

$ git show d7c717aac9b3 
commit d7c717aac9b37b79a66fd8d5d0dfad1b6214a638
Author: Tj <linux@iam.tj>
Date:   Thu Jul 27 16:52:03 2023 +0100

    ath: add module_param country_default for regulatory domain control

diff --git a/drivers/net/wireless/ath/regd.c b/drivers/net/wireless/ath/regd.c
index f15e7bd690b5..1cedb926585a 100644
--- a/drivers/net/wireless/ath/regd.c
+++ b/drivers/net/wireless/ath/regd.c
@@ -16,6 +16,7 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include <linux/module.h>
 #include <linux/kernel.h>
 #include <linux/export.h>
 #include <net/cfg80211.h>
@@ -680,6 +681,10 @@ static void ath_regd_sanitize(struct ath_regulatory *reg)
        reg->current_rd = 0x64;
 }
 
+ushort ath_country_default = CTRY_UNITED_KINGDOM;
+module_param_named(country_default, ath_country_default, ushort, 0644);
+MODULE_PARM_DESC(country_default, "Default country when firmware is unset");
+
 static int __ath_regd_init(struct ath_regulatory *reg)
 {
        struct country_code_to_enum_rd *country = NULL;
@@ -704,7 +709,7 @@ static int __ath_regd_init(struct ath_regulatory *reg)
            regdmn == CTRY_DEFAULT) {
                printk(KERN_DEBUG "ath: EEPROM indicates default "
                       "country code should be used\n");
-               reg->country_code = CTRY_UNITED_STATES;
+               reg->country_code = ath_country_default;
        }
 
        if (reg->country_code == CTRY_DEFAULT) {

pietrushnic assigned miczyg1 Feb 21, 2021

chr0mag pushed a commit to chr0mag/linux-wireless-router that referenced this issue Jun 5, 2021

Add ath10k module build script

51c3343

See: pcengines/apu2-documentation#189

mkopec closed this as completed May 27, 2022

AndreySV mentioned this issue Feb 11, 2024

could you share the ko file after compile "ath_regdm_patcher", so I could quick test if my issue is exactly same. AndreySV/ath_regdm_patcher#1

Closed

tmshlvck mentioned this issue Mar 26, 2024

Missing ath10k firmware tmshlvck/turris-debian#1

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Compex wle900vx (qca988x) support in Linux kernels > 5.6 #189

Compex wle900vx (qca988x) support in Linux kernels > 5.6 #189

chr0mag commented Dec 20, 2020

miczyg1 commented Dec 21, 2020

chr0mag commented Feb 17, 2021

pietrushnic commented Feb 21, 2021

johnjameswhitman commented Apr 16, 2021 •

edited

Loading

johnjameswhitman commented Apr 16, 2021 •

edited

Loading

veehaitch commented Apr 17, 2021

chr0mag commented Apr 24, 2021

silentcreek commented Jun 1, 2021

iam-TJ commented Jul 5, 2021

silentcreek commented Jul 6, 2021

tomfitzhenry commented Aug 9, 2021

silentcreek commented Aug 10, 2021 •

edited

Loading

silentcreek commented Oct 3, 2021

greearb commented Oct 5, 2021

jowrjowr commented Mar 22, 2022

chr0mag commented Mar 26, 2022

silentcreek commented Mar 26, 2022

AndreySV commented Mar 27, 2022

silentcreek commented Mar 29, 2022

mkopec commented May 10, 2022 •

edited

Loading

mkopec commented May 27, 2022

Gateworks commented May 27, 2022

gsustek commented Jan 4, 2023 •

edited

Loading

Gateworks commented Jan 10, 2023

chris-liu commented Feb 12, 2024 •

edited

Loading

iam-TJ commented Feb 13, 2024

Compex wle900vx (qca988x) support in Linux kernels > 5.6 #189

Compex wle900vx (qca988x) support in Linux kernels > 5.6 #189

Comments

chr0mag commented Dec 20, 2020

miczyg1 commented Dec 21, 2020

chr0mag commented Feb 17, 2021

pietrushnic commented Feb 21, 2021

johnjameswhitman commented Apr 16, 2021 • edited Loading

johnjameswhitman commented Apr 16, 2021 • edited Loading

veehaitch commented Apr 17, 2021

chr0mag commented Apr 24, 2021

silentcreek commented Jun 1, 2021

iam-TJ commented Jul 5, 2021

silentcreek commented Jul 6, 2021

tomfitzhenry commented Aug 9, 2021

silentcreek commented Aug 10, 2021 • edited Loading

silentcreek commented Oct 3, 2021

greearb commented Oct 5, 2021

jowrjowr commented Mar 22, 2022

chr0mag commented Mar 26, 2022

silentcreek commented Mar 26, 2022

AndreySV commented Mar 27, 2022

silentcreek commented Mar 29, 2022

mkopec commented May 10, 2022 • edited Loading

mkopec commented May 27, 2022

Gateworks commented May 27, 2022

gsustek commented Jan 4, 2023 • edited Loading

regulatory domain

Gateworks commented Jan 10, 2023

chris-liu commented Feb 12, 2024 • edited Loading

iam-TJ commented Feb 13, 2024

johnjameswhitman commented Apr 16, 2021 •

edited

Loading

johnjameswhitman commented Apr 16, 2021 •

edited

Loading

silentcreek commented Aug 10, 2021 •

edited

Loading

mkopec commented May 10, 2022 •

edited

Loading

gsustek commented Jan 4, 2023 •

edited

Loading

chris-liu commented Feb 12, 2024 •

edited

Loading