I'm not going to go into detail on setup; it's been described thoroughly in other reviews. I used the Android app with a Dell Venue 7 tablet and it worked uneventfully, including the audio-based portion where OnHub plays an sequence that is received by the Android device. The tone connects the Android device and OnHub directly for final configuration.
The Android app scaled fine to the larger tablet screen. It also worked well on a Moto X phone. I didn't try the iOS app.
The OnHub is designed for folks who don't want to know nothin' about what makes their Wi-Fi go. So there are precious few settings. WAN connection types are limited to commonly found DHCP, Static and PPPoE types. There is no support for PPTP or L2TP connections and no settings whatsoever for IPv6. You can put the router into bridge mode to use as an AP, but that's about it.
To get a better sense of what OnHub will and won't do, I've taken a feature list typical of many current AC1900 class routers and edited it.
- Static and Dynamic IP, PPPoE ,
PPTP and L2TPWAN connections IPv6 WAN connections MAC address cloning MTU Adjustment DHCP Server, range setting, lease time setting, and default domain
- DHCP Client list
- DHCP reservation (by setting LAN Static IPs)
- Bridge mode (bypass NAT router)
- Port forwarding for single or multiple ports with TCP, UDP or both forwarded. Enable/disable for each entry.
Port filtering – can set individual or range of incoming ports. Allows you to enable or disable TCP and UDP ports on network devices. Four level priority-based download QoS control. Bandwidth rules list based on IP or MAC address, port range and protocol DMZ Host
- UPnP enable/disable
- Can set "priority" device that receives more bandwidth for a settable time period
- Total and per device bandwidth monitor, real-time, last hour, last 7 days, and last 30 days
- Internet up and downlink speed test
DDNS support for Dyndns (www.dyndns.org) NAT enable/disable RIP 1/2 dynamic routing Static routes
VPN Passthrough enable/disable for PPTP and IPsec DoS (denial of service) enable/disable Enable UDP Flood filtering (with settable threshold) Enable TCP-SYN Flood attack filtering (with settable threshold) Ignore Ping Packet from WAN port
- Secure remote management via iOS and Android apps
- Ability to control multiple OnHubs
Block all network access by MAC and IP address URL filtering (applies to all users, HTTPS not blocked) Internet access control - Rule based access control for host (domain name or IP address) IPv6 firewall
WEP,WPA / WPA2 Personal and Enterprise (RADIUS) support
- One SSID for both radios
4 guest wireless networks per band Wi-Fi Protected Setup (WPS) support, pushbutton and PIN Auto and manual channel set SSID broadcast enable/disable Enable/disable wireless Beacon interval, RTS threshold, Fragmentation Threshold adjustments Wireless MAC address filtering (allow or deny based on MAC address) WMM disable Short GI disable Wireless access schedules 5 GHz Wireless modes: a, a+n, a+n+ac (default) 2.4 GHz Wireless modes: b, b+g, b+g+n (default) 5 GHz channel width 20MHz/40MHz/80MHz 2.4 GHz channel width 20MHz/40MHz 5 GHz channels: 36, 40, 44, 48, 149, 153, 157, 161 2.4 GHz channels: 1-11 Transmit power adjust, 15%, 35%, 50%, 70% and 100%
- Wireless network bandwidth use per client
SMB file sharing (no user accounts) FTP server. Can set port and control anonymous FTP and anonymous write protection. No secure FTP DLNA media server
All admin is via Android and iOS apps. If you hit the OnHub's 192.168.86.1 IP, you'll just get the screen below.
OnHub browser admin interface
The gallery will walk you through most of the app and settings you can make. You'll note from the list above that the only control you have over Wi-Fi is to set the SSID, which will be applied to both radios and the WPA/WPA2 key. You can't control channel, mode, bandwidth mode or even shut off a radio. The Google On app provides no information about which band a device is connected to and doesn't allow you to block a device from connecting. Wi-Fi Protected Setup (WPS) isn't supported either.
My overall experience with administering OnHub wasn't positive. I'm not saying that because I couldn't control things that I'm accustomed to controlling. You have to accept that with OnHub. But the overall experience seemed shaky.
For most of my time with OnHub, I connected one device. Yet the Overview showed me at least two devices, one of which had no IP address. The Android app and / or OnHub also briefly disconnected from time to time for no apparent reason. The OnHub also appeared to disconnect (reboot?) when saving a port forwarding rule (more on this shortly), but provided no indication that it was doing so. The app seems to require checking in with Google's cloud to accomplish configuration changes. But to change WAN connection type, you must first disconnect from the internet.
I also tried running the "Network check", which appears to be an upload / download speed test. It took me three tries to get the result screen shown below. For the first two attempts, the check seemed to run ok, but then no results were presented.
OnHub Network check result
Maybe the flakiness was due to testing the OnHub behind my network's router. But that's how I test all routers. If OnHub is going to depend on Google's cloud to operate reliably, it better learn to deal with other routers between it and the internet. Most every DSL or cable "modem" today includes at least a basic NAT router that in many cases can't be bridged.
Configuring the router for our standard router test suite was a battle, which I lost. The only wired routing test I could run was LAN to WAN, which turned in a respectable 817 Mbps, as shown in the IxChariot plot below. I was also able to run the Maximum connections test, which at 37,037 easily exceeded the 30,000 connection mark after which we consider all products equal.
Uplink routing throughput
The WAN to LAN and simultaneous up and downlink tests require putting the LAN client in DMZ or opening a wide range of ports. Since OnHub doesn't support the former, I tried the latter.
I first had to assign a static IP to the LAN-side client, which seemed to go ok. I then tried to create a forwarded port as shown below. The first time I tried, I got a message about my request being queued and applied shortly. But the saved port forwarding never appeared. I then tried to recreate the mapping, but was first told that the rule was conflicting with an existing one. When I tried again, I was told the rule was saved, but it then never appeared on the port forwarding screen. Note the OnHub appeared to go briefly offline without warning when saving a port forwarding rule.