Accidentally flashed RT-AX86U firmware on RT-AC86U and now unable to flash back the correct firmware

[UzEE]

Hi,

I made the mistake flashing the firmware first thing after waking up and accidentally downloaded the AX86U release (RT-AX86U_386.2_4_cferom_pureubi.w) and flashed it via the ASUS Firmware Restoration tool by putting the router into recovery mode.

Since then, I'm unable to put the router back into recovery / rescue mode again. The usual Hold Reset while plugging in power cable doesn't work anymore, and neither does the hold WPS while turning on to reset NVRAM.

The router always boots up into an odd state where it is always in it's initial setup wizard (running on 192.168.50.1), and the firmware seems to show some features from AX86U but obviously doesn't work correctly. It does show it's running 386.2_4 however. Trying to flash any firmware (tried a few Merlin versions, stock FW versions and even the original version the router shipped with) via the Merlin Web UI doesn't work. It just completes the flash process and returns to the exact same initial setup wizard state.

The LED lights never change their state with always the first one being lit no matter what.

I reenabled SSH and tried to reset NVRAM from there by running "nvram erase" but it just errors out saying it's unable to open the nvram file.

Is there anything I can still do via the CLI to recover the router or is it essentially beyond any recovery now? I'm comfortable trying out things since it's probably a brick (well mostly, since WAN and LAN still works) anyways.

Thanks!

 

[NotA+]

Try this:

[Wireless Router] How to use Rescue Mode (Firmware Restoration)? | Official Support | ASUS Global

 

[UzEE]

Try this:

[Wireless Router] How to use Rescue Mode (Firmware Restoration)? | Official Support | ASUS Global

This doesn't work anymore. The router just boots into the Initial setup wizard despite pressing and holding the Reset button and inserting the DC In cable. The power light never even turns on, only the LAN4 light is always on as in the above picture, and that's it.

 

[Tech9]

I'm not prepared to answer your question, but I believe this router has 2 firmware images. If one fails to boot, the other will be attempted, in theory. I started playing with those routers just recently, but I have some experience with other models. I see 3 possibilities to recover it - 1. Trick the router to boot from the second partition by interrupting the boot process 3-5 times consecutively; 2. Serial recovery attempt, but I don't have what is needed at the moment; 3. Direct ROM chip swap. This is what I would do because I have dead AC86U units around with bad power and radios. @RMerlin may know more details about how this thing works.

 

[Lord Lovaduck]

If you can SSH can't you just reflash the CFE from it? Search for flashing CFE. May find a valid CFE for your router, and from there get the rest done since the recovery firmware process is coded in the CFE.
Please look this up carefully. You definitely can use CLI to reflash, at least I can with my AC68U.

 

[UzEE]

If you can SSH can't you just reflash the CFE from it? Search for flashing CFE. May find a valid CFE for your router, and from there get the rest done since the recovery firmware process is coded in the CFE.

Thanks. I tried tftp to the CFE but failed, but didn't try this. I'll look around and see if there is a way to do this.

 

[Lord Lovaduck]

Thanks. I tried tftp to the CFE but failed, but didn't try this. I'll look around and see if there is a way to do this.

No, that is NOT what I mean. Nothing involving TFTP. There are commands that access the CFE partition directly from the CLI using SSH.

 

[UzEE]

No, that is NOT what I mean. Nothing involving TFTP. There are commands that access the CFE partition directly from the CLI using SSH.

Yes, I understood that. I'm just trying to lookup how to do that since I haven't touched this stuff before. I assume I also need to find the CFE that is an exact match for my hardware revision as well or I'll end up with a perma-brick.

 

[Lord Lovaduck]

Thanks. I tried tftp to the CFE but failed, but didn't try this. I'll look around and see if there is a way to do this.

No, that is NOT what I mean. Nothing involving TFTP. There are commands that access the CFE partition directly from SSH.
The command name is mtd-write and there's another, mtd-write2 they are for different versions of firmware.

 

[Tech9]

Wait, SSH is working? Then definitely try what @Lord Lovaduck is suggesting. This router has one single hardware revision V1.5.

 

[Lord Lovaduck]

No, that is NOT what I mean. Nothing involving TFTP. There are commands that access the CFE partition directly from SSH.
The command name is mtd-write and there's another, mtd-write2 they are for different versions of firmware.

Here's an example. From the CLI you would be executing something like this. You need the exact incantation for your router but this is the idea.

set -x
wget -nH 192.168.29.5/newfw.zip
unzip -o newfw.zip
mtd-write2 yourvalidfirmware.trx linux

 

[Lord Lovaduck]

Yes, I understood that. I'm just trying to lookup how to do that since I haven't touched this stuff before. I assume I also need to find the CFE that is an exact match for my hardware revision as well or I'll end up with a perma-brick.

Yes, but there's a repository of CFE's somewhere, and some kind soul here can probably download one for you. Or maybe the whole thing can be done with a valid firmware which rewrites the CFE, some of them do bring updates to the CFE, repartition etc and may do the trick, I believe. Sorry I am just a junior, have done this to my router out of need and learned on the fly I guess it's the same for you now....

 

