Wndr3800 bricked by latest trunk openwrt-ath79-generic-netgear_wndr3800-squashfs-sysupgrade.bin

I hadn't updated my wndr3800 running the latest nightly trunk since Jan. or Feb. 2021.

Today, I did my tried-and-true routine of downloading the latest
https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-netgear_wndr3800-squashfs-sysupgrade.bin and then doing "sysupgrade" on CLI. However, the wndr3800 seems to be stuck in a boot loop after this.

Pressing the bottom reset button after it powers on:

  1. It becomes pingable at for 6-7 pings (Power LED blink only)
  2. It returns "no route to host" for 10-15 rounds (Power LED still blinking, all LAN LEDs on and blinking, then off)
  3. It then keeps a steady slow (one per second) blinking green at the Power LED, and connected wired LAN port LED also on. The ping to returns:
    40 bytes from icmp_seq=2849 ttl=64 time=-6114939688.242 ms
    wrong total length 60 instead of 84
    wrong data byte #8 should be 0x8 but was 0x69
  4. Rinse and repeat.

If I try to upload a factory image (Netgear or Openwrt) during Stage 3), the tftp transfer mostly times out at some point (both tftp times out AND ping stops responding), and at other times seems to finish. If the tftpboot times out, the Power LED goes off and stays off until then. Regardless, the router never recovers to a bootable state.

If I power it off, power it back on, and then press the WPS button (or any front button) early during power on, the Power LED then soon blinks fast, and the ping to returns normal response. If I try a factory image (Netgear or Openwrt), it always times out eventually. However, the router remains responsive to ping on normally (in contrast to the above, slow steady Power LED blink and "wrong total length 60 instead of 84" response to ping).

Looking at https://downloads.openwrt.org/releases/, I see 21.02.0-rc3, while I was probably on some nightly trunk of 19.07.6 or 19.07.7. Is the change that dramatic to have caused the "upgrade" to fail?

What else can I try to recover from this?

Try a TFTP with the master or 21.02 RC3 factory image. Putting a switch in between might help, TFTP can be a bit iffy.

If you wanna find out what's wrong, you'll need serial.

1 Like

Have you tried nmrpflash ?

1 Like

I thought there was something like that, but can't remember the name. I will give nmrpflash a try. Thanks.

Ahh, apparently the problem is, I have the wndr3800ch (for Charter Cable), while the readily available Netgear firmwares are for the standard wndr3800. I'm pretty sure Netgear's own WebUI refused to flash the firmware for the latter onto the wndr3800ch variant, when I accidentally tried. Is there a way to modify the standard wndr3800 firmware for the 3800ch? Or, can nmrpflash flash Openwrt?

It seems it's possible to patch wndr3800 firmware's header to make it usable on wndr3800ch, per (https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=984299). Is there a tutorial for a lay person who's savvy on the CLI? I have binwalk installed which seems useful for firmware patching.

I stumbled upon https://github.com/insanid/NetgearTelnetEnable, but after compiling it on macos, it's to no avail, as telnet is still not enabled.

nmrpflash is a user-friendly alternative to tftp. It can be used to flash any firmware image you like (see the -f <firmware file> option).

Have you tried the 21.02-rc3 wndr3800ch factory firmware? It might be more stable than the daily snapshot.

1 Like

I will definitely give those a try. My big concern is the tftpboot repeatedly timing out, which had never happened to this wndr3800ch before. This makes me suspect something has gone awry with the bootloader or boot partition. Hopefully nmrpflash could do the trick, or else I'm SOL, as serial access is not an option for me.

Holy ****! I finally got around to trying nmrpflash, and it worked in reviving my wndr3800ch. I used a 19.07 factory image. To my amazement, it came back alive complete with the stock luci interface, even though I did not get positive response during the attempt such as " Received keep-alive request (11)." as the github example showed.

Thank you so much!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.