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