The low-down on home routers – how to buy, what to avoid

Ever had the experience of not realizing you’re a subject-matter-expert until someone brings up a topic on a mailing list and you find yourself uttering a pretty comprehensive brain dump about it? This happened to me about home and SOHO routers recently. So I’m repeating the brain dump here. I expect I’ll get some corrections, because at least one of my regulars – I’m thinking of Dave Taht – knows more about this topic than I do. But here goes…

If you’re looking to buy or upgrade a home router, I’ll start with some important negative advice: Don’t go near hardware with a Broadcomm chip in it. The current too-weak-to-thrive threshold for router hardware is Don’t trust vendor firmware! Always reflash your router with a current version from one of the major open-source firmware stacks.

If your prompt reaction is “I ain’t got time for that!”, then the Romanian, Bulgarian, and Russian cyber-mafias thank you for your contribution to their bot networks and promise they won’t do anything really bad with your router. But they will sell control of it to the highest bidder, all right.

Yes, it’s that bad out there. You’ll understand something of why by the time you finish reading this.

In fairness to one vendor who seems to be trying to do right, Ubiquiti may be an exception to the vendor-firmware-sucks rule. They have very good buzz among my knowledgeable friends, but I haven’t tested their stuff myself and experience has taught me skepticism in these matters. So I can’t recommend them as an alternative to reflashing yet.

There are two major open-source firmware distributions and several tiddlers. The tiddlers haven’t attracted enough of a community to self-sustain and are best ignored unless you ahem crave adventure.

The majors are OpenWrt and DD-WRT. For a while OpenWRT looked almost moribund and there was a third called LEDE that was an OpenWRT fork, but no more. It looks like LEDE has merged back into OpenWRT and revivified it. They shipped a new stable release at the end of January 2019.

DD-WRT is a different project than either OpenWRT or LEDE. It’s not as well run as OpenWRT, which actually has one builder and stable releases. DD-WRT survives mainly because it has good support for one common SOC that OpenWRT/LEDE doesn’t – IIRC it was some exudation from the never-to-be-sufficiently-damned Broadcomm (“Our products are shitty, but boy are they cheap!”).

I’ve found OpenWRT very solid and reliable; the reason my knowledge of the state of these projects got a bit stale is that my router Just Works and has Just Worked for a long time. I have a plan B to buy one of the Ubuquiti routers if OpenWRT shits the bed, but I’ve never come even close to exercising that option.

(Note: What I’m actually running is CeroWRT, a now fairly old fork of OpenWRT by my friend and semi-regular A&D commenter Dave “Bufferbloat’s-Bane” Taht that he wrote to experiment with improved buffer-queue management; since then his patches were merged upstream to OpenWRT/LEDE and Linux and CeroWRT has been discontinued.)

My current recommendation, therefore, is to flash OpenWRT if you can and DD-WRT only if you must. At 846 vendor/model combinations OpenWRT has pretty broad support.

If I needed a new router today (I don’t, I have a couple of cold spares) I’d trawl e-Bay for a one-generation-back commodity router on the OpenWRT support list that does have 4GB+ flash and 32GB+RAM and doesn’t have a &$@*$! Broadcomm chip in it, buy it, and flash OpenWRTs latest stable release. I’ve had good history with Netgear, so I’d probably look at those first.

Flashing OpenWRT is not a complicated or lengthy process, and you will get the happy feeling that comes from high confidence that your router isn’t infected with vendor malware – a serious issue, some of them have pulled very evil shit like rewriting HTTP traffic to push ads of their choice at you, and if you’re wondering if those ad sites are also likely to be malware vectors the answer is “Why, yes, well spotted.”

Even when the vendors aren’t actively evil, remotely exploitable bugs in router firmware stacks have been depressingly common. The problem is not usually kernel-level but higher up, in the admin stack; simple factory misconfigurations (for example) can leave your device totally vulnerable even when the individual software components are sound.

The pragmatic reason to go with OpenWRT is that it greatly decreases your odds of having this kind of problem out of the box and improves your odds of a prompt fix if there is one. It’s a plain fact that OpenWRT ships buggy releases far less often than vendors do.

These are the major reasons I say “Friends don’t let friends run proprietary router firmware.” Ubiquiti *might* be an exception, I’m prepared to be cautiously optimistic on that score, but in general it is not safe out there in vendor-land. Not even close to safe.

OK, now let’s take a look at why it’s so awful in vendor-land…

You have to start by knowing how routers are developed. Almost nobody in this space spends actual NRE on hardware development beyond what it takes for the cases to look different. What happens instead is that there are a handful of reference designs by chip and SOC vendors that get replicated endlessly. This is why, if you look at OpenWRT’s support page, you’ll notice there are a lot fewer images than there are supported routers. I didn’t do a full count, but it looks like there are less than 30 for those 846 products.

Cisco is an exception to this pattern, but only in the commercial-grade hardware they sell to data centers – their SOHO routers are cheap flank guards for the upper end of their range, built on the same reference designs as RandomRouterCo’s. Ubiquiti is not an exception. I can tell both things by noticing that all the Cisco and Ubiquiti stuff on the OpenWRT support list uses a handful of generic images.

Ubiquiti’s value add, if it’s real (which I’m willing to believe – everything I can see from the outside suggests a smart, well-run company) is going to be mostly putting more talent and money into the software end. Which is exactly what I would do if I were running their business strategy; software differentiation is way less expensive than new hardware design. They might do some of the latter, but probably not at the SOHO end of their range – it’s not cost-effective there.

In a market structured like this, optimal strategy is to buy cheap generic hardware and let open-source obsessives add the value on the software end. The main thing you need to be careful about is flash/RAM capacity; everyone’s incentives favor cutting BOM to the bone, and given the fixed coast of the reference designs the best lever on that is to lowball flash/RAM capacity as much as you think you can get away with without having the product go catatatonic in under 90 days.

There’s also a potential problem with cheapjack Chinese component substitutions that contract manufacturers will do unless you’re watching like a hawk, but everybody has that one. If Cisco and Ubiquiti manufactured in the U.S. it would show in their marketing.

And that’s it. I’ll finish by emphasizing a consequence of these things being variations on a handful of reference designs – flash/RAM capacity and port count are about the only differentiators there are. Even if you wanted to try to buy better quality in the rest of the box by paying more money, that’s remarkably hard to do – they’re like toasters that way, except that you can’t actually bail out by buying a better-designed antique. Alas.