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
