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

For Developers
162

Yes, quite clear. And would you like a little attitude with that? :slight_smile:

If we decide to adopt a BYO category, we might soften the article to say something like this:

Why does OpenWrt no longer support 4MByte Flash devices?
Technology marches along, and OpenWrt developers have already spent significant effort to create a build that will fit in these devices.

In view of the wide availability of ~US$20 devices that fully support OpenWrt, it's not fair to ask the developers to spend further time creating pre-built binaries.

Then the other questions...

Another thought: Who's testing those pre-built binaries? My guess - no one. I offer this semi-facetious suggestion:

  • If you wish to have new firmware for a low-capacity device, please post a note to the forum, offering to send one of those devices to a developer who can custom-build a binary for you.
  • For priority service, offer to include US$100. :slight_smile:
1 Like
163

Yes, but it leaves unsaid what "limited support" means. I was hoping/casting about for short identifiers that could convey that device's status with regard to current pre-built binaries.

There's also the maintenance question - when we ship 19.03 (or 20.04), how does the ToH get updated to reflect new limitations for specific devices? I know @tmomas has a (semi-automated?) process - would these different categories create undue heartache?

164

I don't think differentiations between SSH / BYO etc is a good idea. It will create a lot of problems, generate a lot of questions and possibly maintenance headaches.

As suggested consider keeping Lede 17.x with a 4.4 LTS kernel and patch big security problems. Don't build those images anymore with the "bots", don't even spend those resources. However keep the sources available so (power)users can built their own. And actually depending how you look at it, build your own should always be done. Every user has a different use case and that has always been the power of OpenWRT in comparison with let's say DD-WRT where the user gets the "full" experience what those developers envision with limited options to add or remove features.

At one point in time every main distribution had to make similar choices: Be it Windows 98 -> 2000 -> XP -> 7 -> 10 all those steps left "hardware" behind. The some (possibly worse) for Apple Mac OSX. My perfectly running iMac (late 2013 with 8Gb, SSD intel i5) is NOT able to upgrade to OSX Mojave (at least not via the official way). Of course Linux always supported old hardware much longer and was still able to have a useful modern machine but even old hardware has to start looking for "alternative" distros, not lets say a full featured Ubuntu / Mint / ..

165

I think what should be done is distinct from what should be communicated to end users. We need to be nice to end users and this means two things

  1. give them the information they need to make good purchase decisions and to not waste time on fools errands.
  2. Make it hard for them to misunderstand, waste time, or get out of their depth.

Part 1 means avoid giving the misimpression that 4/32 devices should ever be purchased. Table of hardware should list them as unsupportable for modern versions of OpenWrt. Sure if you have one and have skills to build custom stuff you can maybe get it to do some limited stuff, but you should never ever spend any money to get a new one. Advanced users will dig into details, but new users need to see this will not work

Part 2 means don't have downloadable images or anything people could waste time on. A good user will try to do some stuff on their own, they will download the image and flash it and not connect to LuCI because it's not there and then think they have a network problem and debug that and etc. They'll waste a whole afternoon. Don't be mean to your users by trying to be nice to them. Creating an image without a GUI that can barely save configs is not a service, it's an invitation to waste time. Better to point the users at an online build your own instruction manual and a list of inexpensive modern hardware as alternatives.

Here's the current warning

Devices with ≤4MB flash and/or ≤32MB ram suffer from limitations in usability, extensibility and stability of operation. Consider this when choosing a device to buy, or when deciding to flash OpenWrt on your device because it is listed as supported. See 432_warning for details.

I'd recommend rewording this more strongly. Something like:

Devices with < 4MB flash and/or < 32MB of RAM have barely enough space just for the Linux Kernel and should never be purchased for use with OpenWrt. If you have this kind of legacy device already you may possibly be able to build your own image to do limited functions such as acting as a simple managed switch. OpenWrt does not provide pre-built images for these devices

3 Likes
166

In your own words: Hear Hear !

167

I'd also recommend to make it hard to get a Table of Hardware that includes these devices. Basically by default they're filtered out and then you can dig in somewhere and eliminate that filter if you're paying enough attention.

And, I think we should set "ideal for OpenWrt" to mean greater than or equal to 16 MB of flash and greater than or equal to 128 MB of RAM. Today you can buy devices that support those specs for $18 https://www.amazon.com/GL-iNet-GL-AR300M-Lite-Pre-Installed-Performance-Compatible/dp/B073TT7KB2

if someone buys a lesser thing and spends a half an afternoon futzing with it, they've lost irretrievable hours, and many of the devices with less actually cost MORE.

168

How about making v17 an OpenWrt LTS release with only vital security updates? You could stop spending time on v18 and release v19 with one or two maintenance releases. After that add vital security fixes for v17 while the kernel is being maintained, and only add new features and general fixes in master for v20. Make a new OpenWrt LTS release when 4.4 will no longer be maintained. The next LTS release would probably require 8/64, but then those routers might also get a longer life span.

