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
