Recommended / Limited / Difficult for use with OpenWrt

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 Follow instructions here using bootp and should be good
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

I think the de-bricking ease should be a factor as well (and probably possibility to revert to stock). Because bricking happens. So, particularly for a novice user who may just have one router, it would be good to have a safety net in case things go wrong. Also sometimes a user flashes OpenWrt then realise it's not for them, so for a novice-friendly devices, reverting to stock should be conveniently possible.

@tmomas wrote me a thoughtful note regarding my proposal. His questions made me think more about the motivation behind the Recommended/Limited/Difficult proposal. Rather than writing it (only) to him and then repeating it, here are my thoughts:

TL;DR: Yes, this change is primarily a "Recommendation for Newcomers to Get a Good Router". Although OpenWrt is good for many things, we are known for making a great router - it's our "brand". That's what initially makes people pay attention to the project.

I believe newcomers are our most important (untapped) resource for OpenWrt. To get them working easily on robust, reliable router only enhances the project. That's why I'm focusing the energy onto this subject.

Longer answer:

  1. I want to be sure that smart people who are curious about the project can quickly see that OpenWrt could work for them. Having a clear indication of a good path forward helps. A modest set of recommended devices with straightforward installation instructions are critical for this. (Imagine the alternative: it's daunting to try to decide between 100 different devices, with conflicting "recommendations" and a tricky installation process. A router that features debricking instructions simply induces quesiness. A newcomer would feel justified staying with their crummy vendor firmware.)

  2. The bump to a minimum of 16MB Flash puts us in a very good position for the future. We've been running into the 4MB limit for (over) two years as the firmware grew incrementally. Having "four times" the space (more realistically, it may only be twice as much Flash) for the base system still retains a lot of headroom for growth of packages. I can't guess how long that would be, but given the relatively slow rate of kernel growth, I suspect that people will be able to install newer OpenWrt firmware in their 16MB devices for quite a while.

  3. What's the use case for these labels? I am explicitly focusing on routers. It seems that 16/128 gives us enough space to install virtually all the router-like packages in the router. (I am hopeful that it will be long time before we again have to get into the business of counting kilobytes to install a VPN package, the SQM package, the adblock package, etc.)

  4. To avoid bulking up the Flash requirement, I explicitly excluded "server-kinds-of-things" from being a requirement. Setting up a file server, weather station back end, Wordpress, or even your full IT infrastructure is definitely cool, but you a) are probably already an expert, and b) can locate a device with greater capacity. (If it's confusing to have this in the bullets, we should remove it.)

  5. As for Experts, these labels won't really tell them anything that they don't already recognize about their hardware. They'll likely be looking for a specific set of capabilities, and can ask cogent questions on the forum to get help.

  6. A lot of members on the forum are weary of having to say, "Sorry, your router won't work with ..." I want to be protective of everyone's time, so that we don't burn out otherwise helpful and friendly people on the forum.

  7. Finally, I also want to emphasize the magnificent job @tmomas has done to create and maintain the ToH infrastructure. It makes it easy for me to glibly say, "Let's just filter out all the devices that don't meet our criteria..." and get credible results. I have some thoughts on implementing this in the ToH. I'll add those to the Machine Readable topic.

Thanks again for the discussion.


In this same line of thinking if we can come up with a decent machine readable TOH then I think an interactive recommender using Javascript in the browser with real time filtering is probably reasonable to make. That's my goal there.


...but installing tftp32 is OK?

Just asking to get a clearer picture.