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

Not quite

But

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,

I think you have bigger problems if you feel emasculated by this. Also it's obviously a poor argument in favor of supporting smaller devices. :roll_eyes:

To be very clear, I am supportive of users with the knowledge and skills to maintain a "fleet" of devices for a community or their clients (such as Freifunk, or those that deploy a specific device en masse). They should be able to take sources that are not routinely built as "public" releases or snapshots and customize them to the needs of their community or clients.

If 90€ were the cost of a current router at the entry level that has reasonable resources, I'd have a different viewpoint. However, that cost is around 15-20€

Yes, the GL-S1300 is on my short list, but I also routinely use a US$17 (delivered) GL-AR300M-Lite (16/128). It doesn't even have to be flashed with OpenWrt, as it's delivered that way, ready for use as an AP, client bridge, router, or repeater, with GL-iNet's "helper UI" making it even easier than LuCI to configure these things (yes, LuCI is available as "advanced" settings).

3 Likes

Perhaps like the GL-inet AR300M-lite for $17.99 which should last for say at least 4 years, more likely 7 or 8, meaning something like the equivalent of $2-4/year. Perhaps your not-for-profit could offer interest free loans payable $4/yr ?

As predicted, let's remember to Follow Rule #12 - Be nice to each other Thanks.

Well, it is 18.30€ here, shipping not included. I don't find it fully satisfactory, but, hey, this is quite good. I will have it under the sleeve, thank you.

However, as you realized, my point is the need some of us have, it is to be able to maintain a fleet of devices. It does look that it will be impossible if we don't say we need it as small as possible.

@dlakelan: it would be easier not to have to dump our material

A couple thoughts:

  1. As noted before there are alternatives in the 20-30€ range that are perfectly suitable for OpenWrt.
  2. If you have that many devices (and 50 is a lot), then it may be worth it to spend some time finding someone who can make an OpenWrt build that prolongs their life. (50 devices x 30€ = 1,500€)
  3. This is definitely the case for Freifunk - with 40K+ devices, it's worth a lot of engineering to keep using the existing hardware if it's working in all other ways.

Good luck.

The problem of financing "public goods" is well known in economics. A public good is one that is unrestricted in access, and does not get used up once created. For example the knowledge that there are photons in the world and how they work is a public good. Once published everyone can read and find out about this wonderful fact. Similarly the census data from the US is a public good: if I download it, you also can still download it.

But the problem is someone pays the cost to develop and maintain the thing... For the knowledge of photons there were hundreds of people with expensive laboratory experiments throughout the world working to understand them. The census has tens or hundreds of thousands of employees collecting data and sorting it and quality controlling it etc. They need to eat, and to buy laboratory equipment, and to have their children's cough taken care of.

Eventually, as the developer, researcher, whatever, paying the cost to develop or maintain a thing by just giving up those resources yourself is too costly for the small group that pays it... they move on to something else, and then there is no development, everyone loses, no OpenWrt routers at all, or no support, or no experiments about how gravity works, or how to cure the flu virus or the census data that tells us about income and cost of living and employment and whatever.

We can't pretend this isn't a problem. it is in fact a well known problem in economics. https://en.wikipedia.org/wiki/Public_good

There are various types of solutions, one of which is to start charging for downloads. Perhaps OpenWrt can charge you $20 to use the bandwidth to download the image from their site. That would be a good solution, because then you'd know to just buy the $20 new router that works better anyway. Or, perhaps we can ration things but still let you get the public good free: you can download some stuff, but there is absolutely no support or development. Then the OpenWrt community has much lower cost to provide this public good to your clients and spends its time developing support for other better hardware.

In any case, the solution of "OpenWrt just keeps providing free resources to everyone at unlimited quantities" should come with a pony, and rainbows, and world peace.

I found it quite a good solution. Please note I don't download images, but full source instead.

Of course I understand we have not the right to think that devs are slaves. I think our money speaks louder than our tongues.

Rather than charging for downloads I suggest something like a bug bounty account for someone or some small group who has the knowledge and interest to both develop the software for 4/32 devices, and support the usage of those devices. You find some similar groups to your own, pool your resources, and offer $5000 to produce builds for 4/32 devices after the next release. If someone finds this attractive they can do it, and then get the $5000. If you and your similar groups together have say 1000 routers or so, you have only spent $5/ea which is a good deal compared to $20 for the replacement hardware.

In the mean time, those who are donating their time to get progress towards the future where inevitably devices will be bigger and bigger devices get cheaper, they can maintain their focus there and not put time and effort towards build and support for 4/32 devices.

