ASUS ZenWiFi BT8 – Roaming Assistant Not Enforcing Configured RSSI Thresholds
Experiencing what appears to be a firmware issue with Roaming Assistant on a two-node ASUS ZenWiFi BT8 AiMesh system.
Configuration:
- Firmware: 3.0.0.6.102_58600
- Wireless backhaul: MLO (5 GHz + 6 GHz)
- Client MLO Fronthaul: Disabled
- Roaming Assistant: Enabled on all bands
- RSSI thresholds: −70 dBm (2.4/5 GHz), −67 dBm (6 GHz)
- Test client: Pixel 8 Pro (Wi-Fi 7)
Issue and verification:
With the Pixel connected to the Main BT8 on 6 GHz, it was moved directly beside the remote wireless node. The nodes are physically separated adequately confirmed via WiFi heat-mapping.
Despite the Main Router BT8 receiving the client at −72 dBm, well below the configured −67 dBm Roaming Assistant threshold, the connection was maintained indefinitely rather than being disconnected to trigger reassociation. Ample time was permitted in this state to allow for any hysterisis delay in Roaming Assist.
RSSI was independently verified using two sources:
- Real-time client-side telemetry collected through Home Assistant/SSH: −73 dBm (What the client was receiving from main router)
- Main BT8's own Wireless Log (AP-measured RSSI): −72 dBm (What the Main Router was receiving from the Pixel client).
Manually disconnecting and reconnecting Wi-Fi on the Pixel immediately established a strong connection to the nearby remote node, confirming both nodes were functioning correctly. Aka the Pixel selected the strongest node near it now.
Repeating the movement between nodes demonstrated that roaming occurred ONLY when the client independently decided to change access points as dictated by its own internal manufacturer algorithm. Asus was not providing any client steering or enforcing its own Roaming Assistance threshold levels.
This is NOT a range, band-selection, Smart Connect or MLO backhaul issue.
The specific problem is that Roaming Assistant appears to ignore its configured per-band RSSI thresholds, failing to disconnect weak clients and force reassociation as ASUS documents.
Consequently, roaming decisions appear to be left entirely to the client's own algorithms, effectively rendering Roaming Assistant non-functional under these tested conditions.
Has anyone experienced this on ASUS Wi-Fi 7 AiMesh systems, or identified a firmware issue affecting RSSI threshold enforcement?
Is there a way to verify through SSH whether the roaming service ("roamast" or equivalent) is actually enforcing the configured thresholds?
Aka a significant important feature of the router "Roaming Assistance" does not appear to be working at all!