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