Remember, the source is already available to you, and can not be removed (for at least 3 years according to the GPL for example). Finding that bug bounty hunter and the pool of similar minded people is the issue. Perhaps the time and effort spent on doing that is too expensive to justify. Fundraising itself costs money.

1 Like

You are right.

However, I don't see it as feasible by our little group. Even OpenWrt community would be small for it since main source of bloat is linux kernel.

Long history short: if someone can put a system so old but perfectly working devices can be still supported and not dumped, we are going to take it. We will be happy and guess the planet will be a little less dirty, too.

Best wishes

From an economics perspective the problem is what's called "transaction costs". That is, it takes resources to find enough similar minded people to pool your resources and come up with a bug bounty and deal with all the overhead of publicizing it and getting a "taker" and then ensuring that it gets done in a timely manner, and then transferring the money safely without getting scammed etc etc .

For your organization, if the transaction costs are more than 50 * $20 then the low end GL-inet device looks like it's a very good solution, as it offers you more value at similar cost. So if it will take you more than 20 or 40 hours to put together this bug bounty thing... then indeed it is better to buy the new routers.

Perhaps OpenWrt could offer a kickstarter campaign: pay $100,000 and it will support 4/32 devices for 2 years... Then if there are enough takers, fine if not, then perhaps fine too. All it would take is say 10,000 people to each want support for a 4/32 device for $10 each, half the cost of buying a 16/128 Gl-inet AR300-lite. If there aren't 10000 people in the world willing to spend $10 for this purpose, perhaps it really shouldn't be done.

The fact is to extend this support likely will really require going back to old kernel versions, patching them, creating alternative build systems, etc. It really does cost $100k worth of time and effort to rework the build system and debug ancient kernels. Whereas when the device fits into the current build system, adding a new device is much easier, a few configurations, a couple of patches... and it integrates with the existing build infrastructure that's already in place.

You are right again.

OEMs never will have interest in that, they want to sell new hardware. May be they will make this moot simply by getting the worse capacitors they can find so boards die before 5 years. Nor
will they hire any devs for that. So it's up to us. If we want to escape from that "dictatorship" we need to back our words with our money.

All I can say is: "if that kickstarter campaign really appears, we will take it" and hope a lot of people will take it too.

I'm the "developer" you mention here, (I actually just compiled a firmware selecting options from the ncurses makeconfig GUI).

I partially confirm what you said.

Some of the people using such low-end devices are actually sane people that just want to repurpose an old device they have laying around (like willingnew user here), while fully knowing limitations. That's ok for me and this is why I answered to his plea and provided a download link.

But many are completely clueless and keep asking over and over the same stuff and complain, and ask for help and so on and so forth without reading the 40 posts over them where all questions are already answered.

No wait. Why 8/64 devices should not be recommended anymore? I mean I'm ok with showing them as the "recommended" ToH page, but can someone tell me why?

1 Like

That "recommended" page is for end users buying their own device, expecting to be able to install whatever and use whatever all at once, without knowing anything beforehand.

For devices provided by an ISP-like entity, or a veteran user that controls and knows what firmware features they will have, then you can skimp on hardware you know you won't need.

Afaik no it is an issue of wireless hardware, not of the kernel itself. I know of Qualcomm devices that do waste a ton of RAM for their wireless hardware because they need caches and stuff and whatever, and you can't just remove that without changing the firmware too.
see here

Afaik the candela firmwares for these wifi cards (now used by default in OpenWrt, and will be in next release) allow to set these wifi cards to calm the fuck down and use less RAM, but this patch has not landed in OpenWrt, it's still stting in a downstream project

So I urge people to get this in OpenWrt proper for the very least.

Some people check the "Recommended" or "Ideal for OpenWrt" to decide what to buy. This community is looked on by some as experts in all-in-one routers. As such, we shouldn't recommend what we acknowledge is going to have significant limitations either now, or in the next few years.

