Interesting... Can you check a initramfs image build by our system if it has the uencrypt package?
Oh, uencrypt is in the buildbot squashfs-sysupgrade image, just not the initramfs-kernel image.
Which is fine, since the install instructions are going to say to install sysupgrade from the initramfs image anyway. Should be ok I guess
but the uencrypt package should be installed by default...
It is, at least in the squashfs-sysupgrade image.
I don't know if my initial expectation to see it in the initramfs-kernel is even valid.
Although, surely there exists some other target-specific module that is required to boot an initramfs for some device (i.e. a kmod). buildbot has to have some way to bake that into the initramfs-kernel image for those devices. I'm just not smart enough to know the mechanism openwrt uses for that, or if we would even want that for uencrypt (which is not absolutely necessary to boot obviously)
I binwalked the tplink_deco-s4-v2 snapshot image and it contains uencrypt. So. the essence of the problem is not clear for me.
~/temp/_openwrt-ath79-generic-tplink_deco-s4-v2-squashfs-sysupgrade.bin.extracted/squashfs-root/usr/bin$ ls -la | grep uencrypt
-rwxr-xr-x 1 xxxxx xxxxx 8213 Sep 12 00:43 uencrypt
this is sysupgrade the concern was that initramfs and i think also factory doesn't have the package
uencrypt is in place in deco-s4's factory.bin.
Yes, the unexpected part was only that the initramfs image did not have uencrypt.
I see that for the other Arcadyan WG4Ń Ń 223 devices that need it, they have telnet so they just flash the sysupgrade directly.
On the DecoS4, we have no telnet and have to hack uboot to bypass signature verification, so we just boot to the initramfs version initially as a temporary measure to install sysupgrade.
So its not a big deal that the macs are bogus during the temporary initramfs foothold since they will be fixed when the sysupgrade is installed, I just wasn't expecting it since I always built initramfs as a single target thus I got uencrypt there as well.
Ah, ok. Initramfs for Arcadyans wasn't tested because U-Boot is password protected and there is no way to interrupt boot process and start such type of image. Thus, this "feature" wasn't identified before. 
Well, with the expectation that you can't easily test the mac address decryption when operating in temporary initramfs mode during installation (no biggie), I think we have a successful snapshot being built, and it can even be flashed without opening the case. I'll add it to the table of hardware...
1 Like
No, I didn't risk totally destroying it.
Which sysupgrade image should I use? I've got the Deco S4R, FFC ID: TE7M4RV2
snapshot links (see caveats at https://openwrt.org/releases/snapshot):
https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_deco-s4-v2-initramfs-kernel.bin
https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-tplink_deco-s4-v2-squashfs-sysupgrade.bin
1 Like
Thank you! Worked perfectly.
Can you tell us more about that "firmware"? I'm sure a lot of people with a Deco M4 would be very interested in one for their devices too.
The "firmware" file takes advantage of unsafe code added by tplink into uboot to provide the http uboot firmware recovery functionality in the bootloader. Specifically a stack buffer overflow from a size-unlimited sscanf early in the reading of the firmware file's fw-type field. The overflow is exploited to overwrite the return address to take control of code execution and run shellcode that simply executes stock uboot tftp functionality (see source of shellcode inside "firmware" file)
It is possible that something very similar, if not the exact file, would work on all tplink firmwares with http uboot firmware recovery, which according to https://www.tp-link.com/us/support/faq/2958/ includes the M4, but I can't easily verify that since I don't have any of those devices and, at least as far as I've seen, tplink doesnt include the uboot partition in downloadable firmware files (relying instead on what was already put in place at the factory without upgrading it).
If someone with an M4 (or any other device from that link) could dump the uboot partition from openwrt, we can take a quick peak and verify. (Or someone really bold could just uboot-recover to the S4 "firmware" and find out the quick-and-dirty way)
May I ask what happened to the debug firmware method for M4?
The debug firmware seems to not work for some people. That's the main reason I ask. And your version seems more elegant since you don't need telnet or can just sysupgrade from the ramfs version.
I myself have never used it since I soldered cables to my three devices and flashed them directly from uboot. But that's not an option most people even want to consider.
I'll send you a pm to get that uboot dump to you.
The tftp method works great. I have three S4 access points now on openwrt.
Thanks.
1 Like
Would you be willing to share your config? Iām looking to do the same thing soon. Thanks.
Happy to share - the config itself was fairly normal OpenWRT except for the wpad mesh install and mesh config. What are you wanting to know? The whole process to get OpenWRT on the devices (taken from all the prior work and notes above) or just the wpad-basic removal and wpad-mesh install and setup?