IEEE802.11w enabled by default

Wed Dec 23 09:20:31 EST 2020

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 <henrique at 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 <henrique at 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 <henrique at 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