Note that this is very different than support. If someone already has an 8/64 device, as long as it makes sense to put effort into supporting those devices (since we'll no doubt have this same discussion in a few years about 64 MB of RAM), that makes sense. But that's not recommending them.

I was lucky enough to read that the Archer C7v1 was having problems under OpenWrt, even though, at the time, it had plenty of resources and an Atheros chipset. Had I bought it then because it was on an "Ideal for OpenWrt" or even "Recommended" list, I'd be royally pissed right now.

Could I honestly recommend an 8/64 device to anyone as a new purchase? No.

Could I honestly recommend a MIPS-based router to anyone for a new purchase? Unless looking for a very inexpensive device or a low-power / travel-size device, no.

That was the genesis of a few "classes" for devices; ideal, recommended, supported, and "well, here's the source, good luck with it" :wink:

While an EE by training, I'm a product manager by trade these days. I'd rather underpromise and overdeliver, than the reverse.

3 Likes

I'd like to remind here that many OpenWrt users don't have the skills/time/inclination to even set up for the Image Builder, much less for a true compile from source.

Even if I, as a relatively long-time Linux user, don't find either particularly hard, I know that I'm a minority.

Ok it makes sense, that's my same thinking.

Just to expand on this (and I wholeheartedly agree on the distinction between "recommended" and "supported" @jeff raised), OpenWrt with samba4 barely fits into 16 MB of flash - and this is not really a fringe package only enthusiasts will install (actually enthusiasts are more likely not to abuse their router for non-routing services). Why samba4 and not samba2/ samba3? Because, security/ maintenance issues aside, the SMB3 protocol was only introduced in samba v4.1 - and current windows versions want this version of the protocol.

Looking at the current figures, mips based firmware images are around ~4.5 MB in size - leaving some margin for the future. You can still install several optional services on 8 MB flash devices without hard restrictions - and I do expect them to work in their default configuration for a few more years to come, but at the same time you can't install multiple optional services willy-nilly (and this is something beginners often want to do). 64 MB RAM isn't a problem on a default configuration either, but for adblock with multiple blacklists this may get slightly limiting - for services like BitTorrent (bad idea on a router) this would already be 'tight'.

Recommendations are for devices you can suggest to newcomers without full knowledge of their exact requirements, because their listed requirements are invariably vague and incomplete - and they often do take many features for granted, which really shouldn't be considered part of a normal "router". It doesn't help that modern mid- to high-end commercial routers have been plagued with feature-creep as well (basic QoS (streamboost), OpenVPN and DLNA/ media server services are something you can almost expect by now, parental controls and even light network protection are not unusual either), raising the bar for what novices tend to expect.

I personally find it very hard to recommend devices that don't meet these minimum specifications:

  • dual-core (VPN can clog one core, without hampering normal operations, without fighting against netfilter and pppd for ressources)
  • 16 MB flash (thinking about samba4; very personally I wouldn't buy devices with less than 32 MB flash myself)
  • at the very least 128 MB RAM, at least 256 MB RAM for devices with (two-) ath10k wlan cards
  • concurrent dual-band wlan
  • at least one USB 2.0 port

Given that mid- to high-end routers are switching (actually have switched already) to ARMv7/ ARMv8 based SOCs, I would suggest to avoid mips based devices aside from very cheap/ used offers. I also tend to find it easier to suggest solid/ reliable WLAN solutions (ath10k, mwlwifi (with the caveat of interoperability issues with IoT devices), maybe mt76 - the later not without at least mentioning issues in congested environments (interference) and for 2.4 GHz (mt7602e/ mt7603e) in particular).

Please do keep in mind that >100 MBit/s WAN connections are becoming common around the world, with ar71xx/ ath79 only providing around 150 MBit/s routing throughput at most - less with SQM enabled (another thing many, including novice, users expect from OpenWrt).

Btw. "ath10k-ct: reduce memory pressure" is already part of chunkeey's staging tree, who originally wrote the same patch for ath10k before - because the ASUS RT-AC58U didn't work reliably without it. This is the main reason why I personally don't feel very well recommending devices with less than 256 MB myself. Yes, the aforementioned patch can mitigate the memory pressure, but the mere fact that it is needed (and that it's needed to diverge from upstream here) tells a story that 128 MB can be considered marginal.

When recommending a device, I want to be rest assured that the suggested options will work reliably with OpenWrt and provide some margin for hopefully around 5 years to come (not assuming massive changes of the WAN connection, but very well providing headroom for some more gradual improvements), even without knowing the full extent of the user's requirements (now and tomorrow). To give them some headroom for experimenting. At least around here there has been some 'unexpected' and sudden increase of common WAN throughputs since 2016 (by a factor of 10-30, with the 'sudden' and massive deployment of outdoor DSLAMs and VDSL2+vectoring, instead of ADSL2+ hampered with old/ long POTS cables before, as a result of political pushing and subsidies and the ex-monopolist 'fighting against' newly encouraged fibre proliferation).

Please do take into consideration that, if faced with buying a new device, the financial delta between devices that meet these specifications are not as large compared to sub-par solutions than you might think.

3 Likes