Hi,
this patch broke several 5GHz AP in my home based on different Atheros
cards (ath9k and ath10k). Both of them have FCC ID and were purchased from
different suppliers (EU and non-EU) in 2020 and in 2018. I know many other
users are affected as well.
I know this problem was discussed several times already. But I have a
couple of questions.
1) Current behaviour maps 0x0 regulatory domain to the most restrictive
world domain. According to the wiki (probably based on Atheros
documentation) 0x0 means US. Does wiki contain wrong information?
2) If I understand correctly, 0x0 is always replaced with 0x64 and that
makes the following code useless, because it will never be executed. Is it
ok?
drivers/net/wireless/ath/regd.c:703:708
if (reg->country_code == CTRY_DEFAULT &&
regdmn == CTRY_DEFAULT) {
printk(KERN_DEBUG "ath: EEPROM indicates default "
"country code should be used\n");
reg->country_code = CTRY_UNITED_STATES;
}
3) Previously it was possible to get regulatory information using 'iw reg
get', but now it doesn't work anymore. Is it expected behavior?
[--------------------4.19 ---------------------------------]
# iw reg get
global
country 98: DFS-UNSET
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5250 @ 100), (N/A, 20), (N/A), NO-OUTDOOR
(5250 - 5350 @ 100), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
(5650 - 5730 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
(5730 - 5850 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
(57240 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
phy#0
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#1
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
[--------------------- 5.10 --------------------------------]
#iw reg get
global
country RU: DFS-UNSET
(2400 - 2483 @ 40), (N/A, 20), (N/A)
(5150 - 5350 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
(5650 - 5850 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
(57000 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
[-----------------------------------------------------------]
4) As many users are affected by this problem and maintainers don't really
want to revert the problematic patch, is there any other solution to make
AP work again using a clean mainline kernel? Firmware upgrade or any other
solution? What should we do with non-working hardware now?
1. https://wireless.wiki.kernel.org/en/users/drivers/ath#the_0x0_regulatory_domain
P.S. sorry, I've resent the message using other MTA, because it wasn't delivered to MLs.
--
Best regards,
Andrey Skvortsov
On Sun, Aug 22, 2021 at 9:49 AM Andrey Skvortsov
<[email protected]> wrote:
> 4) As many users are affected by this problem and maintainers don't really
> want to revert the problematic patch,
I'm not totally sure that's true. So far, it looks like an oversight.
Over a year ago, Kalle said he "just need[ed] to check something
internally first":
https://lore.kernel.org/linux-wireless/[email protected]/
I don't see the result of that, except that this is marked Superseded:
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
and this is marked Rejected:
https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
I'm not sure if the Rejected was before or after the last reply above...
Maybe it needs an Nth person to submit a revert?
Brian
On 8/22/21 9:49 AM, Andrey Skvortsov wrote:
> 1) Current behaviour maps 0x0 regulatory domain to the most restrictive
> world domain. According to the wiki (probably based on Atheros
> documentation) 0x0 means US. Does wiki contain wrong information?
0x0 means country section in OTP is not written yet and open to set to
any country.
QCA sets to US in this case as a default value.
> 2) If I understand correctly, 0x0 is always replaced with 0x64 and that
> makes the following code useless, because it will never be executed. Is it
> ok?
>
> drivers/net/wireless/ath/regd.c:703:708
>
> if (reg->country_code == CTRY_DEFAULT &&
> regdmn == CTRY_DEFAULT) {
> printk(KERN_DEBUG "ath: EEPROM indicates default "
> "country code should be used\n");
> reg->country_code = CTRY_UNITED_STATES;
> }
I don't think that's true. If you're seeing 0x0 is replaced with 0x64
(CTRY_BULGARIA = 100), it could be because your device's manufacturer
preconfigured country code with the value.
> 3) Previously it was possible to get regulatory information using 'iw reg
> get', but now it doesn't work anymore. Is it expected behavior?
>
> [--------------------4.19 ---------------------------------]
> # iw reg get
> global
> country 98: DFS-UNSET
> (2400 - 2483 @ 40), (N/A, 20), (N/A)
> (5150 - 5250 @ 100), (N/A, 20), (N/A), NO-OUTDOOR
> (5250 - 5350 @ 100), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> (5650 - 5730 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> (5730 - 5850 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
> (57240 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
>
>
> [--------------------- 5.10 --------------------------------]
> #iw reg get
> global
> country RU: DFS-UNSET
> (2400 - 2483 @ 40), (N/A, 20), (N/A)
> (5150 - 5350 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> (5650 - 5850 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> (57000 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
>
> [-----------------------------------------------------------]
The 4.19 output tells you that country code is changed to different one
from manufacturer is set(US).
The 5.10 output seems manufacture set country code to RU. If it's the
case, No phy level country code looks wrong or a bug.
Thanks,
Peter
On 21-08-23 10:23, Brian Norris wrote:
> On Sun, Aug 22, 2021 at 9:49 AM Andrey Skvortsov
> <[email protected]> wrote:
> > 4) As many users are affected by this problem and maintainers don't really
> > want to revert the problematic patch,
>
> I'm not totally sure that's true. So far, it looks like an oversight.
>
> Over a year ago, Kalle said he "just need[ed] to check something
> internally first":
> https://lore.kernel.org/linux-wireless/[email protected]/
>
> I don't see the result of that, except that this is marked Superseded:
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
> and this is marked Rejected:
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
> I'm not sure if the Rejected was before or after the last reply above...
>
> Maybe it needs an Nth person to submit a revert?
Later (Dec 23, 2020) said "Actually I don't see how I could apply the
revert due to the regulatory problems explained by Jouni". [1]
I think this could be the date when your patch was marked as Rejected.
1. http://lists.infradead.org/pipermail/ath10k/2020-December/012370.html
--
Best regards,
Andrey Skvortsov
On 21-08-23 11:15, Peter Oh wrote:
>
> On 8/22/21 9:49 AM, Andrey Skvortsov wrote:
>
> > 1) Current behaviour maps 0x0 regulatory domain to the most restrictive
> > world domain. According to the wiki (probably based on Atheros
> > documentation) 0x0 means US. Does wiki contain wrong information?
>
> 0x0 means country section in OTP is not written yet and open to set to any
> country.
>
> QCA sets to US in this case as a default value.
Do you mean it's set to US by code fragment described below?
> > 2) If I understand correctly, 0x0 is always replaced with 0x64 and that
> > makes the following code useless, because it will never be executed. Is it
> > ok?
> >
> > drivers/net/wireless/ath/regd.c:703:708
> >
> > if (reg->country_code == CTRY_DEFAULT &&
> > regdmn == CTRY_DEFAULT) {
> > printk(KERN_DEBUG "ath: EEPROM indicates default "
> > "country code should be used\n");
> > reg->country_code = CTRY_UNITED_STATES;
> > }
> I don't think that's true. If you're seeing 0x0 is replaced with 0x64
> (CTRY_BULGARIA = 100), it could be because your device's manufacturer
> preconfigured country code with the value.
0x64 is not BULGARIA, it's not the country code in this case, but regulatory domain - WOR4_WORLD
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/wireless/ath/regd_common.h?h=v5.14-rc7#n84
country code is still default (CTRY_DEFAULT == 0x00), but regdmn is
sanitized (set to 0x64) and is not CTRY_DEFAULT (0x00), therefore
country_code is not set to CTRY_UNITED_STATES any more.
> > 3) Previously it was possible to get regulatory information using 'iw reg
> > get', but now it doesn't work anymore. Is it expected behavior?
> >
> > [--------------------4.19 ---------------------------------]
> > # iw reg get
> > global
> > country 98: DFS-UNSET
> > (2400 - 2483 @ 40), (N/A, 20), (N/A)
> > (5150 - 5250 @ 100), (N/A, 20), (N/A), NO-OUTDOOR
> > (5250 - 5350 @ 100), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> > (5650 - 5730 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS
> > (5730 - 5850 @ 80), (N/A, 20), (N/A), NO-OUTDOOR
> > (57240 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
> >
> >
> > [--------------------- 5.10 --------------------------------]
> > #iw reg get
> > global
> > country RU: DFS-UNSET
> > (2400 - 2483 @ 40), (N/A, 20), (N/A)
> > (5150 - 5350 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> > (5650 - 5850 @ 160), (N/A, 20), (N/A), NO-OUTDOOR
> > (57000 - 66000 @ 2160), (N/A, 40), (N/A), NO-OUTDOOR
> >
> > [-----------------------------------------------------------]
>
> The 4.19 output tells you that country code is changed to different one from
> manufacturer is set(US).
>
> The 5.10 output seems manufacture set country code to RU. If it's the case,
> No phy level country code looks wrong or a bug.
There hardware is the same in both cases. RU is displayed just because
I played with 'iw reg set RU/US/..'. My question is more about why on
newer kernels 'iw reg get' doesn't report regulatory information about
these cards (phy#..) any more.
I mean following lines:
phy#0
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
phy#1
country US: DFS-FCC
(2400 - 2483 @ 40), (N/A, 30), (N/A)
(5150 - 5250 @ 80), (N/A, 23), (N/A), AUTO-BW
(5250 - 5350 @ 80), (N/A, 23), (0 ms), DFS, AUTO-BW
(5470 - 5730 @ 160), (N/A, 23), (0 ms), DFS
(5730 - 5850 @ 80), (N/A, 30), (N/A)
(57240 - 71000 @ 2160), (N/A, 40), (N/A)
--
Best regards,
Andrey Skvortsov
On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
<[email protected]> wrote:
> On 21-08-23 10:23, Brian Norris wrote:
> > Maybe it needs an Nth person to submit a revert?
>
> Later (Dec 23, 2020) said "Actually I don't see how I could apply the
> revert due to the regulatory problems explained by Jouni". [1]
> I think this could be the date when your patch was marked as Rejected.
>
> 1. http://lists.infradead.org/pipermail/ath10k/2020-December/012370.html
Oh wow, I almost forgot about that... Too many threads. I also forgot
that I already replied, expressing my disagreement:
http://lists.infradead.org/pipermail/ath10k/2020-December/012372.html
But I guess it's not really expected that mainline Linux really works
as-is on most products, unfortunately, and the maintainers don't have
enough time or energy to provide constructive paths forward on real
issues like this :(
Brian
On 8/23/21 11:06 PM, Brian Norris wrote:
> On Mon, Aug 23, 2021 at 1:19 PM Andrey Skvortsov
> <[email protected]> wrote:
>> On 21-08-23 10:23, Brian Norris wrote:
>>> Maybe it needs an Nth person to submit a revert?
>>
>> Later (Dec 23, 2020) said "Actually I don't see how I could apply the
>> revert due to the regulatory problems explained by Jouni". [1]
>> I think this could be the date when your patch was marked as Rejected.
>>
>> 1. http://lists.infradead.org/pipermail/ath10k/2020-December/012370.html>>
> Oh wow, I almost forgot about that... Too many threads. I also forgot
> that I already replied, expressing my disagreement:
> http://lists.infradead.org/pipermail/ath10k/2020-December/012372.html>>
> But I guess it's not really expected that mainline Linux really works
> as-is on most products, unfortunately, and the maintainers don't have
> enough time or energy to provide constructive paths forward on real
> issues like this :(
Jouni gave a good explanation for why the offending patch is correct,
but it hinges on an interpretation of country code 0x0 which seems to be
incorrect. I followed up on that almost a year ago here[1] but the
thread went cold after that.
Numerous people - myself included - have cited sources clearly
indicating that 0x0 = US, NOT unset. See the same post[1] for more info.
I still think this patch should be reverted unless somebody can provide
a source to the contrary, re: the meaning of 0x0.
It's unfortunate that this is still affecting users, particularly when
the original author of the patch even asked for it to be reverted.[2]
Alvin
[1] https://lists.infradead.org/pipermail/ath10k/2021-January/012374.html
[2]
https://lore.kernel.org/ath10k/[email protected]/
On Tue, Aug 24, 2021 at 1:00 AM Alvin Šipraga <[email protected]> wrote:
> Numerous people - myself included - have cited sources clearly
> indicating that 0x0 = US, NOT unset. See the same post[1] for more info.
>
> I still think this patch should be reverted unless somebody can provide
> a source to the contrary, re: the meaning of 0x0.
>
> It's unfortunate that this is still affecting users, particularly when
> the original author of the patch even asked for it to be reverted.[2]
FYI, my revert was recently merged to Linus's tree and is making its
way into various -stable trees:
https://git.kernel.org/linus/1ec7ed5163c70a0d040150d2279f932c7e7c143f
Side note: it's a small shame that Kalle's scripts seem to have munged
the authorship date -- git thinks it was authored in 2022, when in
fact it was in 2020 ;)
Regards,
Brian
Hi Brian,
On Tue, Mar 29, 2022 at 02:06:40PM -0700, Brian Norris wrote:
> On Tue, Aug 24, 2021 at 1:00 AM Alvin Šipraga <[email protected]> wrote:
> > Numerous people - myself included - have cited sources clearly
> > indicating that 0x0 = US, NOT unset. See the same post[1] for more info.
> >
> > I still think this patch should be reverted unless somebody can provide
> > a source to the contrary, re: the meaning of 0x0.
> >
> > It's unfortunate that this is still affecting users, particularly when
> > the original author of the patch even asked for it to be reverted.[2]
>
> FYI, my revert was recently merged to Linus's tree and is making its
> way into various -stable trees:
>
> https://git.kernel.org/linus/1ec7ed5163c70a0d040150d2279f932c7e7c143f
That's great news, thanks for sharing the update or else I would have
missed it.
>
> Side note: it's a small shame that Kalle's scripts seem to have munged
> the authorship date -- git thinks it was authored in 2022, when in
> fact it was in 2020 ;)
>
> Regards,
> Brian
Kind regards,
Alvin
Brian Norris <[email protected]> writes:
> Side note: it's a small shame that Kalle's scripts seem to have munged
> the authorship date -- git thinks it was authored in 2022, when in
> fact it was in 2020 ;)
Oops, sorry about that. I use stgit and then I edited the commit log to
add the Link tag, it must have changed the date.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches