Google WiFi Reviewed

[sfx2000]

Thanks. Just feeling a bit overwhelmed lately. The new test processes are taking too much time and need to be streamlined.

As always - I appreciate all the efforts - been there myself, and we always want to look at more...

(some would say automation saves time, but it takes time to write the scripts and verify them)

 

[sfx2000]

As good as rolling your own Ubiquiti based network for like 20% of the price.

It'll meet the needs of many - but there is that 20 percent that do want a bit more control, and out of that group, there are those that will take that next step...

If one is at the knowledge/skill level of rolling out a UBNT or similar solution - then Google WiFi isn't for that person, for others, however, it's worthy of a look, similar to the other, gosh, how do I state this - plug in and let it work solutions...

 

[sfx2000]

Google cited security concerns as the reason why WPS is not supported. It's not supported on eero, Luma or Amplifi for the same reason. Only Orbi, which isn't true mesh, supports WPS.

This comes down to trust at the end of the day - both for the client and the mesh nodes - it's not impossible to do, but it's not secure as Tim mentions above...

WPS has had issues over the years - and with Mesh, if implemented - who would one trust? IF someone, with the appropriate tools, skills, and knowledge, could mimic a WPS authenticator... with legacy that's one concern, with Mesh, it's a whole layer a trouble over that...

 

[sfx2000]

i will say no wps will have consequences as ppl return them simply because their printer wont connect etc , with more and more IoT devices using wps connection method i think this is a real deal breaker that i cant why google would not have seen , certainly a strange decision , seems google use the same though process as apple , eg we do it our way !!

WPS - most printers have an alternative means - might involve installing some extra SW on the primary PC to set things up...

As for IOT - WPS isn't an answer... simply put...

What's interesting about what Google is doing is to build a secure ring of trust around items, but that's a problem at the moment, but Google is trying to solve that problem, similar to what Apple is doing with HomeKit...

HomeKit's a mess at the moment, I think Google's approach might have some advantages with their API approach, but it's cloud dependent right now, but at first glance, it's not a bad approach....

There are other API's outside of Google/Apple, and they're lightweight, but again, the API's are there, but it needs end-point support from the devices.

 

[pete y testing]

it's a nice turnkey solution...

only problem is that most buy a turnkey solution and them complain and complain because it wont do all the stuff their old bhr would and then crack it and bleed all over the internet about how crap it is because it doesnt have the features it never advertised it had lol , i think some just like a big whinge

 

[sfx2000]

only problem is that most buy a turnkey solution and them complain and complain because it wont do all the stuff their old bhr would and then crack it and bleed all over the internet about how crap it is because it doesnt have the features it never advertised it had lol , i think some just like a big whinge

Getting off topic - but this has happened before, and it will happen again...

Esp as security tightens down on the Gateway side, and new API's are rolled out on devices...

 

[Rhyle R]

With these results and early firmware I don't see how anyone can justify +$200 for the eero.

FWIW, I bought 3 ASUS OnHubs off eBay for $99 each new. I meshed them over Ethernet and now have the best networking setup I've had in a long time.

Even a single OnHub provided similar routed Internet speeds to my iPhone 7 as my RT-AC5300. The OnHub lost slightly on the downlink but outperformed the AC5300 on uplink.

Here's my speed test standing right next to each one:

RT-AC5300

http://www.speedtest.net/my-result/i/1892868618

ASUS OnHub running latest firmware:

http://www.speedtest.net/my-result/i/1892869456

I recommend this setup to anyone looking to build a great network at very low prices.

I turned off my RT-AC5300 and I'm never looking back.

You're describing exactly what I'm looking for. I have Ethernet throughout the house and I am looking for a way to create a wifi mesh.
Do you mind sharing a few more details on how you did it?
Questions that come to mind are:

