What has to be done so we remain able to build next years an OpenWrt image for 4/32 devices

That sure is a lot of straw men. I am not making demands. I don't even have a 4/32 router, so it doesn't really matter to me what happens. I will be using v19 either way. I am just saying what I think would be the best way to solve it. I think it would be more time consuming to try to make a special version of v19 for each 4/32 router in use to make it fit.

I haven't said it's easy, I have only said that it's not necessary to fix as many security issues as some people have claimed for the firmware to be good enough. I am not refusing to do anything, I just don't have the skills. Your allegation about not seeing that different hardware has different capabilities makes no sense. Why would I suggest to keep an older version that still fits fairly well if I didn't?

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.

3 Likes

Out of curiosity are any of the common devices actually 4/32 devices?

When I do this search I find that there are quite a few TP-Link devices with 8/64 or better

https://openwrt.org/toh/views/toh_available_864?dataflt[0]=device+type_%3DWiFi+Router&dataflt[Brand*~]=tp-link

It is only 4/32 units that you can buy here.

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.

1 Like

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,

Maybe we should share here about "optimization" for 4/32 devices. Like Optimized build LEDE 17.01 / OpenWrt 18.06 / libreCMC for "small devices" TP-LINK WR740N(D) WR741N(D) WR743N(D) WR841N/D) All Versions.
Disable IPv6 or remove iptable if this is internal Access Point

1 Like

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.

    1. Security Fixes
    1. ?
    1. ?

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.

3 Likes

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.

1 Like

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.

1 Like

Honestly, given the ubiquity of USB power banks, this seems to be the ideal combination unless volume is really really important...

1 Like

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.

3 Likes

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