ath11k multicast action frame RX

[James Prestwood]

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