[UzEE]

Yes, but there's a repository of CFE's somewhere, and some kind soul here can probably download one for you. Or maybe the whole thing can be done with a valid firmware which rewrites the CFE, some of them do bring updates to the CFE, repartition etc and may do the trick, I believe. Sorry I am just a junior, have done this to my router out of need and learned on the fly I guess it's the same for you now....

This is already a big help since I now at least have a lead that I can follow up on. Most repository links I'm finding so far now are dead links but I'll eventually find one. I also know someone who used to have the same model so I'll check with them as well if they can dump their CFE and share with me. Thanks!

 

[john9527]

- I don't think mtd-write or mtd-write2 exist anymore on the HND routers. Try running via ssh cli and see if it finds it.
- The cfe's for the HND routers are encrypted. Not sure what problems this is going to cause.

There looks like there may be a closed source 'hnd-write' executable. Might try running that with -h or --help to see if there are any clues.

 

[Tech9]

I don't know why you guys use firmware restoration tool for updating the firmware:

Release - Asuswrt-Merlin 386.2 is now available

Soooo turns out if you flash the ax86 firmware rather then the ac86 firmware onto a ac86 things get quite weird. You can get into the router but you can no longer upgrade the firmware be it through the ui or recovery firmware. Think it may be checking for ax firmware rather then ac firmware...

www.snbforums.com

Asus plan to confuse the customers is working perfectly - RT-AC68U, RT-AC86U, RT-AX68U, RT-AX86U.

 

[UzEE]

I don't know why you guys use firmware restoration tool for updating the firmware:

Release - Asuswrt-Merlin 386.2 is now available

Soooo turns out if you flash the ax86 firmware rather then the ac86 firmware onto a ac86 things get quite weird. You can get into the router but you can no longer upgrade the firmware be it through the ui or recovery firmware. Think it may be checking for ax firmware rather then ac firmware...

www.snbforums.com

Asus plan to confuse the customers is working perfectly - RT-AC68U, RT-AC86U, RT-AX68U, RT-AX86U.

For the past few releases, my router wouldn't take the update with the normal method so I had to resort to the restoration utility each time and it worked fine. I know I was playing with fire and seems like this time I finally got burned.

- I don't think mtd-write or mtd-write2 exist anymore on the HND routers. Try running via ssh cli and see if it finds it.
- The cfe's for the HND routers are encrypted. Not sure what problems this is going to cause.

There looks like there may be a closed source 'hnd-write' executable. Might try running that with -h or --help to see if there are any clues.

Yes, I mtd-write and write2 don't exist anymore from what I can tell.

I tried hnd-write with various common params including -h and --help but nothing turned up so that command is still a mystery. I wonder if @RMerlin may know what it does, or if there is another way to completely flash the firmware via CLI.

 

[RMerlin]

hnd-write allows to write a firmware image, however the same validation process as the webui is applied, so it won't let you cross flash. Which makes me wonder how you managed to flash the wrong model, since the model is validated at flash time when you do so through the webui.

 

[UzEE]

hnd-write allows to write a firmware image, however the same validation process as the webui is applied, so it won't let you cross flash. Which makes me wonder how you managed to flash the wrong model, since the model is validated at flash time when you do so through the webui.

Web UI was not applying the update. It would go to 100%, and then reload to the same Firmware Update page without showing any error messages or warnings. I thought this is just some issue with the Web UI itself since it has happened to me in the past, so I did an NVRAM reset via the holding the WPS button and try again. Still the same result.

That's why I decided to use Rescue Mode instead using the ASUS's Recovery Utility, since it had worked in the past. Apparently, it did not do any validation and just flashed the wrong firmware.

I'll try to flash the correct firmware via hnd-write once I get a backup router, as I'm still using this one for WAN / LAN connections and don't want to completely brick it until I have something else to fall back on.

 

[Tech9]

Did you try interrupting the boot process few times? Turn the router on, wait 15-20 sec., turn it off, repeat. Do it 5 times in a row and then let it boot. See what firmware it boots with. Yours is booting somehow and doesn't trigger the image switch. I don't know if it works on this router, but used to work on Linksys routers with dual boot partitions.

 

[RMerlin]

That's why I decided to use Rescue Mode instead using the ASUS's Recovery Utility, since it had worked in the past. Apparently, it did not do any validation and just flashed the wrong firmware.

There's your problem then...

Rescue mode does not do any validation because it's intended for all sort of cases where flashing may otherwise fail (for instance, due to invalid nvram values that would cause any validation process to flash).

If the regular webui fails, then hnd-write will also fail. It does the same model + CRC validation checks as the webui.

The only way to recover is either by reflashing in Rescue Mode, either using Asus' tool, the recovery webui, or a TFTP client. Personally, the only way I always had 100% success recovering from a bad firmware was using a TFTP client. Asus's recovery tool often fails mid-upload for some reason, and the webui does not seem to be present on all models.