Re: [PATCH v6 0/4] wifi: ath12k: store and send country code to firmware after recovery

[Mihai Moldovan <ionic@ionic.de>]

[-- Attachment #1.1: Type: text/plain, Size: 2574 bytes --]

* On 12/2/24 02:53, Kang Yang wrote:
> On 11/29/2024 8:18 PM, Mihai Moldovan wrote:
>> Have you tested this in AP mode or was testing limited to STA mode?
> 
> Not yet.

Okay, so a useful heads-up, I guess!


>> Even with this patch set, hostapd fails to start on a channel that is
>> disabled in the default regdomain, even if 11d is enabled and a CC
>> specified, even after a CC update is requested and CHANEL_LIST_UPDATE is
>> being received.
>>
> 
> What is the probability of failure?

In my tests, 100 % reproducible, but I admit I haven't stress-tested it.

It always fails the first time hostapd is started if the default rules define 
NO_IR on the channel you want to use (even if CC rules disagree) and can also 
easily be reproduced by, e.g., using channel 100 with hostapd and setting CC for 
instance to DE or US in the hostapd config file:

# Chinese regulatory does not allow operation on channels 96 to 128.
iw reg set CN; hostapd ... => fails
iw reg set DE; hostapd ... => works

Luckily it's really easy to reproduce.


hostapd is special in the sense that it's using netlink directly and this is 
probably very fast.

I was never able to reproduce the issue with iw reg set CN; iw reg set DE; iw 
list, but I don't find that surprising due to all the overhead and highly 
different code path.


>> You recently re-submitted a patch set for ath11k by Wen Gong[0] that is
>> supposed to fix a race condition during reg updates and this smells like
>> the same issue. I'll try to port it to ath12k on top of this patch set
>> to see if it fixes this issue.
>>
>>
> 
> Thanks for trying, currently, i'm occupied by other tasks...

All good.

If and when you try, another heads-up: ath12k is currently running into an rtln 
deadlock quite often (but not always) when hostapd is stopped (or fails) because 
that's also bringing the interface down.

Fortunately, Baochen Qiang ported the fix for this issue from ath11k to 
ath12k[0], but it wasn't applied to ath-next or main yet, so you will likely see 
a very irritating deadlock requiring a hard machine reset if you don't also use 
his patch when testing.

His patch, apart from fixing the deadlock, also ports some parts of the ath11k 
patch set I mentioned in my previous mail, but unfortunately doesn't fix the 
chan list update race I'm seeing.

I'll dig further into it and hope to come up with something usable in the next 
few days.



Mihai


[0] https://lore.kernel.org/ath12k/20240830023901.204746-1-quic_bqiang@quicinc.com/

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 840 bytes --]