Has anybody a rough guess, how much RAM to save, when using 15.05.1 instead of 18.06, for ar71xx/generic as target ?
Minimal system (no IPv6, no ppp, no opkg), so the difference in size of the kernels used
will be dominant, I guess.
Has anybody a rough guess, how much RAM to save, when using 15.05.1 instead of 18.06, for ar71xx/generic as target ?
Does it really matter, if the result is an insecure system which has been out of support for over three years?
BTW: 18.06 is not secure. Only "more secure" compared to 15.05.1 Support is not an issue, as 15.05.1 is good enough, and prooven to be stable for my usage case.
Not very good style, to answer a question just with another question.
Compile it and let us know.
if on 4/32 replace flash for 16MB (easier than replacing RAM, anyone should be able to do it) and build jffs2 image (instead of squashfs). that will free up several MBs of RAM at least
I know you are trying to be helpful, but replacing a flash chip is certainly not something that "anyone should be able to do." It takes the necessary equipment to solder and to program the new flash chip, nontrivial acumen in SMD soldering and chip flashing, a modified u-boot, and the knowledge to troubleshoot problems with all of the above if the result doesn't immediately work out. That's way outside the means of a regular consumer.
a regular consumer will not know how to build image, or if his router is low on RAM, he will only notice it's not working as expected. reffering to "anyone" in a post in "For Developers" section of the forum should indicate type of users this reply concerns.
after all it is not rocket science to use solder iron and spi flash programmer, modified u-boot is not required, and all it takes is a fresh brain and hour or two of reading instructions that can be found on the forums/wiki
sorry but i agree with @takimata beeing a devloper doesn't mean also know how to solder and desolder smd. also... YES it's actually rocket science use a sloder iron... to do such things you need hot air station... solder... flux... without this you will pratically break the pcb... change a smd chip is not like solder 3 pins for the serial header.
Also... you talk like modified uboot is something easy to do... while in reality to do so you need to find the source (if they actually exist) build them with the right config (also here if they actually exist) fix the makefile as most of the times OEM use very old uboot dist and at the end flash the uboot to the flash chip.... that most of the times is not a regular chip that can be readed with clips but you need to use adapters and desolder/solder...
Read all of this and you quickly understand that it's easier to buy a new device than try to upgrade old devices...
@reinerotto 99% on a device with 4/32 you will not find a way to run a 18.06 image due to kernel size, also performance will be very bad for low ram.
It is correct that no non-trivial piece of software will ever be bug free - and some of these bugs will have security implication. Keeping software secure is always a race against the competition, if you fall behind, you've lost
It's provably no longer secure enough, nor stable (SACK can make an external attacker crash your devices in a loop) anymore.
The problem here is that 15.05.x has a multitude of known security issues for attackers to choose and combine, security bugs that are severe enough to take over devices running it remotely - both over the internet and locally in wireless range. Known defective software really shouldn't be used anymore, even if that means retiring devices which were considered low-end ten years ago when you bought them.
In case of 18.06, which is still maintained, you 'only' have to deal with the unknown portion of these security issues, as serious -remotely exploitable- bugs are getting attention, e.g. look SACK, which was the reason to accelerate the 17.01.7 and 18.06.3 releases.
The difference of "known" and "unknown" security issues here is a major classifier in terms of your security exposure to the web at large. While there will always be very determined attackers (both state actors and financially motivated entities, some of which are feeding the state actors) sitting on a batch of unpublished security issues for their nefarious purposes, these categories tend to be regarded as valuable and are rarely 'wasted' on wide scale attacks with an accordingly bigger chance of discovery. They rather tend reserve them for more surgically precise, targeted, attacks against relatively few high value targets. Once these bugs are discovered, they've lost their value -even if they might still be highly effective against the un-updated portions of the web- and enter the arsenal of the mob, using them to gather zombies for the botnets, to infect you with crypto trojans, to mine crypto currency on your devices, to inject ads and other viruses into your browsing, to override DNS entries for fishing expeditions, to exfiltrate content from your network, to run dDOS attacks on other servers and conent delivery networks, to toy with you.
As mentioned before, security can never be absolute and final, it's always an ongoing race to keep the attackers out - while your options are very limited to against guard yourself against unknown security bugs, you can -and must- do your best at defending yourself against the known issues, as hordes of criminals, script kiddies wanting to have fun, will try them on you constantly, every hour of the day. These entities don't need much knowledge, they just take from ready-made attack toolkits, containing the bulk of no longer valuable (but still effective against un-updated devices) exploits, they are fishing with dynamite, but they'll bring home their catch.
This is the range of attacks you can and need to defend against, to fight these it is essential to run current/ maintained hard- and software, to make yourself less of a target than your neighbours. By running outdated/ unmaintained software, you have already lost before you started to fight.
While OpenWrt tries very hard to keep older devices supported, this is getting increasingly difficult for the bottom end of the range (4/16 and 4/32), basically impossible if you want to publish an enduser compatible release image (in other words, something with a webinterface an ordinary user can actually operate). This does mean retiring devices that have slipped below the minimum system requirements for running current releases, the warning signs have been around for long (at least since mid 2016) and were also explicitly published here, causing quite a stir every couple of weeks. Especially considering that devices meeting and surpassing these minimum system specs don't need to be expensive, you can find them for under 20 EUR/ USD brandnew, delivered to your doorstep and under 5 EUR/ USD on the used market. There simply is no excuse to knowingly operate vulnerable devices, putting yourself and others at risk - ignoring these issues might even put you into legal peril.
 you can even define this two-fold, both the dark side, who's trying to attack you, and OEM firmwares - as long as they're even less secure, they'll be deemed as the easier target by the bulk of financially motivated attackers.
 yes, I'm affected by this as well and still own three devices falling under the 4/32 category and one under 4/16. yes, I do still spend insane amounts of time on trimming current OpenWrt (master) down enough to keep them running, but I wouldn't consider running an unmaintained version on a 24/7 device sitting at the edge of my network, which is supposed to form the first barrier of defense against attackers. The day I'll no longer be able to keep them secure and updated, will be the day they'll be disconnected from the power grid - actually I've already thrown away two lantiq AMAZON ME and one TI AR7 routers this year.
 yes, issues on the buildbot side have slightly delayed them again, but they're building right now - and (at least to the current amount of knowledge), SACK allows 'only' a denial of service attack against you, not to take over your device.
 all of these examples have already happened - and are happening on a daily basis, with criminal groups herding millions of infected devices in their botnets, even renting them out to the highest bidder.
 with as few pending security implications as humanly possible.
 for further background information, please see https://openwrt.org/supported_devices/432_warning
 at least if you can't trim OpenWrt down enough (e.g. by using the imagebuilder or building from source) to keep using them with current software.
 by participating in vast botnets roaming the internet for prey, to participate in dDOS attacks.
 when (not if!) your devices are used in staged attacks against others, to hide criminal activities from bank fraud to drugs, over illegal porn to weapons sales or even terrorism, your bets are off once your devices have entered service in 'commercial' criminal or state driven botnets.
