Client Steering | Usteer: high latency and timeouts

A fast and stable WLAN is indispensable these days. Many users want to optimize their networks to achieve the best performance. One approach is to use a client steering daemon on OpenWrt. This is intended to make network communication more efficient and make better use of access points. But how effective are these adjustments really? This article describes the challenges and observations made when configuring such a setup and whether the results justify the effort.

For a long time, I wanted to refine my OpenWrt setup with a Client Steering Deamon and used the official documentation as a guide.

Documentation and interpretation

First a look at the OpenWrt documentation and my original settings derived from it:

According to the documentation: "For AP steering to take effect, signal_diff_threshold needs to be set to a value greater than 0."
(For AP steering to take effect, signal_diff_threshold needs to be set to a value greater than 0)
As an example, I have tried the value 15 for signal diff threshold, which is also used by others in various forums.
According to the documentation: "band_steering_threshold only takes effect if load_balancing_threshold is also set to a value greater than 0."
band_steering_threshold does not take effect unless load_balancing_threshold is also set to a value greater than 0.
I tried the two settings as follows:
Finally, "roam_scan_snr" According to the documentation, a value must be set for this in order to trigger client scans for roaming.
roam_scan_snr needs to be set to trigger client scans for roaming.
If roam_scan_snr is unset and roam_trigger_snr is set, then roam_scan_snr will take the value of roam_trigger_snr.
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, I would have accepted this, but I don't think it has to be ...

With or without the settings: I couldn't notice any difference in the behavior of the WiFi devices, except that something causes increased latency for certain devices from time to time:

High latency and timeouts

Some Windows clients sometimes had a subterranean response time with my last settings and timeouts were the order of the day after a while:

As an example, Windows 10 and the following USB WiFi stick:

on amazon.com:

TP-LINK Nano Card...

Product prices and availability cannot currently be accessed from Amazon. Check on Amazon.com

Cause?

After some testing and gradually removing and adding all possible WiFi settings and Usteer settings, I was able to isolate the phenomenon somewhat: Certain clients on my network, specifically Windows clients, respond to the following option with delays and timeouts:
Roam scan SNR: -60

BEACON samples are noted in the log after activating Roam scan SNR:

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

There tends to be a possible temporal relationship between the beacon status information and the WLAN delays.

Now and again, 802.11v causes a slight delay for the affected clients even without roam_scan_snr:

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

I was able to eliminate this by deactivating 802.11v:

Usteer, you're not actually missing anything!

Without changing the rest of the WLAN settings, it was enough to stop / deactivate the Deamon under "Software" / "Startup":

And lo and behold: the affected Windows computers immediately, consistently and sustainably have a decent response time again for me:

further troubleshooting

In the meantime, a client was constantly reconnecting to the WLAN. In the event log:

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

The cause could be an incorrect Mobility Domain setting. At least I was able to solve the problem by deleting the mobility domain, i.e. with the default value:

Short connection interruptions with certain clients could possibly also be remedied by one of the following two settings:

Interface Configuration / Advanced Settings:

Sources

Conclusion

With 802.11r/k and optionally v, the clients should be able to make the right decisions on their own. If Usteer is activated without additional parameters, the steering deamon does not actively intervene in the behavior of the clients. Even the parameters described above do not improve the behavior in practice, at least not noticeably, and: one wrong setting and Usteer does more harm than good. All in all, Usteer has only cost me time and nerves: Without Usteer, the WLAN usually works just as well or possibly even better. So if in doubt, just try it without usteer: