TPLINK RE450v1 too small overlay

Hello guys,

I've been running RE450v1 & v3 for several years and decided to upgrade both of them last week to the latest release, but failed with v1, while v3 went just fine.

I use wifi roaming between them and therefore deploy full WPAD instead of the default one.

it turned our that after the upgrate v1 doesn't have enough space in the overlay partition, while v3 has plenty. They both have 8MB on board and I can't figure out what is wrong and how to fix that:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                    60.3M     64.0K     60.2M   0% /tmp
tmpfs                    60.3M     68.0K     60.2M   0% /tmp/root
tmpfs                   512.0K         0    512.0K   0% /dev
/dev/mtdblock4          512.0K    236.0K    276.0K  46% /overlay
overlayfs:/overlay      512.0K    236.0K    276.0K  46% /


root@OpenWrt:~# cat /tmp/sysinfo/model
TP-Link RE450 v1

cat /tmp/sysinfo/board_name
tplink,re450-v1

cat /etc/banner
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 21.02.2, r16495-bf0c965af0
 -----------------------------------------------------

grep squash /proc/mounts
/dev/root /rom squashfs ro,relatime 0 0

v3 has the following"

root@Extender2:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                    28.6M    216.0K     28.3M   1% /tmp
/dev/mtdblock8            2.3M    912.0K      1.4M  39% /overlay
overlayfs:/overlay        2.3M    912.0K      1.4M  39% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@Extender2:~#  cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 00002000 00010000 "info"
mtd2: 00002000 00010000 "partition-table"
mtd3: 0000a000 00010000 "info2"
mtd4: 00022000 00010000 "config"
mtd5: 007a0000 00010000 "firmware"
mtd6: 001f4097 00010000 "kernel"
mtd7: 005abf69 00010000 "rootfs"
mtd8: 00250000 00010000 "rootfs_data"
mtd9: 00010000 00010000 "art"

and of course I was able to deploy WPAD.

I did firstboot and all kinds of sysupgrade -n, but not sure what is the culprit here. Any advise?

You should check the v1 DTS, the partition layout is probably such that it does not allow for a big chunk to be used by OpenWrt, unlike on the v3.

Might be at the point where you'd need to strip things (PPP is an obvious candidate e.g.).

Thanks @Borromini for your response!

are you saying that solution would be to build an image myself excluding ppp packages?

i wonder if somehow the partition was flashed in a wrong place/address and hence there is practically no space left just because it is occupied by the firmware piece?
I mean the f/w is 4-5 MB in size, but total flash is 8 MB and therefore I should have +/- the same amount of space just like on another h/w v3. Do I miss the point?

PPP and what it pulls in take quite some space (although it would not surprise me if your device already doesn't have it, since it's not a router but a repeater/AP).

If the flash partitioning is all over the place then it might very well be that the actual space available to OpenWrt, while keeping compatibility with TP-Link firmware, is very limited. Hence my recommendation to compare DTSes for the partition layout between v1 and v3.

Thanks! @Borromini

I'm not sure I'm following you with DTS comparison :upside_down_face:
Do I get you right that it should be a predefined configuration file which Iwould later be used by image builder?
I did that 5-7 years ago last time when all devices were of 4 MB ROM :smiley: so need to recap.

here is what I have in v1 at the moment:

root@OpenWrt:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00020000 00010000 "u-boot"
mtd1: 005e0000 00010000 "firmware"
mtd2: 001f466d 00010000 "kernel"
mtd3: 003eb993 00010000 "rootfs"
mtd4: 00080000 00010000 "rootfs_data"
mtd5: 00010000 00010000 "partition-table"
mtd6: 00020000 00010000 "info"
mtd7: 001c0000 00010000 "config"
mtd8: 00010000 00010000 "art"

Your firmware partition is 005e0000 which is hex for 6160384 bytes (< 5.9 MiB). That's the space used for all three partitions you see listed underneath - kernel/rootfs/rootfs_data. In the DTS, you can see the partitions labeled, along with their sizes. Compare that with 7a0000 for your v3 ( > 7.6 MiB) and you can see the size difference (and the probable issue).

Keep in mind the kernel partition is not mounted and won't show up in df.

