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:

auf amazon.de:

TP-Link Archer T2U Nano AC600 USB WLAN S...

Verfügbarkeit: Jetzt
Preis: 12,49 €
zum Stand: 27.11.2024 04:54 Details

[Produktpreise und Verfügbarkeit gelten zum angegebenen Datum/Uhrzeit und können sich ändern. Für den Kauf dieses Produkts gelten alle zum Zeitpunkt des Kaufs auf amazon.de angezeigten Preis- und Verfügbarkeitsinformationen.]

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-Wertbeheben:

kurze Verbindungsabbrüche bei bestimmten Clients könnte ev. auch durch eine  der folgenden beiden Einstellungen behoben werden:

Interface Configuration / Advanced Settings:

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.