1. Can you keep your original router? or does one of the OnHubs have to be the 'master' router? (I'm assuming the onhub has to be the master router given how Google wifi seems to work)
2. How big are the onhubs? Do you see a convenient way to wall mount one?
3. Can the LEDs be turned OFF from the onHubs?
4. Do all the Google Wifi Mesh features work with OnHubs? I'm thinking about being able to individually disable net access for clients, automatically switch from one onhub to another, beam steering, management through phone app?
5. Was there anything special that you did to setup a 2nd onhub as a mesh node with a wired backhaul? Or did the app do the configuration directly?

What you did almost seems too good to be true... Inidividual onhubs should have better performance than the google wifi nodes... and you can get them for the same price (~$100 a node)... what's the catch?

thank you!

 

[pete y testing]

I have Ethernet throughout the house and I am looking for a way to create a wifi mesh.

well the new ubiquiti wifi mesh ap's are your answer , not the google wifi

 

[thiggins]

When you have Ethernet backhaul, wireless connection for backhaul is just wasting bandwidth.

 

[thiggins]

Any idea what Google Wifi uses for backhaul? 2.4 ghz? I'm really surprised to see the eero perform in the same range as the other solutions since it has a dedicated backhaul. I'd have really expected it to perform somewhere between the Orbi and the others.

If properly designed, backhaul connections will be dynamic. That's why I measure throughput at the client, which is all that matters.

I'm really puzzled as to why most of these products are only AC1200 with no dedicated backhaul. I would think being a mesh product would mean more radios rather than less.

Price. Look at the per-unit price of Orbi and relative price of eero.

 

[Rhyle R]

well the new ubiquiti wifi mesh ap's are your answer , not the google wifi

Thank you for the recommendation.

I am looking into this. I found the unified ac mesh.

Is this what you recommend?
I'm a little hesitant on using enterprise solutions.
I'm under the impression that they will cost the same or more and that I'm going to have to invest a fair amount of time deploying and maintaining it.

What do you think are the advantages of this system?

This seems like it would require a new router plus the APs.
Does it require the cloud key too? Or is that optional?

http://dl-origin.ubnt.com/guides/UniFi/UniFi_AP-AC-M_QSG.pdf

 

[pbarnes]

You're describing exactly what I'm looking for. I have Ethernet throughout the house and I am looking for a way to create a wifi mesh.
Do you mind sharing a few more details on how you did it?
Questions that come to mind are:

1. Can you keep your original router? or does one of the OnHubs have to be the 'master' router? (I'm assuming the onhub has to be the master router given how Google wifi seems to work)
2. How big are the onhubs? Do you see a convenient way to wall mount one?
3. Can the LEDs be turned OFF from the onHubs?
4. Do all the Google Wifi Mesh features work with OnHubs? I'm thinking about being able to individually disable net access for clients, automatically switch from one onhub to another, beam steering, management through phone app?
5. Was there anything special that you did to setup a 2nd onhub as a mesh node with a wired backhaul? Or did the app do the configuration directly?

What you did almost seems too good to be true... Inidividual onhubs should have better performance than the google wifi nodes... and you can get them for the same price (~$100 a node)... what's the catch?

thank you!

The catch is that it has fewer "features" than a big expensive router. To me, that's a good thing. I used to run my network on a bunch of AirPort Extremes since they supported a similar "mesh" very early on, but they were extremely unreliable.

Then the RT-AC5300 came out and I thought this was it. But the firmware is so buggy that it doesn't even matter how many radios or whatever buzzword thing it has. The problem with all these giant routers with 1000 features is that the companies really aren't that good at writing software or integrating it into whatever Linux distribution they have running on the thing. It's always a buggy mess.

Just as an example, sometimes all my Bonjour (mDNS) using devices would just stop seeing each other. I'd have to ssh into the router and restart mDNSResponder for it to work again. I just don't have time for that stuff. My kid starts throwing iPads around when the network isn't working.

Okay, to the questions:

1. You can't keep the original router and run the mesh.

2. They're fairly large things due to the vertical antenna array. Roughly the same size as an AirPort Extreme. You could fit 4 OnHubs in the footprint of a RT-AC5300. I can't think of a way to mount them, but I'm sure it could be done. I've just hidden them around the place.

3. Yes the LED can be turned off. There's a slider in the app where you can control the brightness of the LED of each unit.

4. Yes. All features work identically across both devices. They run the exact same firmware version (a version of Chrome OS). The app can communicate with specific nodes for some things or push out a new configuration to the entire mesh.

5. The OnHub ships with an ancient firmware release that is unaware of the mesh. It needs to be connnected directly to the Internet for 5 minutes until it updates to the new firmware. After that it works in the mesh with no issues. I think this is the reason why Google isn't advertising this ability.

Hope that helps.

 

[Denethor Steward]

The catch is that it has fewer "features" than a big expensive router. To me, that's a good thing. I used to run my network on a bunch of AirPort Extremes since they supported a similar "mesh" very early on, but they were extremely unreliable.

Then the RT-AC5300 came out and I thought this was it. But the firmware is so buggy that it doesn't even matter how many radios or whatever buzzword thing it has. The problem with all these giant routers with 1000 features is that the companies really aren't that good at writing software or integrating it into whatever Linux distribution they have running on the thing. It's always a buggy mess.

Just as an example, sometimes all my Bonjour (mDNS) using devices would just stop seeing each other. I'd have to ssh into the router and restart mDNSResponder for it to work again. I just don't have time for that stuff. My kid starts throwing iPads around when the network isn't working.

Okay, to the questions:

1. You can't keep the original router and run the mesh.

2. They're fairly large things due to the vertical antenna array. Roughly the same size as an AirPort Extreme. You could fit 4 OnHubs in the footprint of a RT-AC5300. I can't think of a way to mount them, but I'm sure it could be done. I've just hidden them around the place.

3. Yes the LED can be turned off. There's a slider in the app where you can control the brightness of the LED of each unit.

4. Yes. All features work identically across both devices. They run the exact same firmware version (a version of Chrome OS). The app can communicate with specific nodes for some things or push out a new configuration to the entire mesh.

5. The OnHub ships with an ancient firmware release that is unaware of the mesh. It needs to be connnected directly to the Internet for 5 minutes until it updates to the new firmware. After that it works in the mesh with no issues. I think this is the reason why Google isn't advertising this ability.

Hope that helps.

A few questions if you happen to know the answer...
Using the OnHubs with the latest firmware:
1. They can ONLY mesh via hardwire? or they can also mesh via WiFi (at a speed loss obviously due to the double communication).
2. Each OnHub has two hardwire ports, correct? On the satellite OnHubs can both ports be used as normal switch ports?
3. Do the satellite Onhub(s) bridge to the main OnHub or does each one perform NAT on the devices hardwired, essentially double NATing that would break some devices communications.

 

[thiggins]

A few questions if you happen to know the answer...
Using the OnHubs with the latest firmware:
1. They can ONLY mesh via hardwire? or they can also mesh via WiFi (at a speed loss obviously due to the double communication).
2. Each OnHub has two hardwire ports, correct? On the satellite OnHubs can both ports be used as normal switch ports?
3. Do the satellite Onhub(s) bridge to the main OnHub or does each one perform NAT on the devices hardwired, essentially double NATing that would break some devices communications.

OnHubs act just like Google Wifi points. So answers apply to both.
1. They run mesh Wi-Fi or can use Ethernet for backhaul in any combination.
2. Yes
3. Only the root node (the one connected to your internet modem) runs NAT. Others are devices on the root node's network (192.168.86.x).

 

[pbarnes]

One more point to add here is that according to /api/v1/diagnostic-report the mesh WiFi backhaul seems to only use 5Ghz.

This is what the output of 'ip addr' looks like on one of my mesh points connected over Ethernet. Pretty cool.

/bin/ip -s -d addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default
    link/loopback 000000000001      brd 000000000001      promiscuity 0
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    6508       84       0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    6508       84       0       0       0       0     
2: wan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc nssprio master br-lan state UP group default qlen 1000
    link/ether 2c56dc000002      brd ffffff000003      promiscuity 1
    bridge_slave
    inet6 fe80::2e56dc000004  :13ad/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    6702330356 4612601  0       19      0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    259289004  2273153  0       0       0       0     
3: lan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br-lan state UP group default qlen 1000
    link/ether 2c56dc000005      brd ffffff000003      promiscuity 1
    bridge_slave
    inet6 fe80::2e56dc000004  :13ae/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    32899657   409901   0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    993475028  742350   0       0       0       0     
4: qca-nss-dev0: <> mtu 0 qdisc noop state DOWN group default
    link/generic  promiscuity 0
    RX: bytes  packets  errors  dropped overrun mcast 
    0          0        0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0     
5: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default
    link/ether 2c56dc000005      brd ffffff000003      promiscuity 0
    bridge
    inet 192.168.86.128/24 brd 192.168.86.255 scope global br-lan
       valid_lft forever preferred_lft forever
    inet6 fe80::2e56dc000004  :13ae/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    1908224214 1341786  0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    28169616   380553   0       0       0       0     
6: br-guest: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether 9e62e4000006      brd ffffff000003      promiscuity 0
    bridge
    inet6 fe80::9c62e4000007  :31ef/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    0          0        0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    1629       23       0       0       0       0     
7: br-setup-mesh: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether fe6200000008      brd ffffff000003      promiscuity 0
    bridge
    inet6 fe80::fc62ff000009   51/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    0          0        0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    536        8        0       0       0       0     
8: br-station-mode: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default
    link/ether eabce700000a      brd ffffff000003      promiscuity 0
    bridge
    inet6 fe80::e8bce700000b  :3363/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    0          0        0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    536        8        0       0       0       0     
9: wlan-2400mhz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
    link/ether 2c56dc00000c      brd ffffff000003      promiscuity 1
    bridge_slave
    inet6 fe80::2e56dc000004  :13b1/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    188984     1345     0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    22220118   88346    0       0       0       0     
10: wlan-5000mhz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
    link/ether 2c56dc00000d      brd ffffff000003      promiscuity 1
    bridge_slave
    inet6 fe80::2e56dc000004  :13b5/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    192815946  1479401  0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    3866078026 2689160  0       0       0       0     
11: aux-radio0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000
    link/ether 2c56dc00000e      brd ffffff000003      promiscuity 0
    RX: bytes  packets  errors  dropped overrun mcast 
    0          0        0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    0          0        0       0       0       0     
12: mesh-5000mhz: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br-lan state UP group default qlen 1000
    link/ether 2e56dc00000f      brd ffffff000003      promiscuity 1
    bridge_slave
    inet6 fe80::2c56dc000010  :13b5/64 scope link
       valid_lft forever preferred_lft forever
    RX: bytes  packets  errors  dropped overrun mcast 
    18595512   109640   0       0       0       0     
    TX: bytes  packets  errors  dropped carrier collsns
    3644350    27611    0       0       0       0

Editor comment: Full URL to get this report is http://192.168.86.1/api/v1/diagnostic-report

 

[pbarnes]

I found a much quicker way to get all new OnHubs up to date so you don't need to mess around with connecting each one to the Internet.

Just follow these steps:

https://support.google.com/wifi/answer/6274977

You can create a USB drive that has the latest firmware. Awesome.

 

[Denethor Steward]

Just for comparison sake since net/net its the same price. would three OnHubs (one hardwire backhaul, one wireless backhaul) give any better results than two Ubiquiti UAP-AC-LR Long Range Wi-Fi points being fed by a Ubiquiti Edgerouter (ERPOE-5)?

 

[Rhyle R]

<Lots of great information >

Hope that helps.

Ceertainly did!
Thank you,
I'll start scouting eBay after the holidays



Sent from my iPhone using Tapatalk

 

[sfx2000]

I found a much quicker way to get all new OnHubs up to date so you don't need to mess around with connecting each one to the Internet.

Just follow these steps:

https://support.google.com/wifi/answer/6274977

You can create a USB drive that has the latest firmware. Awesome.

Cool - that's similar to how to recover a Chromebook if one gets truly horked up somehow... like tinkering about in Dev mode

 

[Ronv42]

Nice review. Still see issues with mesh as defined by the latest entries. For some reason they all seem to require "apps" to configure and a web service on the internet to manage the mesh. Orbi was the only one I found that didn't need the app or constant internet access to keep the mesh operating.

That said it's great to see the movement in the market place. Many solutions and competition.

Has anyone analyzed the connections made by Google WiFi to internet services? With it being from Google there has to be some information collecting going on to offset the cost running of this service.