Compex WLE200NX: regdomain sanitized regression

[Nuno Oliveira]

Hi Sebastian,

* Sebastian Bachmann <hello at reox.at> [2021-11-27 08:17]:
>Hello,
>
>I recently upgraded my Debian based AP from buster to bullseye, just 
>to find out that hostapd does not work any more, because all 5GHz 
>channels are marked as No-IR. This regression was already discussed on 
>this ML here: 
>https://www.mail-archive.com/ath10k@lists.infradead.org/msg12018.html
>and there is also an entry in Debian's bug tracker for the same issue: 
>https://bugs.debian.org/959821
>
>I have a slightly different card (branded Compex WLE200NX):
>04:00.0 Network controller: Qualcomm Atheros AR928X Wireless Network 
>Adapter (PCI-Express) (rev 01)
>        Subsystem: Qualcomm Atheros AR928X Wireless Network Adapter 
>(PCI-Express)
>        Kernel driver in use: ath9k
>        Kernel modules: ath9k
>
>But as you can see, also the EEPROM gets sanitized:
>[   15.461755] ath9k 0000:04:00.0: enabling device (0000 -> 0002)
>[   15.911600] ath: EEPROM regdomain sanitized
>[   15.911612] ath: EEPROM regdomain: 0x64
>[   15.911615] ath: EEPROM indicates we should expect a direct regpair map
>[   15.911625] ath: Country alpha2 being used: 00
>[   15.911628] ath: Regpair used: 0x64
>
>I read in the other thread, that this is a regression, but the actual 
>commit causing it was never reverted.
>I tried to search for newer messages explaining the issue, however as 
>far as I can tell, the thread ends in June 2020 with no solution 
>available.
>
>Therefore, I kindly want to ask if there is any workaround available 
>to re-enable 5GHz channels in AP mode for my card? (expect sticking to 
>a pre-5.6 kernel or manually patching and recompiling ath)

After June 2020 there were other users also affected by this change (see 
e.g., 
https://lists.infradead.org/pipermail/ath10k/2021-August/012802.html).
Users were complaining that this change was too restrictive since it 
meant that the intersection of restrictions for regdomains 0x00, 0x64,
US, and their local domain, together with a cumulative mode of applying 
these constraints meant that, in practice, they would not be able to use 
their world domain cards anymore as APs in the 5GHz band, for certain 
regdomains where they were located.

And several people pinpointed the exact source changes responsible for 
this. In my case, I ended up applying the attached patch, that just 
loads the parameters for the regdomain that I'm interested in 
(CTRY_PORTUGAL). I'm not in the US; and I care for their regulatory 
restrictions as much as they are interested in mine.

So I think that you might be able to use the attached changes, with the 
specific CTRY_xxx parameter suitable for your case. And then recompile 
the respective Debian kernel package, which takes a lot of CPU if you 
just recompile the whole package. Let me know if you need instructions.

A more robust option would be to go the OpenWRT way, and use their 
patches to make this country selection a parameter for the kernel 
module. This way, you would just reload the kernel module to change to a 
new regdomain, subject to the restrictions of your hardware / firmware. 
I have not looked into that. Please let me know if you isolate these 
patches.

In any case it seems difficult to escape a kernel recompile, due to this 
small, entirely legitimate, yet remarkable decision by the driver 
maintainers.

Regards,

Nuno.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ath-regd.c.patch
Type: text/x-diff
Size: 793 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20211127/0396dec8/attachment.bin>