The pros and cons of mesh networking
One thing you'll discover right away and (like me) might find odd is that Google Wifi uses the same SSID with the 2.4 GHz and 5 GHz wireless networks, for a claimed "better, easier experience." It's up to each network client to select which frequency "beacon" it's compatible with and (if both are options) which is better in a particular location, balancing performance (usually but not always 5 GHz) against range (usually but not always 2.4 GHz). And of course, for network clients that regularly relocate themselves, such as smartphones, tablets, and laptop computers, this selection decision is dynamic, not one-time.
Another oddity: the LAN subnet is fixed (192.168.86.xxx), not admin-alterable. In most cases, this'll be a non-issue for implementers. But in times (recent) past, I've needed to be careful about which subnet I used, to avoid choosing the same one employed by a remote work network I was periodically logging into via VPN. Then again, there's no VPN support built into the router, either ... A user-definable subnet assignment would seemingly be a simple feature addition, one that's common today with conventional routers, in fact, and one that could be stuck away on an "advanced settings" page. So, I'm not sure why Google declined to include it.
Speaking of subnets, there's seemingly no way to restrict the router's DHCP server to use only a portion of the total available CIDR /24 subnet space. This seemingly means that static IP-assigned network clients can't be reliably used with Google Wifi, although it's alternatively possible to reserve at the router an IP address for a particular DHCP-configured client. Again, this seemingly simple feature addition is common today with conventional routers, and its omission in Google Wifi is baffling to me.
As shown in the above screenshot, Google Wifi periodically "pushes" new network firmware updates to the "root" (router) and mesh (access point) nodes. And as the previous post in this series documents, I was clumsily able to get all of my network hardware to the then-latest firmware revision during initial setup, by direct-connecting each OnHub to the modem with no attention-contending LAN traffic going on behind it at the time. But the decision criteria that Google Wifi uses to determine an appropriate time to do an auto-update remains a mystery.
There's no manual firmware check-and-update option. There's not even the ability receive an alert on the availability of an update, but then choose when to install it. Cloud-based configuration can be problematic, as users discovered early this year. To the best of my knowledge, server-side settings archive and restore still isn't supported, surprising given the abundance of other information about me that Google already stores in the cloud. And more generally, I'd really like for my network to not go down for an upgrade when, say, I'm in the middle of hosting a webinar for a client. This area sorely begs for more polish on Google's part.
I've already discussed (in my last post) the fact that initial setup, along with ongoing configuration and monitoring, can occur only via an Android- or iOS-based app, not through a web browser GUI. In my particular case, since Google-sourced software powers not only my network but also my smartphones and (primary) tablet, I'm not particularly concerned about long-term app viability. And since the app is tied to my Google account, I'm able to administrate my network even when I'm on the road. Still, a web browser-based option would be nice.
One final nit; setup of the mesh nodes must initially occur via a wireless connection to the "root" node, not over wired Ethernet, although subsequent wired connectivity is supported (via the WAN Ethernet port of mesh node OnHubs, fellow owners ... I had to figure this out via trial-and-error experimentation, as I couldn't find any online documentation):
This limitation is not only baffling but also location-limiting, since a mesh node can't be placed beyond the wireless broadcast range of the "root" node (and isn't that sometimes the point of the exercise?).
Critiques aside, Google Wifi does support a fair-sized set of capabilities:
- WAN DNS server selection (not just Google and/or ISP)
- WAN access mode (DHCP, static IP, PPPoE)
- Guest network support
- Configurable network name and password (both regular and guest)
- Optional IPv6
- Optional UPnP
- Temporary (up to 4 hour) network traffic prioritization of a particular client
- The previously mentioned "Family Pause" feature
- OnHub LED brightness control
- Ongoing LAN and WAN checks (status, bandwidth)
- Port forwarding support (although to activate a settings change, it seems necessary from my experience to reboot the router)
And at the end of the day, here's the bottom line: the "mesh" aspect of the new network seems to solidly operate as advertised. Does a particular roaming client cling to a particular network node's broadcast beacon a bit longer than I'd prefer? Sometimes. But then again, I'm doing a review, so I'm probably more aware of such things than I would be in normal usage. And I've gotta say that it's pretty cool to carry a mobile client from one end of the house to the other and watch its reception signal strength momentarily dip, then recover to full strength as it's handed off from one node to another with no required user intervention.
Like Google's engineers, many of you are probably regularly involved in designs that strive to balance simplicity against feature set robustness. And of course, the dividing line between the two endpoints varies depending on what you imagine to be your typical target customer's technical competence, patience, and the like. After reading this blog series, I'm curious to see how well (or not) you think Google's done in tackling this balancing act. Sound off in the comments, please; thanks in advance!
—Brian Dipert is Editor-in-Chief of the Embedded Vision Alliance, and a Senior Analyst at BDTI and Editor-in-Chief of InsideDSP, the company's online newsletter.