Recommended / Limited / Difficult for use with OpenWrt

A recent conversation amongst moderators/developers/admins/senior folks about how to help people with older devices has led to the proposed policy: Device Support and Suitability for OpenWrt

We propose to label various kinds of devices with regard to their ease-of-installation of the current version of OpenWrt. The three labels would be:

  • Recommended - straightforward for newcomers to get OpenWrt going

  • Limited - OpenWrt works, but certain hardware/software limitations may limit options

  • Difficult - OpenWrt can be made to work, but needs a lot of knowledge to get it going.

The full proposal is at:

There is a sample "Recommended for OpenWrt" Table of Hardware at:

Let's continue the discussion here. (And remember: Rule #12...)


This serves exactly zero purpose as it is and I'm sure everyone wants to know how that discussion went in the first place since one the purposes of LEDE (which then merged back to OpenWrt) in was to have open discussions.

I'm all ears to know how this going to be progress as it will highly affect the evaulation (possibility) of having patches merged since we're already on the borderline of supporting 4/32 (and similar devices) and 4.19 will more or less be impossible without heavily stripping kernels etc making firmware images/default configurations highly inconsistent.

This looks like a documentation policy, not a development policy and does serve an important purpose.


I agree with the lists of limitations for the tiers. I think the reasons why a device ends up being labeled as limited or difficult should be listed for each device, so that each user can decide if they are important in their use case.

One thing caught me in the present, proposed wording:

current version of OpenWrt without reservation

I don't know that I'd say "without reservation" as there are likely going to be devices there that there are reservations about, even though they may appear to be suitable.

Perhaps something like

current version of OpenWrt, based on its specifications.


Optional support for a file server, Wordpress web server, or other “big” services

that's pretty broad. I might change that to something more like

Has resources that likely allow installation and operation of small-scale executables, such as personal file and web servers

I'm pretty sure that my Wordpress install would not run on an all-in-one router, especially the image upload/thumbnail/gallery services.


One of the biggest obstacle to install Openwrt is to buy an suitable Device, because it is huge difficult to find out what is working and what are not and if the information inside the list actual and true.
I does not mean if the 5G-Wifi of the device xyz are working or not, this should now be inside the list.
I mean things like hardware-NAT or how stable are the Wifi and which modes are supported.
It exist some threads from people where have installed openwrt and are disappointed because the stockfirmware are very faster.
It exist Router where the manufacturer advertise with openwrt but in real use there her own openwrt with propatary driver and the driver for openwrt are unstable.
And when i read a littlebit inside Forum i find out that now a stable Driver exist but only possible or not and inside the doku standing unstable no idea what are be right.
For this reason it will really interresting how many people are engage for this device and for each fact/changes should be a date.

1 Like

@Plonk34 makes an excellent point, one that perhaps could be addressed after a good "first cut" based on hardware alone.

Just because a device has good capabilities, doesn't mean it easily can be flashed, or then runs smoothly.

How to fairly manage a "Highly Recommended" or "Ideal for OpenWrt" list, or to fairly "push down a notch" is probably a discussion on its own.

I would like to have some kind of Amazon Openwrt Star ratings with swarm intelligence ;- )

It more or less boils down to much support there's in mainline :wink:

Question to all: Which of these installation methods would qualify for "Yes, that is easy installation?"

This posting is wiki, i.e. everybody can edit the table below.

Installation methods taken from

Installation method Easy? Noob? [Y/N] Advanced / Amateur [Y/N] Developer / Pro [Y/N]
Asus Firmware Restoration Tool
brnboot web recovery
CF card No (who has a CF adapter handy?)
CFE TFTP + serial recovery No
CFE TFTP recovery
CFE web recovery Yes (It seems fairly easy)
CLI generic
D-Link recovery GUI Yes
GUI generic
JBoot web recovery
Linksys TFTP
Mikrotik TFTP
RedBoot TFTP + serial recovery No
RedBoot TFTP recovery
SD card Dicey if you need to format Linux on a Windows/Mac, OK if "dd" of a full-disk image
see devicepage Unlikely
see forum Unlikely
see git-commit Unlikely
Serial No
Sunxi installation
Sysupgrade Yes
TFTP generic
TP-Link TFTP Archer C7v2 era, yes, later?
U-Boot TFTP + serial recovery No
U-Boot TFTP recovery Generally yes
U-Boot USB recovery Generally yes
U-Boot web recovery Generally yes
unknown No
x86 installation With improved instructions, yes (see notes on "SD Card" as well)

