Does Roaming Assistant Not Work Anymore ?

[ComputerSteve]

I have a GT-AX11000 Pro on Merlin firmware 3006.102.4 and I’m noticing that changing the values to any value for roaming assistant seem to do nothing. I don’t see anything in the logs. In older firmwares I would see mention of the service but I never see it at all mentioned and none of my devices roam. I was reading online that the new WiFi drivers killed roaming assistant.. is this true ? That apparently it’s only working correctly on certain dual band models?

 

[Tech9]

It wasn't working reliably with some 3004 firmware versions as well.

 

[ComputerSteve]

Ok so is it working or not ? meaning because there is really no official word on that.. Meaning if you look it up it doesn't say that it isn't working. It says it's still a feature and that it works. I had to like dig for this information.

 

[bennor]

@ComputerSteve, what other AP's, wireless repeaters or AiMesh nodes do you have on your local network in addition to the GT-AX11000 Pro running Asus-Merlin 3006.102.4?

[Wireless Router] How to enable the Roaming Assistant? | Official Support | ASUS Global

Roaming Assistant feature:
In network configurations which involve multiple Access Points (AP) or wireless repeaters, clients with wireless devices sometimes cannot automatically connect to the best available AP because their device is still connecting to the main wireless router. Enable the Roaming Assistant feature so the client's device will automatically disconnect from the main wireless router if the signal strength is under specific threshold and it will connect to a stronger signal.

 

[ComputerSteve]

@ComputerSteve, what other AP's, wireless repeaters or AiMesh nodes do you have on your local network in addition to the GT-AX11000 Pro running Asus-Merlin 3006.102.4?

[Wireless Router] How to enable the Roaming Assistant? | Official Support | ASUS Global

I have tried with XT9's and XT8's with the GT-AX11000 Pro as the main router.. It never seems to work. Meaning I never see anything mentioned in the logs about roaming assistant at all.

 

[bennor]

I have tried with XT9's and XT8's with the GT-AX11000 Pro as the main router.. It never seems to work. Meaning I never see anything mentioned in the logs about roaming assistant at all.

Usually Roaming Assistant entries shows up in the logs as roamast. On a RT-AX86U Pro that defaulted to having Roaming Assistant enabled. No AP, AiMesh or Wireless Extenders on the local network the following is indicated, from time to time, in the system log.

Jun 26 17:25:41 roamast: ROAMING Start...

A wild guess but it is also possible the WiFi client itself is refusing to obey the router's Roaming Assistant settings and forcing itself to remain connected to the main router. Or perhaps the wireless clients are not reaching the threshold to trigger Roaming Assistant.

 

[ComputerSteve]

Usually Roaming Assistant entries shows up in the logs as roamast. On a RT-AX86U Pro that defaulted to having Roaming Assistant enabled. No AP, AiMesh or Wireless Extenders on the local network the following is indicated, from time to time, in the system log.

Jun 26 17:25:41 roamast: ROAMING Start...

A wild guess but it is also possible the WiFi client itself is refusing to obey the router's Roaming Assistant settings and forcing itself to remain connected to the main router. Or perhaps the wireless clients are not reaching the threshold to trigger Roaming Assistant.

Thats what I'm saying: I have not seen any roamast in the logs with the most current firmware ::: I have two setups // 1 setup is a GT-AX11000 on firmware 3004.388.9_2 with XT8 nodes and another is a GT-AX11000 Pro on firmware 3006.102.4 with XT8 Nodes but I tried XT9 nodes as well as EBM68's with the same result !

 

[bennor]

Thats what I'm saying: I have not seen any roamast in the logs with the most current firmware ::: I have two setups // 1 setup is a GT-AX11000 on firmware 3004.388.9_2 with XT8 nodes and another is a GT-AX11000 Pro on firmware 3006.102.4 with XT8 Nodes but I tried XT9 nodes as well as EBM68's with the same result !

