Hi Felix,
On 6/23/23 08:55, Felix Fietkau wrote:
On 18.05.23 11:19, David Bauer wrote:
ath10k does not report excessive loss in case of broken block-ack
sessions. The loss is communicated to the host-os, but ath10k does not
trigger a low-ack events by itself.
The mac80211 framework for loss detection however detects this
circumstance well in case of ath10k. So use it regardless of ath10k's
own loss detection mechanism.
Signed-off-by: David Bauer <m...@david-bauer.net>
Please make a patch for ath10k instead of turning the flag into a no-op in
mac80211.
The rationale for removal was in fact to avoid patching ath1xk separately,
given these
are the only drivers using this flag.
I'm aware this is not the nicest approach, do you have any insight if there's a
downside
to always keeping mac80211 loss detection active?
I however still respect the preferation of keeping this limited to specific
drivers, I'm
just interested if there's a deeper rationale / problem i did not spot :)
Just to outline the issue this is trying to avoid - Intel clients started
dropping their
BA sessions sometimes in late 2020 without notifying the AP. The ath10k
firmware keeps
retransmitting exclusive to the device at the lowest rate while not indicating
a low-ack
situation to the host-os, avoiding station kickout. This results in very low
throughput
for all connected stations (aql enabled) up to DoS of the AP (aql disabled).
Best
David
- Felix
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
