The web flash thingie takes multiple file formats, including the factory image format made by OpenWrt.
Thanks for the data dump, the matching bits on the WD009 are indeed on mtd5 (params, just after the kernel partition), and at 0x00, so even the smallest overflow of kernel bits would result in the overwrite of the original u-boot environment:
However since OpenWrt would be using mtd2 as uboot-env, if it was set up as such in envtools, that partition wouldn't matter - and I doubt it does much for the stock OS either. It does not match neither the running config IP addresses, nor the TFTP/webflash recovery mode network setup. To me it looks like a developer accidentally saved some testing data by accident, and the partition wasn't updated since (not the first time to happen to a Chinese manufacturer, e.g. ZTE sent out an update back in 2010, setting everyone's IMEI numbers to a test unit used in their labs). I'm more or less certain that apart from the section a bit further in the file, it is unused by the stock firmware.
It contains the manufacturer name, device name, a version number, the main MAC address, and two hashes (haven't figured out what they are for, but none of the partitions, or parts of the mtd5 partition, match the hash).
That's interesting. It should work. Can you try generating a script with this and see if that works? Worst case scenario you get telnet access and can do the DD partition dump manually.
Okay, I've read through the PR comments. I think I know the reason for the confusion.
The stock u-boot indeed seems to use mtd5 as uboot-env, however the WD009 builds replace it with a mainline build. This, I believe, changes the partition being used for env stuff from stock_mtd5 to openwrt_mtd1 (which is stock_mtd2). The reason why on the WD03 builds saveenv screwed things up is most likely because parts of the kernel slipped over to that partition, and saveenv basically overwrote parts of the kernel. This shouldn't be an issue on the WD009, however I'll test this theory tomorrow.
Yeah, the RP-WD03 uses a wrong attitude: it starts the firmware partition at the stock kernel partition and doesn't care about params, config and other partitions in the middle. In turn, u-boot doesn't care about OpenWrt also.
And yeah, WD-009 uses the original partition scheme (while wasting a few KByte flash space), so no issues will arise!
Sorry! Already installed OpenWrt, so not running OEM now. But I did enable telnet, manually executed my script, and it worked fine (backing up the partitions). I am wondering about path issues perhaps, couldn't really check that.
I think you could fix that by rolling your own u-boot, as per the WD009. I've also recommended ditching the extra partitions inbetween for the WD009, but as you can read above, it was ditched.
No worries, as long as you have the backups, everything should be fine. If it comes to that, you can even pry the case open (make sure you don't make the same mistake I did, and do it with an SD card inserted - I pretty much killed the slot on my first unit), and with a standard SOIC8 clip and serial flasher, you should be able to easily write the backup of mtd0 back onto the flash.
Just work your way around the edge horizontally with a plastic pick. Watch out, because the plastic is soft, and the plastic ears are thick - it's hard to open it up without damage. Once you clicked them all out, you'll have to apply some continuous force, as the battery has a nice double sided tape sticking it both to the bottom and top part of the case, BUT also the antennae are glued to the case - make sure you don't rip them.
FYI Pushing the 2.4G/5G button on my router soft-bricked the device.
The router was configured with 2.4G working, but I left 5G disabled. The button seems to have put the router in 5G only mode, as the 5G led lit up. Pushing and holding the button did not reverse the issue, and neither did rebooting the device.
The router would allow wifi connections, but would not hand out IP addresses. With SSH disabled on the Ethernet / WAN port, using the reset button was the only way to get access to the device. I will provide details when I get them, but wanted to put this warning out there.
In OpenWrt, the 2.4 > 5G button is used for radio reset, whereas on the official firmware it is indeed used to switch between modes (IIRC you need to long press the button, this is to avoid accidental switching since the button is not recessed at all - which is why I recommended above to map it to something else, as this will most definitely happen to people who carry the device around).
Thanks for all your hard work on this guys. I've been waiting for support on this for a while. I got the snapshot installed and luci finally installed. My only issue is with the wifi. Specifically 5 GHz seems to be problematic. It says its active and openwrt allows me to connect as a client, but using 5 Ghz as an AP only, I cant get to work. Seems like Ravpower's switch config is getting in the way? Anyone having temperamental wifi issues?
@blocktrron another interesting thing popped up. Apparently the latest u-boot builds for the WD009 are over 350kB in size - which would most definitely not fit the 192kB partition allocated. The factory target includes u-boot, however I'm not sure if it actually gets flashed during a factory flash (either with TFTP or the web recovery). Have you done any testing with the custom built u-boot? As far as I can see, so far only this device has mainline support (or rather, target builds) for u-boot on ramips targets, so there's not much to go on from.
...reading through all of the above entries (thanks to all contributors and their hard work to get and keep this thingy rolling), it is unfortunately not fully clear to me whether or not one can easily get back to the stock (RAVPOWER) firmware - in the case of the cases...
I have one original RAVPOWER WD-009 unit in operation and bought a dedicated second unit specifically for OpenWRT trials (RAVPOWER recently sold some refurbished units for just 25 bucks).
SD Card support would be essential for me, as I am running a wirelss cyphered file server on it, which does it's job beautifully. I know it could be covered by USB as well, but the SD card fits better in the housing and I can close the lid to cover the connections. Also I could copy from SD Card to USB port.
If this does not work out for me, I am keen to go back to the original stock firmware and use it as it was delivered...