Client Steering | Usteer: hohe Latenz und Timeouts
Ein schnelles und stabiles WLAN ist heutzutage unverzichtbar. Viele Nutzer wollen ihre Netzwerke optimieren, um die beste Leistung zu erzielen. Ein Ansatz ist die Nutzung eines Client Steering Daemons auf OpenWrt. Dies soll die Netzwerkkommunikation effizienter machen und Zugriffspunkte besser nutzen. Doch wie effektiv sind diese Anpassungen wirklich? Hier werden die Herausforderungen und Beobachtungen bei der Konfiguration eines solchen Setups beschrieben und ob die Ergebnisse den Aufwand rechtfertigen.
Lange Zeit wollte ich mein OpenWrt-Setup mit einem Client Steering Deamon veredeln und mich dazu etwas an der offiziellen Dokumentation orientiert.
Dokumentation und Interpretation
Zunächst ein Blick in die Dokumentation von OpenWrt und meine daraus abgeleiteten ursprünglichen Einstellungen:
-
Laut der Dokumentation: "Damit AP-Steering wirksam wird, muss signal_diff_threshold auf einen Wert größer als 0 gesetzt werden."
(For AP steering to take effect, signal_diff_threshold needs to be set to a value greater than 0)Als Beispiel habe ich für Signal diff threshold den Wert 15 versucht, was von der Größenordnung auch von anderen in diversen Foren verwendet wird.
-
Laut der Dokumentation: "band_steering_threshold wird nur wirksam, wenn load_balancing_threshold ebenfalls auf einen Wert größer als 0 gesetzt ist."
band_steering_threshold does not take effect unless load_balancing_threshold is also set to a value greater than 0.Die beiden Settings habe ich wie folgt versucht:
-
Zuletzt noch "roam_scan_snr" Laut der Dokumentation muss dafür ein Wert gesetzt werden, um Client-Scans für Roaming auszulösen.
roam_scan_snr needs to be set to trigger client scans for roaming. - Wenn roam_scan_snr nicht gesetzt ist und roam_trigger_snr gesetzt ist, dann nimmt roam_scan_snr den Wert von roam_trigger_snr an.
If roam_scan_snr is unset and roam_trigger_snr is set, then roam_scan_snr will take the value of roam_trigger_snr.
OK, hätte ich so hingenommen, muss dann glaube ich nicht sein ..
Mit oder ohne den Einstellungen: Ich konnte am Verhalten der WLan-Geräte keinen Unterschied feststellen, außer dass irgendwas immer wieder mal bei bestimmten Geräten eine erhöhte Latenz verursacht:
Hohe Latenz und Timeouts
Manche Windows-Clients hatten mit meinen letzten Einstellungen manchmal eine unterirdisch schlechte Antwortzeit und nach einiger Zeit waren Timeouts an der Tagesordnung:
Als Beispiel Windows 10 und folgender USB-WiFi-Stick:
Ursache?
Nach einigen Tests und schrittweisem Entfernen und Hinzufügen aller möglichen WLAN-Settings und Usteer-Einstellungen konnte ich das Phänomen etwas isolieren: Bestimmte Clients in meinem Netzwerk, speziell Windows Clients, reagieren auf die folgende Option mit Verzögerungen und Timeouts:
Roam scan SNR: -60
Im Log werden nach dem Aktivieren von Roam scan SNR BEACON-Proben notiert:
Tue Oct 1 19:02:52 2024 daemon.notice hostapd: phy0-ap1: BEACON-REQ-TX-STATUS 40:1a:58:c0:05:68 71 ack=1
Tue Oct 1 19:02:52 2024 daemon.notice hostapd: phy0-ap1: BEACON-RESP-RX 40:1a:58:c0:05:68 71 04
Tue Oct 1 19:02:52 2024 daemon.notice hostapd: phy0-ap1: BEACON-REQ-TX-STATUS ac:6c:90:31:1c:35 72 ack=1
Tue Oct 1 19:03:03 2024 daemon.notice hostapd: phy0-ap1: BEACON-REQ-TX-STATUS 40:1a:58:c0:05:68 73 ack=1
Tue Oct 1 19:03:03 2024 daemon.notice hostapd: phy0-ap1: BEACON-RESP-RX 40:1a:58:c0:05:68 73 00 01240000000000000000000000ba00f64d5cfa8a2400000000000150a6138f2ea1000000640011102d1aef0917ffff000000000000000000000100000000000000000000bf0cb1398933faff0000faff000030180100000fac040100000fac040200000fac02000fac040c00
Tue Oct 1 19:03:03 2024 daemon.notice hostapd: phy0-ap1: BEACON-RESP-RX 40:1a:58:c0:05:68 73 00 01a10000000000000000000000ba006038e0c53a41000000000001505ce0713904010000640031102d1a6f0817ffffff00010000000000c2010100000000000000000000bf0c32798b33eaff9204eaff920430180100000fac040100000fac040200000fac02000fac040c00
Tue Oct 1 19:03:03 2024 daemon.notice hostapd: phy0-ap1: BEACON-REQ-TX-STATUS ac:6c:90:31:1c:35 74 ack=1
Tendenziell gibt es zwischen den Beacon-Status-Informationen und den WLAN-Verzögerungen einen möglichen zeitlichen Zusammenhang.
Hin und wieder verursacht 802.11v bei den betroffenen Clients auch ohne roam_scan_snr eine leichte Verzögerung:
Fri Oct 12 18:20:10 2024 daemon.notice hostapd: phy0-ap0: BSS-TM-RESP c0:06:c3:42:c0:3b status_code=7 bss_termination_delay=0
diese konnte ich gefühlt durch das Deaktivieren von 802.11v eliminieren:
Usteer, du fehlst eigentlich gar nicht!
Ohne einer Änderung an den restlichen WLAN-Einstellungen, reichte es den Deamon unter "Software" / "Startup" zu stoppen / deaktivieren:
Und siehe da: die betroffenen Windows Rechner haben bei mir sofort, durchgehend und nachhaltig wieder eine ordentliche Antwortzeit:
weiteres Troubleshooting
Zwischenzeitlich hatte sich ein Client ständig mit dem WLAN neu verbunden. Im Eventlog:
Fri Oct 10 18:08:11 2024 daemon.notice hostapd: phy1-ap1: AP-STA-DISCONNECTED c0:06:c3:42:c0:3b
Fri Oct 10 18:08:11 2024 daemon.info hostapd: phy1-ap1: STA c0:06:c3:42:c0:3b IEEE 802.11: authenticated
Fri Oct 10 18:08:11 2024 daemon.info hostapd: phy1-ap1: STA c0:06:c3:42:c0:3b IEEE 802.11: associated (aid 1)
Fri Oct 10 18:08:11 2024 daemon.notice hostapd: phy1-ap1: AP-STA-CONNECTED c0:06:c3:42:c0:3b auth_alg=open
Fri Oct 10 18:08:11 2024 daemon.info hostapd: phy1-ap1: STA c0:06:c3:42:c0:3b RADIUS: starting accounting session 86735B5EE68C7D5A
Fri Oct 10 18:08:11 2024 daemon.info hostapd: phy1-ap1: STA c0:06:c3:42:c0:3b WPA: pairwise key handshake completed (RSN)
Fri Oct 10 18:08:11 2024 daemon.notice hostapd: phy1-ap1: EAPOL-4WAY-HS-COMPLETED c0:06:c3:42:c0:3b
Fri Oct 10 18:08:17 2024 daemon.notice hostapd: phy1-ap1: AP-STA-DISCONNECTED c0:06:c3:42:c0:3b
Ursache könnte eine fehlerhafte Einstellung der Mobility Domain sein. Zumindest konnte ich das Problem durch das Löschen der Mobility Domain, also mit dem Standard-Wert beheben:
siehe auch: Ununterbrochenes WiFi: Roaming (Fast Transition)
Quellen
- openwrt.org/docs/guide-user/network/wifi/usteer
- forum.openwrt.org/t/lets-talk-about-usteer/124603/130?page=2
Fazit
Durch 802.11r/k und optional v sollten die Clients von sich aus in der Lage sein die richtigen Entscheidungen zu treffen. Wird Usteer ohne zusätzlicher Parameter aktiviert, greift der Steering-Deamon nicht aktiv in das Verhalten der Clients ein. Auch die oben beschriebenen Parameter verbessern das Verhalten in der Praxis zumindest nicht spürbar und: eine falsche Einstellung und Usteer richtet mehr Schaden an, als es nützt. Usteer hat mich in Summe nur Zeit und Nerven gekostet: Ohne Usteer funktioniert das WLAN in der Regel genauso gut oder möglicherweise sogar besser. Also im Zweifelsfall, einfach mal ohne usteer versuchen:
Solltest du andere Erfahrungen gemacht haben, oder bestimmte andere Parameter für Usteer verwenden, bitte gerne ein Feedback in den Kommentaren hinterlassen.
{{percentage}} % positiv
DANKE für deine Bewertung!
Fragen / Kommentare
(sortiert nach Bewertung / Datum) [alle Kommentare(neueste zuerst)]
Es gibt einiges Patches von mir zu Usteer (ein wichtiger in hostap ist auch ausstehend) damit funktioniert Usteer exzellent. Dabei müssen nur wenige Parameter gesetzt sein. Im folgenden Thread im OpenWRT Forum sind die Einstellungen auch hinterlegt. Damit funktioniert es auch in der aktuellen Version recht gut. https://forum.openwrt.org/t/lets-talk-about-usteer/124603/179?u=nilsro Das Verhalten von den Windows Clients konnte ich nicht nachvollziehen, ich hab Usteer selber im Einsatz und auch optimiert, weil einige Windows Rechner die korrekte Auswahl des AP nicht hinbekommen und Usteer diese korrekt verschiebt. Viele Grüße, Nil