On 22/12/2020 11:31, Tom Psyborg wrote:
In that case, check router side, client can support it most likely.
Try different release or factory firmware
Well, according to this page:
https://kevinlocke.name/bits/2019/12/28/checking-802.11w-support/
the *client* hardware supports it (CMAC is present in the "iw phy phy0
info" output), but there is no MFP_OPTIONAL in the output of "iw phy" in
the client (iw version 5.0.1). In fact, there is no MFP anywhere in the
iw output for the client.
From what I understood, that means the Debian 10 kernel driver+firmware
combination doesn't support MFP for QCA6174, although the hardware does.
So, we have a client that has hardware support for MFP, but either its
firmware or the kernel driver apparently doesn't. Whether I can try to
address that in the Debian-stable side or not is something I will look
into later, after we have the full picture.
Now, for the router, in this case a Archer C6v2(US) which has a newer
chipset than the Archer C7v4(BR) where I also get the same problem:
ath10k 4.19 driver, optimized for CT firmware, probing pci device: 0x56.
ath10k_pci 0000:00:00.0: pci irq legacy oper_irq_mode 1 irq_mode 0
reset_mode 0
firmware ath10k!QCA9888!hw2.0!firmware-6.bin: firmware_loading_store:
map pages failed
ath10k_pci 0000:00:00.0: qca9888 hw2.0 target 0x01000000 chip_id
0x00000000 sub 0000:0000
ath10k_pci 0000:00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 1
testmode 0
ath10k_pci 0000:00:00.0: firmware ver 10.4b-ct-9888-fW-13-8c5b2baa2 api
5 features
mfp,peer-flow-ctrl,txstatus-noack,wmi-10.x-CT,ratemask-CT,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,tx-rc-CT,cust-stats-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT,wmi-bcn-rc-CT
crc32 cbf49903
ath10k_pci 0000:00:00.0: board_file api 2 bmi_id 0:24 crc32 f228337a
ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32
ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186
msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
ath10k_pci 0000:00:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508'
ath10k_pci 0000:00:00.0: htt-ver 2.2 wmi-op 6 htt-op 4 cal pre-cal-file
max-sta 32 raw 0 hwcrypto 1
after that, it chances region to "BR", and complains about something
from the client:
ath: regdomain 0x804c dynamically updated by user
ath10k_pci 0000:00:00.0: 10.4 wmi init: vdevs: 16 peers: 48 tid: 96
ath10k_pci 0000:00:00.0: msdu-desc: 2500 skid: 32
ath10k_pci 0000:00:00.0: wmi print 'P 48/48 V 16 K 144 PH 176 T 186
msdu-desc: 2500 sw-crypt: 0 ct-sta: 0'
ath10k_pci 0000:00:00.0: wmi print 'free: 114572 iram: 12804 sram: 29508'
ath10k_pci 0000:00:00.0: Firmware lacks feature flag indicating a retry
limit of > 2 is OK, requested limit: 4
ath10k_pci 0000:00:00.0: mac-vif-chan had error in
htt_rx_h_vdev_channel, peer-id: 0 vdev-id: 0 peer-addr: xxxxxxx.
However, "iw" in my OpenWrt build seems not to be iw-full, since it
doesn't list cyphers. debugfs does show MFP_CAPABLE.
Should the lack of iw-full impact in the operation of ieee802.11w on the
openwrt side?
I can do further tests and provide more information if requested. I
could try a special build to drop the -ct firmware and drivers, and
switch to vendor ath firmware and drivers, though, but if there are
other tests that can be done beforehand, it would be best.
On 22/12/2020, Henrique de Moraes Holschuh <henri...@nic.br> wrote:
On 21/12/2020 17:13, Tom Psyborg wrote:
In case your client doesn't support mfp, you should configure the
setting on router to optional instead of required so non-mfp client
can fallback to basic connection type.
I took my time to answer to test it again just in case, but as soon as I
set it to "optional" from "disabled", the slowdown happens. For the
record, the client goes from 200Mbit/s effective transfer rate (not
signal rate) to about 65Mbit/s effective transfer rate.
So, at least here, setting ieee 802.11w to "optional" does not avoid the
performance loss.
On 21/12/2020, Henrique de Moraes Holschuh <henri...@nic.br> wrote:
On 21/12/2020 17:01, Tom Psyborg wrote:
Your firmware does not advertise mfp support, first check if your
client device can actually support 802.11w
Does it mean that we should expect the large performance loss for any
clients that don't have mfp support on any routers that have 802.11w
enabled?
That sounds extremely sub-optimal, to use very nice words... so
hopefully there is more to the scenario?
On 21/12/2020, Henrique de Moraes Holschuh <henri...@nic.br> wrote:
On 20/12/2020 06:42, Petr Štetiar wrote:
I would like to let you know, that there was virtual meeting week ago
and
you
can find the meeting minutes on the wiki[1].
1. https://openwrt.org/meetings/20201210
FYI, about IEEE802.11w enabled by default:
This is a very limited experience, but here it *tanks* client
performance here drastically.
The wireless routers are TP-Link Archer C6v2(US) and TP-Link Archer
C7v4
(BR), running openwrt 19.07 snapshot.
I am not sure the slowdown is caused router-side, it could be
something
in the *client* that gets triggered by the 802.11w support, for all I
know: the only client I have that can hit the throughput where
performance loss gets more noticeable is a Dell laptop.
The client is running the standard Debian 10 kernel (up-to-date), the
hardware is a Dell laptop, with a QCA6174 radio and the standard
firmware:
ath10k_pci 0000:02:00.0: qca6174 hw3.2 target 0x05030000 chip_id
0x00340aff sub 1028:0310
ath10k_pci 0000:02:00.0: kconfig debug 0 debugfs 0 tracing 0 dfs 0
testmode 0
ath10k_pci 0000:02:00.0: firmware ver RM.4.4.1.c2-00057-QCARMSWP-1 api
6
features wowlan,ignore-otp,no-4addr-pad,raw-mode crc32 e061250a
ath10k_pci 0000:02:00.0: htt-ver 3.56 wmi-op 4 htt-op 3 cal otp
max-sta
32 raw 0 hwcrypto 1
I did notice slowdowns on *both* bands (2.4GHz and 5GHz), but it is
far
more visible in 5GHz, since it reaches far higher throughput.
It is bad enough that it is unfeasible for me to even consider
enabling
it :-(
--
Henrique de Moraes Holschuh
Analista de Projetos
Centro de Estudos e Pesquisas em Tecnologias de Redes e Operações
(Ceptro.br)
+55 11 5509-3537 R.:4023
INOC 22548*625
www.nic.br
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
