Thanks @jow for the insight. And I share the concerns from @tmomas - it will be hard to create and maintain a list.
I started this thread to ask the question "Should LEDE support devices with only 4MB Flash?" The clear answer is, YES.
The discussions also revealed two follow-on recommendations:
For people who want to buy a new router for your home that "just works", we need to make the recommendation to seek a model with 8/64 mbytes.
For those who want to use an existing 4/32 mbyte router, our recommendation should be, "It may work, and will certainly be more effort than using a 8/64 mbyte router. Check the device page and forums for assistance."
Choice #1 is the easy path; Choice #2 is sort of "choose your own adventure."
Beyond that, I would want to stay away from defining various levels of support since those suggest much larger commitments of attention/effort/understanding than most/any of us are willing to offer.
How do we get now the classification Full/medium/small/micro for each supported device? As far as I have understood, there is no general rule, and free space after installation (and hence the classification) depends on the specific device.
1145 devices in the ToH
638 devices listed as supported by LEDE
170 thereof with 4MB flash
I can certainly add a new field to the dataentries, but before doing so, I would like to have the classification for each device, in order to have this field filled for all devices and being useful for the users.
A list that is automatically generated via script would be prefered; a manually updated list should be avoided (high maintenance effort, never complete, always outdated).
Could you generate such a list?
Is it possible to get the amount of available flash out of the build system?
That is a good summary. The key thing is to warn people looking for a new router that anything below 8/64 can be considered challenging.
I feel that trying to figure out yet another classification and to maintain it would be too burdensome in the long run. We should not make the device database over-complicated.
My suggestion for supporting 4MB devices with honest releases is just to scope them back to the epoch they birth from.
The means the build config removes IP6, SSL, and thrifted other features (dnsmasq extra lite). Non-ssl luci and qos scripts are mostly plain text and squash nicely. SQM has unique binary dependencies and doesnt.
LEDE/OpenWrt are not just for enthusiasts. Low income markets benefit greatly from back generation hardware given new life with open source software.
Maybe... But only if they come with significant technical backup.
There's a corollary in with eyeglasses. In the US, there are dropboxes around where you can donate your old prescription eyeglasses. It feels like a "good thing to do".
But the costs of sorting, categorizing the prescriptions, repairing, cleaning the used glasses, then trying to match them (both for the prescription plus the style) to people who come in is daunting, and arguably not even cost effective.
The same argument holds with routers. I would only advocate LEDE (or or any open source firmware) for someone who already knows (or is motivated to learn) how this stuff works. You can get a pretty decent $12-15 router from eBay. Putting LEDE on it, without the safety net of a local friendly techie, is beyond most people's pain threshold.
This is what I repeatedly see in the OpenWrt forum: I have a device with only 4MB flash. Which packages can I safely remove to get OpenWrt (+some other packages) on it?
The usual suspects are IPv6 and PPP and its relatives (and their LuCI front-ends). Of course, not everyone can/wants to do without that, so... There's no catch-all solution for everyone.
luci-ssl isn't enabled by default (for the security concious, it really should be, but it's both an issue of size (hard to fit into 4 MB at all) and making it more difficult for the user to deal with self-signed certs - not all browsers do allow ignoring the certificate error). IPv6 can't be disabled for a release build, because toggling the setting has quite significant effects on conditionals in kernel and other packages, but given that all firmwares are created from one kernel/ packages build, you'd have to decide to toggle the setting for all (even the routers that are more than capable) or no one (which would be a bad idea and quite a regression these days, with DS-lite becoming common place).
That is the problem, devices with 4 MB flash/ <=32 RAM are quite limited, yes catered individually for your own needs, you are able to extend their life time by quite a bit, but these tradeoffs are pretty individual. This is nothing you can really solve in the prebuilt (release-) firmware images, once they've fallen off the cliff and no longer fit the 'default' release image.
Edit: a quite 'entertaining' illustration of this could be TP-Link TL-WR841N(D) - LADUS build, which goes back and forth which components are actually needed. While ppp/ PPPoE isn't necessary for cable customers, users with ADSL/ VDSL usually hard-depend on it - at the same time many cable users will need IPv6 functionality (DS-lite), while ADSL/ VDSL users typically still have a real IPv4 address (and either full dual-stack or no IPv6 at all). The same argument goes for pretty much all other (de-)listed features, neither of them is particularly large, all of them can be considered basic functionality for a modern router - but you simply can't fit them all at once.
I'm probably an outsider to this discussion, as I'm using LEDE not as an alternative router OS for existing mass produced hardware, but as an efficient embedded Linux for more specialized hardware (probably one would call that "IoT", although I hate the buzzword).
I hope I understand correctly that LEDE actually aims to expand from the router-only space into the more general embedded space.
On that ground, I think there are two quite different angles to look at the "old" device support question. It's about 4M/32M now, but it will be about 16M/64M not too long in the future.
The router case: router hardware has a release cycle that automatically corresponds more or less with what users demand from the software installed on these devices (in average), because that's what such hardware is designed for. Nobody expects to use 10 year old router hardware to get latest and greatest IPv6 firewall, VPN etc. And routers are readily available, cheap mass produced hardware - if it turns out the old hardware cannot support a new release that is absolutely needed, the hardware can (relatively) easily be replaced with a newer model.
The embedded case: these can be devices in installations that have totally different hardware release cycles. The actual application of such a device might be static for 20 years. These use LEDE for having a Linux OS and a (possibly wired-only) network stack that can be updated not for features, but for security (closing vulnerabilities, replacing broken cyphers by new ones). For these devices, the key is efficient maintainance: How long will it be possible to use a current LEDE build system to still build custom images small enough to fit into existing hardware? 2 years? 5 years? 10 years?
I think it is important that LEDE separates these two questions, and has a clear statement to both.
I totally agree it does not make sense to support old router hardware for too long.
But embedded applications should not have to fear that 16M/64M platform level support will end once the majority of router hardware has 64/128, for example by making decision for a memory-instensive base system component (think something like systemd).
The length of this thread (94 comments already) and the effort (from involved parties) already exerted on it are good enough reasons to "drop" 4Mb/16Mb devices.
I'd second suggestion to leave the Image Builder and SDK for them be, so that enterprising/techie souls can make their own firmware, but do not generate ready-to-flash images.
Would that help avoid ambiguity on wiki pages with level/status of support?
@stangri - I agree that the "easy install" instructions should only allow 8/64 devices. Toward that end, I have updated the Quick Start Guide to recommend 8/64. Please check to see if the page makes sense: https://lede-project.org/docs/guide-quick-start/start
Would be good if we dropped "trunk" and used "development snapshot" instead, it comes from svn's name for the main development branch but now they use git where the name is "master" or "head".
In general it's not something easy to understand unless you were a long-time user of OpenWRT or SVN
Many devices don't have a WAN port, and even those that have one will likely not work with your instructions.
Default home network subnet is 192.168.1.x, the same as default subnet of LAN ports in LEDE. It's very likely that just connecting the WAN port to an existing network will NOT work as NAT (what is used on that port) works only between different subnets.
We had at least a couple guys on forums asking help for this issue after they followed your instructions (or for devices without WAN ports), so you can improve what I wrote, but not remove it or move to optional stuff.
Rich, this article looks very well written to me. In the future, would be great to have a set of screenshots (yeah, probably separate for each theme or at least for default theme, as navigation is a bit different between them) to show how to complete the setup from luci and I think it's a great idea to have a small explanation why does LEDE ship without the pre-set password with WiFi disabled. It may not be as obvious to a lot of non-techies.
I am happy to relegate the "trunk" name to the back burner, in favor of the "development snapshot" term (or maybe just "snapshot" for short...) That's what's on the downloads page, anyway...
I have modified these pages to see how it reads...
It has always been my desire to have this page provide simple, clear instructions for people with the most common use-case: "normal routers" that they want to use in their homes.
For others, people who want to embed LEDE in other devices, who want to make special configurations, etc., the instructions can send them to the forums or to separate pages of the site.
I added another prerequisite to the Quick Start Guide that the router must have a "LAN and WAN Ethernet port", and send them to that separate page if that's not the case.
I would submit that these people should be sent to a different page before they even begin the steps of this procedure.
[quote] ...and even those that have one will likely not work with your instructions. Default home network subnet is 192.168.1.x, the same as default subnet of LAN ports in LEDE. It's very likely that just connecting the WAN port to an existing network will NOT work as NAT (what is used on that port) works only between different subnets.
[/quote]
Hmmm... I haven't thought about "double-NAT from the same subnet range" in a while. Maybe someone can tell me if it should work or not... Otherwise, I'll have to try it myself.
And those folks are best served by getting them to the forums before they run into trouble, so they can converse with people have already addressed the problems.
