[tedm]

I have one of these running OpenWRT 19. I'd like to migrate it to dd-wrt.

Unfortunately, all of the guides out there for reverting to factory firmware don't work. The router WILL pull the file named firmware_WHR-600D.ram via tftp on boot if the AOSS button is pressed on power up - but, it won't run it. Instead it only will work with the AOSS button using the initramfs firmware off the openwrt site.

Since I can SSH into the OpenWRT command line on the router, I can wget the dd-wrt firmware and do an mtd write to the linux partition. I was wondering which firmware file I should use for this? The current build directory has a firmware.uimage, a firmware-us.bin and a buffalo_whr_600d-webflash.bin file.

I can open the router and use a serial cable if necessary but I'd rather not do that if I don't have to.

[bushant]

In this pretty long thread is found
this procedure.

May be of help.

[kernel-panic69]

I'm trying to recall how I recovered / flashed DD-WRT, but this procedure on the next page in that thread is for no serial to recover to factory. I have one of these in hand somewhere, have not updated it in a hot minute. If you read to the end of that thread, you will see where I collab'd with another user and BrainSlayer to fix the issue of upgrading DD-WRT on the device I could've sworn I had worked on building a device wiki for this damn thing.

[tedm]

Thanks, all, the non-serial procedure documented in that thread is what I used, no joy.

The same 27 05 19 hex string is present at the front of the openwrt initramfs, as what is recommended in the wiki to do to modify the factory firmware (which I have a copy of) and it's present in the firmware-us.bin at the beginning, etc. Evidentially it's the beginning of the actual firmware, with the header stripped off, and the idea behind the AOSS tftp is to tftp in that firmware to ram, than transfer boot to that firmware. Once the firmware is then running, you can then flash the actual hardware with a copy of the real firmware which has the header (which I assume has checksum info, etc.)

Except, that you can't. In other words, the only firmware with header stripped off that the AOSS tftp will accept is the Openwrt initramfs one.

Without a serial console on it I can't see what happening (assuming I might even get output from the serial console)

The openwrt, factory, and ddwrt firmware all have this extra 52 bytes at the head of the firmware and I'm ASSUMING it is being used by the factory webflash interface to verify the firmware is "real"

But what I don't know is if during the conversion process from factory to openwrt, if the openwrt initramfs firmware not only boots, but repartitions the flash or does other mucking about. I don't know enough about how OpenWRT or DD-WRT implement their "factory-to-myfirmware" process. I BELIEVE that what is done with the "normal" way with most routers is that the actual Linux partition firmware has a header tacked on it to "fake out" the OEM firmware into believing that a factory-to-dd-wrt or factory-to-openwrt firmware is actually an OEM firmware. That's what I think the 52 bytes are.

But this Buffalo device is an outlier. Not only does it do some very wrongheaded things with the 5 Ghz radio (which DD-WRT has a fix for and OpenWRT does not) but this AOSS tftp recovery process also seems to be doing SOME kind of inspection or checksumming or something to verify the firmware it accepts via TFTP is "real" For whatever reason the OpenWRT initramfs file meets that criteria, the dd-wrt firmware does not.

DD-WRT and Freshtomato appear to take a minimalist view of the CFE and uboot loaders, the factory-to-ddwrt firmwares for most routers don't seem to mess around - and with weirdo routers like the Cisco Exxx series where the CFE does that dual partitioning nonsense, the factory-to-dd-wrt firmwares don't mess with the bootloaders - instead you have to load a minimal dd-wrt firmware on the router then overwrite the CFE with a better one. But OpenWRT I don't entirely trust because they seem to take the approach that if the bootloader doesn't do what they want or if the flash is not partitioned how they like, during the factory-to-openwrt process they will completely overwrite and change things around.

I don't know of many DD-WRT supported routers that can't be returned to factory. But there are many OpenWRT supported routers that once you convert them to OpenWRT it's a one-way door, there's no way to go back to factory firmware without bricking the router. Some of the newer ASUS ones are like that. I'm kind of wondering if this Buffalo is the same way and that once I loaded OpenWRT on it, the flash got repartitioned or the uboot got replaced or modified or something, so it's impossible to return it to factory.

[kernel-panic69]

I don't have my notes handy, and I don't have time to read through the paper trail betwixt myself and BrainSlayer about this device. Pretty sure there is also another how-to somewhere that I've bookmarked, but not sure on which workstation or laptop. I'll pick through everything, but I am fairly certain that I have had to TFTP back to stock in my travels on that device as well as another Buffalo device I have in inventory.

EDIT: Every resource I have found uses the same TFTP procedure with header removed(except to flash initramfs image of openwrt). So, are you saying that the header is present in all the files or the byte sequence AFTER the header is present? I'm wondering if the firmware.uimage file of DD-WRT can be used to recover (I need to find my notes and such). I would recommend an unmanaged switch and setting TFTPD32/64 to use at least a 1024 byte anticipation window, if not 2048.

https://forum.wifihell.com/thread-301-1-1.html

https://openwrt.org/toh/buffalo/whr-600d

[tedm]

