Hi Eric,
On 4/29/24 5:18 AM, Kalle Valo wrote:
Eric Park <m...@ericswpark.com> writes:
On 4/25/24 5:51 AM, Kalle Valo wrote:
I do not use Network Manager or other connection managers when testing.
It's much more reliable to use wpasupplicant directly and you get full
control. I usually create a custom config file and then start the
supplicant manually. Some pointers:
(...)
I had some time today to test this, but unfortunately I couldn't
figure out if wpa_supplicant was using WPA2 or WPA3. Trying to connect
via `key_mgmt=SAE` caused `dhcpcd` to time out looking for carriers,
so I guess it was connecting via WPA2. In any case the speed results
were the same as disabling WPA3 on the router-side.
If you run wpa_supplicant -dddt (or similar) you get a lot of debug
output, I'm sure it will also include the cipher.
The reason I'm sending this email despite not making much progress
above is because it turns out I was chasing a red herring. The real
problem behind the degraded throughput was 802.11w. The router was
advertising support for it (802.11w capable but optional), but was not
forcing clients that didn't have the capability (required mode).
In Optional mode, I was experiencing the degraded performance. But
after I disabled 802.11w on the router side, the speeds recovered to
normal levels on both 2.4 GHz and 5 GHz bands, even connected over
WPA3.
So I'm guessing something on the driver's side is signaling that it
supports 802.11w, when in reality it doesn't or some bug with the
implementation causes the speed to drop. Or maybe there's an overhead
I'm unaware of when 802.11w is enabled? My limited understanding of
802.11w is that the management frames are protected to prevent deauth
attacks.
I'm not sure where to begin troubleshooting this, but in the interim
can I disable the capability advertising on the driver-level? I don't
want to disable 802.11w on my entire network, if possible.
Very good that you found this is 802.11w related. What is the make and
model of your router?
I don't know how well ath10k 802.11w support is tested and then it was
last tested. Do you happen to have other Access Points supporting
802.11w? That might help to pinpoint if 802.11w is completely broken in
ath10k or if this is an interoperability issue with ath10k and your AP.
FWIW I just had 802.11w enabled on our test floor (should have been to
begin with...) where all clients are running QCA6174's. I tested with
iperf and saw zero difference in throughput between MFP disabled and
enabled. We also set MFP to required, not optional. So at least the
hardware variant/firmware we run isn't picky with MFP:
qca6174 hw3.2 target 0x05030000 chip_id 0x00340aff sub 168c:3363
firmware ver WLAN.RM.4.4.1-00288- api 6 features wowlan,ignore-otp,mfp
crc32 bf907c7c
Thanks,
James
