Linksys Announces Velop Mesh Wi-Fi System

[michael814]

I also don't know if you missed it, but the review stated that there is no cloud service involved in managing backhaul.

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)?

 

[gowg]

So purely for your own interest Tim, I'm currently working an issue with Velop support - although it shouldn't really affect your review, you might be interested to see what is 'under the hood' although not currently exposed in the admin UI.

Go to http://192.168.1.1
Click on the 'Velop' word logo
Login using the local admin password
click on the 'CA' link (bottom of the page , opposite the link to the end user license'

Theres a whole heap of extra functionality in there (ability to change DHCP info etc, support for dynami RIP routing etc) - as I say obviously outside the scope of what an end-user would experience, but thought it might interest you to poke around.

On the backhaul conversation there are clearly 2 x 5Ghz radios in there , but its not clear if either is dedicated for this purposes - they just look like 2 radios (one with low channels, and one with high channel support)

That's very interesting. Can you assign each radio a different SSID like Orbi?

 

[michael814]

tim , not saying i dont believe you , im saying there is a lot of confusion on the market as to what this actually does as with page i have read quite a few other reviews who all stated its dedicated backhaul , seems some of these other so called reviews havnt put in the work and are just repeating whatever blurb they have been fed and in turn misleading their readers

The MacWorld review linked in an earlier post gives a little bit more accurate information on this. Paraphrasing, but it essentially says that the utilization of the two 5ghz radios is dynamic... for instance, a node may use the lower channels to communicate with the client, while using the upper channels as backhaul. Another node might use the opposite. At least that's how I interpreted it. Regardless, I think the main point is that while it might not be a dedicated backhaul in the sense of a group of channels that is not used for anything else in the system, it's not a single shared 5ghz radio that has to pull double duty for clients and for backhaul.

 

[michael814]

It's possible, but unlikely that I had defective Velops. At any rate Linksys hasn't offered that as an explanation for the poor backhaul performance I saw. Instead, they suggested nodes were place too far apart.

I'm really curious as to the poor backhaul speed you saw in your test. My arrangement of nodes looks very similar to yours, at least in the relationship between your main and Living Room positions as illustrated in your floorplan diagram. I have the main unit and a hardwired remote node upstairs, and downstairs is a wireless remote node. The wireless node is about 20-25 feet (horizontally) and a floor away from each wired node, which appears to be a similar distance as your setup. In my case, the signal passes through the floor and a couple of walls, which I assume is also similar to yours.

You noted a speed of ~20mb/s, but with my laptop in the "wireless bridge" configuration (plugged into to the wireless node's ethernet port) as your test was, I'm averaging over 400mb/s of backhaul speed:

Similarly, my iOS devices when wirelessly connected to this node and standing nearby get about 350mb/s.

 

[michael814]

OK, thanks. So the low speeds should definitely improve when using Ethernet then? You didn't happen to test that, by any chance?

The speed through an ethernet-connected remote node is pretty much identical to that of the main node... standing about 10ft. in front of either one (and confirming that my device is connected to that node), I get about 500mb/s in both cases.

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.

 

[Pericynthion]

That's very interesting. Can you assign each radio a different SSID like Orbi?

Yes - in fact to try and troubleshoot the Nestcams losing connectivity , I'm currently running a different 2.4Ghz SSID (to try and eliminate band steering as an issue).

But yes you could also assign a different SSID for the high and low 5Ghz radios. Might be an interesting way to see what happens to the backhaul ;-)


Sent from my iPhone using Tapatalk

 

[Pericynthion]

The MacWorld review linked in an earlier post gives a little bit more accurate information on this. Paraphrasing, but it essentially says that the utilization of the two 5ghz radios is dynamic... for instance, a node may use the lower channels to communicate with the client, while using the upper channels as backhaul. Another node might use the opposite. At least that's how I interpreted it. Regardless, I think the main point is that while it might not be a dedicated backhaul in the sense of a group of channels that is not used for anything else in the system, it's not a single shared 5ghz radio that has to pull double duty for clients and for backhaul.

If you run the channel finder util it tells you what channels it put the radios on, but no indication which is doing what function, hence I'm leaning towards the assumption it picks one for the backhaul but it could change its mind depending on environmentals.


Sent from my iPhone using Tapatalk

 

[michael814]

That's very interesting. Can you assign each radio a different SSID like Orbi?

Here's a screen shot of the wireless settings... looks like you could hypothetically change the SSID of each radio (and in fact, each node has its own individual web GUI, so presumably all of the radios on all of the nodes could have different SSIDs), but that would probably screw up the roaming feature and maybe even the backhaul.

 

[michael814]

Also, FWIW, the Linksys people seem to be realizing that omitting an easily-accessible web GUI with advanced configuration options was a mistake. A week or two ago, they were discouraging users from accessing the secret web interface, but now, although they still warn against making certain wireless changes (which could mess up the operation of the system), it's sounding more and more like they are ok with more savvy users accessing this feature, and they indicated today that they do plan to make the web GUI "official" soon, once they have time to clean it up a bit and make it more robust.

 

[pete y testing]

and they indicated today that they do plan to make the web GUI "official" soon, once they have time to clean it up a bit and make it more robust.

way to cave into the masses linksys / belkin , thats really going to give you headaches now allowing the noobs to break it and then deal with the returns and complaints , i see no real logic in doing this as they are designed to be plug and play , give them too many options and they are sure to break it

 

[michael814]

way to cave into the masses linksys / belkin , thats really going to give you headaches now allowing the noobs to break it and then deal with the returns and complaints , i see no real logic in doing this as they are designed to be plug and play , give them too many options and they are sure to break it

I think the intention is to continue to steer people to the app, but reduce the hoops one has to jump through to enable the web GUI (and hopefully remove or at least add warnings for the settings that could break the mesh / roaming functionality). The average user would just continue to use the app, and wouldn't even know the web GUI was there. Meanwhile, advanced users (who know to go looking for it) would have access to the more detailed network and routing settings they need.

In the end, it's still a router. While, yes, it would be a good idea to remove access to settings that would affect the way nodes talk to each other, the absence of advanced routing features (well, actually the fact that they are so hard to get to, at least initially) is the most noted negative against the Velop in user reviews.

 

[pete y testing]

until

The average user would just continue to use the app, and wouldn't even know the web GUI was there.

they read this and other posts and then go fiddling

the absence of advanced routing features (well, actually the fact that they are so hard to get to, at least initially) is the most noted negative against the Velop in user reviews.

but how many features will be enough ? i see to many ppl expecting the feature set they had in their big honking routers and thats never going to happen and is why AP mode on these mesh systems is important as then you can use the mesh system as what its designed for ( eg whole home wifi coverage without the need for ethernet ) while having a full blown router do the heavy lifting if thats what your network and user base needs

 

[Pericynthion]

until

they read this and other posts and then go fiddling



but how many features will be enough ? i see to many ppl expecting the feature set they had in their big honking routers and thats never going to happen and is why AP mode on these mesh systems is important as then you can use the mesh system as what its designed for ( eg whole home wifi coverage without the need for ethernet ) while having a full blown router do the heavy lifting if thats what your network and user base needs

I'll be honest my biggest gripe is information about where the nodes/client connections are. I'm ok with it making some intelligent decisions about placement (and with the fact I might be sacrificing some control/performance for simplicity) but the sheer lack of transparency makes it difficult to troubleshoot the most basic thing.

I'm been running Edgerouters and hard wired APs for the past couple of years at home, and if they get these Velop admin issues solved I'll be glad to let it run itself so I can worry about the rest of my IOT devices taking over the world.


Sent from my iPhone using Tapatalk

 

[pete y testing]

I'll be honest my biggest gripe is information about where the nodes/client connections are. I'm ok with it making some intelligent decisions about placement (and with the fact I might be sacrificing some control/performance for simplicity) but the sheer lack of transparency makes it difficult to troubleshoot the most basic thing.

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

 

[michael814]

until

they read this and other posts and then go fiddling

I guess I just don't agree with the notion that a WiFi system like this needs to be locked down any more than a traditional router, outside of the settings that would break the mesh functionality. Just because it's a distributed WiFi system doesn't mean it MUST have an extremely dumbed-down interface with no advanced routing features.

but how many features will be enough ? i see to many ppl expecting the feature set they had in their big honking routers and thats never going to happen and is why AP mode on these mesh systems is important as then you can use the mesh system as what its designed for ( eg whole home wifi coverage without the need for ethernet ) while having a full blown router do the heavy lifting if thats what your network and user base needs

I guess it depends on how you define "advanced". For me, it was a shock to find that the Velop would not allow me to define the DHCP range. No problem, I thought... I'll just keep my old router and run the Velop system in bridge mode (as you suggested as well), only to find that it can't do bridge mode either. I was able to get it to work with my setup, and I'm quite happy with it, but it would have been far simpler if I could have just gone to the router's web page (or even in the app) and set my desired DHCP range, or (less desirably) switched it to bridge mode and kept my old router. Other people are annoyed that they can't change it from 192.168.1.x to the IP numbering scheme of their preference. Want to specify a DNS? Too bad. Static routes? DMZ? Nope. And so on.

I believe most of these features (and others) are present, but are just not accessible through the app, only through the secret web GUI. These are features that some buyers are going to expect to be there, and when a reasonably savvy user unwraps the system only to find that it is missing so many standard features and is so unconfigurable that they cannot incorporate it into their network, guess what? It gets packed up and returned, and a bad review is posted.

Now, you may have the view that this stuff has no place in a product like this (even though the Orbi has these features), but I think it's undeniable that the omissions are hurting sales and causing a lot of aggravation among users. So, I applaud Linksys for being flexible in this regard. Yes, by all means keep the app as the primary way to set up and interact with the system, but facilitate advanced users as well, either by adding these options to the app, or (even better) stashing them away in a web GUI that is there for those who need it, while keeping the app simple and clean and non-bewildering for the benefit of the general population.

 

[michael814]

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

Yes, and this ties into our ongoing discussion about features vs. simplicity. Linksys probably make a conscious decision to make the node placement test EXTREMELY simple... it's either "good" or it's "not good". They didn't want to display a confusing array of RSSI numbers and link rates, or even a graphical representation of link quality, nor did they want users to worry about which nodes their devices are connected through at any particular moment.

For many users this is perfectly fine. But if you are the kind of person who wants to invest some time into moving nodes around a bit to find the best balance of speed and coverage, there is nothing in the Linksys app to aid you in this task.

 

[Pericynthion]

Yes, and this ties into our ongoing discussion about features vs. simplicity. Linksys probably make a conscious decision to make the node placement test EXTREMELY simple... it's either "good" or it's "not good". They didn't want to display a confusing array of RSSI numbers and link rates, or even a graphical representation of link quality, nor did they want users to worry about which nodes their devices are connected through at any particular moment.

For many users this is perfectly fine. But if you are the kind of person who wants to invest some time into moving nodes around a bit to find the best balance of speed and coverage, there is nothing in the Linksys app to aid you in this task.

The funny thing is if you look in the user guide and online support articles most of the advanced settings are there in the screenshots. Maybe QA didn't get them approved in time for the actual release date but they'll start drip feeding them back in forthcoming releases.


Sent from my iPhone using Tapatalk

 

[michael814]

If you run the channel finder util it tells you what channels it put the radios on, but no indication which is doing what function, hence I'm leaning towards the assumption it picks one for the backhaul but it could change its mind depending on environmentals.

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.

 

[michael814]

One more observation about backhaul. My Velop setup consists of the main unit, an ethernet-wired remote node, and a wireless remote node. Looking at a WiFi scanner, the main and the wired remote show BSSIDs being advertised for both the upper and lower 5ghz radios. But the wireless node only shows one 5ghz BSSID (presently the upper channels, but it changes sometimes). Presumably that means Linksys has decided that wired units don't need to dedicate one radio exclusively to backhaul, and instead (again presumably) in a heavy traffic situation could distribute clients (as well as wireless remote nodes) across both radios depending on load. Meanwhile, the wireless node IS apparently using one of its radios just for backhaul.

 

[pete y testing]

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