Compex WLE200NX: regdomain sanitized regression

[Nuno Oliveira]

Hi Kalle,

Thanks for looking again into this.

* Kalle Valo <kvalo at kernel.org> [2021-12-20 10:38]:
>Thorsten Leemhuis <regressions at leemhuis.info> writes:
>
>> Hi, this is your Linux kernel regression tracker speaking.
>>
>> On 27.11.21 13:21, Nuno Oliveira wrote:
>>> * Sebastian Bachmann <hello at reox.at> [2021-11-27 08:17]:
>>>
>>>> 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.
>>
>> This is a regression due to 2dc016599cfa ("ath: add support for special
>> 0x0 regulatory domain") that seems to affect quite a few users, but
>> afaics was never properly addressed. I fully understand that this might
>> be a special case where Linus' "no regressions" rule can't be simply
>> applied.
>
>Yes, this is a tricky problem and I am taking a second look at this.
>Regulatory rules are complicated and we do not want to break them in any
>circumstance.
>
>I see two ways to workaround this:
>
>1) calibrate your board with a correct country code (which is impossible
>   for an average user)
>
>2) use 2.4 GHz band
>
>> But isn't there some way to provide users with a solution that doesn't
>> force users to compile a module or a kernel? Like a module-parameter
>> that only works if the the regulatory domain code in the EEPROM is empty
>> (as apparently used by OpenWRT?). Yes, module parameters are normally a
>> bad idea, but this case it might be a situation where it's the best
>> solution.
>
>I don't think setting the country code via a module parameter would be
>acceptable for the authorities, more info here:
>
>https://wireless.wiki.kernel.org/en/developers/regulatory

The issue involves finding a reasonable compromise between relative 
inconveniences, given the perspectives of both developers and users. As 
implemented currently, the restriction seems to affect both ath9k and 
ath10k (and probably ath11k -- I have not tried it, and frankly with the 
current status, I'm not eager to do it), but only when users try to run 
a 5 GHz AP. This is still reasonable (and legal) use, although not 
without many restrictions. Other drivers (e.g., iwlwifi) are much more 
restrictive relative to this, but at least they genuinely have made it 
completely clear from the beginning.

A common point of the previous messages was that, after these last 
changes, the boards with the 0x00 domain in the EEPROM were successively 
initialized with the 0x64 and later with UNITED_STATES domains by the 
driver. In practice this prevented their use as an AP when, later in 
userspace, the user tried to declare a 3rd local regdomain. My 
suggestion here would be to avoid this double interpretation of what 
default initialization would be appropriate. Either keep the old 
behavior (UNITED_STATES) which limited but did not originally prevented 
the AP usage, or replace it completely with the updated interpretation 
of what's applicable to this case (0x64); but please don't do both by 
default, or we will be in the current situation. Other users have asked 
for this before, and this sort of clarification seems to be the minimum 
to consider at this point, if anything is to be considered.

If this limiting double initialization is already achievable entirely 
through user configuration of default distribution kernels, please 
excuse my lack of knowledge. In this case, just documenting this better 
could also help other users.

Besides this consistent "safe" initialization, for users with special 
cases there's always the options of either providing alternative CRDAs 
or patching and recompiling the driver. This is a matter of relative 
inconveniences; as long as they remain feasible, it's always a weighting 
issue.

Thanks for your good work. Regards,

Nuno.