169

I can't see the problem. Currently even with the 4.14 kernels default config fits into 4/32 devices. It is true that it fits only "just" and installing additional software is almost impossible.

So that could be mentioned in a warning. I ported tp-link mr3040 to ath79 and it builds well with Luci.
For my personal use I had to remove some default packages to be able to add some that I need. But for an ordinary user it's quite OK to use a prebuilt image.

170

Just for starters, what about this misguided user who has bought (and hopefully not as a result of the OpenWrt wiki proclaiming that the POS is "Supported")

Even the developer behind it says that it's not worth dealing with the people that cling onto these nearly useless devices.

Don't argue with people using a wnr2000v5, lost cause.

Umm, no it doesn't. Did you miss that there was the "tiny" configuration to keep these craptastic devices on life support for another year already?

Did you somehow miss the pinned thread

I really want to thank you for helping to make such a strong case that 4/32 should be clearly stated on our forum and wiki as NOT SUPPORTED and that anything with less than 16 MB flash or 128 MB RAM no longer be "recommended" in any way.

Especially as OpenWrt is not selling firmware, I'd much rather have a "customer" say

Wow, they said it wasn't supported, but I can at least do a few things with it

over way too many forum posts and time spend on routine support of mis-informed people with piece-of-crap routers

But it said "Ideal of OpenWrt". Why doesn't it run LuCI, SQM, VPN at over 50 mbps, Transmission, file sharing, transparent wireless repeating, and TLS-based DNS?

No, I'm not kidding on that -- just look at the posts

@per -- A maintained branch is a maintained branch and close to doubles the amount of work involved with every kernel or driver change. Just because it's an LTS branch doesn't mean that pace is reduced. Take a look at the commits on master and you'll see just how many files are involved with kernel- and driver-related changes.

1 Like
171

I didn't miss that. My point is that trunk fits the flash and the next release will fir with default tiny config. So I see no problem with that at the moment.

I have tp-link 1043v1 and mr3040. Both are ok.

172

The mr3040 is really 4/32 and I have no hands on experience with it, but it seems like a wr740 or wr841 all with 4/32 and they are “usable” as simple range extender or managed switch for 100M connections.

The 1043v1 has 8/32 which gives it a big advantage in loading firmware. However owning one of those, the 32mb ram is definitely limiting the experience or usefulness. I’m keeping it around for the 1Gb switch and as range extender it works fine.

Other than basic route and AP those devices can’t do anything anymore. Forget VPN or Adblock or any package which needs a little memory to run properly. Even when those 4/32 devices come with usb to do some kind of extroot, the RAM part will kill it...even with compression and/or swap to usb storage.

As for the investment in a new device: I just ordered 2 coffee and 1 little cake at Starbucks...this will also pay for my Mercury 1200R which is 8/64 with both 2.4 and 5 GHz and AC WiFi including shipping :grinning:

2 Likes
173

@jeff - just to clarify I bought the router years ago for the same reason anyone else grabs a router from a store (I didn't need wireless range extender functionality). It was most certainly not because of the openwrt wiki (I didn't even know about openwrt at the time). I just happened to check now if I could get more use out of it before tossing it in the trash and ended up here.

edit - I'm not trying to insert myself into this argument one way or another, I just wanted to clarify since I was used as an example that didn't reflect my situation.

174

Your use case: try to use a 4/32 device to be useful, like using it as a range extender is exactly why I suggest to keep v17 with a 4.4LTS kernel with minimal security patches. Those can be setup over SSH as “set it and forget it” devices.

However as you found out: even you bought it only last year, basically you spend money on an old product that the manufacturer is now dumping on the market to get rid of their remaining stock. And since you ended up here, even with the OEM firmware you couldn’t (or not properly) even get it usable as a simple range extender. Your example actually makes a good case that those devices become obsolete quickly AND that people first buy a product, then start “googling” to get something more out of their hardware and come here hoping for miracles. Which also shows that it doesn’t help to put all kinds of warnings/banners/ BYO type of remarks...it’s mostly “after the fact” anyway

175

You only see no problem with it because evidently you already have the right expectations. A new user will see "it works" in some table, and expect it to actually work that is, to provide lots of functional possibilities and customization.

Jeff, and I and 5-10 other people spend hours a day here on the forum supporting users. It's a volunteer service out of a desire to help community members, but to hire ten skilled network engineers at half time = $500,000/yr total equivalent salary, to say nothing of the developer time spent customizing builds for small devices etc. So let's say there are 120 people a year on the forum asking for help with a device they're likely never going to really be satisfied with, and a perfectly good solution is for them to spend $20, then this costs them a total of $7200 / yr, whereas if each one takes 2 hours of support time to either show them how to enable their device to perform their task, or convince them that they shouldn't try, the equivalent salary for the support "engineers" is $12,000 (not to mention the time cost to the end-user who probably just wasted his or her own time compared to just buying the $20 device)

