Aimesh Sticky Client Issue

[ComputerSteve]

I have had so many problems with AiMesh not reliably being able to kick my Mac even with roam assistant enabled and the setting changed to a drastically low number. I read about this and apparently it’s a known issue something that has to do with sticky clients. Does anyone have any suggestions on how to fix this problem. Do any Merlin compatible routers actually roam properly. Right now I have a GT-Ax11000 pro main router and 4 XT8 Nodes and the Mac will never roam. This also happened when I had the RT-AX88U and RT-AX86U node combination. I can forcefully make it roam by disconnecting the client and then re-enabling it but it doesn’t do it automatically. I also found that if there was a way to make AiMesh use this type of BSS request
disassoc_imminent = 1 instead of what it currently does of = 0 it would work. However without scripts and using HostAPD it’s not possible.

 

[Tech9]

If your client never roams - it sees good signal from single AP. You have too much Wi-Fi. I don't know where do you live, but in US/CA region your routers blast close to 5000mW on single channel. I have 4x APs on 400mW total in >6000sqft house in CA region.

 

[ComputerSteve]

If your client never roams - it sees good signal from single AP. You have too much Wi-Fi. I don't know where do you live, but in US/CA region your routers blast close to 5000mW on single channel. I have 4x APs on 400mW total in >6000sqft house in CA region.

I understand that concept. That isn’t what I’m talking about! I’m talking about even if I remove all my nodes, and just keep my main router with 1 node. My Mac will stay connected to the main router till it’s basically an unusable signal, and never choose to roam. I thought AiMesh is supposed to handle this? I’ve watched all the marketing. I’ve seen it talk about this seamless roaming thing. this is not what is happening. Instead my Mac will stay stuck. I’m asking are there any fixes for that. I can fix it with scripting.. however I don’t know why this isn’t being addressed. It’s not making this system as efficient as it should be.

 

[Tech9]

I thought AiMesh is supposed to handle this?

No, roaming is client's decision. The APs can only encourage roaming using different techniques, but AiMesh has limited options. If your APs are spaced at around -70dBm signal, the APs and clients support 802.11k/v/r, the roaming assistant is actually working, etc. - your client will roam. This document may give clues what may be wrong:

Wi-Fi roaming support in Apple devices

Supported Apple devices and Cisco networks recognize each other, allowing the devices and network to use the latest Wi-Fi technologies to optimize the experience.

support.apple.com

Check support forums for tips about possible client settings modification. It will be hardware specific.

 

[ComputerSteve]

You’re absolutely right that roaming is client-driven, but ASUS AiMesh doesn’t hold up to its own marketing. They advertise seamless roaming, yet in reality, Roaming Assistant often doesn’t work as intended—it’s passive, triggers too late, and in many cases doesn’t even kick the client when it drops below the configured RSSI threshold.
This is especially obvious with MacBooks and iOS devices, which are notorious for sticking to distant or the wrong nodes. ASUS users have reported this for years, and it’s not just “client behavior”—because these same devices roam just fine on systems like Eero, UniFi, Deco, and even Google Nest.
The real issue seems to be how ASUS handles roaming internally:

• No real-time steering logic.
• Weak or inconsistent 802.11k/v implementation.
• No proper BSS transition enforcement.
• Poor node load awareness.

So while yes, clients decide when to roam, ASUS gives them very little help, unlike other mesh systems that actually encourage or even push the client to move. The sticky client issue isn’t universal—it’s an ASUS problem. If AiMesh wants to be taken seriously, it needs smarter logic, better enforcement of roaming standards, and more transparency about what it’s really doing under the hood. I am hoping that in future firmware updates these problems will be addressed.

 

[Tech9]

So while yes, clients decide when to roam, ASUS gives them very little help, unlike other mesh systems that actually encourage or even push the client to move.

Agree and my own observations are similar. Lack of individual APs Tx power control in AiMesh is enough to cause severe roaming issues. When playing with AiMesh I also found Roaming Assistant non-working on different firmware versions or it disconnects the clients and they re-connect to the same weak AP. Perhaps different hardware with different drivers and home AIO devices mainly designed to work as single AP holding all clients until the signal dies completely is causing this behaviour. AiMesh is like a patch software on top of what Broadcom is doing on driver level. Qualcomm based Eero, Nest, Deco, etc. have mesh features built-in and supported by the chip manufacturer. Some newer models do environment assessment and auto-tune the system for optimal roaming.

