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
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
>
>
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
>>
>>
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 [email protected], with
multiple emails accounts sometimes my corporate account sneaks in. Sorry
for the confusion.
>
> Thanks,
>
> James
>
>>
>>> Thanks,
>>>
>>> James
>>>
>>>>
>>>> Thanks,
>>>>
>>>> James
>>>>
>>>>
>>
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
>>>
>>>
>
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
>>>>
>>>>
>>
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
>>>>>
>>>>>
>>>
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
>>>>>>
>>>>>>
>>>>
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
>>>>>>>
>>>>>>>
>>>>>
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
>>>>>>>>
>>>>>>>>
>>>>>>
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
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
>
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
>>