You can check the DTSes here:

Thanks for looking into this, if I got the point the DTS files for the boards are indeed different and v1 seems to lack the details, while v3 is full of stuff:

as a result, every v1 build that is compiled will miss necessary allocation &partitions structure resulting this misbehavior? or it will inherit the details from the #include https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/qca9558_tplink_rex5x.dtsi ?

what would be the most appropriate way to resolve this?

I merely pointed to the DTS so you could get an idea of the complete layout.

The only thing you can do is making sure your image fits. I pointed out how much flash OpenWrt can use on each model. That's the constraints you're operating within.

aha, okay, so practically speaking that's behavior by design due to platform difference.

if I remember well the daily snapshot doesn't have luci so perhaps that would be easiest solution to move ahead, as i don't really use it on a dump AP.

Snapshot will have an even bigger kernel than 21.02. I'd recommend you build a 21.02 image without LuCI, but yeah you can use snapshot as well if you'd like.

OMG :smiley: that's the latest snapshot:

does it have a different partitions layout?

root@OpenWrt:/# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                    59.5M     76.0K     59.4M   0% /tmp
tmpfs                    59.5M     48.0K     59.4M   0% /tmp/root
overlayfs:/tmp/root      59.5M     48.0K     59.4M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev

You could explore the possibility of absorbing partition-table, info and config into the firmware, i.e. letting OpenWrt use them for jffs2 storage, clobbering any data that might be used by stock firmware. There is about 2 MB set aside there. But it is possible that something important like the sticker MAC address is in info, or it may not boot properly without partition-table. So make backups of all of them and have a way to restore if it doesn't work.

This sort of change usually isn't approved into the project since being able to somewhat easily return to stock firmware is considered important.

aha, I see, thanks @mk24 for the details. that would definitely explain the difference in available space.

Nope. Exact same layout, otherwise sysupgrade would have broken your device. Did you notice you have no /overlay? So no writable file system? :wink: Like I said: bigger kernel, less space left.

ouch, something is really strange over here, 4 years old build cant fit as well:

root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 3.5M      3.5M         0 100% /rom
tmpfs                    59.5M     76.0K     59.4M   0% /tmp
tmpfs                    59.5M     48.0K     59.4M   0% /tmp/root
overlayfs:/tmp/root      59.5M     48.0K     59.4M   0% /
tmpfs                   512.0K         0    512.0K   0% /dev
root@OpenWrt:~# cat /etc/banner
  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt SNAPSHOT, r19069-98113220fa
 -----------------------------------------------------

I wish I recall the version I was running before the upgrade, it was definitely not THAT old

ohm no, my mistake:

root@OpenWrt:~# sysupgrade  -n openwrt-18.06.0-ar71xx-generic-re450-v1-squashfs-sysupgrade.bin -F
Mon Mar  7 21:28:50 UTC 2022 upgrade: Image not in /tmp, copying...
Mon Mar  7 21:28:50 UTC 2022 upgrade: Image metadata not present
Mon Mar  7 21:28:50 UTC 2022 upgrade: Use sysupgrade -F to override this check when downgrading or flashing to vendor firmware
Image check failed.

trying to go back to 18.06 with no luck

ha, finally killed it :slight_smile: while forcing 18.06, doesn't boot up and LAN is not blinking

will look for uart now

Use the image builder to rebuild 21.02 without LuCI.

Little point in downgrading to 19.07 (or even 18.06!) as that will be EOLed in the near future.

managed to recover the device somehow:

BusyBox v1.28.3 () built-in shell (ash)

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 OpenWrt 18.06.0, r7188-b0b5c64c22
 -----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~# fd -h
-ash: fd: not found
root@OpenWrt:~# df -h
Filesystem                Size      Used Available Use% Mounted on
/dev/root                 2.5M      2.5M         0 100% /rom
tmpfs                    61.2M     68.0K     61.1M   0% /tmp
/dev/mtdblock4            1.9M    300.0K      1.6M  16% /overlay
overlayfs:/overlay        1.9M    300.0K      1.6M  16% /
tmpfs                   512.0K         0    512.0K   0% /dev

apparently it was possible to deploy something large enough with old releases... I can't belive I was running SUCH old one :joy: