Should OpenWrt/LEDE support devices with only 4MB Flash?


I'm using LEDE even on Nanostation2 4MB flash/16MB ram - with Luci.
This is internal AP so don't need:

  • disabled IPv6,
  • remove all related elements to iptables
  • remove dhcp servers,
  • remove opkg - not needed as I don't have more place and ram :slight_smile:
  • added LUCI and zram

I have few router TP-link 4MB flash/32MB ram so there just disable IPv6 and remove opkg, and add Luci, wireguard, Zram

So I think there is no point to complain just read:

And once again thanks developer for their hard work and making openwrt/LEDE so modular that everyone can take what want/need


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?

Would be worth mentioning this in the Frequently Asked Questions: Before installation, or setting up a separate wiki page for this FAQ if the answer is too big for the FAQ.


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 updated the Quick Start Guide with a note that the procedure described on that page requires an 8/64 MByte router.


Done. Everyone are welcome to correct/add/remove this post in


Tweaked that post. Please check for correctness. (It might help to list the correct package names to add/remove)


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.

  1. 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.

  2. 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).


Remove debug symbols, compile with gcc 6.3, squashfs block size to 1024KB, strip etc.


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:

For the more adventurous, or those who are willing to work harder to flash LEDE in a device, I have also factored out a separate "Trunk Installation" guide at:

Are there other places in the site that need the 4/32 vs 8/64 warning?


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

Also, don't cut out the networking instructions as I wrote in an old revision of that page

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...


I factored that discussion out to a separate page ( and listed it as a separate optional step because it made a huge increase in complexity.

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.
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.


[quote="richb-hanover, post:101, topic:1018"]
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...
[/quote]It will not work. Routing logic goes partially wrong if you have the same subnet on both LAN and WAN side. (It may actually work partially, but half of the packets go missing etc. causing latency, download problems = mysterious opkg problems etc.)

It might be added as a checklist item for the installation instructions, that the WAN should not have 192.168.1.X subnet as that is the default for LAN.

  • If you have upstream WAN (router, ISP) that provides an address from the 192.168.1.X subnet for the LEDE router, you need to change LAN subnet to something else before connecting WAN.


Regarding the default IP address, Alberto's page suggests changing the IP address to something other than, and this is the very first thing I do on every install. What are the challenges of making a "wholesale" changes in the default delivered IP address for all LEDE devices to something less common ( etc)? FYI Gli uses

Regarding the other playground pages in process:
In the section "Installing LEDE System Upgrade" I believe it is relevant to note that the process described assumes Luci is installed. This process does not cover a CLi only device. Should this section be renamed "Installing LEDE System Upgrade with LuCi"?

There is a drastic difference between Rich and Alberto's pages, being that one is written from a UCI perspective (snapshot builds with no Luci) and the other with Luci installed. I believe there need to be 2 clearly defined paths and see Rich has created a blank page for this.

I agree with Rich that going directly to an AP deserves to be separate and that all users should build a standard router first. There already are wiki pages for Dump AP in OpwnWrt, but I am not seeing this on LEDE.

Regarding "Many devices do not have a WAN port", I believe that the standard instructions will work for a single port device up to step 5 here: . Not all single port devices are used as Access Points. There are many "Travel Routers" (HooToo TM-02 and many TP-Links) that are intended to connect to a WISP\AP\STAtion. I think it would be helpful to cover enabling and configuring wireless via UCI. The user will need to know the credentials and security for the WISP\AP\STAtion they wish to connect to. This could be added to the "Router vs Access Point" page content and linked from step 5. For devices with Luci, this can point to an existing(?) wiki.

On this new page can we please add at the top a note about the life cycle of "Snapshot" builds and packages (they change almost daily, packages may be build specific, you may wish to download all the packages for your build w wget to support your particular install going forward). There are a number of users who will adopt snapshot as they need support for a new router not supported in Release 17.01, but also want stability until the next release. This may also need to link to other wikis on extroot and modifying the default package repository.

A number of these comments are based on my experience installing "snapshot" on a HooToo TM-02, with a single LAN and USB.

I think Rich may have incorporated some of this, but I am not clear on how these pages sequence at the moment.


Should we be moving this discussion to the Documentation section here?