This hw fix applies to the wrt54g version 2 hardware ONLY (US version).  I have not tried it on any other units.

User's assume ALL risk in utilizing this information in any manner what so ever.

If you do not take full responsibility for your own actions, don't read this post any further.

This may ruin you wrt54g Version 2 HW, or other hw, if not a wrt54g, and god know what other possible harm may come to you or others using this information. Use at you own risk.  Also, if you bricked your unit, do be a wus and just return it. Take responsibility for you actions, don't sluff it on to others.

Also, be sure you have read and understand http://openwrt.ksilebo.net/temp/00-WARNING.TXT

End of Disclaimer.

-------------------------------------------------------------------------------------

Really, you're still reading.  This is all up to you, don't blame me, this website or anyone else for problems resulting from attempting to utilize this information in any shape or form.  It is up to you to take care of yourself, property, etc....  Use your head, take your time, read twice, flash once or not at all.

Before I begin, props to [mbm], mjn3, and others for all their hard work and getting things to where they are at.
Also, thanks to gps (for being one of the first to use this de-bricking trick).

Enough of that, here's my story and I'm sticking to it.

I'm a dumb-ass and bricked 3 wrt54g hardware v2 units attempting to use b4-pre.

2 of the 3 had boot_wait=on in nvram, the other didn't. It's a funny story, but this post is already running way long.

Here are my lessons learned:

1) Use a normal tftp client for attempting to send an image during the boot_wait interval.
1a  Be sure binary mode in enabled,
1b  Set the retransmission interval (rexmt 1) in the tftp client to 1 second. Mine defaulted to 5 (you can miss lots of windows with the 5 second interval)
1c  With one of my units the tftps were starting, but failing to complete. I needed to go to 10Mb hub and try several times before it completed correctly.
1d  If you are familiar with ethereal or other sniffers, it useful to monitor the packets into and out of the unit. That's how I knew, the tftp's were actually starting, but not finishing  (no last packet).
1e  the status command in the tftp client shows you mode, retransmission intervals and other stuff, use it a check before you type the put code.bin command
1f  try to uses a known good images (in my case the image was not known to work on the v2 units)
1g  I used the arp -s command to statically set the MAC addr of the wrt (it's on the bottom of the unit).
1i  my tftp client is tftp-hpa 0.34 (just fyi for the curious or desperate)

These steps allowed me to de-brick 1 of my three units. The other 2 seemed toast. 1 was rebooting every 3 seconds, and the other was KNOWN to have boot_wait=off and rebooting every 15-20 seconds.

Did I say you should try this at you own risk ? It's all up to you.

The last 2 units we revived by shorting two pins on the flash chip. Specifically, white stenciled pins 15-16 near the LED end of the board.

With the unit that was rebooting every 3 seconds, I kept moving along the address line pins. I had kind of given up hope with the method, when the unit stopped rebooting and I saw the tftp xfer in the ethereal window. The first time surprised me and freaked me out a little. I had to power cycle the unit and find the pins again. I just shorted pins 15-16 together (note there is a white hash mark every 5 pins) and let the unit reboot.   The tftp was running all the time with a 1 second rxmit interval and a timeout of 360 or 6 minutes of attempting before reissuing the command. Just like that, the unit was re-flashed.  I waited for a couple minutes after the tftp completed (via live scrolling in ethereal) and it woke up de-bricked running the linksys firmware (with a minor ping tweak).

2 units de-bricked, 1 to go.

The flash pin short worked so well, I had to try it on the unit with the boot_wait=off. I had heard there was a tiny window during boot, even with boot_wait=off. I needed to have somebody power-on the unit while I was holding the short on the pins 15-16.  You just keep those pins shorted and power-on as the tftp attempts are happening every second and it worked on the first real attempt.

All three unit fully recovered.  Ready to test the next b4-pre.

Yes, I verified boot_wait=off on that unit. It was quickly changed to boot_wait=on and committed.

Good Luck fellow adventurers.

Thanks again [mbm], mjn3, and gps. I don't know who the other dev's are.

[g2]

Oh yeah, last but not least,  Ksilebo THANKS for hosting this wonderful effort!

thanks for writing this up; i'm sure it'll help someone else.

if you have units with boot_wait=on already you should not need to do any of the flash pin shorting and such mentioned above.  just tftp an image named code.bin  right after power on as described.

i had an extra ethernet interface on a computer connected directly to the switch ports on the unit when tftping.  no intermediate devices and no need to force it to 10Mbit/sec or half duplex or anything.  the unit will always be 192.168.1.1 for the failsafe tftp load.  configure your network interface to 192.168.1.somethingelse

also i never needed to make a static arp entry any of the times i've used tftp to upload firmware (either debricking a boot_wait=off messed up unit by causing a crc error in the flash or uploading normally to a boot_wait=on system).  this is odd because some of the time i failed to notice the unit respond to an arp request for 192.168.1.1 so i don't know how my machine got the mac addr...  i probably wasn't watching the tcpdump close enough.

I've had a siilar problem. perhaps openwrt firmware should setup boot_wait when it boots in failsafe mode.

Umm...

The time you need this is when openwrt doesn't boot and you can't get in to run failsafe.

yes, like with OpenWrt b4. b4 was running fine, but without network access.
b4 seems not working with european people (france, belgique ...).

I would be pleased to try a b4 firmware to see if this problem is hardware or
software.

I works alright for me (I am from Berlin,Germany ;-) ) using a b4

