Opened 3 years ago

Closed 3 years ago

Last modified 22 months ago

#3894 closed (provide more info and reopen)

WZR-HP-G300NH update bricked again

Reported by: Ric03 Owned by:
Keywords: Cc:


The issue with bricking the router on Web upgrade is still present on build 25760, upgrading from 25697. I had to tftp recover the firmware. Basically with current firmwares a web upgrade bricks 100% the router: not a big deal to tftp recover, but it's a bug that needs a fix. I know this is toovague, but instead of closing please let me know what can I do to help track down and fix the issue.

Change History (10)

comment:1 Changed 3 years ago by KrypteX

More info please. First of all, I see it is Atheros-based, so it's not the bricking that was observed for a long time before 25737 on Ralink-based.

What was the last working firmware? How exactly does it brick ?

comment:2 Changed 3 years ago by Ric03

Yes it is an Atheros:

system type : Atheros AR9132 rev 2 (0xb9)

First soft brick observed was upgrading to 23720. After that, no more clean web upgrades on my router. Modes of brick:

  1. From 25697 to 25760 via web upgrade (no reset, over wireless, used to work in past): the router says "upgrading" but in the end enters a boot loop.
  2. Recovered 25697 with tftp.
  3. Again from 25697 to 25760 via web upgrade (but this time using ethernet cable), no special config, no reset, right after step 2., the router says "upgrading" but in the end is bricked double flashing the red light.
  4. Recovered 25760 with tftp.
  5. Now I have reconfigured the router step by step by hand without restoring the previously saved config in order to avoid possible bad NVRAM parameters dangling from previous builds.

Looks like the only way I can upgrade this beast now is by tftp.

Hypothesis: can it be that the only good firmwares able to properly run today are the buffalo_to_dd-wrt binaries while web upgrade binaries are corrupted or malformed?

Another hypothesis: the recovery tftpd is Buffalo's while Web upgrade is dd-wrt's ... Buffalo recovery works 100% of the times while dd-wrt web upgrade doesn't work 100% of the time. Can it be that the dd-wrt web upgrade binary is ok but the dd-wrt web upgrade write firmware procedure is bogus?

comment:3 Changed 3 years ago by ksenchy

I am also experiencing this issue for quite a while now on WZR-HP-G300NH. Last working firmware: I am not sure if it ever did except on stock Buffalo dd-wrt as I am experiencing this for about a year. It's hard to tell how it bricks since it cannot boot up properly to see. (No GUI, no ethernet, no wifi,.. ). All you see is the diag LED that symbolizes boot up for about 20s and then a few other's light up for a brief moment and then boom... repeat. How can I check, I am willing to brick it once more?

comment:4 Changed 3 years ago by BrainSlayer

not sure for the reason yet. need to check it. the only thing i know is that the flash chip on this router has some very strange behaviours sometimes.

comment:5 Changed 3 years ago by Ric03

Build 25948 web upgrade bricked again. I tried to collect some more info and I've found this old post from dd-wrt forums about the same router:

The post reports a double red led flash error and the console log (not mine ... the one from that post) shows a bad CRC (and double flash error from the manual is "Flash ROM error"). Partial log console (from right after tftp transfer completed):

tftp server done
Bytes transferred = 20685004 (13ba0cc hex)
## Booting image at be060000 ...
   Image Name:   Linux Kernel Image
   Created:      2009-09-25  12:49:22 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:    21168064 Bytes = 20.2 MB
   Load Address: 80002000
   Entry Point:  80200000
   Verifying Checksum ... Bad Data CRC
 # LED(0x2) Blink[2] (Please press 'Ctrl+c' to stop)

Pressing ctrl-c at this point boots the kernel but the router wont do a proper startup (obviously).

Can it be that the webupgrade images have wrong header? It consistently brick the router 100% so it doesn't seem to me just a matter of bad luck for some "strange behaviour" of the flash chip. Bad luck may happen but 100% failures is more than that :-)

Had no time today to break open the router (honestly I would avoid it, if possible) and connect a TTL serial to the header to log the console output. If absolutely needed, next upgrade I will do that (well .. pretty please don't ask me to open this 140$ router :-) )

comment:6 Changed 3 years ago by Ric03

Resolution: invalid
Status: newclosed

comment:7 Changed 3 years ago by Ric03

Resolution: invalid
Status: closedreopened

comment:8 Changed 3 years ago by BrainSlayer

Resolution: provide more info and reopen
Status: reopenedclosed

the brick happens in the following way. flashing the wzrg300nh is fucking slow. you have to wait a very long time, even if the browser already shows a timeout. you need to way until its done. and your log shows that you flashed a firmware from 2009. i dont know why are posting this

Created: 2009-09-25 12:49:22 UTC

comment:9 Changed 3 years ago by Ric03

The brick problem is not caused by haste. I know the flashing of this router is fucking slow. The router is bricked because shows red led double flashing and this is a flashing error described in the manual.

BTW, I will see if I can find more info on what happens during update. I don't know if you noticed in the latest build thread: people is starting to lose faith in seeing this issue fixed and they just jump straigth to tftp update without even trying the web update.

Note: See TracTickets for help on using tickets.