ath11k multicast action frame RX

[Baochen Qiang]

On 1/30/2024 8:47 PM, James Prestwood wrote:
> Hi Baochen,
> 
> On 1/29/24 11:00 PM, Baochen Qiang wrote:
>>
>>
>> On 1/27/2024 3:18 AM, James Prestwood wrote:
>>> On 1/24/24 5:06 AM, James Prestwood wrote:
>>>
>>>> Hi,
>>>>
>>>> I recently added support to ath10k, for the QCA6174, to receive 
>>>> multicast action frames in order to support DPP. I'm trying to do 
>>>> this for the ath11k QCNFA765/WCN6855. I took the same approach as 
>>>> ath10k which was actually quite simple but I'm unable to see any 
>>>> multicast frames coming over even when I enable RX/DATA debugging.
>>>>
>>>> What I've done so far is:
>>>>
>>>>  - Add FIF_MCAST_ACTION to the supported filters list
>>>>
>>>>  - Created/started a monitor vdev from within 
>>>> ath11k_mac_op_configure_filter()
>>>>
>>>>     ath11k_mac_monitor_vdev_create(ar);
>>>>
>>>>     ath11k_mac_monitor_start(ar);
>>>>
>>>> - Also tried adding
>>>>
>>>>     ath11k_mac_config_mon_status_default(ar, true);
>>>>
>>>> I can successfully create/start the monitor vdev. I see now as I'm 
>>>> writing this email that my specific hardware does not support 
>>>> monitor mode outright... Is this a dead end or is there hope with 
>>>> purely driver changes? or is it some filtering at the firmware level 
>>>> preventing this?
>>>
>>> I was able to finally see my broadcast frame after some additional 
>>> testing. It seems the driver/firmware/something gets a bit hung up 
>>> when I attempt to put it in monitor mode. It will start printing 
>>> these messages for about a minute:
>>>
>>> [   51.093034] ath11k_pci 0000:00:06.0: data dest_rx: new ppdu_id 
>>> a1a2 != status ppdu_id a1a1 dest_mon_not_reaped = 650 dest_mon_stuck 
>>> = 12
>>> [   51.094461] ath11k_pci 0000:00:06.0: data dest_rx: new ppdu_id 
>>> a1a3 != status ppdu_id a1a2 dest_mon_not_reaped = 651 dest_mon_stuck 
>>> = 12
>>> [   51.096281] ath11k_pci 0000:00:06.0: data dest_rx: new ppdu_id 
>>> a1a5 != status ppdu_id a1a3 dest_mon_not_reaped = 652 dest_mon_stuck 
>>> = 12
>>>
>>> In most cases these ppdu ID's are a one-off from the expected ID 
>>> which seemed weird to me. But if I let it sit long enough I all of a 
>>> sudden get a ton of "data rx" messages, which is what I would expect 
>>> if I enabled a monitor vdev. Once this flurry starts I see the action 
>>> frame from my other client, sometimes at least. The firmware 
>>> generally crashes after a while so I've still got a ways to go but it 
>>> seems within the realm of possibility that this device could receive 
>>> broadcast action frames?
>>>
>>> Hoping for some breadcrumbs to follow here...
>>>
>> Hi James, as you already mentioned, ath11k/WCN6855 doesn't support 
>> monitor mode yet. I don't know why you are testing multicast action 
>> frame with monitor mode. So if monitor mode is not a must, could you 
>> test this with STATION mode? We would look into this if any issue found.
> 
> 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)?

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