Updated 8/2/16: Link to wireless retest added
eero is not Wi-Fi Certified. It supports only WPA2/AES encryption, so may not work with some older devices. It also does not support Wi-Fi Protected Setup (WPS). So any client you connect to it must be able to have its Wi-Fi network password entered.
eero was not as helpful as Google in supporting our test requirements. Google provided OnHubs configured with a special firmware load that allowed channel and bandwidth modes to be configured for both radios and to forward a wide range of parts needed by IxChariot for WAN to LAN and simultaneous up and downlink tests. Both special ASUS and TP-LINK OnHubs were returned to Google after testing. eero said it does not let the special firmware it uses for in-house testing out, for security reasons. So I had to test with what we had.
eero did reply to questions about whether transmit power is automatically managed (Yes), whether devices are band-steered (Not Yet), whether device load is balanced among eeros (Not Yet. Priority has been on load balancing inter-eero links) and whether 802.11k or v are supported (Not Yet, but 802.11r is supported for fast reassociation). I can attest to the last point. I checked for automatic client roaming between eeros with idle devices and found reassociation was virtually immediate (a second or so). If you don't know what I'm talking about, this Apple support note clearly explains 802.11k, r and v.
Like Google OnHub, eero relies on connection to its cloud host for configuration and management. If that connection is interrupted, not only do you lose internet connection, but you also might lose local wireless connectivity, too.
I tested eero in router mode, with the wired LAN test machine connected to its LAN port and nothing connected to the WAN port, which is the way all wireless routers are tested. But when I started testing eero, I found it reliably dropped the wireless connection after about 5 minutes. eero said this behavior is by design, i.e.:
... our customer production firmware is designed to keep the LAN up when WAN connectivity is lost via ISP error, but not when the Ethernet is unplugged. There are a number of reasons for this, the primary one being that when Ethernet is removed from an eero, the customer is typically expecting it to become a wireless leaf node. So the eero starts searching for neighbors, and upon finding none, tears down its LAN while it hunts further.
So I had to also connect eero's other port to my house LAN for testing.
eero provides no way to set channel or bandwidth mode. But I at least could set the band the NETGEAR R7000 bride mode standard test client connected to. I used a variety of Android apps to correlate the BSSID information provided by eero's app to channels used and found Channel 1 was used for 2.4 GHz tests and Channel 36 for 5 GHz.
I confirmed 2.4 GHz was using 40 MHz wide channels (324 Mbps) and 5 GHz was using 80 MHz (702 Mbps) by checking link rates while running a test stream before testing. These link rates correspond to 40 MHz channel bandwidth, normal guard interval and 256 QAM modulation for 2.4 GHz and 80 MHz channel bandwidth, normal guard interval and 256 QAM modulation for 5 GHz. The test client was connected using WPA2/AES encryption.
I tried to force eero to use 20 MHz bandwidth in 2.4 GHz by setting up another access point on channel 1 in close proximity to eero. It's been awhile since I tested 20/40 MHz coexistence, so I forgot that another network on the same primary channel will not trigger the mechanism. When I put the neighboring AP on channel 4, however, eero switched to 20 MHz mode within seconds and moved right to channel 4, too.
I then tried moving the neighboring AP back to channel 11 to see if eero would switch back to 40 MHz bandwidth. But instead, it switched right to channel 11 and stayed in 20 MHz mode. I tried moving the neighboring AP channel a few more times and each time eero would quickly follow. While all this was fun, setting up another AP in the test chamber to keep eero in 20 MHz bandwidth mode wasn't practical. So I let eero do its thing, which was to use channel 1 in 40 MHz bandwidth mode.
eero were centered on the test chamber turntable as shown in the photo below. The 0° position for the router had the front facing the chamber antennas. I put eero on a platform to get it more in line with the chamber's antennas.
eero in test chamber
Because eero couldn't be forced to use 20 MHz bandwidth mode, its 2.4 GHz results are higher than usually measured for AC1200 class products. So I created a special test category for eero, so that it won't be ranked with other AC1200 class products and screw up the rankings. So view the average 2.4 GHz charts below with eero's unfair advantage in mind.
eero 2.4 GHz Average throughput comparison
The 5 GHz average throughput charts should provide a fair comparison to other AC1200 class routers. Although eero was tested on channel 36 instead of our channel 153 standard, both low and high bands now can use the same maximum transmit power and results should be comparable.
eero 5 GHz Average throughput comparison
The 2.4 GHz downlink profile clearly shows eero's advantage from using 40 MHz bandwidth. You would be wise to not count on this if you use eero in a typical setting with lots of neighboring 2.4 GHz networks. As I described, eero has 20/40 MHz coexistence enabled and obeys it quite well. eero's range appears shorter than both other compared routers, dropping to a few Mbps at 54 dB of attenuation.
2.4 GHz Downlink Throughput vs. Attenuation
The 2.4 GHz uplink plot again shows a similar story, starting with high throughput at low attenuation (high signal). Throughput decline starts after the 6 dB test; downlink didn't start to seriously decline until after 12 dB.
2.4 GHz Uplink Throughput vs. Attenuation
5 GHz downlink shows suprisingly disappointing performance. Although maximum throughput is highest, decline is steep and the connection drops earlier than it should have after the 24 dB test yielding 60 Mbps of throughput.
5 GHz Downlink Throughput vs. Attenuation
For 5 GHz uplink, eero starts out with much lower throughput than the Linksys (347 Mbps vs. 420 Mbps), again drops off quickly and again breaks connection sooner than it should.
5 GHz Uplink Throughput vs. Attenuation
As you think about these results, keep in mind that extreme range and throughput are not usually the focus of access points that are meant to be used as part of a system. In fact, you don't want APs stepping all over each other causing co-channel interference that increases packet loss.