Recover Your Bricked NETGEAR WGR614L/v8/v9 Using TFTP

It's happened to all of us at some point - you flash your router with experimental or new firmware and find that something gets corrupted or you have a bad firmware build.  You may already know that you can recover your WGR614L with a USB-TTL cable (serial console.)

Before you try to recover your router with TTL cable, however, you can try this (I've found it on the NETGEAR forums and tried by myself). It works with v8 and v9 - don't know what about previous versions. I've made some changes to the original post as you can see below.

Note: Read these directions carefully from beginning to end, twice, then execute very carefully.  If these directions are not followed exactly, you might be forced to use the serial console to recover your router.  You follow these instructions at your own risk!

Try a Hard Reset First

  1. Disconnect the router from all cables except the power cable.
  2. Push reset button for 30 secs.
  3. Without releasing reset button, disconnect power cord.
  4. Hold the reset button for another 30 secs.
  5. Re-plug the power cord.
  6. Still hold the reset button for another 30 secs.
  7. Release the reset button and give the router about 10 secs to resettle.
  8. Disconnect power cord for another 10 secs and then reconnect.
  9. All should be in default settings now.

Step 1: Finding IP Address and Pinging the Router

In the event that the hard reset did not work, there is a way to re-flash the router.  During start-up, the router will pause to accept a temporary firmware upload via TFTP.  To see if this is possible in your situation, connect your computer with the router using a wired connection and try pinging it.

If pinging 192.168.1.1 does not work, check the IP Address of your computer and make sure it is assigned an IP address in the subnet of the router IP.  For simplicity's sake, you can assume "192.168.1.x" will function. If you do not have a good IP, the DHCP Server might not be working.  In that case, set your IP manually to something like 192.168.1.77 with 192.168.1.1 as your gateway and then try pinging the router again.

Power the router on with a continuous ping running in a command window:

>ping -t -w 2 192.168.1.1 in Windows
#ping 192.168.1.1 in Linux

(The -w 2 parameter forces a lower timeout for the ping answer, this makes it easier to get an answer from the bricked router.) You should see at least a few replies from 192.168.1.1 (or whatever IP you needed to use.)  Do this several times to be sure. If it works, you have a good chance of simple recovery. If you still receive no response, the IP address may be something other than 192.168.1.1.  You should attempt to obtain the IP address of the router.  Especially if previous firmware set the boot_wait variable to on, the router pauses even longer than normal during boot-up to accept a recovery flash.  All you need to do is provide a firmware to it via TFTP during this window of time.

Step 2: Upload Original Firmware with TFTP

Prepare your PC, firmware file and TFTP software and play with the timing of powering it on and starting the TFTP session just after applying power (or as soon as you start to see ping replies.) If you try it a number of times (at least 10) you will probably rescue the router with no fuss at all.

Microsoft Windows contains a TFTP client.  Windows Vista will require that you enable it in Programs and Features.  With TFTP, all of the information about the transfer is specified during the initial setup; there is very little client/server interaction as compared with standard FTP. 

To flash a router using Microsoft Windows, open a command prompt, change to the directory containing the original firmware (from Netgear site - and no other) to use for this boot (this example assumes the firmware file name is firmware.chk), and then enter the following command (assuming your router IP-address is 192.168.1.1):

>tftp -i 192.168.1.1 PUT firmware.chk in Windows
#tftp -m binary 192.168.1.1 -c put firmware.chk in Linux

If you don't have a TFTP client installed, it doesn't work or something else, then try using this TFTP program called tftp2 available here (this will start the download): tftp2.exe in Windows. In Linux, try to search your repository.

Step 3: Finish Reflash & Verify

After the successful upload, the Power LED should blink a little faster than when router was bricked for a couple of minutes.

DURING THIS TIME, DO NOT RESET or DISCONNECT THE POWER.  Wait until the LED stops flashing and the lights turn to a steady green.

Now, your NETGEAR WGR614L should be running the default firmware, and all that is left is to set it up!

Originally by Daniel. Improved and uploaded by Otmar C. Edited by site editor :)

Tags: 

