AiMesh clients not connecting to nodes with strongest signal

[Krusty]

I have a bunch of home automation clients on 2.4Ghz
I have AiMesh with AC-RT5300 and 2 x AC-RT68U nodes (all running 3.0.0.4.384_32799-gfe72567)

I have a bunch of clients (particularly LIFX bulbs, though I'm not yet convinced they are the problem) that are not connecting to the router/node with the strongest signal. Power cycling the bulbs does not help; they reconnect to the same router each time.

I have seen the bulbs migrate (sometimes over a long time) but others continue to sit on a weak connection indefinitely.

This could certainly be an issue with the bulbs maintaining some flash state about the MAC, so I tried finding out.

(Note I have roaming off, because that isn't super stable)... that said, I tried doing what I consider to be similar.

wl -i <ifc> mac <mac>
wl -i <ifc> macmode 1
wl -i <ifc> deauthenticate <mac>

On the node (via ssh login) on the node a device was connected to and it did kick the device off, but the device would not then connect to a different node. (I did verify that the wl settings do not obviously propagate around the network when done this way).

I say device because I tried it with an Auguest connect and a few other device bridges with the same affect (in addition to the LIFX bulbs)

So I'd sort of have to assume that the AiMesh router/nodes are refusing connections based on where AiMesh thinks the device should be connected, or at least that my naive wl attempts don't do what I think.

Anyways, does anyone have any insight on device connection etc in AiMesh (or just in non AiMesh with repeater).

P.S. I tried the deauthenticate withe code 8 with/without the mac filtering which seems to be what roamast does when it kicks a node off, but that didn't make any difference.

 

[drabisan]

And the question is?
Yes! Some clients are super uber stupid! They'll learn a bssid and unless they don't see that bssid, they won't be searching for a better connection.
Welcome to the world!
Wireless is not governed by APs, clients have a strong saying and there's no way around!
If the developer gives you the option to factory default, that's the only way.

I've seen this problem millions of times. Clients insisting on staying on 2.4 despite band steering insisting to move it on 5ghz, clients stuck to a certain AP unless that AP stops broadcasting beacons.
WiFi it's a pure democracy, everybody has a voice. Even the stupid ones.

 

[Krusty]

And the question is?
Yes! Some clients are super uber stupid! They'll learn a bssid and unless they don't see that bssid, they won't be searching for a better connection.
Welcome to the world!
Wireless is not governed by APs, clients have a strong saying and there's no way around!
If the developer gives you the option to factory default, that's the only way.

I've seen this problem millions of times. Clients insisting on staying on 2.4 despite band steering insisting to move it on 5ghz, clients stuck to a certain AP unless that AP stops broadcasting beacons.
WiFi it's a pure democracy, everybody has a voice. Even the stupid ones.

Agreed, but I do certainly see the clients successfully disconnect and then reconnect to another node if for example I turn off the 2.4Ghz wifi on the router node (via wl down)
Also the behavior seems consistent across multiple brands of devices (though thye could have similar wifi h/w)
A client kicked off during roaming may reconnect on a different node whereas a client kicked off via "wl deauthroize" does not (at least for me).
Several of these things indicate to me, that the AiMesh is doing something above and beyond just kicking clients off when their rssi is low.