UniFi Disappointment Router?

The UniFi fanbois were aflutter when Ubiquiti released this video promoting an upcoming UniFi Dream Router:

It sounded like a substantial upgrade to the UniFi Dream Machine: WiFi 6, two ports of PoE, 128GB SSD, an SD slot for storage expansion, and the ability to run Protect and other Ubiquiti controllers that haven’t been available to UDM users due to the lack of storage.

Then it hit the Early Access store for $79. Huh?

Turns out it’s based on MediaTek’s MT7622 platform. Two slow ARM A53 cores vs four fast ARM A57 cores on the UDM. It’s not a Better UDM, it seems more like a move to bring the “UniFi Dream” vision to the entry-level consumer browsing the shelves at Best Buy.

At the software level, like the UDM Pro SE and UXG Pro that still remain trapped in Early Access, the UDR runs on Debian 9 and ditches the mutant Debian unifi-os container. Hopefully that brings a significant reduction in CPU utilization, because my own UDM Pro typically sits at 30-40% just running Talk and Network without IPS/IDS, and I’d expect that to translate to 75-100% on the UDR’s CPU.

Early reports are that the boot process takes upwards of four minutes, LAN to WAN routing is maxing out around 800Mb/s unidirectional and enabling IPS/IDS drops to around 500Mb/s. I don’t think the routing performance is a significant concern for people who’d buy this product at $79 (or $159) but hopefully there’s more optimization that can be achieved because line-rate ought to be table stakes in 2021.

Where I do think Ubiquiti has missed the mark is on the storage and promoting the UDR as running the full suite of UniFi controllers.

SD cards have a well-deserved bad reputation for reliability. These days there are many cards rated for continuous usage in NVRs but the Average Joe is going to buy the cheapest card on the shelves and there’s the longstanding problem of avoiding counterfeit cards.

They could have made the M.2 socket easily accessible for upgrades, though it’s understandable that they wouldn’t. For the target audience, external USB storage would be the best option and the MT7622 does provide a USB 3.0 host.

On the controller front, given the relatively low-performance CPU and 2GB RAM, promoting this device as running every UniFi controller just seems unwise. The Access and Connect markets shouldn’t be bothered by needing a $379 UDM Pro or $199 CloudKey Gen2 Plus, and while Talk on the UDR potentially has an interesting use case as a teleworker gateway, especially with the direction UID appears t be headed, at the moment Talk is a long way from being suitable for that purpose.


Longer-term, Ubiquiti needs to free these devices from the constraint of being locked to their on-board Network controller. The entry-level buyer whose needs eventually push them to a higher-level “UniFi Dream” router will be left with an attractive piece of e-waste because the onboard AP and switch can’t be adopted to their new UniFi Network controller.

Isolating UniFi Devices

I’ve been lax in firealling my VLANs at home, but with the recent controversy over UniFi devices phoning home without consent, this has taken on renewed importance. I’m also taking on a new tenant in my detached apartment and would like to keep all their stuff segregated from mine.

Fortunately it’s all pretty easy.

For my network, I’m keeping my Cloud Key and Pi-Hole on the main LAN. I have additional Corporate VLANs created for Management, Cameras, and the Apartment.

In the Firewall rules, for WAN_OUT I’ve created two rules to Drop all traffic from the Management and Cameras networks. They cannot reach the Internet at all.

To allow and deny particular cross-VLAN traffic, the first step is to create a group of all the Private IP address ranges:

  • 10.0.0.0/8
  • 192.168.0.0/16
  • 172.16.0.0/12
  • 100.64.0.0/10 (this is CGNAT, might be a bad idea if your ISP uses them)

Back in the Rules area, LAN_IN needs a series of rules:

  • Allow (Management | Cameras) networks access to the CloudKey.
  • Allow (Management | Cameras | Apartment) networks access to the Pi-Hole.
  • Drop (Management | Cameras | Apartment) networks access to the Private IP ranges group.

The Allow rules must be before the Deny rules for each Network.

The gotcha with denying devices access to the Internet is that they cannot directly obtain firmware updates. For UniFi Networking products this can be worked-around by having the UniFi Controller cache the firmware prior to upgrading — see Settings -> Maintenance -> Firmware.

I’m not sure whether Protect can distribute firmware updates to the Cameras. Guess I’ll find out the next time there’s an update available. Once my UniFi Protect NVR arrives I will place that in the Cameras VLAN so that traffic doesn’t have to cross the router and figure out the WAN_OUT / LAN_IN firewall rules needed to keep it happy.

Ring and Retry

I have a Ring Doorbell Pro on my front door which has always been problematic. At first I could get it to join the WiFi but then it would error — turns out it was trying to use an outside DNS server and I had blocked clients from using any DNS but mine.

When I replaced my temporary AmpliFi setup with UniFi, I couldn’t get it to find my SSID at all. I literally held an AP directly in front of it and it would find several neighbors WiFi but not mine.

img_3400

I read somewhere that sometimes a Ring will get confused seeing several APs broadcasting the same SSID, so I decided to give it its own AP and SSID on 2.4GHz-only. I put it in the attic slightly offset from being directly above the door. This has mostly worked ok, except that it takes a long time to re-connect after the AP reboots from firmware updates.

Today I had cause to look at my AP retry rates…

Screenshot 2018-11-07 at 12.23.20 PM

And the Ring’s AP retry rate is just ridiculously bad. I crawled into the attic and shoved the AP all the way into the soffit. Gained 6dBm but the retry rate didn’t budge. Changed from Channel 1 to Channel 11, no difference.

Then I had the thought that, since initially installing this stuff, I’ve put a great deal of effort into tuning the power levels and minRSSI values to get devices to use the right AP instead of clinging to a poor signal. Let’s try turning off an AP in the attic I don’t really need anymore, bring the one I’ve been using for the Ring back into broadcasting my normal SSID on 2.4GHz and 5GHz, and trying joining the Ring to it.

And it joined right up! On 5GHz. The signal is decent and the retry rates have dropped to a more reasonable level. Huzzah!

Blasting WiFi across the street

I have a lot of front yard to maintain.

img_0160

UMA-D_Front_Angle

It would be nice to have good WiFi signal while mowing all this lawn. There’s an AP in the attic above the front door but the signal doesn’t reach all that far, maybe 30-40′ out. I needed something with a bit more oomf and the UAP-AC-M + UMA-D antenna combination sounded like the perfect solution.

If you haven’t heard, the UMA-D is a tiny miracle antenna: dual-band, 15dBi, 45-degrees on 5GHz and 90-degrees on 2.4GHz, for $99. It transforms the otherwise unimpressive UAP-AC-M into a directional WiFi blaster that will send its signal hundreds of feet downrange in open terrain.

As an initial test, I placed the combo in the bonus room knee wall space:

img_0157

Blasting through my roof I was getting about 180Mb/s of download speeds to my iPhone XS… from across the street! That’s 140-ish feet away.

Of course, that wasn’t good enough for me, so I found a pre-existing hole to run an Ethernet cable to and mounted it outside the garage.

img_0214

The improvement is incredible.

img_0269

That’s from my phone. 140 feet away.

If you need to blast a WiFi signal far away outdoors, the UAP-AC-M + UMA-D are a powerful and affordable solution.