@tmomas Each of them is easy, but only if there are very good dokumented

1 Like

To qualify as easy you should be able to do it without installing any additional software from a vendor, and without any additional hardware required, and without opening the case. This leaves pretty much "from the factory firmware web page" and TFTP from uboot, and by writing the image to an SD card.

1 Like

Anything that requires soldering or cracking the case, definitely not.

Anything that requires hardware of any sort (serial adapter, for example) other than the router and either a Windows or Mac, no.

Web-based, be it OEM run-time, or boot loader that can be accessed without serial, cracking the case, jumping up and down three times while the moon is full, ... is probably easy.

SSH, telnet, TFTP, that can be accessed without ... is probably OK, though not "easy".

Anything that requires flashing twice (such as having to flash OpenWrt over both instances of OEM firmware on dual-firmware devices) is probably not easy.

Edit: Anything that the name of the "TFTP" file isn't 100% certain, no.

1 Like

Maybe I was editing at the same time.
I'll keep my hand off from the table above, so others can edit.

Your + dlakelan's comments are already helpful!

Can you identify (=list) all those devices?
We could put "requires double flashing" in the Installation methods or in the installation comments:

Hopefully none! You should have the comfort of the "other" firmware being functional.

I'm beating my head against the wall to prevent that from being a requirement on the dual-firmware device I'm working on.

I think anything that doesn't require hardware modifications or special hardware and can be done in 15 minutes or so qualifies as "relatively straight forward". To me that includes things that require TFTP but excludes stuff like Xiaomi 3G (chinese interface, have to download app and register, several steps of flashing using USB and SSH).


I'd add to that insight that the steps should work pretty much the first time through.

As an example of what falls outside of that, the mess of different addresses and file names for the Archer C7 variants. If a user needs to install and learn how to use wireshark to figure out the right "magic", then it moves to "marginal" for me.


For firmware revisions before 3.14.1 (140929), the router looks for an IP address of and a file named ArcherC7v2_tp_recovery.bin . Firmware 3.14.1 updates the bootloader to look for an IP address of and a file named ArcherC7v3_tp_recovery.bin even on hardware v2 units, but may also load ArcherC7v2_tp_recovery.bin . Some v1.1 units may also look for ArcherC7v1_tp_recovery.bin . The model Archer C5 looks for the file ArcherC5v1_tp_recovery.bin .

Setup your computer to or as appropriate for your version (SubnetMask /24 = and connect it to LAN1. Start TFTP server (e.g. tftpd-hpa on debian) and provide recovery file with it. An Archer C7 will repeatedly try at 5-second intervals to connect to the TFTP server if you have the “wrong” address.

Even worse is this mess -- I can reflash an Archer C7v2 in my sleep at this point, but I would run screaming if this was "Easy OEM GUI Install"

1 Like

I agree with this, it easily overwhelms a novice.

But at the same time I do actually consider this to be a reasonably easy and straight forward method of recovery and/ or installation nevertheless. The reasons for this are that it doesn't need opening the device and works reliably (with little, but non-zero, risk of perma-bricking the device).
Yes, I usually have tftpd's logging jacked up and watch journalctl -f for the tftp GET and success messages.
Yes, I usually have wireshark open to confirm that IPs and requested file names are correct.
Yes, I do put an unmanaged 100 MBit/s switch between my workstation and the device, to avoid the link down event and link (re-)training.
But it works, reliably, every time - and in case of problems it allows some insight into debugging (are MAC addresses, IPs, filenames correct, does the tftp transfer start and complete).

ADAM2/ EVA ftp based flashing (mostly AVM devices) falls into a similar category, yes it's not newbie friendly (and getting the correct point to start the ftp connect can take a few attempts), but it is a relatively failsafe and straight forward procedure - if documented correctly.

Is it as easy as uploading a factory image from the OEM firmware, not at all, but if you follow the documentation, you will succeed with relatively little risk of damaging the device (snapping off plastic clamps while opening the device, botching the PCB while soldering, etc.). It is not something everyone will be comfortable with, but if you have some patience to read the documentation and trying to understand it, chances are that at least slightly tech-savvy new users will experience success.


So looks like we need a another category.
Recommended for experts (Non-Novice)

1 Like

Or, perhaps the other way around, a smiley face "novice-friendly install from OEM" near the front of the data row (as once you're past that, it's a one-off pain).

1 Like