The reason I don't recommend Asus with AiMesh when Ethernet is available and multi-AP system is needed (Unifi, Omada) or when the user requirements are "easy button" installation with minimum play with settings to make things work (Eero, Deco, Nest).

 

[hancox]

You’re absolutely right that roaming is client-driven, but ASUS AiMesh doesn’t hold up to its own marketing. They advertise seamless roaming, yet in reality, Roaming Assistant often doesn’t work as intended—it’s passive, triggers too late, and in many cases doesn’t even kick the client when it drops below the configured RSSI threshold.
This is especially obvious with MacBooks and iOS devices, which are notorious for sticking to distant or the wrong nodes. ASUS users have reported this for years, and it’s not just “client behavior”—because these same devices roam just fine on systems like Eero, UniFi, Deco, and even Google Nest.
The real issue seems to be how ASUS handles roaming internally:

• No real-time steering logic.
• Weak or inconsistent 802.11k/v implementation.
• No proper BSS transition enforcement.
• Poor node load awareness.

So while yes, clients decide when to roam, ASUS gives them very little help, unlike other mesh systems that actually encourage or even push the client to move. The sticky client issue isn’t universal—it’s an ASUS problem. If AiMesh wants to be taken seriously, it needs smarter logic, better enforcement of roaming standards, and more transparency about what it’s really doing under the hood. I am hoping that in future firmware updates these problems will be addressed.

I have found outright disabling roaming assistant makes overall roaming better. YMMV. (2 nodes in a rectangular house)

 

[Tech9]

Yes, because your 2x APs are far enough and the clients have 2x choices only.

With 5x APs AiMesh - good luck. @ComputerSteve network must be covering open space football field or a home with double layer metal mesh in the walls. I still believe too much Wi-Fi is the issue. This client with up to 40mW radio has no idea where to connect with >4W available Wi-Fi around. Very strong near AP is not the best choice for the client. Even with my UniFi system if I stay just next to one of the APs with signal level -20dBm or stronger the client in my hands will try to connect to further located AP first.

 

[mswlogo]

I have had so many problems with AiMesh not reliably being able to kick my Mac even with roam assistant enabled and the setting changed to a drastically low number. I read about this and apparently it’s a known issue something that has to do with sticky clients. Does anyone have any suggestions on how to fix this problem. Do any Merlin compatible routers actually roam properly. Right now I have a GT-Ax11000 pro main router and 4 XT8 Nodes and the Mac will never roam. This also happened when I had the RT-AX88U and RT-AX86U node combination. I can forcefully make it roam by disconnecting the client and then re-enabling it but it doesn’t do it automatically. I also found that if there was a way to make AiMesh use this type of BSS request
disassoc_imminent = 1 instead of what it currently does of = 0 it would work. However without scripts and using HostAPD it’s not possible.

This is EXACTLY what I was running into as well

I found a crude work around (but it requires hardwired backhaul) See my post

Fixed - Very poorly balanced RT-AX88U AiMesh running Merlin (w/ hardwired backhaul)

TL;DR - The power up sequence of ASUS AiMesh is what F*k's things up My setup & Issue: I run with a hardwired Backhaul (this is required for the work around unfortunately) I have about 50 clients with two AX88U's running Merlin I do run with split SSID's (2.4Ghz and 5.0Ghz) All the problems...

www.snbforums.com

If you can't run hardwired, you could play with binding, but I didn't have much luck with that. Clients would still end up on the wrong nodes and it would complain it's not on the correct binding

 

[mswlogo]

I have found outright disabling roaming assistant makes overall roaming better. YMMV. (2 nodes in a rectangular house)

I knew that roaming assistant was junk when I saw it. The optimum threshold would need to be per client to have any chance or working, which would of course be impractical.

All ASUS needs is a time based roaming (similar to DHCP expiring). But you don't really want it roaming at anytime of day. So you'd want a specified time window of when to roam and not use a signal strength based threshold.

 

[ComputerSteve]

Yes and all you get on this forum is you have to many nodes ! Meanwhile that isn't the point... The point is the device isn't connecting to the closet node and roaming assistant doesn't work !

 

[degrub]

