IEEE802.11w enabled by default

[Tom Psyborg]

it could be kernel driver bug. try booting other distro, like kali or
ubuntu releases from within last few years - e.g. 18.04,19.04,20.04 to
see if it ever worked better.

On 23/12/2020, Henrique de Moraes Holschuh <henrique at nic.br> wrote:
> 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
>