Received-SPF: pass (google.com: domain of linux-wireless+bounces-2886-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Message-ID: <7a62031b-ad1f-4da2-8217-19a5d7fdc0f4@gmail.com>
Date: Wed, 31 Jan 2024 04:28:35 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ath11k multicast action frame RX
To: Baochen Qiang <quic_bqiang@quicinc.com>,
 "open list:MEDIATEK MT76 WIRELESS LAN DRIVER"
 <linux-wireless@vger.kernel.org>, ath11k@lists.infradead.org
References: <dcdbd757-ad6e-4fe0-a0c1-fe328431b73b@locusrobotics.com>
 <642b61a6-e3c0-4831-887f-f25314bf166d@locusrobotics.com>
 <90ac3bdc-8797-4d57-8bc9-48e0ad406674@quicinc.com>
 <1dafe0e5-292b-4764-86c7-cc1757aeb3b6@gmail.com>
 <ed8eeb92-e1eb-445e-989d-2340c26faf44@quicinc.com>
Content-Language: en-US
From: James Prestwood <prestwoj@gmail.com>
In-Reply-To: <ed8eeb92-e1eb-445e-989d-2340c26faf44@quicinc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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.

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