I run devices that have been supported since version 0.9 (some no longer supported - due to the 4/32 warning). On a 32 MB RAM device, I was able to run up to version 17.01.4; and switched to snapshot due to extremely poor performance while LuCI/uhttpd is running.
So long as I don't run LuCI, I have ~35% performance or less compared to older versions. RAM specifically - I'm not sure.
Hope this helps.
But not in all countries. Having a fleet of 32MB devices, which are certified for use in a certain 3rd world country, actually running dd-wrt, replacement will be impossible for 20USD each, as only few other devices available having national certification for usage. And these few device types are in much higher price range.
Yes, for US or EU-citizen, $20/E20 is small money. But there are quite a few other countries in the world, where this is more than the daily income.
That doesn't change the security implications in the slightest. Attackers don't care if their victims are in "3rd world country[ies]", their zombie routers are still good for crypto mining, DNS amplification (dDOS) attacks and many other illegal and harmful purposes (both to the owner and their victims). They actually like geographical diversification, as that makes blocking them harder.
Your precious certification is gone while you're running a third party firmware anyways.
also if you can't manage to have 20E then you can't also manage to have a real connection... and i didn't understand the national certification for usage...
I agree with the security concerns being brought up here but please let us try to not overdo the user education part
A casual reader stumbling over this thread will see the security implications very clearly after reading the first few replies, but likely won't find a proper response to the OP's question.
I also don't think that this is the place to discuss whether 20 Euro is much money or not, or whether this exceeds the average income in some parts of the world - we simply don't know the circumstances. Could be that the OP would need to replace/acquire a few hundred or thousand units, for which 20 Euro per device would still be quite some amount of money.
@reinerotto - in the end you can only try, but I'd expect some RAM savings in the 1-4MB range, probably largely affected by the squashfs block size.
Finally a real answer.
1-4MB saving is worth a try. Although I do not really understand what to do about "squashfs block size", when using provided imagebuilder+packages from .
Compiling from src seems to have some obstacles, like certain version of gcc.
@Ansuel: Not everywhere CE is the required "certification".
by flashing custom firmware you are violating certification... soooo
... this would put all the Freifunk routers out of service in Germany.
I'm curious....what does this mean?
Router software must be certified in Germany?
Otherwise, I'm not sure how this "certification" relates to the OP's needs.
Decompression of the file system blocks is done in memory. Smaller blocks, lower RAM requirements, likely greater flash requirements to some extent.
I would say about 3 MB IIRC.
Please note our case is quite different from freifunk, we don't have any memory issues even on 18.06.X as long as luci, ipv6, opkg are out, but our devices don't have any routing tables, just the gateway.