For support status and the latest firmware downloads of any device see the ToH.
Thanks. Is there any specific reason that other 4/16 devices get a tiny build but not the 720N?
Cheers.
It's 4/32, and lots of those haven't been built automatically for 18.06.x. It's still in the configuration, so you may be able to build one that's small enough to work yourself.
2 Likes
Thanks for the info and correction. Am still wondering what's the reason, technical or else, that some 4/32 devices got a tiny build while the others don't...
Anyway, since 4/32 is basically a dead-end in OpenWrt development, it's probably a better idea for the devs to work on something else...
Cheers.
All (known) 4/32 ar71xx (other targets may not have introduced it yet) devices have been mass-migrated into the tiny subtarget, but that still doesn't mean that there is enough space to build a firmware image for all devices.
It all boils down to three potential "viable" solutions...
-
Keep/Revert to "older" software in tree and backport security updates only
-
Follow upstream and do various hacks to keep the size down for various software
-
Follow upstream and accept the fact that 4mbyte devices aren't no longer viable in the long run and try to work with "what we have".
Option 1 is more or less a no go, there's little interest for backporting even to release branches looking at the patch/commit history compared to the influx of patches for master (pretty much only the OpenWrt core team backports) and I would imagine there would be even less contributions for a legacy branch and manpower available for code reviews etc.
Option 2 is pretty much the current solution but as seen it's slowly turning into not viable for very old/low-end devices without drastic measures. In general, hacks will eventually turn into ~forks unless someone upstreams code (which rarely happens as it usually clashes with upstream roadmap/ideas) and historically very few forks with a specific use case have been successful (in the open source world) on a large scale. This might also prove to be troublesome and time consuming as upstream diverges meaning that there's no support upstream regarding bugs etc. You'll also need to find a balance otherwise potential contributors will wander off and create various forks with newer software which is be beneficial for their use.
Option 3, I know this is a sensitive topic but sometimes you have to accept the fact that product X might not be up for the task. Usually there's "~no" support upstream to fix bugs even if they are fixable at all (Atheros draft 11-n hardware comes to mind for instance, silicon bugs etc). Of course there should always be a goal to keep the size down but I'm not convinced that it potentially limiting performance/functionality/support of more recent hardware is worth the cost.
Manpower and interest are the main factors which will affect the above, there are obviously more topics and reasons to each option that aren't mentioned but you get the idea...
You mean 4MegaByte, not 4millibit. 
1 Like
As I see on ath79 flash is not the only issue. 32MB RAM is just enough for running.
IMHO, when blindly following this option, the software will not only quickly outgrow 4MB devices, but even 8MB or 16MB ones. Not even considering the additionally required RAM for running the modern bloatfest.
If OpenWrt would have followed that philosophy in the early years, arbitrarily restricting itself to a few selected boards, it would be fully gone by now.
Also if you bloat the system so extremely that it requires fat ARM or x86 boards to function, you can as well abandon it and switch to Debian, BSD or some other distribution of the month.
I don't share your view on this. Especially in the package repository I see very little drastic hacks done to packages to make them smaller, aside from things like disabling documentation, tests and the like.
Which drastic hacks and hard forks do you refer to?
Within reasonable limits, I'm not suggesting that we should adopt systemd but if it boils down to having lets say dropbear and/or busybox up to date instead of forking/hacking it I think it's a no brainer.
Unless I've missed something there are very few packages that currently gets patched (hacked) due to size and I think that's the way to go. To be clear, by patched/hacked I refer to non upstreamed/able patches not configure arguments and similar.
Regarding forks, I'm doing a broad generalization... Of course there are successful ones but type in your random common app on lets say github and you'll most likely find numerous of forks/patched versions around that aren't maintained or upstreamed. I think that scenario should be avoided where we end up with something that need to be fully maintained and having to (back)port from upstream.
Welcome aboard the OpenWRT, we're heading full force towards irrelevance.
It's already hard enough to get devices that support OpenWRT as is - the devices recommended on your project page (128 MB RAM, 8 MB Flash) cost so much that it's better to just buy into Ubiquiti, or set up a dedicated router. I know, I know, it's cool to be the tuff man and say "we no longer support this period" because it makes me feel powerful ("I am the KING"), but the cold truth is that you're about to be the king of a kingdom that's devoid of people. Saying "it is because I say so" no longer feels powerful if there's no one to care.
The big strength of OpenWRT was that you could grab an off-the-shelf $20 router, and do crazy cool things with it. It was amazing in 2014. Fast forward to 2019, OpenWRT got bloated more than Sonic on deviantART, Flash is too small, RAM is too small, everything is crashing, everything's instable.
You should try to slim down, and focus on that cheap commodity hardware, no one in their right mind would buy an Ubiquiti and flash OpenWRT on it. Otherwise you're heading from barely relevant ("only nerds know OpenWRT") to complete irrelevance ("even nerds realize that if they need to spend $$$ for an OpenWRT supported device that it's not worth it").
"I don't support" isn't cool, it's what everyone else does (all phones become unsupported within 2-3 years), the easy way out, and lame.
No. My workhorse, a ZBT-WE826, is about $25 plus VAT, so it is about $30 in summary.https://www.aliexpress.com/item/802-11N-300Mbps-MT7620A-openwrt-wireless-router-300Mbps-WiFi-Router/32361575074.html?spm=2114.search0104.3.112.6ac537cb177LSO&ws_ab_test=searchweb0_0,searchweb201602_4_10065_10068_10547_319_317_10548_10696_10084_453_10083_454_10618_10304_10307_10820_10821_537_10302_536_10902_10843_10059_10884_10887_321_322_10103,searchweb201603_56,ppcSwitch_0&algo_expid=70e20e40-2140-468a-af7f-e01acabf236b-16&algo_pvid=70e20e40-2140-468a-af7f-e01acabf236b&transAbTest=ae803_3
Various variants of this one available; make shure 128MB RAM. For volume orders, you can even get a 256MB version.
Anyway, a stable, frozen minimal up-to-date openwrt for popular 4MB flash devices (i.e. TP-Link 841ND) appreciated. Still usable as dumb AP, for example.
Although I am not really "Grean": Recycle, instead of dump.
1 Like
Thanks for your note. I understand the incentive to avoid bloat, and the urge to keep OpenWrt relevant to lower-price routers, but I don't necessarily agree with your argument.
-
Don't get me wrong: In 2014, OpenWrt was a godsend - it turned the "steaming pile" of vendor firmware into a functioning router that ran reliably without security problems.
-
But, a "$20 router" in those days was a pretty minimal affair. 2.4GHz wifi, wimpy processor, small RAM/Flash. They worked well with the (minimal) internet speeds that were predominant at the time. Nor did they provide a satisfactory internet experience (bufferbloat).
-
Today, "we all want" 2.4GHz and 5GHz connectivity. Many people have 100-500 mbps ISP connections. Your $20 router wouldn't hack it at all, but low-end (now, $40 routers, especially if you shop on eBay or Craigslist) routers are "the standard" and can support these speeds. SQM with Codel/Cake decreases latency for you traffic, but requires a beefier processor than the lowest end.
-
There's also the question of balancing developer focus: maintaining backward compatibility vs. working on new features.
-
It's also true that Ubuquiti equipment is very compelling (as are other OpenWrt-out-of-the-box routers such as IQrouter) since they "just work". They cost a little more than an equivalent OpenWrt install would but your time and experience count for something, and you don't have to be the tech support person for other people's network.
That said, I do think that a Community Build that's focused on specific popular models (such as TP-Link 841ND as @reinerotto suggests) could be valuable.
But I also want continuing features/security fixes, both for myself and for the project. It provides a good experience for people using them, a platform for experimentation (Codel/Cake were developed on a branch of OpenWrt), and a secure router/gateway for your home/business.
Back when I made the original post of this topic (January 2017), we didn't have a clear way of knowing what fraction of our population uses <4/32 devices. I'm not sure we do today either. I'm checking the Table of Hardware to see the hardware specs of newer devices and will report back.
Thanks for your thoughts.
3 Likes
Rarely saw a post on a forum about open source software with that much ignorance.
I want to see Ubiquiti hardware starting at ~35€.
"everything is instable" for millions of devices outthere? Im using at home and on several places network hardware with OpenWrt or Gluon (a fork) since 2012. I provide internet for (mostly in summer) about 150 people thank to a project called Freifunk. Never had big issues the last 7 years. The only fuck ups i saw came from the manufacturers themself (proprietary drivers/firmware/blobs).
About OpenWrt getting bloated... I call myself a bloody beginner in matter of programming, but im following closely what is happening in the Linux world for more than a decade. One is really obvious: software get with the time bigger. You cant stop that. The biggest Problem for 4/32 devices is the linux kernel. It will continue to grow. Not because the devs are lazy, but because of features and security updates. And specially for the kernel: is your code not written perfectly, it will never be accepted. By the way the kernel itself is not made here. Check kernel.org.
So do yourself a favor: better inform yourself for the next time and stop pissing on the head of those working mostly in their freetime to get you access to open source software. Or in better words: freed software.
5 Likes
Update: I have rummaged through the OpenWrt Table of Hardware and done a quick (half-assed, I guess) analysis of the Flash/RAM distribution of recent devices to get a sense of "routers that we're talking about" in the discussion of what are popular/relevant routers.
I separated the full list of devices into "Devices available in 201X", where they were listed either as "Available" or "Discontinued" in that year. This is a sloppy analysis:
- The ToH data is imperfect - there are many devices where the Availability is unknown/not set. (There are 256 routers whose availability is listed as "Unknown 2018", which means that they are simply not counted in this analysis.)
- For simplicity, I also counted as "Other" devices listed as 128NAND or where RAM was listed as "¿". This also leaves out many, many routers.
- Finally, the analysis does not consider any particular device's popularity: those devices will be under-represented in these stats.
Observations: Even in 2016, the most common Flash was 8MBytes, the most common RAM was 64MBytes. This has remained steady through the present. In 2019, there were no 4MByte Flash routers, and only 7 with 32MBytes RAM.
The original question posed above is whether 4/32 devices have sufficient popularity to warrant their continued attention from developers. My sense, in 2019, is No.
The underlying data is available from a Google spreadsheet (below). Enjoy!
2 Likes
PS I can see that this topic may generate some emotion. Let's all remember to be respectful and Follow Rule #12 - Be Nice to Each Other. Thanks.
2 Likes
Well sorry if i went to far. I cant just stand this kind of post. Without your massive efforts, we would all pay thousands in a router with that much features, just to be laid off 2 years later because of "wE hAvE A neWeR PrOduCt".
Back to the topic. I think it wouldnt be that bad to freeze those devices into the 4.4 LTS kernel since it will be supported until at least 2022. Some kind of LTS support for 4/32 devices (security) if you want. Those devices will probably disappear like wrt54gl once did very soon. Maybe its more useful at this point to fork OpenWrt into a 4/32 project for those willing to do so, Like Arch linux did with 32 bit cpus as a community project.
The thing is time spent supporting 4/32 devices is time not spent supporting newer devices or adding new devices or etc.
There are plenty of decent routers with more flash and ram at very low prices, like GL-inet devices for $20. It makes no sense to spend effort on these (older 4/32) devices unless someone has a convincing reason. A good convincing reason would be if an organization has say 10 million of these and wants to spend $0.10 each to get them working... $1M will get you a bunch of development time.
Short of that, mostly people are going to find that it makes more sense to get a lot more functionality for $20 by buying newer hardware.
5 Likes
Well with all Freifunk communitys combined in germany, we have about 42000 nodes. The problem we have is, that a good part from them are TL-WR841N/D. Mostly Freifunk firmware are based on Gluon, a fork from Lede/OpenWrt.They put already a lot of effort, like less ram usage, to keep those devices running. Some problem exist for the communitys and the Freifunk isps providing the vpn infrastructure because of those low-end devices.
Throwing money in wont help much, its already happening for low-end device related bugs.
And im not counting similar projects in the entire world.
Thats the idea i had behind a fork freezing those device on a certain LTS Kernel and focusing on keeping them running for the next few years. And later the same with 8/64,16/128 devices and so on, once they become obsolete too.
By the way maybe somebody can check gluon sources, they have done some nice things lately about ram usage...