So give it a try. The source for b4 is available, it just needs a "make" on a linux system... Just follow the description on the website at http://openwrt.ksilebo.net

If it still does not work, please provide a decent bug report. I mean, a bit more information then "no network access" would be nice - what is not accessible any more? Internet? Lan? What did you try? etc.

yes, I can read fucking manual ;-) I've build my own firmware. It really works. But
I have no acces to my wrt54g box. No ping, no telnet. But Linux is running fine.

so ...

I decided to change /etc/rcS startup script to make some traces in nvram variables. It was a painfull because I need to tftp openwrt b4, make my trace, tftp an other firmware that give my network acces. But this exercice showed me that linux is running fine.

- modules a loaded,
- no particular dmesg error
- ifconfig showed me all eth*

debugging was not trivial. I have alse run failsafe mode without succes.

I have also made some tests on b3. There was some nvram variable that
was disturbing boot process. After a reset with linksys firmare, b3 retarted correctly.

Shorting flash pins 15-16 worked for me on v1.1 hardware! I had given it up for dead several months back but Jim Buzbee stopped by my forum and pointed me to this de-bricking procedure. THANK YOU!!!

Thread where Jim stopped in and saved the day: http://voidmain.is-a-geek.net/forums/vi … .php?t=760

I just wrote up my own de-bricking instructions based on the fine instructions in this thread. I also took a few pictures and added to the tutorial:

TUTORIAL served right from the WRT54G:
http://voidmain.is-a-geek.net:81/redhat … vival.html

Or if I have the above down and playing with it you can get to it on my main site:
http://voidmain.is-a-geek.net/redhat/wr … vival.html

Post a link on slashdot and let's REALLY see what this thing can do!

I'm glad you were able to bring back your unit.  On your instructions you may want to add setting up a static arp cache entry.

Cheers,

[g2]

I didn't find it necessary to set one up, and it actually *shouldn't* be necessary. I did put a link to this thread and to my forums so I hope anyone who has troubles will try setting up a static arp entry, or at least post that they are still having trouble and I would suggest it. If I find some people actually have to do this then I will certainly add it.

Hi all,

