ath11k multicast action frame RX

[Baochen Qiang]

On 2/21/2024 8:24 PM, James Prestwood wrote:
> 
> On 2/20/24 7:45 PM, Baochen Qiang wrote:
>>
>>
>> On 1/31/2024 8:28 PM, James Prestwood wrote:
>>> Hi Baochen,
>>>
>>>>> As you may have guessed I don't _really_ know what I'm doing. When 
>>>>> I got this working with ath10k I saw monitor device was being used 
>>>>> in order to receive probes, and did the same for multicast action 
>>>>> frames and it "just worked". The frames themselves were still being 
>>>>> received on the station device. I attempted to mimic the changes 
>>>>> with ath11k.
>>>>>
>>>>> The end goal here is just that, be able to receive multicast action 
>>>>> frames on the station device which currently does not work. I'm 
>>>>> only seeing unicast frames when i enable RX debugging. The driver 
>>>>> support for multicast action RX in the kernel for this is basically 
>>>>> zero. An extended feature flag was added by Jouni when he added 
>>>>> support to ath9k, I added limited ath10k support for a variant I 
>>>>> tested, and I'd like to do the same for ath11k as we are 
>>>>> transitioning to the WCN6855.
>>>> OK, so you are testing this with latest ath.git, without any private 
>>>> changes, and it doesn't work, right? Could you share your test 
>>>> steps? Basically how are you sending multicast action frames from 
>>>> AP/peer, and how to check if that frame received or not (I am 
>>>> assuming by checking RX logs)?
>>>
>>> Yep I'm on the latest ath.git, and with no changes apart from that 
>>> MSI vector hack to get it working with vfio-pci.
>>>
>>> The way I'm testing this is using IWD with DPP PKEX. Building IWD 
>>> should be relatively straight forward, very few dependencies. This 
>>> will also include iwctl which is IWD's command line utility:
>>>
>>> https://git.kernel.org/pub/scm/network/wireless/iwd.git/
>>>
>>> I have two devices, the configurator device (device A, ath11k) is 
>>> what should be able to receive the multicast action frames. The 
>>> enrollee device (device B) can use probably any hardware as sending 
>>> multicast action frames should be supported. IWD will not start a DPP 
>>> PKEX configurator without EXT_FEATURE_MULTICAST_REGISTRATIONS set but 
>>> if you enable RX logging that should be good enough to see if the 
>>> frame is making it to the ath11k driver itself. Once multicast RX is 
>>> supported we would need to add that extended feature to ath11k, or at 
>>> least the tested variant. If you want, you can hack in that feature 
>>> bit and start a configurator but if your able to get the muticast RX 
>>> working I can probably take it from there:
>>>
>>> 1. Enable RX logging on device A
>>>
>>> 2. Start IWD on device A
>>>
>>>      iwd -d
>>>
>>> 3. Connect to a network on device A
>>>
>>>      iwctl station <wlan> connect <ssid>
>>>
>>>      <enter passphrase>
>>>
>>> # Optional: start a configurator. This won't work without the ext 
>>> feature set
>>>
>>>     iwctl pkex <wlan> configure secret123
>>>
>>> 4. Start IWD on device B, do not connect.
>>>
>>>      iwd -d
>>>
>>> 5. Start DPP PKEX as an enrollee on device B:
>>>
>>>      iwctl pkex <wlan> enroll secret123
>>>
>>> On device B you should see IWD first scan to establish nearby 
>>> APs/frequencies, then begin iterating those frequencies and sending a 
>>> multicast action frame.
>> Hi James, I reproduced this issue following your guide. From the 
>> advise of firmware team, a new flag is needed. With that flag, I did 
>> see the multicast action frame in device A logging. Before I proceed, 
>> want to clarify something: that frame is only seen after device A 
>> triggers a scan (I triggered it manually using iw, not IWD itself 
>> because IWD not working on device A due to unknown errors), if no scan 
>> no frame seen. I am not sure if this behavior is expected so now 
>> checking with internal team on it.
>>
>> So there comes a question: will IWD triggers scan on device A in order 
>> to receive that frame?
> 
> That's great its possible! And thank you for looking into this.
> 
> That seems very odd that device A would need to scan in order to receive 
> a multicast frame. In all reality neither device should have to scan at 
> all, device B just does in order to know what frequencies to start 
> sending the multicast frames on. Even this isn't entirely needed if the 
> frequency was known ahead of time. I think something is not right if a 
> scan must be issued in order to receive these frames. This wasn't 
> required by ath10k when I added it, nor is it by mac80211_hwsim; you can 
But you are using monitor mode, not station mode, on ath10k, right?

> just start listening and receive the frames.
> 
> Thanks,
> 
> James
> 
>>
>>>
>>> Thanks,
>>>
>>> James
>>>
>>>>
>>>>>
>>>>> And help is much appreciated, and I'm happy to put in the work its 
>>>>> just a steep learning curve coupled with the fact that any FW level 
>>>>> communication is proprietary. I really just need a nudge in the 
>>>>> right direction.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> James
>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> James
>>>>>>>
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> James
>>>>>>>>
>>>>>>>>
>>>>>>