OpenWrt 23.05 runs on TP-Link TL-WR1043ND v1 (8/32 device)

Hi everyone,

I just managed to flash a TP-Link TL-WR1043ND v1 (very basic router from 2010 with 32 MB RAM and 8 MB flash) with OpenWrt 23.05 :tada:

  • Did someone try that before and how are things going since then?
  • What tests should I perform to see whether OpenWrt is actually running stable?
  • Any suggestions about how to decrease the RAM usage even further?

I'm fully aware that such devices are unsupported (due to low RAM and flash; there aren't even official builds for OpenWrt 23.05), but I was looking for some challenge and wanted to try OpenWrt's image builder. So, after about half a day I got the router running with zram-swap using a stripped down custom image (no LuCi, no opkg, no DHCP server, no PPPoE, no iptables).

I'm running the router as dumb AP for very few clients (private household) and to connect two networks using a WireGuard VPN. No obvious issues so far, but I don't really know how to actually test whether OpenWrt is running stable. Any suggestions? Besides, did someone try something similar before and can share their experience?

Here's a typical output of free:

              total        used        free      shared  buff/cache   available
Mem:          24696       14988        1944          16        7764        6324
Swap:         32764        1536       31228

Any suggestions about how to decrease RAM usage further? OpenWrt 19.07 usually had about 2x free and about 1.75x available RAM.


For people who are interested in how I did it: First I built a stripped down, custom OpenWrt 23.05 image for the ath79/generic target using OpenWrt's image builder Docker container (with Podman instead of Docker, but should work the same):

podman run -it --rm --rmi -v "$(pwd)/openwrt":"/builder/bin" --user root docker.io/openwrt/imagebuilder:ath79-generic-23.05.3 \
    make -j "$(nproc)" image PROFILE="tplink_tl-wr1043nd-v1" \
        PACKAGES="wireguard-tools -opkg -ppp -ppp-mod-pppoe -odhcpd -odhcpd-ipv6only -iptables -ip6tables -kmod-ip6tables zram-swap kmod-lib-lz4"

Then I flashed my old config backup archive (dumb AP and a WireGuard tunnel) with just two additions: First I told OpenWrt to create a zram-swap device with 32 MB and lz4 compression using the following:

uci set system.@system[0].zram_size_mb=32
uci set system.@system[0].zram_comp_algo=lz4

Second I added some sysctl options in /etc/sysctl.conf to properly enable zram-swap usage:

vm.swappiness = 180
vm.watermark_scale_factor = 125
vm.watermark_boost_factor = 0
vm.page-cluster = 0
vm.vfs_cache_pressure = 200

I don't think that it would work as full-blown router, but as dumb AP and for a WireGuard tunnel... What do you think? :thinking:

1 Like

You might want to patch zram initscript to use memfree as swap size.
swappiness 1 would swap less proactively.
disable luci and start only if needed.

swappiness 1 would swap less proactively.

AFAIK that's not how one should configure zram-swap, unless I understood something wrong. My idea is that since zram-swap is so damn fast, the device should swap early and proactively, especially in near-OOM conditions (i.e. always in case of this router :laughing:). With a swappiness of 1, the device wouldn't swap until the RAM is basically fully allocated; however, this would yield zram-swap unusable, because moving data from regular RAM to zram-swap requires free RAM for zram-swap, which isn't there anymore. The device runs OOM even though the zram-swap is still empty, just because zram-swap has no free RAM to allocate.

You might want to patch zram initscript to use memfree as swap size.

Why? AFAIK the recommended max size of a zram-swap is up to "average compression ratio" times the total RAM, so for lz4 around 2x the total RAM. The reasoning is simple: With a compression ratio of 2.0 one can fit e.g. 64 MB of data in zram-swap into 32 MB of physical RAM.

Naturally one can't really reach double the total RAM, because the kernel itself never swaps, but everything else could potentially go into zram-swap (sure, there's some slowdown due to the compression, but since the device would otherwise just OOM even in normal operation I feel like that this is acceptable). So, I understand your point in using memfree, because if memfree would be the first command to run after the kernel initialized, it would theoretically yield the total RAM minus the unswappable RAM allocated by the kernel. However, memfree isn't the first command to run, /etc/init.d/zram runs way later. So I had to make some assumption and figured that assuming 16 MB to be unswappable sound reasonable, leaving the other 16 MB swappable. So, 16 MB swappable RAM times an assumed average compression ratio of 2.0 yields 32 MB zram-swap.

In the end it doesn't really matter, because zram-swap is physically limited by the remaining free RAM. I could create a zram-swap with 1 GB - AFAIK it just wouldn't matter.

disable luci and start only if needed.

I'm a bit hesitant to flash with LuCi... Even though the RAM surely is the bigger problem, 8 MB flash is very limited, too. See df -h:

Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.3M      3.3M         0 100% /rom
tmpfs                    12.1M     76.0K     12.0M   1% /tmp
/dev/mtdblock4            2.5M    228.0K      2.3M   9% /overlay
overlayfs:/overlay        2.5M    228.0K      2.3M   9% /
tmpfs                   512.0K         0    512.0K   0% /dev

So, just 2.3 MB overlay left. The sysupgrade images with and without LuCi differ by 590 kB. What's LuCi's current total installed size? Besides, LuCi's memory usage is huge in comparison, I figured it will run OOM very early, even if just temporarily enabled.

Dont expect much performance if it swaps in and out, consider it as a safety net in case you grow out of memory with mini setup.

@PhrozenByte I'm running the latest official 23.05.3 on a WR1043ND v3, which has 8MB flash (same as the v1), but twice the RAM: 64MB. The OpenWrt image is about 6MB, including LuCi, so the 8MB flash is enough, it seems.

Regarding the memory, after everything is up and running (PPPoE connection), there's about 12MB free memory available, so the 32MB on the v1 is definitely not enough. These are just my observations, in case any of it helps you in your endeavours. I know it's interesting to experiment and whatnot, but I personally would probably replace the device with something a bit newer.

It has usable gigabit switch, like to have fancy admin module at that....

Regarding the memory, after everything is up and running (PPPoE connection), there's about 12MB free memory available, so the 32MB on the v1 is definitely not enough.

No doubt that 32 MB is not enough :laughing:

I assume that my stripped down custom image (in comparison to yours especially no LuCi and PPPoE) lowers the RAM usage by a few MB. I did some testing and OpenWrt runs OOM and crashes at about 7 MB of additional uncompressable (!) data stored in memory (using dd if=/dev/urandom of=/tmp/urandom.img bs=1K count=XXX). It naturally all depends on how compressable the RAM is, but 7 MB of uncompressable data is pretty impressive, since one could expect up to double that for regular (compressable) data. That's a way bigger margin than I expected...

I know it's interesting to experiment and whatnot, but I personally would probably replace the device with something a bit newer.

I fully agree. It's really just for testing and having some fun, I don't want to create the impression that the v1 is still sufficient and should be used in production.

1 Like

If you're up to it, you could try to mod your v1 with a 64MB chip, that would do the trick, see https://openwrt.org/toh/tp-link/tl-wr1043nd#hardware_mods

Not 32mb, I’ve got 23.05 and snapshot working fine on a few devices with 8/64. Can even run adblock with a small list.

I’ve up such a device (re-450v2) is a wireless repeater (ik double nat mode, so it’s routing too) for my friends Airbnb to get his guests off his main wifi. It’s been working fine for 2 months.