I think I've killed my WRT54G (v2). That's the actual state:
-On startup first power-led blinks, after same seconds power-led and dmz-led are on, some seconds later dmz-led is off and the switch-leds indicate the connected computers
-The switch isn't working when two computers are connected (hardware failure? or software needed?)
-I can't ping the router, even when started with reset button pressed (IP 192.168.1.1)
-I can't flash the router via tftp (boot_wait seems off)
-Even when I brick pin 15-16 of the flash chip, I can't ping (192.168.1.1 right?) the router. But the power-led blinks, so it seemed to work.

That's what I did:
I build the firmware from actual cvs this morning and flashed it via tftp (before that I set boot_wait to on and disabled the wlan via the webfrontend of the original firmware). All that worked well and I installed some packages (openswan, ssh-server). Then I wanted to set up the WLAN interface. Because I disabled the wlan before in the original firmware I thought it were the best idea to reset the router (pressed the reset button on startup). After that the WLAN-led was off and there was no wlan interface (iwconfig). Then I noticed that many values from the nvram list went away (wl*) and I set them from the list in the wiki. But that didn't help. Then I noticed that the wl module wasn't loaded (dmesg showed eth1: 3.50.21.10 driver failed with code 30). When I tried to load the module width insmod wl I got the following message: insmod: init_module: wl: No such device (and eth1: 3.50.21.10 driver failed with code 30 via dmesg). I asked the people in #wrt54g on freenode and someone gave me his nvram value list. After setting this values and rebooting the router was dead.
Is it possible that some nvram values "killed" the router, so that it is even impossible to flash via tftp? I also tried to reset the router with the reset button (30s when running, 30s without power and 39s at startup) after that, but that didn't help.

Any ideas?

Here's the list with the values I set:
[code]
nvram set wl0_net_mode=mixed
nvram set os_ram_addr=80001000
nvram set wl0_frameburst=on
nvram set boardrev=0x10
#nvram set il0macaddr=00:90:4c:5f:00:2a
nvram set ppp_idletime=3600
#nvram set et0macaddr=00:0F:66:30:F8:98
nvram set wl0_wep_buf=
nvram set boot_wait=1
nvram set watchdog=5000
nvram set wl0_macmode1=disabled
nvram set wl0_infra=1
nvram set wl0_country_code=AU
nvram set et0mdcport=0
nvram set pmon_ver=CFE 3.51.21.0
nvram set wl0_ifname=eth1
nvram set gpio2=adm_eecs
nvram set gpio3=adm_eesk
nvram set gpio5=adm_eedi
nvram set vlan0ports=1 2 3 4 5*
nvram set gpio6=adm_rc
nvram set wl0_mode=ap
nvram set os_flash_addr=bfc40000
nvram set wl0_gmode=1
nvram set sromrev=2
nvram set boardtype=0x0101
nvram set static_route=
nvram set wl0_wep_last=
nvram set lan_netmask=255.255.255.0
nvram set wl0_dtim=1
nvram set wl0_ssid=linksys
nvram set ppp_redialperiod=30
nvram set wl0_key1=
nvram set wl0id=0x4320
nvram set wl0_key2=
nvram set wl0_key3=
nvram set wl0_key4=
nvram set ag0=255
nvram set wl0_plcphdr=long
nvram set wl0_rate=0
nvram set wl0_closed=0
nvram set wl0_macmode=disabled
nvram set wl0_radioids=BCM2050
nvram set wl0_phytype=g
nvram set wl0gpio2=0
nvram set wl0_lazywds=1
nvram set wl0gpio3=0
nvram set boardflags2=0
nvram set wl0_antdiv=-1
nvram set wl0_wpa_psk=
nvram set wl0_mac_list=
nvram set wan_proto=pppoe
nvram set wl0_unit=0
nvram set wl_country_code=AU
nvram set tz=CEST
nvram set pa0itssit=62
nvram set wl0_wds=
nvram set cctl=0
nvram set lan_dns=192.168.0.5
nvram set wl0_radius_port=1812
nvram set wl0_mac_deny=
nvram set wl0_auth=0
nvram set wl0_radius_ipaddr=
nvram set pa0maxpwr=0x48
nvram set clkfreq=200
nvram set lan_ipaddr=192.168.1.1
nvram set lan_proto=static
nvram set vlan1hwname=et0
nvram set aa0=3
nvram set wl0_phytypes=g
nvram set wl0_frag=2346
nvram set wl0_wep=off
#nvram set sdram_config=0x0032
nvram set wl0_country=Worldwide
nvram set vlan1ports=0 5
nvram set scratch=a0180000
nvram set ccode=0
nvram set wl0_rateset=default
nvram set wl0_wep_bit=64
nvram set pppoe_idletime=3600
nvram set lan_ifname=vlan0
nvram set boardflags=0x0188
nvram set wl0_afterburner_override=-1
#nvram set sdram_refresh=0x0000
#nvram set sdram_ncdl=0x2031f
nvram set ppp_user=
nvram set ppp_password=
nvram set wl0_passphrase=
nvram set wl0_rts=2347
nvram set wl0_wpa_gtk_rekey=3600
nvram set wl0_key=1
nvram set wl0_active_mac=
nvram set et0phyaddr=30
nvram set wan_ifname=vlan1
nvram set wl0_radio=1
nvram set wl0_bcn=100
nvram set wl0_hwaddr=00:90:4C:5F:00:2A
nvram set wl0_wep_gen=
nvram set wl0_gmode_protection=auto
nvram set pa0b0=0x170c
nvram set wl0_maclist=
nvram set pa0b1=0xfa24
nvram set pa0b2=0xfe70
#nvram set sdram_init=0x0000
nvram set vlan0hwname=et0
nvram set dl_ram_addr=a0001000
nvram set wl0_radius_key=
nvram set wl0_corerev=7
nvram set wl0_channel=6
nvram set wl0_auth_mode=disabled
nvram set boot_ver=v2.3
nvram set boardnum=42
[/code]
[/code]

