What's new

Linksys Announces Velop Mesh Wi-Fi System

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

bizarre that it would randomly switch though as this would cause disconnections which doesnt make a lot of sense

Oddly enough that's the problem I'm trying to resolve with my NestCams. They are 5Ghz only devices and I think the smart wifi is trying to bandsteer them to either the 2Ghz or the other 5Ghz radio so they drop a couple of times a day. In fact on a fairly regular basis so I wouldn't be surprised if there is some kind of scheduled scan as well as the manual one.


Sent from my iPhone using Tapatalk
 
bizarre that it would randomly switch though as this would cause disconnections which doesnt make a lot of sense
I can't say for certain that it (the BSSID used for clients vs backhaul on the wireless remote note) changes on the fly... I know over the course of the past few weeks that I've seen connections on that node sometimes to the lower, and sometimes to the upper channels, but it might just select one on startup and stay with it indefinitely until the system is restarted again, at which time it might pick the same one or the other one for whatever reason.

I can say, however, that moving around the house during a WiFi call and watching the device switch bands and/or nodes, there's no perceptible interruption of connectivity, so that part is definitely working great for me.
 
my NestCams.

these seem to have issues with most of these mesh systems , i think its the nest cams and nest door bells that are the issue in that they have somehow not followed the right wifi standards and struggle with multiple ssid's with the same name
 
I think I understand correctly, but just to make sure. From the review: "So if you're happy with your current router's features and are just looking to improve your Wi-Fi, Velop can do it, but will separate devices connected to it from devices connected to your router."

I assume that devices connected through the Velop can access Plex (for example) which is wired to the broadband router the Velop is wired to? (I've ordered the Velop, can't wait to have WiFi coverage in my entire house.)
 
This is a huge plus for me... from what I understand from reading about some of the other systems (Eero comes to mind specifically, maybe Google as well?), if your internet connection goes down your whole WiFi network becomes inoperative (even for LAN stuff)?
This true for eero, not for Google WiFi
 
And as an added bonus, if you have a wireless remote node that has a better signal to the hardwired remote node than the main node, it will connect through the hardwired remote node (for much faster speed) rather than only connecting to the main unit.
That may or may not happen. All depends on how sticky the client is. Roaming also has nothing to do with a node''s back haul connection
 
seems to be a common issue with all these mesh and distro wifi units they just havnt thought about the end user and placement apart from a colored light
Google WiFi is a good example of how to do this right. You can run internet, backhaul and client connection diagnostics. Result's are given in qualitative terms (poor, good). But enough information is provided for a user to take action.

Backhaul management of multi-node Wi-Fi systems isn't easy, especially in dynamic environments. All consumer DWS are a work in progress and coming up the learning curve.

If you want to manually run a multi-AP system, then buy a bunch of APs and have at it. Buying a consumer DWS and then trying to manually tweak it is a waste of time and money.
 
Yes, I believe you are correct... it doesn't appear to pick a backhaul channel and stick with it permanently, as I've observed my devices connected to the lower 5ghz channels of a node, and then at another time on the upper channels of that same node.
Any radio can be used for both backhaul and client connection. So a client changing channels doesn't necessarily mean the backhaul connection for the node has changed.
 
bizarre that it would randomly switch though as this would cause disconnections which doesnt make a lot of sense
This is precisely the reason why many manufacturers are very careful about band steering (which Velop does not support). Many clients, especially 2.4 GHz only, don't take kindly to being deauthed.
 
I think I understand correctly, but just to make sure. From the review: "So if you're happy with your current router's features and are just looking to improve your Wi-Fi, Velop can do it, but will separate devices connected to it from devices connected to your router."

I assume that devices connected through the Velop can access Plex (for example) which is wired to the broadband router the Velop is wired to? (I've ordered the Velop, can't wait to have WiFi coverage in my entire house.)
Velop operates only as a NATed network. So all devices connected to it are behind a firewall.

You might be able to connect, if you can point your client at the Plex server's IP address. But devices connected to your main router can't initiate connections to devices connected to Velop.

If you want WiFi coverage in your entire house, get a NETGEAR Orbi.
 
That may or may not happen. All depends on how sticky the client is. Roaming also has nothing to do with a node''s back haul connection
Sorry, I see my post was a bit ambiguous... I was referring not to the client's decision of what node to connect to, but rather the wireless node deciding to do its backhaul through the wired remote node instead of the main node if the wired remote's signal was better.
 
How do you know that? Did you do packet captures to trace traffic flows?
No, I'm just speculating, based on the fact that the wireless remote node is only broadcasting one BSSID (the main and the wired remote are broadcasting both radios). I could certainly be wrong, but my assumption was that this meant the wireless node was using the non-broadcasting radio as its backhaul, because it does not appear that it is being made available for clients.

