Reply
Posts: 11
Registered: ‎02-23-2017

Clients not switching nodes when roaming

I have a 3 node setup with a wired backhaul (everything works great). When I connect to a close node with an RSSI of about -32 I can also see the farthest node with a strength of -71 (both upper 5ghz bands, using OSX built in wireless diagnostics to test). I walk with the laptop to the farthest node (75'ish feet) but I stay connected to the same node so my RSSI drops from -32 to -71. While the connection is still 'ok', my speedtest.net downloads have a very large delta (70mbs vs 200+mbs). The only way I can connect to the close node is to turn off and on the wifi. Isnt the idea of Mesh is to connect to the strongest node? 

 

Please advise. 

Thx!

Expert
Posts: 13,306
Registered: ‎01-18-2013

Re: Clients not switching nodes when roaming

Yes but it could switch between the 2.4Ghz and 5Ghz depending on range. There is a large difference in throughput between them by nature.


Smiley Wink Please remember to Kudo those that help you.

Linksys
Communities Technical Support
Posts: 11
Registered: ‎02-23-2017

Re: Clients not switching nodes when roaming

I checked and they are all on 5ghz (using a mac with an AC connection and reran the experiment). I could diable or rename the 2.4Ghz via the web interface but the wireless tools show I am sticking on the 5Ghz thats far away and its not switching to the close one.

 

I will experiment tomorrow to see how poor the RSSI needs to get to for it to move me to the closer node.

Posts: 11
Registered: ‎02-23-2017

Re: Clients not switching nodes when roaming

OK. It seems I can roam until the RSSI hits -89 or below (horrible signal) before the node will kick me off to another node. I beleive the node is sending de-authentication packets or my client to force it look for something better either (which I presume is what is supposed to happen with this setup). In my much older wireless setup I used to be able to adjust the minimum RSSI on the AP to force the client to find a better connection. 

 

So - Couple of questions to this great community:

 

1 - Has anyone else tested to see if they are actually bouncing between the nodes when they move through their houses (e.g. the whole idea of this setup)? 

 

2 - Has there been any discussion about being able to modify the min RSSI for this setup (obv through an advanced or the 'secret web gui)?

 

Thanks!

 

 

Posts: 234
Registered: ‎01-07-2012

Re: Clients not switching nodes when roaming

[ Edited ]

I think a lot of the 802.11/k/v/r roaming features are dependent on the client. I havent seen any 'min RSSI' value in the Velop configs (incl. the web back end or sysinfo.cgi) so my presumption is that its entirely down to the client to control roaming.

As an example, here's how Apple IOS devices decide when the link isn't good enough according to apple
https://support.apple.com/en-us/HT203068

And here's how Cisco describe the same process (they indicate the threshold is around -70dbm)
http://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/8-0/iPhone_roam/b_iPhone-roaming....

 

Like you, my laptop devices (with a higher power radio) tend to hang onto the connection longer.   This is a good reason why in the Velop setup it would be ideal for an option to tune either the minRSSI value or the radio power - ideally it would do it automatically based on the wifi debug/local signal scan it can see.  Especially as the 2.4Ghz must extensively overlap in most locations, whereas the 5Ghz is a pretty short proximity.

Posts: 11
Registered: ‎02-23-2017

Re: Clients not switching nodes when roaming

Yes - Thanks for this info and this is also how I understand a client should work in a standard wifi network.

 

The mesh capabilitiy i am looking for is called client steering. I understand it does band sterring but was also hoping it would enable client steering. Having a mesh solution that keeps you at one bar when you have a node right beside you isnt really mesh and doesnt buy anything more than having multiple separate wifi systems on the the SSID. 

 

So I guess my question comes down to if the Velop supports client steering?

 

Thanks again!

Jameel

Posts: 234
Registered: ‎01-07-2012

Re: Clients not switching nodes when roaming

A point of note - Velop does NOT currently support band-steering (its one of my post in the 'ideas forum').

Based on some testing by another member, I think the concensus is that it does some client steering based on how busy the nodes/radios are - but not based on signal strength or frequency.

@linksys team - please fee free to correct me if I'm misrepresenting the topology
Posts: 8
Registered: ‎09-30-2008

Re: Clients not switching nodes when roaming

This is a must have, or at a minimum it should be an advanced option that one can turn on.
Posts: 11
Registered: ‎02-23-2017

Re: Clients not switching nodes when roaming

Yeah, thats the hole case of a meshing solution. ubiquiti also has this feature and they are in the same price range.

Posts: 117
Registered: ‎01-17-2017

Re: Clients not switching nodes when roaming


Jameel wrote:

 

1 - Has anyone else tested to see if they are actually bouncing between the nodes when they move through their houses (e.g. the whole idea of this setup)? 

 


My iOS devices roam as expected, at about -70db.  I can walk through the house and see it switching from node to node.  However, I just tried the same thing with my MacBook Pro.  It's an older model (no AC wireless), but when connected to the 5ghz band (via N), I noticed that even with a signal of -78 or so, it was still sticking with that access point.  After a while, I tried actively using the connection (instead of just observing the signal), and at that point it did switch to a closer AP.  I read that actual data transfer taking place influences iOS devices to roam, so possibly OSX devices do this as well?  May have just been coincidence.

2 - Has there been any discussion about being able to modify the min RSSI for this setup (obv through an advanced or the 'secret web gui)?

 


I have not seen any such setting, nor have I read anything that indicates that the Velop de-auths clients.  From what I understand from reading the articles rburrows69 posted, and others, is that roaming is purely a client-based decision.  I've also read a bit about "client steering", but details of how this actually works are sparse.
Possibly related, I saw an article that described a technique to deal with sticky clients.  Instead of letting clients cling to weak (but usable) signals, the AP would actively kick them off if their RSSI fell below the specified minimum, which forces the client to look for a new AP.  Let's say you have a huge office building with dozens of APs.  Your main goal is to provide connectivity to users within the building, and your APs are placed carefully to fulfil this goal.  You know that at any point in the building, a client device should be able to get a signal of, say, -60 to a nearby AP.  So, perhaps you can then set a RSSI threshold of -64, and if any client falls below that, they are de-authed, which forces them to connect a closer AP.
If I'm understanding the way WiFi works, if a client device is connected to a network and is happy, the network itself has no way of knowing what that client's signal to other APs would be, because the client does not talk to any of them until it decides to roam.  De-authing clients that fall below a predetermined RSSI helps solve that problem, because this operates under the assumption that anywhere in the building there should be a stronger signal than whatever you set the minimum to be.
But does this translate well to a smaller residential mesh setup?  Here's my problem with this.  Yes, I want my devices to connect to the best available AP, but I also want to maintain connectivity when at the fringe areas of my setup's range, and it would seem that de-authing clients that fall below a certain RSSI, while indeed helping to encourage clients to roam, would be harmful to this goal.
Example.  With my current setup, I can go outside, and even if my signal is a bit worse than -70, it's still usable.  In this situation, there's no "better" AP that it could hypothetically connect to.  So if the network was set to kick off clients that fall below, say, -64, I would lose connectivity in that location.
Now, I do also vaguely recall reading about a similar technique that could possibly work better.  Rather than simply de-authing clients when they reach a specified RSSI threshold, the AP would temporarily "simulate" a worsened signal that would then prompt the client device to look for another AP.  So, in other words, if the signal approaches -64, the AP somehow tricks the client into thinking that the signal is actually -72 or so, and the client scans for other APs to join.  Presumably if it can't find a better one, it's allowed to remain connected to the current AP.