Re: ath11k multicast action frame RX

[James Prestwood <prestwoj@gmail.com>]

On 1/30/24 4:47 AM, 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.
>
> 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.

Meant to mention, I swapped out my email to prestwoj@gmail.com, with 
multiple emails accounts sometimes my corporate account sneaks in. Sorry 
for the confusion.

>
> Thanks,
>
> James
>
>>
>>> Thanks,
>>>
>>> James
>>>
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>>>
>>