Yeah, here in the South-American markets it is actually difficult to get much else than TP-Link hardware. Importing networking gear is terribly expensive here. Amazon/Ebay/NewEgg do not ship to here, so you must pay for a service that receives your goods in the US and then sends it to here. That service bases their tariff on size weight and what they think the package is worth.
Then it arrives at customs and they add a tax of what they think the package is worth as well. And no, the value on your receipt has barely any influence on their opinion.
My friend bought a sound bar for under the TV on Amazon. A Yamaha unit, for 130 USD. When it finally arrived an extra 100 USD was slapped on. That is the cold hard reality here.
People have barely any other option than purchase the TP-Link hardware that is on offer here. Sure, from any other standpoint your advice is valid, But here in South America it is just as useful as Santa Claus, unfortunately.
I fully support keeping the support for people to be able to build for devices like 32/8 which are still very popular and with decent performance. Asking people to throw away their 32MB devices and buy one with 64MB it's a bit of "too much" at the present.
In the other hand I understand the severe limitations of 4MB devices (like people neglecting IPv6 to make it fit) and think these cases are difficult to be kept maintained by developers and should be community-only supported otherwise.
But the main point about this topic I consider should be to keep support for 32/8 devices specially given that 18.06 with newer LuCI has NOT been running well on all of these devices. Therefore despite the release of 19.xx soon I believe 17.xx should be kept maintained at least minimally for bug and security fixes and other major important things so it allows these well spread hardware be used for a while.
I also don't think it imposes any work duplication on developers. Major efforts should of course be kept directed to the current versions.
Has been discussed in depth in other threads over a period of years now and your thoughts are not in line with reality.
This thread, in fact, is a response to those threads and how the OpenWrt project can support those individuals and groups with a significant investment in devices with less than 8 MB or flash and/or less than 64 MB of memory that have the skills to build their own firmware to be able to do so for a brief while longer,
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.
@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 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.
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.
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.
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