Don't forget that client devices determine which radio they will connect to and when they will leave it. Anything done on the AP/wifi router/AiMesh node is only to attempt to encourage the client device to attach elsewhere. Period. Sometimes, that is not successful.

 

[mswlogo]

Yes and all you get on this forum is you have to many nodes ! Meanwhile that isn't the point... The point is the device isn't connecting to the closet node and roaming assistant doesn't work !

Exactly

What I think folks are confusing is Offices vs Homes

In an office environment its a very different problem

You would want to strategically place Nodes (probably AP nodes) throughout the building and set the power on each accordingly (with just a little overlap) or you'd have a mess.
In office it's 99% smarter devices, phones and computers, so they will roam fine.
You also rarely "reboot" the building or network, then want to be able to partial reboots and avoid reboots.
And all an Office typically cares about is within the bounds of the building

In a home

You have a ton of really dumb devices, that don't roam well.
We also want to go well beyond the bounds of the house, to hit the garage and the yard etc.
I'm not putting AP's in the garage (because it can reach -20F)
I'm not putting power out in the middle of the yard
You also have neighbor contentions to deal with (4 AP on lower power and not conflict with Neighbors channels, Fk that)

So I (we) need to "shot gun it". But we'd still like things within the home to be fairly optimally connected too, if possible

So I run a Mesh with two nodes at full power at two ends of the house. And for the most part, that works absolutely fine

If some folks want to treat their home like an office, go for it. But you end up with a different set of "work" to do
Shot gun is way less work for me

 

[mswlogo]

Don't forget that client devices determine which radio they will connect to and when they will leave it. Anything done on the AP/wifi router/AiMesh node is only to attempt to encourage the client device to attach elsewhere. Period. Sometimes, that is not successful.

Problem is, the environment is changing as it comes up and confuses the dumb little things.
AP/wifi router/AiMesh can force it to roam, by disconnecting it, that's what the dumb roam assist does, but its implementation is brain dead
There are many ways they could implement a smarter roam assistant.

 

[degrub]

The levels of "good enough" vary quite a bit. ASUS is only trying to meet the most common denominator and sell boxes. Throw enough mud on the wall and you can have a decent plaster to paint whatever colour suits.

 

[mswlogo]

The levels of "good enough" vary quite a bit. ASUS is only trying to meet the most common denominator and sell boxes. Throw enough mud on the wall and you can have a decent plaster to paint whatever colour suits.

And beat the competition too. I don't know what other consumer network gear does in this regard. But ASUS has generally worked well for me for well over a decade.

I might look at UniFi next time around but it takes a lot of time to learn all the quirks of anything. Friend runs UniFi, he got a new Tesla and it refused to connect, so he had to replace all his UniFi !!! Probably could have been fixed, but he was itching for new hardware any way.

I'll run AX88U's until firmware updates stop.

 

[penguin22]

I had sticky clients using a BE88U main router with BE86U and BE82U wired backhaul AiMesh nodes. I did a few things yesterday that completely resolved for me, though the stickiness was really only an issue with all clients on the 39099 GPL.

First, if you don't have any clients requiring it, disable 11b support, then enable Roaming Assistant on both 2.4GHz and 5GHz bands. Finally, leave 2.4GHz to -70 or even consider raising to -72 since that is your 'range' band, so can stay a bit stickier, then adjust 5GHz to something along the lines of -65, which will allow clients to drive roaming based on stronger 5GHz signal availability of each node.

In doing the above, while using MLO and WiFi 7 on the main SSID, and neither of these for IoT or Guest networks, my desired clients, phones, laptops, devices that move, have been roaming perfectly and the expected balance I was seeing in prior GPL versions has stayed, while also now having IoT devices stick with the correct router/node without constant disconnects.

The BE88U is the main router closest to most devices, the BE86U is the far side of a ranch house and the BE82U is on the second floor centrally located between the two. This split is exactly what I expect to see, so hopefully these setting work ok. It's notable that I leave SmartConnect enabled for SSID and band simplicity and keep settings at the default.

 

[jksmurf]

Yes and all you get on this forum is you have to many nodes ! Meanwhile that isn't the point... The point is the device isn't connecting to the closet node and roaming assistant doesn't work !

@ComputerSteve Whilst it may have been stated in jest, I don’t think that comment is very fair. The bulk of posters who have responded to your threads e.g. this one have genuinely attempted to assist, whether that has produced the desired result does not detract from that.