I think the problem is the following command:

nvram set vlan0ports=1 2 3 4 5*

I'm not sure but I think without double quotes the value is set to "1" not "1 2 3 4 5*" (see also http://www.sveasoft.com/modules/phpBB2/ … php?t=191). That could be the reason because I don't have any connection via ethernet to the router (but I'm not sure if the value is interpreted in the bootloader, too!?). Pressing reset seems not to reset this value.

Any ideas (the only I have is to set the value via a serial link directly in the bootloader)?

From my WRT54Gv2, where I run "nvram erase" from CFE every time I upgrade OpenWRT:

root@OpenWrt:/# nvram show | grep vlan0
size: 1641 bytes (31127 left)
vlan0ports=1 2 3 4 5*
vlan0hwname=et0

Mine works without a hitch.

On the v2 and GS you can reset NVRAM to some rather bare defaults by holding down the reset button while plugging in the power; should solve the vlan* problem but it will unset boot_wait.

I solved the problem. I connected to the WRT54G via a serial link (http://jdc.parodius.com/wrt54g/serial.html, http://www.rwhitby.net/wrt54gs/serial.html) and set vlan0ports back to "1 2 3 4 5*" (it was really set to "1"). I bricked pin 15-16 of the flash and pressed [CTRL]-C to get in the bootloader.
Now my WRT54G is running like a shame

You don't have to, but it improves your chances a little.  If the IP is not in the ARP cache, your PC will have to ask for it and the unit has to respond so it loses a little time - with bootwait off, every few fractions of seconds count.

My wrt54g is as deader than any of the ones I've read about being revived, but maybe someone has ran into it before. If I power it on, the power light blinks, and when I hook up cables to the ethernet ports, I don't get any link lights. However; if I short pins 15 and 16 I get link lights and it works as a switch, but if I ping 192.168.1.1 I get no responses, and same result if I try tftping a a firmware (even when I start sending it before plugging it in). If anyone has any suggestions, please post a reply or send an e-mail to disasm@gentux.org

Thanks,
Sam

First: Please don't ask for email replies, use the 'notify me when a reply is posted' or 'watch this topic for replies' links found on all pages.

Second: You neglected to mention what hardware revision it is and what you did that caused it to break in the first place. The power light didn't blink on the v1.0's so we're talking about v1.1 or later, since you mention the ethernet ports not working I'm going to guess that it's a v2.0 and that you were playing with nvram variables?

Well, after I bricked my router, it flat out refused to take a firmware during the boot_wait period for some unknown reason.  These instructions were the only thing that saved my sorry behind.

I bricked it by modifying a startup script that apparently froze, preventing the services script from starting telnet.  So the hardware was straight, it just didn't like me...odd.

bluedragonx:

Openwrt has a failsafe mode for exactly that case. Failsafe will boot from squashfs and set the ip to 192.168.1.1. To boot failsafe, wait for the dmz led to turn on and then hold the reset button for 2 seconds. Please wait for the dmz led when attempting failsafe, if you're holding the reset button before that NVRAM will reset (changes to ssid linksys, ip 192.168.1.1, without boot_wait)

The jffs2 partition is located immediately after the firmware image so reflashing will not erase, but changing to a larger firmware image will overwrite parts of jffs2.

Hi all !

I have compiled and flashed OpenWRT (snapshot 20040807) onto my WRT54GS, which now is not accessible anymore. I've switched on boot_wait before flashing, but tftp doesn't seem to work.

Has anyone used the tftp procedure on the WRT54GS device?
Has anyone successfully re-animated a WRT54GS device?

*** Details: (basically following www.openwrt.org/userguide.html )
Using the buildroot tarball, I built the toolchain and OpenWRT firmware files (openwrt-g-code.bin, openwrt-gs-code.bin). I then flashed a WRT54G device with the corresponding *g-code.bin file using tftp (tftp-hpa 0.33, with readline). All worked fine, including the boot_wait feature. The device works great; df reports 1812k memory available on /dev/mtdblock/4 after installing dropbear.

Now, trying tftp on my second box (the GS version), I can't get the firmware to load within the boot_wait period. I've verified boot_wait=on as per above userguide, but even after about 30 attempts to flash the *gs-code.bin, still no success. I then used the webinterface to flash. The progress indicator (horizontal lines) had only reached about 1/4 of the total field, when suddenly the screen "Successfully flashed" appeared (that seems suspicious to me). After a power cycle on the box, the power LED doesn't stop blinking and I can't telnet into the box, nor ping it successfully.

One thing I noticed when plugging in power on the GS device was, that the DMZ and WLAN LEDs flash for a split second, even before the Power LED starts blinking and LAN1-4 and Internet light up for 1sec, then turn off. The G box does NOT do that. My assumption is, that the GS box performs some sort of reset or flush on the Intel flash that prevents the boot_wait procedure to perform normally. Maybe Linksys doesn't want us to hack this powerhouse of router!?

Has anyone seen something like that on the GS box before?

I have tried Void Main's 'recipe' for reviving a v1.1 G-box, but shorting pins 15-16 doesn't do the trick on the GS box. http://voidmain.is-a-geek.net/redhat/wr … vival.html

The original firmware was VER:2.07.1, and there is a hand-written date code on the PCB saying 6/18.

I will keep trying to reanimate the box, but in the meantime I have enough paper that needs to be held down by a neat-looking brick.

Thanks for any hints in advance.
- Gromit.

It's been awhile since I've had to debrick a wrt54gs, some random notes:

If you're holding reset for 5-10 seconds while plugging it in, it will reset nvram to defaults but will unset boot_wait (this works for anything v2 or later)

If you want to short the pins, remember that the wrt54gs has different flash chip than the v2 (8M vs 4M) so the pins you short changes ,, I seem to recall pins 5&6 working for that trick.

tftp to 192.168.1.1 using one of the lan ports on the router; helps if you can manually set the mac address in your machine's arp tables.

If you can verify the GS pins to short I will add a note to my HOWTO for the GS (assuming that is the only difference)..