[kernel-panic69]

And you completely ignored the wifihell link. Mixed reports on needing the AOSS button depressed to initiate TFTP related to the possibility of different u-boot versions. Only way to tell what is going on or not is serial console connected. Also, for the sake of sanity:

Restoring the buffalo firmware on a whr-600d
Buffalo WHR-600D with DD-WRT?:

[tedm]

No, I didn't ignore that link, and that link contents were posted into the other dd-wrt thread which I read completely. And they simply don't work. I can strip the header off the factory firmware no problem, I can pull it on to the router via AOSS button press no problem and the router reboots as per the instructions - however it does NOT boot into the factory firmware that was just pulled into ram - it merely reboots into the existing OpenWRT firmware that was flashed to the router.

And no, just booting WITHOUT the AOSS button pressed does NOT trigger a tftp request. I have no doubt there are different uboot versions out in the wild.

As I stated initially, it would be useful, since I have an operating OpenWRT firmware on the router, to do the flash back to the factory firmware - or to the dd-wrt firmware - from the OpenWRT command line.

IT APPEARS the dd-wrt "firmware.uimage" file was designed to be used just like the Openwrt initramfs image - with the AOSS tftp process that pulls the image into ram, boots into it, allowing the operator the ability to have an operating Linux image to do the actual firmware flash. The dd-wrt files firmware-us.bin file was designed to be loaded via the factory webinterface. I say "appears" because with this router, unfortunately there is no DD-WRT wiki page that explains all of this like for many other router models. That's precisely why I'm posting here.

Both dd-wrt webinterface, and openwrt webinterface, and the factory webinterface make assumptions and do different things, but ultimately all of them are using the mtd command under the hood

With Openwrt's webinterface, it just runs the sysupgrade program,

sysupgrade -v /tmp/firmware_image.bin

and that program makes a BFD about of backing up the packages and config before flashing with mtd, then restoring them again. It's explained here:

https://openwrt.org/docs/guide-user/installation/sysupgrade.cli

The actual command that does the flashing is executed by sysupgrade, it is:

mtd -r write /tmp/firmware_image.bin firmware

dd-wrt is similar, the webinterface runs the write command

write routermodel-webflash.bin linux

but like openwrt, I assume that write also executes a variation of mtd

With the factory it may be doing the same thing or it may simply be slapping the next factory firmware version in using mtd and assuming the NVRAM variables are all the same.

Unfortunately, there's a TON of misinformation from various users on what is actually going on. Here for example is a typical one:

https://forum.openwrt.org/t/understanding-sysupgrade-vs-mtd/59614/4

As you can see, user "hnyman" outright lies in his reply to user "mbrijun" claiming that mtd cannot be used to flash his EA8500 only sysupgrade, when in reality, sysupgrade is using mtd to do this very purpose. "mbrijun" later pulls down hnyman's pants by posting the relevant code from sysupgrade showing that it was, indeed, a lie.

The "by the book" way I think to flash my Buffalo router from an AOSS button press tftp would be to rename the DD-WRT "firmware.uimage" file to the Buffalo magic filename, tftp it over via AOSS button press, execute it and then use it's web-update interface to actually flash the router with the webupgrade image. That is what I was trying to do. But it does not work - at least it does not work with the files from the dd-wrt December 3rd release.

So, thus my request to find out if a shortcut will work. Is the mtd command the same between openwrt and ddwrt? Can I pull the dd-wrt firmware-us.bin over via wget and flash it via mtd? Or do I have to strip the 52 byte header off before flashing it with mtd? Or is mtd different between the distributions and none of that will work?

What it appears to look like with this one is that possibly changes to the dd-wrt firmware.uimage file have made it no longer work with AOSS button press tftp. Possibly, going back in time 4 years and pulling a much earlier version of firmware.uimage will work - if so, then that is a bona-fied BUG and must be posted to the build thread.

Since almost the entire point of going through this process is to file an update for this router in the release thread on the forum, (I have no real need of it to act as a wifi access point) basically a thumbs up or thumbs down on whether the current DD-WRT release will work on it, this is another reason for holding off breaking out the serial console cable. Unlike OpenWRT, the DD-WRT project does not really accept reaching for the "step 1 - open the case and install a serial console" crutch. Which I personally heartily agree with, BTW. The world is full of inexpensive used routers, and there has to be something really really useful and compelling about a router or access point to justify the labor of attaching a serial console to one to get it flashed - much easier to "vote with your feet" and drop it back into the bin it came from and go on to the next device.

There is little enough information about mtd out there I have no desire to add to the misinformation like hnyman did on the openwrt forum. If the dd-wrt and openwrt versions of mtd are different and trying to use one to write the other's firmware is a hopeless case, then I'll abandon that approach and go with something different.

[kernel-panic69]

Enjoy your wall of text . As already advised, you are going to need serial to figure out what's broken. Only thing I can advise otherwise is trying to flash the buffalo_whr_600d-webflash.bin via LuCI after forensic examination of that file and the sysupgrade.bin file of OpenWRT, with the usual Caveat Emptor disclaimer.