I have exactly the same problem as issue #14 and #13 but unfortunately the fix provided didn't work in my case

[YyYy-YyY]

I was running a version of XWRT on a R7000, and to revert back to original, I used this firmware:
https://mega.nz/#F!ct9zUaCS!lG4g5i5SDhSzG_NH-QSl1g?cpsnBYBQ
Version R7000-V1.0.3.80_1.1.38.zip

The router still works fine, but I can't upload ANY firmware on the web page, tried different browsers etc. I get this error:
"This firmware file is incorrect! Please get the firmware file again and make sure it is the correct firmware for this product. "

Resetting to factory settings both in the GUI and through the reset button made not difference. It's gives the same error even using the GUI native online update feature.

After searching a lot I found this tool, and after a steep learning curve to get it to this point, I have the same problem as the issues mentioned in the title (#13 and #14 ):

"OK
Waiting for remote to respond.
Ignoring extra upload request.
Ignoring extra upload request.
Ignoring extra upload request.
Ignoring extra upload request.
Received configuration request from 68:fd:3a:47:dd:85.
Sending configuration: 10.164.183.252/24.
Timeout while waiting for TFTP_UL_REQ."

I tried using the the firmware you provided , with a modified version number, but in my case, it still doesn't work...
I'm not sure where the problem is, I'm thinking it's not your software, but decided to ask for some help... If there some way to force flash what I want.

Thanks!

[YyYy-YyY]

Update: apparently R7000-V1.0.3.80_1.1.38.zip is the back to stock firmware for legacy build, mine was not, I should have flashed R7000-V1.0.9.26_10.2.31.zip. Still, my router is not bricked and it's running, but I can't flash any firmware into it.

[YyYy-YyY]

Problem solved through different means, using telnet to flash back to XWRT, read here:
https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=323582&postdays=0&postorder=asc&start=0

[jclehner]

Just an FYI, for anyone reading this later: the Ignoring extra upload request. messages are often caused by attempting to flash a bad image file. If you tried to flash the .zip directly, that's probably the cause. You must extract it first, and then use the contained .trx file as an argument to the -f parameter!

[YyYy-YyY]

Not in my case though, I was using the trx from several firmware versions and developers, none worked.

…

On Mon, May 11, 2020, 11:45 Joseph C. Lehner ***@***.***> wrote: Just an FYI, for anyone reading this later: the Ignoring extra upload request. messages are often caused by attempting to flash a bad image file. If you tried to flash the .zip directly, that's probably the cause. You must extract it first, and then use the contained .trx file as an argument to the -f parameter! — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#29 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACRYNCAQAIHLDUDRBLJQTF3RRAFQ7ANCNFSM4LHTWY3A> .

[jclehner]

In that case, you might still have encountered an issue similar to the ones you referenced. While the .trx header doesn't contain image version info, it's still possible that the bootloader performs some kind of version check. Also, it's possible that the bootloader expects a different image format.

What hardware version of the R7000 is this?

[eduncan911]

Came here for #14 and now this #29 issue. Exact same issue.

What hardware version of the R7000 is this?

I don't think there are multiple versions of the hardware. At least, mind does not indicate any such version number - like my old WRT54s, WRT610Ns, E4200s used to.

That "link" to the dd-wrt forums, marking this as Resolved, is a difficult read (and some unfriendly help - kind of reminding me why I left that community 10 years ago).

The resolution you proposed in that thread basically says to use a TTL cable (I'm guessing a serial cable) to flash the device.

@jclehner How did you "modify" the firmware to change the version number? that is all I think we need to resolve this instead of the "buy a cable and Telnet" approach?

And yes, we are looking to use trx extensions from FreshTomato.

---

I see the biggest mistake we are all making is that we are picking the latest Netgear firmware to flash over, say, an old AdvancedTomato, DD-WRT, OpenWRT, previous firmware. DO NOT DO THIS! But if you landed here looking for a resolution then you most likely have and now you're screwed.

The latest Netgear firmware from 2019 onwards basically prevent you from uploading anything through the UX to flash, except their own firmware.

[eduncan911]

THE REAL WORK-AROUND (and maybe a bug in nmrpflash?)

The hint @jclehner gave about trx file doesn't have the headers needed gave me an idea... An old bit of history popped up to remind me of something. AdvancedTomato, which was an awesome version back it was being updated, had a special chk version to upload FIRST, called the Initial Flash, before you upload the trx file.

Sure enough... When I went to the old AdvancedTomato site, pulled down the chk and trx files dated years ago, it let me flash them - directly from the latest Netgear GUI dated July 28th, 2020!

I even got a nice "old version" warning! And, it let me continue regardless!

Warning! The firmware version you are trying to upload is older than the one you had.
Do you still want to continue?
--
Current Firmware Version | V1.0.11.106_10.2.100
Uploaded Version | V1.0.3.24_1.1.20

Slammed the YES button, and success! No TTL cable needed. No modifications of the file. Etc.

I then proceeded to follow the normal trx upload procedure for AdvancedTomato through the GUI, and have me a solid R7000 running Advanced Tomato. I'm assuming from here, I can launch off and load up FreshTomato if I choose.

To me, the real problem is a manifestation of a few issues with multiple components that all combine to make this a difficult problem to solve:

• nmrpflash does not give proper error codes. Leading people down some wrong paths. Like the initial Timeout errors when first trying to talk to the device: using -vvv clearly shows requesting confirguration, and then instantanously you get Sending configuration: 10.164.183.252/24. Timeout while waiting for TFTP_UL_REQ. error being returned instead of any sort of wait period or timeout - it is instant. There's also the very common, Timeout while waiting for TFTP_UL_REQ which according to -vvv and using -T 6000, there is just a few miliseconds until this "Timeout" occurs - when there doesn't seem to be any timeout message, nor the T working to sit and wait - if this truly is a "timeout".
• Netgear's firmware does not allow trx uploads through the GUI! The author of AdvancedTomato from nearly a decade ago knew exactly this. This is why he had a tiny "initial" chk to flash through the GUI first, to get you a minimal AdvancedTomate install. FreshTomato does not offer such a version to flash. So that's a problem over on FreshTomato's side to resolve.
• This nmrpflash tool does not seem to be able to flash any trx file at all to the Netgear R7000. Even after loading up AdvancedTomato, powering off, and starting the flash for either AdvancedTomato's trx or FreshTomato's trx files, gives the exact same result as Unable to flash R7000 #14 and this I have exactly the same problem as issue #14 and #13 but unfortunately the fix provided didn't work in my case  #29 spells out. This is either a header issue that the tool doesn't support, or it's not sending the correct commands to Netgear, or Netgear ignoring the correct commands, etc. The fact is, it does not support trx, even after a valid "aftermarket" firmware is loaded, to flash any `trx.

I did everything through the GUI today, once I was back to OEM.

I will say that nmrpflash did save my ass: originally I could get an IP address, and the "Reset" button didn't seem to work when I broke this R7000 out of the closet today. I was able to flash the stock OEM .bin using nmrpflash with success, to get back to OEM. 👍

Also, nmrpflash does support chk files as well - as I went ahead and tried flashing that via the tool (even though I was already set and running), and it let me continue. I even reverted back to the stock OEM firmware again (using the tool), and flashed the chk file no problem. It's just trx it seems to have issues with, or the Netgear firmware.

Regardless if this tool can do anything about trx or not, maybe at the least have some better error handling/messaging? :)

/TL;DR

So, it's not a "Version Mismatch" issue. It's something to do with trx files that are not supported by the latest Netgear firmware, and this tool has some incorrect messages/timeouts displayed.

The work around is to:

• use this tool to flash the Netgear stock firmware
• pull down a valid chk file from AdvancedTomato, flash it via the OEM stock firmware's GUI like normal. Click "Yes" to downgrade.
• Use AdvancedTomato's installed GUI to launch other TRX/BIN/CHKs to install, not this tool

I guess AdvancedTomate really was way ahead of its time, even by today's latest firmware. LOL

[jclehner]

@jclehner How did you "modify" the firmware to change the version number?

I've used a modified version of OpenWRT's mkchkimg to change the version info in the image header. I've also created a pull request containing this patch that has since been merged into the OpenWRT source tree.

The user who created #29 tried to flash a .trx image, whereas the R7000's bootloader expects a .chk image for NMRP (which is essentially a .trx file wrapped in a .chk header).

This is either a header issue that the tool doesn't support

In fact, nmrpflash doesn't know anything about the image you're trying to flash. It'll accept whatever you feed it. The device then checks the file, but there doesn't appear to be a defined mechanism for reporting errors in the NMRP protocol. Some devices send a raw UDP packet containing an error message, while other's will simply send another upload request.

nmrpflash does not give proper error codes [...]

I agree that the error messages are rather technical, and not exactly user-friendly, especially for the more inexperienced users.

[...] error being returned instead of any sort of wait period or timeout - it is instant [...]

The timeout was 200 milliseconds, and has been increased to 1 second for the next release.

[kernel-panic69]

In regards to this issue, I personally suggested flashing FreshTomato (implied that it be done via the mini CFE webserver in the modified Asus CFE) to revert the CFE. There was even an indirect pointer to a viable solution by egc (that would've required serial console). Furthermore, I would like to add a suggestion that folks who are too timid to interject and offer up help because of folks who are abrasive need to pull up the bootstraps and push up their sleeves and dive in and relieve us abrasive folks of the burden. That's about as nice as I can put it. Feel free to remove this comment if you wish.

[FrostKnight]

@kernel-panic69

Quick note, I don't think that helps whatever your case is...

I don't think you can pull yourself up by your bootstrap without falling...

:/

Kind of odd that you use that as an arugment

https://uselessetymology.com/2019/11/07/the-origins-of-the-phrase-pull-yourself-up-by-your-bootstraps/

That being said, I agree with the point about ssh/telnet, especially if @YyYy-YyY has access to the admin controls via ssh/telnet, but unless the person knows what is needed to do serial cable flashing, which is dangerous even if you do know how to then the below applies:

Then it is really a bad idea...

as A K.I.S.S operating system user, I did assist in debricking a libreboot comp via raspberry pi b, but if I hadn't had an engineer with me then even know how to install FDE + /Boot Successfully:

WOULD have been a NIGHTMARE. Or possibly worse depending on the level of failure.

So you are half right, AFAIK.

;)

[kernel-panic69]

@FrostKnight I never said to pull oneself up by their bootstraps. I guess I should've said something a little less "cliché-esque" and typed out "put on your big boy boots, push up your sleeves, and go to work". Anyhow, all water under the bridge and ancient history. The only direction to move is forward; no need to move backwards.