Out of curiosity do you have Smart Connect enabled or disabled on the main router? Wonder if that plays a role when enabled. WiFi client might be jumping to the other main router band rather than jumping to the node, AP or WiFi extender (or maybe not and has nothing to do with the issue).

 

[ComputerSteve]

Out of curiosity do you have Smart Connect enabled or disabled on the main router? Wonder if that plays a role when enabled. WiFi client might be jumping to the other main router band rather than jumping to the node, AP or WiFi extender (or maybe not and has nothing to do with the issue).

I tried both ways ! It didn’t change anything.

 

[Tech9]

A wild guess but it is also possible the WiFi client itself is refusing to obey the router's Roaming Assistant settings

The wireless log will have disconnection and re-connection messages in this case. I have tested AiMesh some time ago on different firmware versions and router models (3004.386/388) and also found Roaming Assistant not working quite often. Perhaps wireless drivers used in firmware related issue. And I test with Asuswrt only so it's not Asuswrt-Merlin related issue. As usual - wait for update and hope for the best.

 

[ComputerSteve]

Right but I have not noticed it not working for a few updates... I mean thats like major functionality. @RMerlin is there any updates to this meaning is it not working on certain firmwares cause of drivers ? or is it supposed to be working ? It basically means theres now no roaming when using Aimesh just the roaming that the device decides to do.

 

[Tech9]

Switching to another AP is a client decision always, actually. Multi-AP system can only help making the decision by using 802.11k/v/r, Minimum RSSI, Tx Power adjustment, etc. when the client supports the additional roaming assist features.

 

[ComputerSteve]

Ok but Roaming assistant is supposed to help correct ?

 

[Tech9]

In theory - Yes. It's what Asus calls the Minimum RSSI. The biggest issue with AiMesh is in inability to control individual node Tx Power and by default Asus routers come with Performance setting or "shout as loud as you can". Last time I checked adjusting Tx Power on the main router doesn't change anything on the nodes.

 

[ComputerSteve]

I've been using chatGPT to explore roaming assistant & amas a bit more:: The issue is that for some reason roaming assistant isn't sending Macs or sticky clients a forced disconnect when they don't listen to the BSS request. See I was under the assumption that roaming assistant was just a basic kicker when hit a certain RSSI. It's actually not. I don't know why theres no way to force BSS Transition with disassoc_imminent=1 (which AiMesh doesn’t always set)I was able to find toggles that do change its behavior such as :

