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

GeroldM · March 5, 2019, 6:14pm

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.

dlakelan · March 5, 2019, 6:20pm

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

GeroldM · March 5, 2019, 6:24pm

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

ffredy · March 7, 2019, 4:55am

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.

jeff · March 7, 2019, 5:22am

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,

kofec · April 4, 2019, 7:31am

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

Per · April 4, 2019, 12:08pm

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.

anon50098793 · April 4, 2019, 2:15pm

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. ?

kofec · April 4, 2019, 3:05pm

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

CodeFetch · April 4, 2019, 4:02pm

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 · April 4, 2019, 4:04pm

What about using Zram ? Make it worst or better ?

CodeFetch · April 4, 2019, 4:17pm

@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.

lucize · April 5, 2019, 1:51pm

is there someone who has problems with 32mb ram ?
is this a fix https://github.com/openwrt/openwrt/pull/1944

Entropy512 · April 5, 2019, 5:29pm

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.

tmomas · April 5, 2019, 5:45pm

Feel free to open a new topic for your hardware request.

richb-hanover-priv · April 6, 2019, 9:34pm

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.

moeller0 · April 6, 2019, 10:46pm

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

ffredy · August 31, 2019, 7:38pm

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.

tatel · September 1, 2019, 10:34am

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

gwlim · September 1, 2019, 10:42am

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