There is a wiki page with a lot of optimizations for saving space: https://openwrt.org/docs/guide-user/additional-software/saving_space
Unfortunately v19 will be so much larger that it will be very hard to make it fit even with a minimal build on many 4MB routers.
Hypothetically;
Lets say the buildroot has a;
[ x ] Enable build 4/32 feature stripping
[ x ] level1: ipv6 mroute
[ x ] level2: luci + ipv6 + mroute + xyz
a) What are your opinions on the best things to sacrifice?
b) What would a 4/32 user REALLY be missing from 19.... luci2? etc.
In my case: tplink_tl-wr741-v1 (4/32). Router used as internal Access Point + statistics (send to main router - collectd configuration). Image size:
3343115 - openwrt-ath79-tiny-tplink_tl-wr741-v1-squashfs-sysupgrade.bin
One change in luci dependency: feeds/luci/collections/luci/Makefile
remove "+ luci-firewall"
Linux version 4.14.107 (kofec@E5420Mint) (gcc version 7.4.0)
root@wr741NDv1:~# uptime
17:02:46 up 4 days, 14:14, load average: 0.00, 0.00, 0.00
root@wr741NDv1:~# free -h
total used free shared buff/cache available
Mem: 28036 14432 6900 52 6704 11260
Swap: 0 0 0
root@wr741NDv1:~# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 2.0M 2.0M 0 100% /rom
tmpfs 13.7M 52.0K 13.6M 0% /tmp
/dev/mtdblock4 640.0K 244.0K 396.0K 38% /overlay
overlayfs:/overlay 640.0K 244.0K 396.0K 38% /
tmpfs 512.0K 0 512.0K 0% /dev
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_tiny=y
CONFIG_TARGET_ath79_tiny_DEVICE_tplink_tl-wr741-v1=y
# CONFIG_ATH9K_UBNTHSR is not set
# CONFIG_BUSYBOX_DEFAULT_FEATURE_IPV6 is not set
# CONFIG_IPV6 is not set
# CONFIG_KERNEL_IPV6 is not set
CONFIG_PACKAGE_ATH_DYNACK=y
CONFIG_PACKAGE_collectd=y
CONFIG_PACKAGE_collectd-mod-cpu=y
CONFIG_PACKAGE_collectd-mod-interface=y
CONFIG_PACKAGE_collectd-mod-iwinfo=y
CONFIG_PACKAGE_collectd-mod-memory=y
CONFIG_PACKAGE_collectd-mod-network=y
CONFIG_PACKAGE_collectd-mod-ping=y
CONFIG_PACKAGE_collectd-mod-uptime=y
# CONFIG_PACKAGE_dnsmasq is not set
# CONFIG_PACKAGE_firewall is not set
# CONFIG_PACKAGE_iptables is not set
# CONFIG_PACKAGE_kmod-ipt-conntrack is not set
# CONFIG_PACKAGE_kmod-ipt-core is not set
# CONFIG_PACKAGE_kmod-ipt-nat is not set
# CONFIG_PACKAGE_kmod-ipt-offload is not set
# CONFIG_PACKAGE_kmod-nf-conntrack is not set
# CONFIG_PACKAGE_kmod-nf-flow is not set
# CONFIG_PACKAGE_kmod-nf-ipt is not set
# CONFIG_PACKAGE_kmod-nf-ipt6 is not set
# CONFIG_PACKAGE_kmod-nf-nat is not set
# CONFIG_PACKAGE_kmod-nf-reject is not set
# CONFIG_PACKAGE_kmod-ppp is not set
# CONFIG_PACKAGE_libip6tc is not set
CONFIG_PACKAGE_libiwinfo-lua=y
CONFIG_PACKAGE_libltdl=y
CONFIG_PACKAGE_liblua=y
CONFIG_PACKAGE_liblucihttp=y
CONFIG_PACKAGE_liblucihttp-lua=y
CONFIG_PACKAGE_liboping=y
CONFIG_PACKAGE_libubus-lua=y
CONFIG_PACKAGE_lua=y
CONFIG_PACKAGE_luci=y
CONFIG_PACKAGE_luci-app-opkg=y
CONFIG_PACKAGE_luci-app-watchcat=y
CONFIG_PACKAGE_luci-base=y
CONFIG_PACKAGE_luci-lib-ip=y
CONFIG_PACKAGE_luci-lib-jsonc=y
CONFIG_PACKAGE_luci-lib-nixio=y
CONFIG_PACKAGE_luci-mod-admin-full=y
CONFIG_PACKAGE_luci-mod-network=y
CONFIG_PACKAGE_luci-mod-status=y
CONFIG_PACKAGE_luci-mod-system=y
CONFIG_PACKAGE_luci-proto-ppp=y
CONFIG_PACKAGE_luci-theme-bootstrap=y
# CONFIG_PACKAGE_ppp is not set
CONFIG_PACKAGE_rpcd=y
CONFIG_PACKAGE_rpcd-mod-rrdns=y
CONFIG_PACKAGE_uhttpd=y
CONFIG_PACKAGE_watchcat=y
CONFIG_PACKAGE_zlib=y
CONFIG_PACKAGE_kmod-lib-crc-ccitt=y
We (Freifunk) still have deployed 30,000 of such devices (mostly TL-WR841Ns). The problem are the 32 MiB RAM, not the flash. SquashFS has got severe thrashing issues when the memory is very low as it's pages are constantly being freed and reread, decompressed from flash leading to a load of ~7 and unresponsive devices. The thrashing state of SquashFS is not being detected. That is a known issue. We've started to replace the RAM and flash chips of these devices running them with pepe2k's u-boot mod. If you're trained at doing it and have the right tools, you need ~10 minutes per device for the replacement.
What about using Zram ? Make it worst or better ?
@kofec Actually I haven't tried it, yet. Thanks for the hint. I'm going to post some results, when I've tested it. In the long-term this will still not be enough, but it might bridge the time, until we've upgraded the devices.
is there someone who has problems with 32mb ram ?
is this a fix https://github.com/openwrt/openwrt/pull/1944
As far as 4/32 devices disappearing - are there any modern equivalents of the 4/32 TL-MR3040 (battery powered travel router)?
The closest I've seen is GL.iNet's wireless router, but you can't buy that without a built-in 4G module.
Feel free to open a new topic for your hardware request.
Is it mandatory that it be battery-powered? I am about to test out a GL.iNet MT300N (16/128MByte) device while I'm on a trip. It's powered by USB, so I plan to plug it into my laptop.
I realize this comment is OT: the original thread is about 4/32 devices. We should move this to one of the topics talking about good travel routers.
Honestly, given the ubiquity of USB power banks, this seems to be the ideal combination unless volume is really really important...
I think removing IPv6 om 4MB builds is a real disgrace and very contra-productive now a days as IPv6 is the new standard and regardless if it's present or not on any given ISP it may be anytime soon. Remove other things but not IPv6.
As mentioned the real issue with 18.06 is the 32MB of RAM not the 4MB flash and that's one reason the 17.01 should have its life extended a little more. It is a scenario that justifies.
It's not true that devices with 32MB RAM are disappearing, not for quiet a while.
I am interested in finding out 18.06 building for 32MB devices that is stable and running without any issues.
Hi:
Our users don't care about IPv6 as long as they can get into Internet without issues... of course your mileage is different.
About RAM: We don't have any RAM issues, KERNEL_SWAP is not set, so any RAM shortcomings would hang the devices, still all devices (more than 40) are working without issues. Of course they don't need to have any routing tables, just a gateway, and again, YMMV.
I think snapshots could work for you and they do have IPv6 enabled. I don't know if you think you need Luci too. The fact is, 4/32 devices are very little things now, and, if you are looking for a recent openwrt image fully-featured to work on those devices, you are crearly asking for too much.
So, I think you have three options:
a) If you don't want to build your own image, and want to have a recent, full-featured image working, a more beefy device should be chosen, as you don't need to replace many devices but only one.
b) If you don't care about luci, snapshots for tiny devices will probably work fine, they do have IPv6 enabled, no need to build custom images
c) If you need to build your own custom image, you could try that diff as an entry point, of course you'll need to make your own changes -as putting IPv6 on.
Hope this helps
I actually am able to continue building 32MB/4MB Image on Openwrt Snapshot using the following.
1)Strip out CPU suppport for cpu not supported in OpenWRT
2)Remove kmod-usb support completely
3)Patch out functions not supported in embedded devices
4)Strip out debug completely
We need to monitor and maintain a set of patches to stripped out functions not used in the linux kernel
It is not up to your uses to care about IPv6, but up to you that deploy OpenWrt. Internet is not IPv4-only anymore.
I recommend all the related reading about its importance in order to find out better the issues of not having it.
I agree with your sentiment, that an ideal firmware these days needs IPv6 support.
But @tatel is probably aware of the fact, that he will probable have to deploy suitable v4-v6 translation at the border routers to the internet. He'll have a beefier device there, where he doesn't need to worry about RAM and flash space.
So, if you control all the exits of your network, you can get away with having only v4 internally on the access points. Plus, for Layer 2 bridging(the main function of an Access Point), v4 or v6 is irrelevant.
who's got some stats of a stripped L2 AP 4/32.... ( snapshot minus as much as possible... but anything more then LUCI will do... ) UNDER LOAD ( at least 1 client hammering the connection anyway )
ram/cpu usage?
I'm using wr741nd on ATH79 (Strip out debug - leave printk) as Access Point (as second router/AP for better wifi coverage).
Generally I follow this guidelines:
I also removed all elements related to iptables (also kernel modules) and it is working quite well till now.
I add collectd to have statistics - send it to main router (it is collectd functionality)
I have MR3040. It runs quite well with 19.07 ath79 build, even with luci.
Sorry, man, but as @stragies guessed correctly, we deploy Mikrotik devices and even x86 hardware with plenty of RAM/Flash/hard disk space to do tasks as those you are talking about.
Our problem is not that we want to remain on 4/32 hardware out of homesickness, but that we really don't want to compel our people to buy new hardware, while what they already have at home can still be made to work fine.
So, we don't want to replace any user device unless absolutely necessary, but for newcomers we are willing to buy the newer, beefier, and even cheaper, hardware available today, that we know is working fine now, which was not the case when this thread started.
Again, my 2 cents: it is probably better for you to get a beefier device anyway
Please note I'm not saying you can't do, or shouldn't do, what you want. Probably you already have an old 4/32 device and simply want to try it out of curiosity. Anyway, please feel free to check -or build- what you want, and please let us know how it works.
And please note that you have plenty of snapshots for tiny devices here:
https://downloads.openwrt.org/snapshots/targets/ar71xx/tiny/
Last time I checked one of those it had IPv6 support, it was stable and it ran without any issues, as you asked for. Again, YMMV, so If you test any of these and find it lacks IPv6 support, it's not stable or is having issues, could you please report a bug, or, even better, post a patch?
Cheers