Recommended routers

The second half of this page (specific device recommendations) is very outdated.

Users should consider multi-core, ARM-based (or x86_64/AMD64) devices for mid-range and higher applications.

Purchase of a device with less than 16 MB of flash or less than 128 MB or RAM is unwise at this time (2019).

A device with two, “ath10k” radios should have at least 256 MB of RAM. This eliminates the Asus RT-AC58U, RT-ACRH13, and similar.

Really specific per scenario but these are generic recommendations based upon what's considered “reasonable” in terms of reliability and performance. Please note that the OpenWrt project itself does not endorse any hardware or manufacturer unless there's a public statement, this is solely a list put together by the community. General recommendations are at least 16 Mbyte of flash and 128 Mbyte of RAM.

Note that some manufacturers claim “32 mb flash” or the like (small “b”) -- this is 32 Mbits, or only 4 MBytes.

Platforms that have less than 16 Mbyte of flash will have noticeable space constraints. Having less than 128 Mbyte of RAM also imposes limitations, basic network functionality may work however there are reports of memory errors while using opkg and luci among other services which may operate unreliable or in worst case freeze the system. Support for either 4 MB of flash or 32 MB of RAM has already been discontinued, due to the size of the Linux kernel and run-time footprint of the third-party software required for a basic, running OpenWrt system. One should expect that 64 MB RAM will be unsupportable in the near future, as well as support for 8 MB of flash.

A device with two, “ath10k” radios should have at least 256 MB of RAM for stable operation. This eliminates the Asus RT-AC58U, RT-ACRH13, and similar.

For many opinions, see the OpenWrt Forum. For example https://forum.openwrt.org/search?q=favorite%20device

Yes, devices are supported by OpenWrt “snapshots” until a formal release includes the device.

In many cases, a newer device (or one that has recently had OpenWrt ported to it) will only be available as a snapshot build for months (or even over a year) before a formal release includes it. Snapshot (or master) builds and code are not necessarily “less stable” than “release” builds. In many cases the snapshot build will outperform a release build, or resolve issues found in the release builds.

The main challenge for many users with snapshot builds are that they don't come with LuCI (GUI) preinstalled, and many “special” packages a user wants to add generally need to be flashed when the ROM is downloaded and flashed. Getting LuCI up and running is easily resolved with an Internet connection, SSH client, and a couple of simple commands.

See further Development builds / snapshots

All-in-one routers generally are built around a System-on-a-Chip (SoC). They often include a CPU, wireless subsystem, and Ethernet switch. Each of those components can impact performance of the device.

The Ethernet switch usually is limited only by the speed of its “phy”, the portion that connects to an Ethernet cable. A device with a 100 Mbps phy will be limited to ~95 Mbps throughput. A 1000 Mbps phy is not a guarantee that the overall device can achieve gigabit rates. For most users working with a reputable manufacturer, it is sufficient to know that the switch and phys in the device were likely properly matched to the rest of device.

The next bottleneck is the connection between the switch and the CPU. This is, unfortunately, not visible to most end users. One point to remember is that often (2019) this is a single “[R]GMII” connection ([reduced] gigabit media-independent interface) that is limited to 1 Gbps, raw, so bonding ports on the switch doesn't overcome this limitation. Some devices have two gigabit-rate internal links, which are sometimes configured for WAN and LAN.

The CPU, in most devices, needs to handle the packet flow, including firewall, connection tracking, and NAT. It also needs to handle every packet for SQM (smart queue management), as well as other tasks, such as DNS, DHCP, VPN, logging, time keeping, ..., as well as any “unnecessary” functions such as GUI or end-user firmware. For most all-in-one routers, this is a primary bottleneck. As Internet speeds have increased, the ability to do this “effortlessly” with a cheap, single-core CPU has been stressed. A multi-core CPU lets one work with the traffic, while another can handle the other moment-to-moment demands. With the computational loads of a VPN, a multi-core CPU becomes even more attractive.

Because there are tasks other than just routing the traffic, the throughput doesn't scale directly with CPU speed. For example, going from 500 MHz to 750 MHz clock with the same CPU core is going to be less than 50% faster, often a lot less.

The CPU in an SoC is often licensed as a library. Think of it like building a car -- You go to the shop and buy a complete engine, rather than designing and building it from scratch. There are many different architectures, but the most common include:

Older, lower-power design (compute and mains/battery consumption, both). Very common in all-in-ones in the past, and still common in budget-priced “home” routers or compact “travel” routers.

Solid design, basic performance levels. Generally single-core devices. Good “budget” or “travel router” choice, as long as with at least 16 MB of flash and 128 MB or RAM.

Mid-range, MIPS-based SoCs clock around 600 MHz in 2019. Many higher-performance devices clock around 750-775 MHz. MIPS-based SoCs clocked at 500 MHz or below are likely poor choices for purchase at this time.

