Re: ath11k multicast action frame RX

[Baochen Qiang <quic_bqiang@quicinc.com>]

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?

> 
> 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
>>>>>>
>>>>>>
>>>>