WNDR3700v3 - rescued from dumpster

All -

I'm going to just post this here as a lessons learned / useful information/tidbits of goodies.

This was specifically on a WNDR3700v3 Broadcom BCM4718A processor, not sure of specific board revision (I know there are a few different ones). This may apply to other WN* series routers, this may apply to other BCM47* series routers - I have no way of testing (and I've not had the same issues on my WNDR3700v1 and I don't feel like trying). 

Important keywords for future searches: bricked, tftp, board_data, dd_wrt, boardid, recovery, telnet, telnetenable, burnethermac

Quick story: I was given a WNDR3700v3 that had been in use at a small home office for years. The semi-techie-literate owner had decided to "upgrade" to dd-wrt for the ability to put each of the different WiFi networks onto VLANS and have family not connected to his work stuff etc... it had worked for a while but he then tried to go back to Netgear FW when a newer release came out and somehow in the process "bricked" the router. It would power on to a steady orange light and green LAN lights wherever cables were plugged in, but no router functionality, etc. He claimed he had tried several 30/30/30 resets with no luck and was ready to toss it in the dumpster, he bought a lightly user R6400 and soldiered on.

Here's the 3-day-weekend procedure I did to recover the router (including the issues I found) without needing to open the case and attach a serial or JTAG cable to the board. This may be handy to someone with similar hardware dinking around trying to make it work someday. It may not. No guarantees, no warranty, you may break things more than they were already broken if you do any of this, but if you're 3 seconds from heaving it in the e-cycling dumpster you may want to give it a shot.

So - first up - I tried getting into TFTP recovery -- pressed and held reset for 30,60, 90, 120 seconds after power on and light stayed orange..... But then after that tried another hard 30/30/30 reset (never trust the "other"). Something was different on reboot but something was still odd. The router appeared to power on properly, but an ethernet cable plugged into my PC and the router (PC hard IP'd at 192.168.1.2) couldn't ping 192.168.1.1. LAN LED's were on as were WiFi LED's.

Tried access by WiFi and I could see a "NETGEAR" access point (note "NETGEAR", not "NETGEAR12" or "NETGEAR12-5G") - with WiFi interface on PC hard-coded to 192.168.1.3 I was able to ping the router (over wifi.. but not LAN.. interesting). I connected to the web interface and logged in. It had the original 1.0.0.18 FW on it, and all the MAC addresses were reporting 00:FF:FF:FF:FF:FF - a little searching says this meand the "board_data" partition on the router is likely corrupted, and this often prevents you from going into TFTP recovery mode, and also prevents you from loading or upgrading firmware, and apparently also makes PC's very reticent to talk on the LAN interface. It also prevents you from updating the firmware or loading new firmware from the OS.

I used the "telnetenable" software (I'm not linking here, as locations change all the time, google for it and find the latest location of "netgear telnetenable".) - I used the oldschool Gearguy username/password (as this was at an old FW version) - from windows:

.\telnetenable 192.168.1.1 00FFFFFFFFFF Gearguy Geardog 

Using a telnet client I was able to log into the busybox terminal of the router. Some searching online said if you delete the OS partition from in busybox it will hard-force the router into tftp recovery mode on power cycle. They were right. You probably shouldn't do this. See tl; dr; below.

cat /proc/mtd    -- find the one named "linux"

erase mtdX  (replace X with the value in your list - it should be mtd1 for most units)

reboot

The router rebooted and sure enough was in tftp recovery mode even though board_data was corrupt - I wanted to get back into dd_wrt firmware so I could look at all of the memory and stuff in the system from a fully-featured linux OS. I set up tftp on my PC but again, couldn't ping or connect to the router, and now there was no wifi obviously either. Interestingly, I happen to have a raspberry pi board sitting on my desk running raspbian/PIXEL - i plugged it into the router and i could ping and tftp to it (apparently RPi/PIXEL doesn't care about an "All F's mac address" like windows 10). I tried to load dd_wrt 37305 but no luck - it rebooted into tftp recovery mode again. I installed dd_wrt 20453 and I was in. I was able to confirm all of the board_data was toast - it didn't know anything about the router - I found some threads about what should be in the board_data file and what a dump of it should look like - mostly from the OpenWRT forums - I verified a dump of mine was all "ff" (binary 1's) with no valid data.  Every time I tried changing MAC addresses in dd_wrt I would lose connection and the router would stop responding. I'd have to do a hard 30/30/30 reset and then it would be back into dd_wrt.

