The pros and cons of mesh networking
Article By : Brian Dipert
Designers strive to balance simplicity and feature set robustness. After reading this blog series, how well (or not) do you think Google's done in tackling this balancing act?
With my new mesh network set up and running, now’s the time to answer the all-important question of how well it’s running. Also, Google’s designed Google Wifi to be easy to maintain (along with being family-friendly, such as via the “pause” feature that temporarily disables network access for one or a group of devices, or the recently-added device-specific or network-wide porn site blocking feature); how well did Google execute on its aspirations, and did any important features fall by the wayside in the process?
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.
Related articles:
- Is it time to upgrade to mesh networking?
- Mesh networking: setting up Google OnHub-based Wi-Fi
- Wi-Fi versus 5G? Nope, it’s both
- Reactions mixed to home mesh networking effort
- Wireless Current Sensing made possible with a Micropower, Zero-Drift Op Amp
- VPN: Proceed with caution
