ath11k multicast action frame RX

ath11k multicast action frame RX

[James Prestwood]

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?

Thanks,

James

Re: ath11k multicast action frame RX

[James Prestwood]

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

Thanks,

James

>
> Thanks,
>
> James
>
>

Re: ath11k multicast action frame RX

[Baochen Qiang]

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.

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

Re: ath11k multicast action frame RX

[James Prestwood]

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.

Thanks,

James

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

Re: ath11k multicast action frame RX

[James Prestwood]

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

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

Re: ath11k multicast action frame RX

[James Prestwood]

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

Re: ath11k multicast action frame RX

[Baochen Qiang]

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?

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

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

Re: ath11k multicast action frame RX

[Baochen Qiang]

On 2/21/2024 8:24 PM, James Prestwood wrote:
> 
> 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 
But you are using monitor mode, not station mode, on ath10k, right?

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

Re: ath11k multicast action frame RX

[James Prestwood]

Hi Baochen,

On 2/21/24 6:26 PM, Baochen Qiang wrote:
> But you are using monitor mode, not station mode, on ath10k, right? 

No I'm using station mode. It looks like ath10k creates a monitor device 
to receive these frames (that was already done before my patch), but the 
interface I'm using from userspace is a regular station interface

Thanks,

James

Re: ath11k multicast action frame RX

[Baochen Qiang]

On 2/22/2024 11:38 PM, James Prestwood wrote:
> Hi Baochen,
> 
> On 2/21/24 6:26 PM, Baochen Qiang wrote:
>> But you are using monitor mode, not station mode, on ath10k, right? 
> 
> No I'm using station mode. It looks like ath10k creates a monitor device 
> to receive these frames (that was already done before my patch), but the 
> interface I'm using from userspace is a regular station interface
> 
OK let's forget what ath10k does to receiver those frames for now and 
focus on ath11k. From what I got from firmware team, it's expected that 
ath11k station interface can't get those frame without a scan because 
device A is connected to an AP already and is supposed to get frames 
only from within the BSS, apparently device B here is not within that BSS.

> Thanks,
> 
> James
> 

Re: ath11k multicast action frame RX

[James Prestwood]

Hi Baochen

On 2/22/24 5:56 PM, Baochen Qiang wrote:
>
>
> On 2/22/2024 11:38 PM, James Prestwood wrote:
>> Hi Baochen,
>>
>> On 2/21/24 6:26 PM, Baochen Qiang wrote:
>>> But you are using monitor mode, not station mode, on ath10k, right? 
>>
>> No I'm using station mode. It looks like ath10k creates a monitor 
>> device to receive these frames (that was already done before my 
>> patch), but the interface I'm using from userspace is a regular 
>> station interface
>>
> OK let's forget what ath10k does to receiver those frames for now and 
> focus on ath11k. From what I got from firmware team, it's expected 
> that ath11k station interface can't get those frame without a scan 
> because device A is connected to an AP already and is supposed to get 
> frames only from within the BSS, apparently device B here is not 
> within that BSS.
>
I still don't know why a scan would change anything. Maybe the act of 
scanning triggers something in the firmware to allow the RX of multicast 
frames (like to receive probe responses)? If so that's not really a 
mechanism to enable multicast RX, its just a side effect of scanning.

But yes currently when an ath11k device is connected to a BSS it will 
only receive frames from within that BSS. This is what I was attempting 
to change, allow it to receive multicast action frames while connected 
(or disconnected for that matter).

The whole point of DPP is to provision a new device. So one device is 
offline and asking the connected device for credentials. This is done 
via multicast action frames.

Thanks,

James

>> Thanks,
>>
>> James
>>