I decided I'd try to go back to Netgear F/W again after some research said the busybox on the NG FW contained some "burn" commands that might solve by problem.

Again deleted the linux partition, rebooted, and used tftp to "re-up" the firmware from the RPi computer (this time back to netgear 1.0.0.18 that I knew should run).

Re-enabled the telnetenable (as above) and telnet into the router. Using the data on the botom of the router I used:

/sbin/burnboardid U12H194T00_NETGEAR   (this is the specific boardid for a WNDR3700V3 - every router version has its own - google searches should uncover)

/sbin/burnethermac 204E7FC5xxxx    (Fill in the proper MAC addy with your MAC from the bottom of the router) - interestingly the router will auto-calculate the proper MAC's for the other devices (WAN and WLAN_N) and store those as well

/sbin/burnsn 2SP1187700xxx (again fill in your proper Serial Number's from bottom of router) - this records the router serial # in the board_data partition

/sbin/burnpin 140033xx  (use the PIN on the bottom of your router)

/sbin/burnssid NETGEAR12  (this is the standard SSID for the 2.4ghz radio from the factory - note above I saw "NETGEAR" - this indicated the SSID wasn't the normal)

/sbin/burn5gssid NETGEAR12-5G (again standard for the 5G radio on the WNDR3700V3)

/sbin/burnpass basicmoon295  (I found this in a thread on OpenWRT with a copy of the hex dump of the WNDR3700v3 board_data file)

/sbin/burn5gpass basicmoon295 (same) -- I guess these set default passwords for the WLAN radio on a hard 30/30/30 reset

I did not have and could not find details for the few remaining "burn" settings - burnsku contains a region number, language, and wl_region - mine are 0xFFFF, English, and 5 respectively - I don't know if these are right/wrong (well English is fine!). Also have no data on burn_hw_rev values.

I then did a 30/30/30 hard reset on the router, and to my delight (as this was the middle of day 3 dinking with the router) it came up with all the lights looking good, and I could use my PC to reach it at 192.168.1.1 like expected. I logged in (standard default  "admin/password") and router status showed MAC addresses and proper hardware info, etc.

I tried a firmware update to 1.0.0.42 and it went successfully! Everything in the router now appears to be working. I did one more 30/30/30 hard reset after that firmware update and all looks good.

I plugged the WAN side of the router into one of the spare ports on my fiber switch, plugged in my appropriate PPPoE user/pass, it obtained an IP and went online immediately, I ran a speed test through it, and it seemed to be able to pull in a "semi-respectable" download speed of about 275 mbps over PPPoE.  (I have 1.5gbps service into the GBIC on my fiber switch, I have 8 gigabit ports on the switch, I can plug in and log in up to 8 simultaneous routers on my PPPoE ID - each getting its own public IP/etc - short of plugging a high end corei7 computer right into the switch and configuring a PPPoE connection directly through the LAN interface I can rarely get over 900mbps - my relatively new R7800 router can manage about 817 Mbps over PPPoE)

For anyone who thinks the following they are correct - but it was a learning experience:

tl; dr; If you can get a netgear router with bad board_data partition to boot into any netgear firmware, no matter how corrupted things look, you can use telnetenable to get into the busybox and use the "burn" set of commands to re-program the bad board_data partition, then reset the router, upgrade firmware, change to dd_wrt or openWRT and continue using it.  You don't need to do everything I did *if* you can manage a telnet prompt into busybox that's enough to recover the board_data. I made a mistake by deleting "linux" as early as I did before discovering the "burn" commands.