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 <henri...@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 <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