Common OpenWrt “targets” include:

  • ar71xx (deprecated, ath79 current)
  • ath79 (QCA wireless)
  • ramips (MTK wireless)
  • lantiq (QCA or MTK wireless)

FIXME: Discussion of “unique” MT7621; single/dual-core boards (and any clue as if there is an identifiable, SoC variant), mention of hardware flow-offload (MT7621A for integral switch), including its drawbacks.

More sophisticated, higher performance than MIPS. Generally consumes more power than MIPS (more compute power pretty much means higher power consumption). Common in high-end all-in-ones and becoming common in mid-priced (US$60-125, €50-100, late 2019) devices.

There are “older” and “newer” generations of ARM processors, and a higher “V” or “A” number unfortunately doesn't mean a more powerful SoC. See some details on ARM cores

Moderate to high performance levels. Generally multi-core devices.

Common OpenWrt “targets” include:

  • mvebu (Marvell wireless)
  • ipq806x (QCA wireless)
  • ipq40xx (QCA wireless)
  • mediatek (MTK wireless)

The mvebu units tend to be the highest performance. The ipq40xx units tend to be available at lower price points.

For those desiring “true” gigabit throughput or high-speed VPN, a low-power x86_64/AMD64 SBC (single-board computer) or an ITX board (Information Technology eXtended, a small motherboard form-factor) with AES-NI (Intel's Advanced Encryption Standard New Instructions) and dual NICs is an option. With proper component selection, such devices can actually consume less power than a high-end, all-in-one router, even when paired with a suitable AP for wireless.

Virtually no 802.11 link between a consumer AP and phone, laptop, or desktop in the real world can reliably support gigabit throughput.

Wireless tends to be supplied by the SoC's designer. Almost always the wireless components are part of the SoC and, if they use a second chip set, are from the same vendor.

In addition to the chips themselves, there are “invisible” components that make a big difference in wireless performance, such as power amplifiers, receiver “chains”, and antennas.

You can't judge the performance of an antenna by its looks. Big, fat antennas generally aren't any better than skinny ones. Well-executed patch antennas or internal antennas can be every bit as good as impressive-looking external antennas. For a variety of reasons, using external antennas on feed lines is often a net loss (exceptions being for professional-quality antennas and feed lines for point-to-point links, which often cost more than a high-end router for just one).

QCA Wireless

The Atheros or Qualcomm Atheros (QCA Wireless) SoCs and chip sets are common, have long-established open-source support with both the upstream (Linux) ath-series drivers and firmware, as well as the ath10k-CT (Candella Technologies) drivers, currently “default” with OpenWrt (v19). Support for advanced features such as IBSS and 802.11s tends to be good with the recent chip sets under both the upstream drivers, as well as the ath10k-CT drivers.

older “Wave 1” devices, such as the Archer C7v2, may need to use the non-CT drivers for 802.11s support.

“ath9k” devices are not “better” or “worse” than “ath10k” devices.

MTK Wireless

FIXME: Help describing MTK drivers

Marvell Wireless

FIXME: Help describing Marvell drivers - please note issues with IBSS and 802.11s

Broadcom Wireless

FIXME: Which Broadcom wireless chips have meaningful support?

Broadcom wireless is generally problematic, as Broadcom's support for open-source development is very limited.

Devices with Broadcom WiFi chipsets have limited OpenWrt supportability (due to limited FLOSS driver availability for Broadcom chips). Consider this when choosing a device to buy, or when deciding to flash OpenWrt on your device because it is listed as supported. See Broadcom WiFi for details.

See https://wireless.wiki.kernel.org/en/users/drivers/brcm80211 for more details on specific chips and their level of support.

With NAND flash typically providing 128 MB or more of total storage capacity, many devices now support “dual firmware” with a fail-over if one repeatedly doesn't successfully boot. This makes upgrades and roll-back a lot easier. The downside is that the space for each copy is less than half of the total flash, typically in the 40-60 MB range.

Remember that if you want to use SQM (Smart Queue Management) or similar, hardware flow offloading can't be used.

As discussed above, quite a bit of CPU resources are consumed doing routing and NAT functions. Since router-SoC manufacturers know that device reviewers will measure the throughput of the device under well-known conditions, they often include specialized hardware into the SoC to be able to “offload” basic routing and NAT from the CPU itself. This is a cost-effective way to get “better” numbers and “marketing bullets” for those that use their SoCs (“Full, gigabit routing” or the like).

This specialized hardware often requires closed-source drivers and/or proprietary information from the SoC manufacturer to utilize robustly. As a result, hardware offload to the switch, or to things like NSS cores in the IPQ806x devices, is generally not supported with open-source firmware. This is often the reason why any third-party firmware doesn't match the LANWAN, NAT-only throughput of OEM firmware.

However, if you use SQM (bandwidth shaping, “bufferbloat” mitigation) or similar functionality, you generally can't use hardware flow offloading, but software flow offloading seems to work. Functions like SQM require each packet to be handled by the the CPU, so the various hardware “shortcuts” can't be used. Even with high-bandwidth connections, SQM can greatly reduce “lag”, improve responsiveness of Internet browsing, and make VOIP and video calls smoother. OEM firmware generally doesn't support SQM, so no direct comparison is possible.

Flow offload generally does not improve VPN performance significantly as the limitations there come primarily from the CPU and its ability to encrypt/decrypt the packets and move them between interfaces.

OpenWrt officially supports software flow offload on several SoCs, which can greatly speed “NAT-only” configurations. At this time (2019), the MT7621A is the only device on which OpenWrt supports hardware offload.


Many devices listed below are outdated and no longer recommended (2019)

This page was solely created because people kept asking this question each and every day on #openwrt @ Freenode.

Please also read the wiki page for the specific device as there may be information not mentioned here that may be of value.

If a specific SoC/model isn't listed please look here.

(Qualcomm) Atheros ar71xx

This platform has been supported for years and have a proven to be a mature one including wifi.
Major downside is that it's a family of single core SoCs and their age are starting to show in terms of performance and also compared to what's available in the same price range.

  • AR9331 series uses a cheaper SoC (MIPS 24Kc) and lower clockrates which results in lower performance but also less power consumption making it a popular choice in small designs or development boards.
    <Please provide generic numbers here>
  • AR934X are preferred due to their performance (MIPS 74Kc), usually shipped with ath9k (11n) compatible radios and if any USB 2.0-port(s).
    Generic throughput numbers are about 150-230mbit/s (LAN-WAN without PPPoE) and ~15mbyte/s using the USB interface. Applying QoS cuts throughput in half or more depending on used algorithms. These devices are in general being phased out in favor for the newer QCA95XX-series.US lockdown notes go here
  • QCA95XX are the latest family of MIPS based SoCs by QCA and provide a slight boost in performance (~10-15%) compared to the AR934*-series because of the higher clock frequency. These systems are usually shipped with ath10k radios which supports 11ac however these drivers need to rely more on the firmware blob which makes improving the driver hard. Wifi performance peaks at about 400mbit depending on conditions.US lockdown notes go here

Mediatek MT7621(A/AT)

A quite well supported platform, it has 2 cores and 2 threads (somewhat similar to Hyperthreading on x86) along with a more powerful core (MIPS 1004Kc) which makes this SoC about about twice as fast as the AR934X-series (depending on application). These are typically shipped with 11ac hardware and the driver (mt76) works fairly well, it's still under development but is more open than the ath10k driver making it a more interesting choice for the Open Source community. Generic throughput numbers are about 400-500mbit/s (LAN-WAN without PPPoE) and ~45mbyte/s using the USB3 interface. It's also worth noting that products using this SoC are usually cheaper or priced about the same as the Atheros 11n and 11ac counterparts but might be hard to come by.

Marvell Armada 385 aka 88F6820

This is a platform based on ARM compared to the other ones here that are MIPS based. It offers the best performance but is also in general the most expensive one. It offers 2 cores running at 1.6Ghz and does linespeed NAT. It's usually coupled with wifi using the mwlwifi driver which is not as recommended as others. Wired performance and stability is good(?), USB (status?), SATA (status?) however.

Quite well supported products of this family are:

There may be several reasons, here's a few:

  • Unavailable
  • Not supported
  • Requires serial access (may not be an issue for some) for flashing and/or recovery.
  • Unstable

MediaTek MT7620A

A quite common “value” SoC that's aim for the same market as the Atheros AR9311 SoC. Slightly higher clock speed making it a bit faster while still having low power consumption. Wired performance is stable including partial VLAN support (up to VLAN ID 15?) however some are reported stability issues with 2.4G (rt2800-pci) and 5G radio may not work depending on chipset. MT7610E lacks a driver (please confirm) although some also ship with MT7612E which is supported by the mt76 driver.

Below are some models reported stable.

Needs confirmation: Buffalo WHR-1166D seems to be suitable?

OpenWrt is a community project and works a lot of platforms, these are just a few ones that are “easy” to get working. There are a lot of other products/boards that OpenWrt runs on so be sure to check out the Table of Hardware for more supported hardware.

This page isn't obviously for the hardcore user, if you were you wouldn't be here. =)

This website uses cookies. By using the website, you agree with storing cookies on your computer. Also you acknowledge that you have read and understand our Privacy Policy. If you do not agree leave the website.More information about cookies
  • Last modified: 2024/02/11 21:58
  • by 127.0.0.1