• RAST (Roaming Assistant) NVRAM Toggles​

  These control ASUS’s Roaming Assistant (roamast):
  

  Core Behavior & Modes​

  • rast_mode – Global mode selector (0=off, 1=legacy, 4=smart/static)
  • wl0_rast_mode, wl1_rast_mode, wl2_rast_mode, wl_rast_mode – Per-band RAST mode toggles
  • rast_adv_init – “Advanced initialization” toggle (controls how RAST initializes station lists)

  🎛 Sensitivity & Triggers​

  • rast_sens_level – Global sensitivity (0=relaxed, 2=most aggressive)
  • wl0_rast_sens_level, wl1_rast_sens_level, wl2_rast_sens_level, wl_rast_sens_level – Per-band sensitivity
  • rast_weak_rssi_diff – How far below RSSI threshold before a “weak hit” counts
  • rast_video_rssi – Special RSSI threshold for streaming/video clients

  Client List / ACL​

  • rast_aclist_timeout – How long MACs stay in the ACL/block list
  • rast_static_cli_enable – Enables static client list logic (1 = smart mode, 0 = legacy)
  • rast_static_client, wl*_rast_static_client – Per-band static client MAC lists

  Debugging​

  • rast_dbg – Enables RAST debug logs
  • wl0_rast_dbg, wl1_rast_dbg, wl2_rast_dbg – Per-band debug
  • rast_force_syslog – Forces logs to syslog
  • rast_syslog – General syslog verbosity toggle
  • Other Hooks: rast_add_to_maclist, rast_add_static_client – Internal use (list handling) : rast_send_beacon_request – Fires 802.11k beacon requests (internal call)
  
  AMAS (AiMesh) NVRAM Toggles
  These control the AiMesh orchestration service:
  Core Control
  • amas_force – Forces AiMesh logic to stay fully active
  • amas_support – Bitmask for what AMAS features are enabled
  • amascli_dbg – AMAS CLI debug logging toggle (0=off, 1=on)
  
  RSSI & Cost
  • amas_cap_2g_rssi_th, amas_cap_5g_rssi_th, amas_cap_6g_rssi_th – CAP-level RSSI thresholds for nodes/clients
  • amas_costmode – How AMAS weighs RSSI, backhaul, link rate for decisions
  • amas_rssiscoremode – RSSI scoring mode (how RSSI converts into “score”)
  • amas_re_rssiscore – RSSI score baseline value
  
  Backhaul & Band Control
  • amas_wifi_bhmode – Wi-Fi backhaul mode
  • amas_eth_bhmode – Ethernet backhaul mode
  • amas_ethernet – Ethernet port control bitmask
  • amas_ethif_type – Ethernet port type
  • amas_ifname, amas_ifname_br – Interface names for AMAS
  
  Per-Band Controls (for each wlc0, wlc1, wlc2)
  • amas_wlc*_band – Band index (2.4/5/6 GHz)
  • amas_wlc*_priority, amas_wlc*_priority_ongoing – Steering/backhaul priority
  • amas_wlc*_optmz – Self-optimization toggle
  • amas_wlc*_optmz_rssi_threshold – RSSI threshold for optimization
  • amas_wlc*_optmz_tigger_count – Number of weak RSSI hits before optimization triggers
  • amas_wlc*_keep_connecting – Keep retrying connection even if weak
  • amas_wlc*_cost, amas_wlc*_cost_result, amas_wlc*_papcost – Cost metrics for band decisions
  • amas_wlc*_target_bssid – BSSID target for steering
  • amas_wlc*_target_same_ap – Tracks whether steering target is the same AP
  • amas_wlc*_rssi – Last RSSI recorded
  • amas_wlc*_rssiscore – Last RSSI score computed
  • amas_wlc*_state, amas_wlc*_state_fail – Connection state & error state
  • amas_wlc*_unit – Unit index (0,1,2)
  • amas_wlc*_use – Whether this band is active for AiMesh
  
  Global Action / State
  • amas_wlc_action – Current global AiMesh action (e.g., START_SELF_OPTIMIZATION)
  • amas_wlc_action_band – Which band the action is running on
  • amas_wlc_action_state, amas_wlc_action_ongoing – Tracks state of the action
  • amas_wlc_active, amas_wlc_active_ongoing – Which bands are actively engaged
  • amas_wlc_request_lock – Prevents overlapping actions
  
  🖧 Ethernet-Specific
  • amas_eth0_* – (cost, linkrate, state, etc.)
  • amas_eth0_state_fail – Error tracking for eth0
  
  Misc / Service Readiness
  • amas_bdl, amas_bdlkey, amas_bdl_wanstate – Boot loader handshake keys for AiMesh
  • amas_bhctrl_service_ready, amas_misc_service_ready, amas_lanctrl_service_ready, amas_ssd_service_ready, amas_wlcconnect_service_ready – Service readiness flags for AMAS daemons
  • amas_status_init, amas_status_service_ready – AMAS global init flags
  
  What’s Missing or “Hidden”
  • Variables like amas_wlc*_optmz_rssi_threshold and amas_wlc*_optmz_tigger_count don’t always show in nvram show unless you create them — but they are in /sbin/roamast and can be set manually.
  • RAST also has under-the-hood toggles like rast_video_rssi and rast_adv_init that don’t appear by default & also can be set manually.

 

[Tech9]

I was able to find toggles that do change its behavior

Any positive results?

 

[ComputerSteve]

Any positive results?

