Re: a nuking the mac80211 changing codel parameters patch
I cannot help but wonder what the results have been on people applying
this patch over the past 6 months?
On Tue, Dec 20, 2022 at 12:24 PM Dave Taht wrote:
>
> This is the single, most buggy, piece of code in "my" portion of wifi
> today. It is so wrong, yet thus far I cannot get it out of linux or
> find an acceptable substitute. It makes it hard to sleep at night
> knowing this code has been so wrong... and now in millions , maybe
> even 10s of millions, of devices by now Since I've been ranting
> about the wrongness of this for years, I keep hoping that we can
> excise it, especially for wifi6 devices and even more especially on
> 6ghz spectrum... but just about everything, somehow, would benefit
> hugely if we could somehow do more of the right thing here.
>
> I'd tried, last time I got this bee in my bonnet, tried to nuke this call
> here:
>
> https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/
>
> As it is, I really encourage folk, especially with mt79 and to some
> extent mt76 ac or ath10k, to try out the attached patch, measure tcp
> rtts, and throughput, etc. A slightly less aggressive patch might suit
> wifi-n
>
> Maybe there's a reason for keeping this code in linux wifi that I do
> not understand. But here are my pithy comments as to why this part of
> mac80211 is so wrong...
>
> static void sta_update_codel_params(struct sta_info *sta, u32 thr)
> {
> - if (thr && thr < STA_SLOW_THRESHOLD * sta->local->num_sta) {
>
> 1) sta->local->num_sta is the number of associated, rather than
> active, stations. "Active" stations in the last 50ms or so, might have
> been a better thing to use, but as most people have far more than that
> associated, we end up with really lousy codel parameters, all the
> time. Mistake numero uno!
>
> 2) The STA_SLOW_THRESHOLD was completely arbitrary in 2016.
>
> - sta->cparams.target = MS2TIME(50);
>
> This, by itself, was probably not too bad. 30ms might have been
> better, at the time, when we were battling powersave etc, but 20ms was
> enough,
> really, to cover most scenarios, even where we had low rate 2Ghz
> multicast to cope with. Even then, codel has a hard time finding any
> sane drop
> rate at all, with a target this high.
>
> - sta->cparams.interval = MS2TIME(300);
>
> But this was horrible, a total mistake, that is leading to codel being
> completely ineffective in almost any scenario on clients or APS.
> 100ms, even 80ms, here, would be vastly better than this insanity. I'm
> seeing 5+seconds of delay accumulated in a bunch of otherwise happily
> fq-ing APs
>
> 100ms of observed jitter during a flow is enough. Certainly (in 2016)
> there were interactions with powersave that I did not understand, and
> still don't, but
> if you are transmitting in the first place, powersave shouldn't be a
> proble.
>
> - sta->cparams.ecn = false;
>
> At the time we were pretty nervous about ecn, I'm kind of sanguine
> about it now, and reliably indicating ecn seems better than turning it
> off for
> any reason.
>
> - } else {
> - sta->cparams.target = MS2TIME(20);
> - sta->cparams.interval = MS2TIME(100);
> - sta->cparams.ecn = true;
> - }
>
> And if we aint gonna fiddle with these, we don't need these either.
>
> In production, on p2p wireless, I've had 8ms and 80ms for target and
> interval for years now, and it works great. It is obviously too low,
> for those that
> prize bandwidth over latency (I personally would prefer TXOPs shrink
> intelligently as well as bandwidth, as you add stations, some of which
> happens naturally by fq-codels scheduling mechanisms, others don't, I
> even run with 2ms txops by default on everything myself)
>
> + return;
>
> Ideally we could kill this entire call off entirely.
>
> }
>
> A pre-thx for anyone actually trying the attached patch and reporting
> back on any results.
>
> https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/
>
>
> --
> This song goes out to all the folk that thought Stadia would work:
> https://www.linkedin.com/posts/dtaht_the-mushroom-song-activity-698135607352320-FXtz
> Dave Täht CEO, TekLibre, LLC
--
Podcast: https://www.youtube.com/watch?v=bxmoBr4cBKg
Dave Täht CSO, LibreQos
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: trouble with hostapd
On 03.08.23 20:17, e9hack wrote: Am 03.08.2023 um 18:51 schrieb Felix Fietkau: On 03.08.23 15:34, e9hack wrote: Am 03.08.2023 um 14:35 schrieb Felix Fietkau: thanks for reporting this. Unfortunately I can't reproduce it myself based on your description. Can you please let me know what device you are using, and send me the config that reproduces this issue? I'm using an ASUS RT-AX53U. Hostapd has the radius server compiled in. Fixed in b8be20c7e81de2894df8fa2b361c39bc723e4cb5, thanks. This does fix the issue, thanks! Now I see some errors, which I've never seen before: Thu Aug 3 19:59:19 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:23 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:24 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 19:59:24 2023 daemon.err hostapd: Failed to set beacon parameters Thu Aug 3 19:59:25 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:00:35 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:00:36 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:00:47 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Thu Aug 3 20:03:23 2023 daemon.err hostapd: nl80211: kernel reports: integer out of range Can you please build hostapd with CONFIG_WPA_MSG_MIN_PRIORITY=0 in the OpenWrt .config, add -d to the hostapd command in /etc/init.d/wpad Afterwards, please show me the relevant log part with the full context of the beacon command, so that I can figure out which parameter might be going out of range. Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] hostapd: revert upstream commit to fix #13156
Commit e978072baaca ("Do prune_association only after the STA is
authorized") causes issues when an STA roams from one interface to
another interface on the same PHY. The mt7915 driver is not able to
handle this properly. While the commits fixes a DoS, there are other
devices and drivers with the same limitation, so revert to the orginal
behavior for now, until we have a better solution in place.
Fixes: #13156
Signed-off-by: Stijn Tintel
---
.../patches/991-Fix-OpenWrt-13156.patch | 63 +++
1 file changed, 63 insertions(+)
create mode 100644
package/network/services/hostapd/patches/991-Fix-OpenWrt-13156.patch
diff --git
a/package/network/services/hostapd/patches/991-Fix-OpenWrt-13156.patch
b/package/network/services/hostapd/patches/991-Fix-OpenWrt-13156.patch
new file mode 100644
index 00..671b8ffecd
--- /dev/null
+++ b/package/network/services/hostapd/patches/991-Fix-OpenWrt-13156.patch
@@ -0,0 +1,63 @@
+From 26cd9bafc1d25e602952ee86cd2a5b8c3a995490 Mon Sep 17 00:00:00 2001
+From: Stijn Tintel
+Date: Fri, 28 Jul 2023 16:27:47 +0300
+Subject: [PATCH] Revert "Do prune_association only after the STA is
+ authorized"
+
+Commit e978072baaca ("Do prune_association only after the STA is
+authorized") causes issues when an STA roams from one interface to
+another interface on the same PHY. The mt7915 driver is not able to
+handle this properly. While the commits fixes a DoS, there are other
+devices and drivers with the same limitation, so revert to the orginal
+behavior for now, until we have a better solution in place.
+
+Ref: https://github.com/openwrt/openwrt/issues/13156
+Signed-off-by: Stijn Tintel
+---
+ src/ap/hostapd.c | 14 +++---
+ src/ap/sta_info.c | 3 ---
+ 2 files changed, 11 insertions(+), 6 deletions(-)
+
+--- a/src/ap/hostapd.c
b/src/ap/hostapd.c
+@@ -3619,6 +3619,8 @@ int hostapd_remove_iface(struct hapd_int
+ void hostapd_new_assoc_sta(struct hostapd_data *hapd, struct sta_info *sta,
+ int reassoc)
+ {
++ int mld_assoc_link_id = -1;
++
+ if (hapd->tkip_countermeasures) {
+ hostapd_drv_sta_deauth(hapd, sta->addr,
+ WLAN_REASON_MICHAEL_MIC_FAILURE);
+@@ -3626,10 +3628,16 @@ void hostapd_new_assoc_sta(struct hostap
+ }
+
+ #ifdef CONFIG_IEEE80211BE
+- if (hapd->conf->mld_ap && sta->mld_info.mld_sta &&
+- sta->mld_assoc_link_id != hapd->mld_link_id)
+- return;
++ if (hapd->conf->mld_ap && sta->mld_info.mld_sta) {
++ if (sta->mld_assoc_link_id == hapd->mld_link_id) {
++ mld_assoc_link_id = sta->mld_assoc_link_id;
++ } else {
++ return;
++ }
++ }
+ #endif /* CONFIG_IEEE80211BE */
++if (mld_assoc_link_id != -2)
++ hostapd_prune_associations(hapd, sta->addr, mld_assoc_link_id);
+
+ ap_sta_clear_disconnect_timeouts(hapd, sta);
+ sta->post_csa_sa_query = 0;
+--- a/src/ap/sta_info.c
b/src/ap/sta_info.c
+@@ -1318,9 +1318,6 @@ void ap_sta_set_authorized(struct hostap
+ mld_assoc_link_id = -2;
+ }
+ #endif /* CONFIG_IEEE80211BE */
+- if (mld_assoc_link_id != -2)
+- hostapd_prune_associations(hapd, sta->addr,
+- mld_assoc_link_id);
+ sta->flags |= WLAN_STA_AUTHORIZED;
+ } else {
+ sta->flags &= ~WLAN_STA_AUTHORIZED;
--
2.41.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