Brandon C
Brandon C's picture
Humm, not sure about the

Humm, not sure about the wireless deal under Windows. But if you are trying to do it wired I recommend you use a hub as shown here. http://www.myopenrouter.com/article/10276/WGR614L-and-TFTP-on-Windows/ It removes the wait time for the adapter to become active.

otmar
otmar's picture
Editor made a mistake - the

Editor made a mistake - the article wasn't about wireless re-flash. This is obviously impossible :) I've already corrected the mistake.

nEpunk
nEpunk's picture
Thanks a lot for your tutor!

Thanks a lot for your tutor!
Your way of hard reset looks like the Black Mass, but still didn't work, as like the manufacturer's way. :D
But I didn't get by myself that router is accessible for tftp only a few seconds after the power is on, so I did the right things at the wrong time :)
P.S.: Sorry for my English - I'm Russian & have no practice for a long time

otmar
otmar's picture
HollowMac said:

HollowMac said:
Hello and thank you for your tutorial. Excuse me if my english is bad, but i am french.
Your tutorial work fine :) After a lot of tentatives, i have arrived to re-initialised my Netgear WGR614l :) :) :)
But one thing doesn't work in your tuto : tftp 192.168.1.1 -m binary -c PUT firmware.chk
It have to enter tftp 192.168.1.1, then binary, then put firmware.chk
In my case, after it has worked, i have to put on reset button while 10 seconds, to can access at the web interface !
Thanks a lot my friend ! Vive Linux !!!!!!! Et vive Internet !!! Je vous aime !!!

Another mistake, I believe by portal editor. Corrected! :)

Eneen
Eneen's picture
I can't upload firmware,

I can't upload firmware, always get timeout. There is response to ping (not so few, 30 pings or more). Should I go for serial recover?

Varuna
Varuna's picture
Hello Folks,

Hello Folks,

Thought of sharing my experience on recovering the router that had httpd in a non-working state.

Setup:
Netgear WGR614v9 router
Source code: Netgear WGR614v9-V1.2.6_18.0.17WW
Tool chain: hnd-tools-3.2.3
Tools: Telnetenable-0.3
Development system: Fedora 8 kernel 2.6.26

Prime focus was to reduce the foot print of the image on the router; hence, decided to remove the support for NAT. Ensured that the ../src/linux/linux/.config did not have the ACOS NAT and ACOS NAT FireWall support enabled. The kernel that resulted was less in size by about 500k. Things went fine while flashing the router, post reboot, was not able to access the web GUI at all.

Using telnetenable, was able to get into the router and tried to restart /usr/sbin/httpd. The message given out was that the /dev/acos_nat_cli was not available. Created the dev file with major 204 and minor 0, and tried to restart httpd. This did not take me any were as the message still given was that the device file was not accessible. Tried to restart the /sbin/acos_services, and also tried using /sbin/acos_init. The message on the console was still the non-availability of the required device files for the NAT. This put me into a situation where I could not recover the httpd, without which I could not reflash the router.

I then tried to use the Netgear provided router recovery tool a good number of time, and only to receive the message that the router does not have any issue that requires a recovery. Searching this website, found a couple to pointers such as to use either tftp or tftp2 to get the image onto the router. Well I was not able to get the router into the flash mode as it was quickly getting into the booting sequence. There has not been any information about what password to provide in the tftp2 tool as Geardog and the configured password for the router did not work.

I tried to use the erase_mtd_block bundle, then again the question was how to get the binary onto the router? Found /usr/bin/tftp on the router. Figured out that I need to tftp onto my development system and get the binary into the router. The installation on my development did not have xinetd and tftpd, and these packages were not available on the install media.

The question that still remained was how to flash the router.

This was when I noticed /sbin/erase available while exploring the router through telnet. Executing /sbin/erase I realised that I need to provide the device name as a parameter. The question was: what should be the device name? Should it be rootfs or ramfs? Well I do know for sure that embedded systems generally mount the rootfs in the RO mode, was still not sure if the functioning of the erase.