Since it's all volunteering, unfortunately these real costs, which exist in terms of time and skill, are not "seen" by anyone and so there is no signal to "stop wasting time and effort and instead spend a little money to get something that you will actually be happy with."

So, pretending to support these devices does a disservice to

  1. The end users who are mostly going to be better served by the $20 device anyway, and often will spend a bunch of wasted time and eventually give in and spend the $20 to get something that actually works for their use case anyway: time wasted, bad experience.

  2. The forum helpers who don't get to use those hours of support to solve more complicated problems like wireguard tunnels or multi-vlan setups or cross-subnet samba browsing or whatever. The value of these kinds of tech-support is much much higher than repeatedly stating why it is that 4/32 devices just really aren't going to work in many/most cases because the answers are not common knowledge that is easily conveyed by a properly worded warning.

  3. The developers who could be enabling support for inexpensive more advanced devices instead of supporting out of date ones, thereby producing progress in giving people access to features at lower prices.

Basically no-one wins here, since the only people actually likely to make 4/32 devices work are those who already understand their limits and already understand how to work around them.

It's all about economics: the use of limited resources. I think we can all agree that if 16/128 routers cost $1 and were widely available with free shipping, we should stop supporting less powerful devices because even a couple of minutes of a typical skilled person's time spent flashing the device would be worth more than the $1 to get a better device. Also taken to the other extreme if suddenly anything more powerful than a 4/32 device cost $1000000 because of some kind of global EMP pulse knocking out all more sophisticated devices, then we'd all spend all our waking hours trying to get the world back online with ancient technology...

By using these extreme examples it becomes clear that whether to support devices is directly related to the cost of getting something better vs the value of the limited time spent supporting them

2 Likes
176

Snapshot images do not contain LuCI.

I see quite some users in the forum asking "I can not access the GUI after flashing [snapshot] OpenWrt image". Once they get to know that snapshots do not come with LuCI preinstalled, they panic and ask for how to get back to stock (urgently!!!11), because they can not live without a GUI.

While you may be happy with snapshots (and without LuCI), others are not.

1 Like
177

I have created https://openwrt.org/toh/views/toh_available_16128 now, which shows only devices with 16/128MB or more.

Pagetitle: Table of Hardware: Ideal for OpenWrt (16/128MB or more)

How can we re-title https://openwrt.org/toh/views/toh_available_864?
Current title: Table of Hardware: Ideal for OpenWrt
New title proposal: Table of Hardware: Ideal for OpenWrt (8/64MB)

Together with the re-titleing (and already anticipated in above new title proposal), we could restrict toh_available_864 from currently 8/64MB or more to strict 8/64MB, and leave the "or more" to toh_available_16128.

Your comments, please.

1 Like
178

Proposed titles:

"Table of Hardware: Ideal for OpenWrt" for 16/128
"Table of Hardware: Provides Minimum Resources for basic functions" 8/64
"Table of Hardware: Unsupported on forum, requires build your own stripped image. Experts Only" 4/32

3 Likes
179

I build with Luci and it fits OK.

180

Not quite

But

181

Hi all,
I do like that new page for 16/128 devices. So I did go to amazon to see that GL-inet GL-B1300... just 89,23€.

Well, should I say to the 50 families we have in our not-for-profit organization that probably next year they have to dump their routers and got those magnificent, 90€ new thing? I understand I'll probably have to do... then I'll got (probably) castration or even complete emasculation.

I understand bloat problem is mainly on linux kernel, which is not as little as it was/should/could be. I understand that's not openwrt devs problem. I agree that supporting old/little/ugly devices is neither fun nor fancy... But I still need to support those old devices as long as possible (preferably forever ;-)).

My people does not need anything more than a basic, safe and as-cheap-as-possible AP in their homes. They even don't want to know nothing about it. It's up to me to make it work and I don't need neither lucy nor opkg nor IPv6 nor... They just know this 90 € thing is far from being as-cheap-as-possible.

I just hope that someday, while my balls are still on place, linux devs will realize that there are lots of people out there that need a kernel with just the basic functionality network devices offered in, say, year 2000, and little more, while the remaining, modern, fancy and funny features can be
disabled in menuconfig. Sadly, if embedded guys don't say it loud, then they probably will not get it.

But, wait a minute, I think I have found a good solution! See

for just 40 €, so you can buy 2 for less than one of these GL-B1300 things

And, perhaps, for the same amount, one could get in on steel or even titatium, those freifunk guys with their thousands users will need the toughest materials or sure!

Ciao,