Okay, now it's completely wrong.
As per the oem firmware image this is the "default-mac" partition:
partition default-mac base 0x85000 size 0x01000
But you let it start at 86000, skipping 1000. So the file you sent me in the PM is the "device-id" sub-partition. And what you wanted to send me you skipped completely.
My apologies. The 0x085000 block is now in your inbox.
@Mork Hey there. We’re you able to load the OpenWrt firmware onto the device? If so, did you load it via soldiered wires or using the web recovery page? Thanks.
He flashed his modified version via soldered wires.
Yeah @Pocket_Sevens, I was able to load OpenWrt onto the Deco S4. Like Bob said, I flashed by cracking the device open. All in, I it definitely doesn't appear to be as simple to get rolling as the M4 is. Especially without the benefit of the web interface.
The first issue I had was that I wasn't able to read the label mac address from the config the same way the Deco M4 can, so I made a risky decision to manually overwrite the config partition with the label mac address stored in the same place. This does work, but I question whether the 5g antenna calibration is being loaded properly.
The default configuration from Bob's fork (and my subsequent changes) has both logical ethernet ports mapped to the same interface. It was easier for me to fix these in /etc/config/network after the fact, and I had documented that new network config in this thread.
Lastly, if you want to do this I'll let you know that I was not able to get the 21.xx release running on the device. I flashed the squashfs-sysupgrade image which only resulted in a bootloop on the device. My final working changes were accomplished by checking out the v19.07.10 tag from the git repo, and incorporating @bobthebuilder's fork modifications into that local branch. I can try to get a fork going for Deco S4 support on Github. I just haven't had an opportunity to yet.
I had the problem that ubus wouldn't work if I built a custom firmware based on v21.x and it turned out that using ubuntu was the problem. Using debian the image should work fine. Here is a link leading to the root cause of that: Init routine goes into loop when trying to execute ubus with custom image for Deco M4R - #4 by Lanchon
Regarding the location of the mac address in the Deco S4 flash, looking into the uboot binary it appears the mac-default section is encrypted with an as-yet-unknown scheme (appears to be DES based) with key of "360028C9064242F81074F4C127D299F6" (apparently a popular hardcoded constant for tp-link)
Does anyone already have a magic decoder ring for this?
wrote a decoder ring here: https://gist.github.com/naf419/4184fd2c370caffd8a9430f7164e060f
not sure how it could be integrated in an openwrt image though
UPDATE: oh i see, it appears the purpose of 02_network's ath79_setup_macs() is for exactly this situation where there's more logic needed to translate a mac than straight DTS magic. ok let's try that...
here's my work-in-progress if anyone wants to make a suggestion:
working: script to decrypt label mac address from flash, autosetting the mac for the 5g radio (wlan0) and eth0.1 (?)
not working: setting the other eth0 and the 2.4g radio (wlan1) mac:
not attempted: packaging deco_decrypt correctly, currently just shoving the binary into the image
root@OpenWrt:~# find /sys -name address -exec echo {} \; -exec cat {} \;
/sys/devices/pci0000:00/0000:00:00.0/net/wlan0/address
28:ee:52:4d:cf:2a
/sys/devices/platform/ahb/18100000.wmac/net/wlan1/address
00:02:03:04:05:06
/sys/devices/platform/ahb/19000000.eth/net/eth0/address
0a:49:6e:f0:fa:88
/sys/devices/virtual/net/lo/address
00:00:00:00:00:00
/sys/devices/virtual/net/eth0.1/address
28:ee:52:4d:cf:28
/sys/devices/virtual/net/br-lan/address
28:ee:52:4d:cf:28
(label is 28:ee:52:4d:cf:28)
i see where in 'art' 00:02:03:04:05:06 is coming from, but my attempt to patch it in 10-ath9k-eeprom fails. i don't really understand the difference between eth0 and eth0.1 or how one picks up the label mac and one doesn't.
For folks that have lost their soldering irons, I created a "firmware" file that exploits a memory safety bug in the S4 bootloader web recovery to allow unsigned openwrt firmware to be tftp uploaded without serial access: https://drive.google.com/uc?export=download&id=1Szb5G5iWWnKNk8BOfs0i2cVAnv3oN9d1
Installation:
@naf How did you make that firmware file? Also did you figure out the issue with the 2.4g radio mac address?
Yes, all mac addresses are decrypted and used successfully in the version I submitted for official support (https://github.com/openwrt/openwrt/pull/10444).
Firmware file was created based on reverse engineering the tplink-modified uboot code located in flash (assisted by similar source code in M4R GPL'd code), leveraging trivial stack buffer overflow to overwrite return address in stack, and exploiting with a payload that calls back to stock uboot functions in memory (shellcode source included in firmware file itself in junk data)
Patches are merged in master now, so I tried the first snapshot.
It boots fine but is missing the uencrpyt, so no correct macs.
Apparently MULTI_PROFILE and PER_DEVICE_ROOTFS means uencrypt gets built as a module, which doesn't do a whole lot for you on the initramfs boot. Obviously building yourself with only the deco target selected will include it for real, but what about snapshots/releases?
@Ansuel @cotequeiroz @csharper2005
I wonder how the Arcadyan router folks address this?
Do the Arcadyan install instructions just say "make sure to install the uencrypt opkg after flashing or your mac addresses will suck", or am I missing something extremely dumb on how to get uencrypt included in initramfs for MULTI_PROFILE?
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