Received-SPF: pass (google.com: domain of linux-wireless+bounces-3857-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Message-ID: <eaeb8e9b-3809-4f89-a5b2-7949aa01fbde@gmail.com>
Date: Wed, 21 Feb 2024 04:24:46 -0800
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: ath11k multicast action frame RX
Content-Language: en-US
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>
 <7a62031b-ad1f-4da2-8217-19a5d7fdc0f4@gmail.com>
 <f363f179-b41f-4bea-882f-e4aacb8ad519@quicinc.com>
From: James Prestwood <prestwoj@gmail.com>
In-Reply-To: <f363f179-b41f-4bea-882f-e4aacb8ad519@quicinc.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit


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