Another observation. As I mentioned, my wired remote node broadcasts BSSIDs for both the upper and lower 5ghz channels. However, if I pull the ethernet plug, after a few moments of a red pulsing light it establishes a wireless connection to the main unit and goes blue again. But now, it too is only advertising one BSSID. Plug it back in, and after a few moments both BSSIDs are once again being broadcast.

So, again, my assumption is that a wired unit (main or remote) uses both radios for talking to clients and to wireless nodes, while a wireless node only makes one of those radios available for clients and reserves the other for backhaul to the upstream node.
 
No, I'm just speculating, based on the fact that the wireless remote node is only broadcasting one BSSID (the main and the wired remote are broadcasting both radios)....
Thanks for sharing your analysis. Sounds reasonable.
 
This is precisely the reason why many manufacturers are very careful about band steering (which Velop does not support).

So are they just publishing the same SSID and letting the clients figure it out? I thought band steering was all over their marketing..

EDIT: I take it back, they conveniently avoid that phrase ;-)
  • Simultaneous Tri-Band Wi-Fi Mesh System
  • Seamless Wi-Fi
 
So are they just publishing the same SSID and letting the clients figure it out? I thought band steering was all over their marketing..
Wi-Fi clients are always in charge of "figuring out" which BSSID to connect to. APs can "help" with this process with things like 802.11k/v/r, but these must also be implemented on the client.

APs can also "help" by disconnecting (deauth) clients, with the hope they will take the hint and connect to a different AP with better RSSI. But not all clients do that.

More info here:
https://www.snbforums.com/threads/what-are-sticky-clients-802-11k-v-r-explained.30689/
 
Wi-Fi clients are always in charge of "figuring out" which BSSID to connect to.

relevant question but a bit OT

will we see a day when this is reversed and the clients just advertise they are here and the nodes or ap's make the decision based on location and signal strength and client capability or is that a step to far ?
 
will we see a day when this is reversed and the clients just advertise they are here and the nodes or ap's make the decision based on location and signal strength and client capability or is that a step to far ?
I was thinking the same thing. But from reading the thread/articles Tim posted, it sounds like the clients themselves are the biggest impediment to this, since they don't bother scanning for other APs until the signal strength degrades significantly. That's the most annoying thing about these kinds of distributed WiFi systems... you can be standing right next to an AP, but the client remains on one further away because it's "good enough", so the device doesn't see a need to look for a better one.

I understand that mobile device manufacturers would not want to have their devices constantly polling all the APs in the area because of the impact on battery life. BUT, maybe a new WiFi standard, similar to 802.11k, could fix that. Specifically, if a network that consists of multiple APs (and any handoffs between APs would be seamless or near seamless) the router could give this information to clients, and clients would respond by occasionally (maybe even just once a minute or so) poll only those specific APs (not all your neighbor's networks... just your APs) to see if there's a significantly better one it could connect to, or to simply provide signal strength info to the WiFi system and let it decide whether the client should be moved. Either way would work, I would think.
 
Wi-Fi clients are always in charge of "figuring out" which BSSID to connect to. APs can "help" with this process with things like 802.11k/v/r, but these must also be implemented on the client.

APs can also "help" by disconnecting (deauth) clients, with the hope they will take the hint and connect to a different AP with better RSSI. But not all clients do that.

More info here:
https://www.snbforums.com/threads/what-are-sticky-clients-802-11k-v-r-explained.30689/

Got it - thanks. And band steering just involves a little 'probing' to assess which radio to send it to based on hardware capabilities at the initial connect.

If only just one vendor would do it properly!.!.!.!.


Sent from my iPhone using Tapatalk
 
Got it - thanks. And band steering just involves a little 'probing' to assess which radio to send it to based on hardware capabilities at the initial connect.

I find that this is rarely a problem on initial connect... my computers and mobile devices almost always pick the 5ghz band even though the 2.4ghz band of course usually has a stronger signal. I'm guessing modern devices are capable of making the determination that a moderate 5ghz signal is going to be faster than a great 2.4ghz signal, up to a point of course... if I'm in the far reaches of the house or are outside, and 5ghz reception is weak, it chooses 2.4ghz.

What I'm curious about is what Tim mentioned about true band steering working by de-authing clients on 2.4ghz in the hopes that they reconnect to 5ghz, which seems to indicate that this is something that comes into play at some point after initial connection. For instance, if I'm outside and my phone connects to 2.4ghz, but then I come inside, because it's still getting a good signal it won't switch to 5ghz. In practice, this is not necessarily a big deal, as I think when the iPhone is in sleep for a little while and you wake it, it scans WiFi and connects to the best network.

Still, I'm curious... is how band steering works? Not necessarily just on the initial connection, but also for already-connected devices that the router thinks would be better off being forced over to 5ghz?
 

Similar threads

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top