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.
On
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.
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.
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.
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 192.168.1.66 and a file named ArcherC7v2_tp_recovery.bin . Firmware 3.14.1 updates the bootloader to look for an IP address of 192.168.0.66 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 192.168.0.66 or 192.168.1.66 as appropriate for your version (SubnetMask /24 = 255.255.255.0) 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"
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.
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).
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:
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.)
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.
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.)
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.)
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.
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.
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.
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.
