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.
@richb-hanover-priv
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.
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.
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).