Looking into the source .../src/rc/rc.c, the erase functionality was: mtd_erase(argv[1]). Neither .../src/rc/mtd.c was of any help as there was no mention of the device name. This is where the contents of /proc/devices came in handy, now should the device be mem or acos_nat_cli or raw or nvram? Finally nvram did work which erased the Linux partition and got the router into a state where the Netgear router recovery tool worked.

The learning out of this experience has been:
- Brought to fore the amount dependence on the --help option. (Well disk/flash space is a premium on an embedded system.)

- Need to read the source code often.

- Better documentation will help.

- Intelligence is not built into the .../src/router and .../project code section to pick up the configuration details of the kernel.

- OpenSource will always help to progress.

I explored further on the 4th learning and found that the .../project/acos/httpd/httpd and the .../src/router/mipsel-uclibc/install/httpd/usr/sbin/httpd differ. Still yet to explore why is there a difference between the two httpd? May be .../src/linux/linux/net/khttpd has the intelligence to pick up from the kernel configuration, which Netgear is not using.

With regards,
Varuna

Rolipoli
Rolipoli's picture
You just saved me over 100$ .

You just saved me over 100$ . Thank you this worked like a charm. It seems the bad firmware update stops DHCP from working. We get used to DHCP being on LOL. Was able to see router (only ip -ping-, not web sign in) after manually assigning my PC an IP address and gateway. and the tftp transfer you stated worked like a charm thereafter. WOW!!!! Now i have back fulll accesss again as before the bad update. Thanks a million again.

Oz Dogan
Oz Dogan's picture
Dear Otmar (Author),

Dear Otmar (Author),

Thank you!

Finally a page from Google that was worth the visit and it really helped me to salvage my Netgear DG834Gv5 after crashing halfway during a firmware update I did earlier on today.

The firstt 2 points on the post did not work for me however, after completing the first 2 points above I decided to TFTP it. I had to execute is from the command line once the router was visible using ping.exe under windows.

Congratulate yourself Otmar, you have saved my modem which I would have trashed it if I hadn't landed here on this page.

Many thanks!

Kind regards,
Oz Dogan

otmar
otmar's picture
Oz Dogan said: Dear Otmar

Oz Dogan said: Dear Otmar (Author), Thank you! Finally a page from Google that was worth the visit and it really helped me to salvage my Netgear DG834Gv5 after crashing halfway during a firmware update I did earlier on today. The firstt 2 points on the post did not work for me however, after completing the first 2 points above I decided to TFTP it. I had to execute is from the command line once the router was visible using ping.exe under windows. Congratulate yourself Otmar, you have saved my modem which I would have trashed it if I hadn't landed here on this page. Many thanks! Kind regards, Oz Dogan

I'm glad I could help :)

Best regards!

otmar
otmar's picture
Rolipoli said: You just saved

Rolipoli said: You just saved me over 100$ . Thank you this worked like a charm. It seems the bad firmware update stops DHCP from working. We get used to DHCP being on LOL. Was able to see router (only ip -ping-, not web sign in) after manually assigning my PC an IP address and gateway. and the tftp transfer you stated worked like a charm thereafter. WOW!!!! Now i have back fulll accesss again as before the bad update. Thanks a million again.

My pleasure :)

 

Best regards!

Empty
Empty's picture
The hard reset did not work

The hard reset did not work for my 'NETGEAR RangeMax Wireless Router WPN824 v2' so I did 'step 1 through 3' and now it works, Thank You.

srinivas
srinivas's picture
thanks a lot

thanks a lot

where tftp.exe to download for windows

please update

i think it works good

machine5
machine5's picture
Thanks!

Thanks!

At first I tried tftp2.exe pointed out in Netgear support article, it didn't work out.

Then I tried tftp command-line here in this article. It finally debricked my R7800.

R9000X10
R9000X10's picture
Thank you

Thank you soooooooooooooooooooooooooooooooooo much.

My Netgear R9000 X10 was sitting in the closet for about a month.  I tried everything but no luck, till I found this solution.  30-30-30 did not work but I follow step 1, 2 and 3 after 10 sec reset switch hold and I was back in business.  Thank you once again.