I mean I’m not sure. I made a change and it did work but only on my main router. Then, stupidly I made a different change, and then I kind of lost track. I’m not very familiar with this. Editing all the variables is scary stuff lol. I was nervous to do too much and mess up my whole network. It would be great if someone could look at these variables, and explain them or even say if any of them will help to fix this sticky client issue. Or provide some insight.

 

[Tech9]

What you are fighting with is practically unsolvable on this hardware and software. Here is simple explanation what happens: The AP barely hears a distant client at -80dBm, this client has 14mW radio; The client still hears the AP loud and clear though, way above it's own cut-off threshold, the AP has >400mW radio. What you need is balancing the links between the AP and the client, both have to see each other at -80dBm. Only then the client will switch to suggested better signal AP. If you cut this client off the AP forcefully it will most likely attempt to re-connect to the same AP again. I know what fixes the sticky client situation, but you have to call me before your next upgrade. AiMesh was designed for convenience. It doesn't scale well.

 

[ComputerSteve]

What you are fighting with is practically unsolvable on this hardware and software. Here is simple explanation what happens: The AP barely hears a distant client at -80dBm, this client has 14mW radio; The client still hears the AP loud and clear though, way above it's own cut-off threshold, the AP has >400mW radio. What you need is balancing the links between the AP and the client, both have to see each other at -80dBm. Only then the client will switch to suggested better signal AP. If you cut this client off the AP forcefully it will most likely attempt to re-connect to the same AP again. I know what fixes the sticky client situation, but you have to call me before your next upgrade. AiMesh was designed for convenience. It doesn't scale well.

Yeah but whats so weird is it works perfect with iOS meaning with iOS I see my device moving between all the nodes --- It has something to do with Macs hardcoded roaming logic:::

How macOS Handles Roaming: ​

• macOS relies on the device’s Wi‑Fi chipset/driver logic (Broadcom/Apple Silicon radios) for deciding when to leave one AP and connect to another.
• The OS does not expose a tunable RSSI threshold for roaming like some enterprise clients (e.g., Intel’s Roaming Aggressiveness on Windows).
• Instead, roaming is based on a mix of signal quality, retry/failure rates, and 802.11k/v support. macOS heavily prefers staying associated (“sticky”) unless a new AP offers a clear improvement.

---

Observed RSSI “Hard” Behaviors​

• Field testing and enterprise documentation suggest:
  
  • Macs almost never roam above –65 dBm unless explicitly disassociated by the AP (via deauth or 802.11v BSS Transition Request).
  • Many admins report Macs tend to “cling” to APs until RSSI falls to ~–75 dBm or worse, and only then begin scanning for a better AP.
  • If 802.11v BSS Transition Management (BSS‑TM) is supported by the AP (e.g., ASUS, Cisco, Aruba), the Mac will honor the request if:
    
    • The disassoc_imminent flag is set.
    • The suggested target AP is in the same SSID and offers better signal.

---

🏗 Why People Call It ‘Hard‑Coded’​

• There’s no user‑accessible setting in macOS to change roaming aggressiveness.
• The “sticky until –75 dBm” behavior appears consistent across versions of macOS and hardware (Intel and Apple Silicon), implying a built‑in threshold deep in the driver/firmware.
• Apple provides no MDM profile, plist tweak, or CLI command to adjust it.

Ways Admins Work Around It​

• 802.11v/k: Use BSS Transition Requests (with disassoc_imminent=1) to nudge Macs to the preferred AP. (This is what your SmartRoam scripts do.)
• Coverage design: Enterprise Wi‑Fi designers sometimes deliberately tune AP power or disable lower data rates (like 2 Mbps) to force roaming sooner.
• Deauth tricks: Some admins rely on APs sending polite deauths when RSSI drops below a threshold, essentially forcing a Mac to roam.

 

[sfx2000]

How macOS Handles Roaming

You realize that Apple has billions of samples across the same amount of networks and they have total control over their wifi stack across multiple platforms over the past 15 years...

They're likely right with thresholds...