In that case, check router side, client can support it most likely. Try different release or factory firmware
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 >> > > > -- > 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
