I've also bricked a WRT54GS, but I can't come it back to life with shortening pins 5&6
Any other tip?

Regards,
Slapic

Unfortunately, I can not verify these pins, nor any other pin combination. I've gone down pins 1-28 with no success.

I've noticed one difference between G and GS though: when plugging in power, the DMZ and WLAN LEDs of the GS flicker for a split second, whereas they stay dark on the G. Can anyone verify this? I had one comment where the GS LEDs stay dark too. Might have been an older version, and Linksys changed something around on the GS since then to prevent the tftp upload within boot_wait.

- Gromit.

I too have bricked my GS.  I had the boot_wait=on, and tftp still didn't work.  The power LED kept flashing.  When I held the reset down for 10 seconds, I still couldn't tftp.  I then tried holding the reset down for 30+ seconds, and miraculously, tftp worked.  At this point, the boot_wait was set to off.  So I'm not really sure how tftp worked.

Strange, I wish we could get some definitive instructions that work. Has anyone else with a GS who couldn't get the shorted pin trick to work tried the reset button and have it work like dloki?  If so I'll add the GS footnote and also point to this thread.

Just as another data point, I've got a WRT54GS and I had no trouble at all using the standard boot_wait procedure (enabling boot_wait from the Ping.asp page, and then tftping an image across during boot). I've flashed it probably a good dozen times using this method, and I haven't had any troubles, though it was quite picky with the timing of the TFTP transfer.

I found that I had the most luck when flashing from a machine plugged directly in to the router, starting the transfer just after the light for the LAN port I was using first lit up. Using the exact instructions on the site (starting transfer with rexmt 1 and then turning the router on) was more problematic.

Before flashing openwrt, I've flashed Sveasoft Satori, so that anabling boot_wait is really easy

With one GS, I've forget this, that was my problem. I've flashed Niko's fork of openwrt. After this failure, I could't ping, couldn't tftp and no pins worked for me.
I could de-brick it with holding down the reset button when powering it. The flashed system started to work, I could telnet and enable boot_wait.
With an other router, I've first flashed openwrt-cvs (20040808 as I remember), then Niko's fork. In this case, I had no problem.

About the tftp:
I've never succeeded to put anything with netkit-tftp.
I use atftp (I use Gentoo Linux if it matters). Whit atftp the following works for me:
atftp 192.168.1.1
tftp> trace
tftp> timeout 1
tftp> put openwrt-gs-code.bin

Right after I press enter on the put line, I power on the router. It works.

Regards,
Slapic

The tftp worked once.  I could telnet into the box and configure.  When I power-cycled it, the power light was blinking and I have been unsuccessful trying to re-animate it.

-Sam

I also am the happy owner of a bricked WRT54GS and tried several things to get it up and running again. Until now no succes. Se below a brief history on the issue:

The problem started after I flashed the box with nico's openwrt. It worked fine until I started playing with the NVRAM variabeles. After a few changes I tried to commit the new values to NVRAM but the box didn't let me do this. It generated an error after the 'nvram commit' command (Don't know the exact message but is was something about not able to write to NVRAM). So I tried to power cycle the device to get it working again. Since then the power LED started flashing constantly and the box did not work anymore.

I tried to solve this problem by soldering a Com port on the device to check what was really happening and to try to break into the CFE with CRTL+C. This didn't work either. Also tried to do the trick with pin 15+16 and pin 5+6 and several TFTP downloads. None of this solved the problem. So I am afraid that the box really died on me. See below the screen dump I got via the serial port:

--BEGIN DUMP--

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Sat Jul  3 18:38:57 CST 2004 (root@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena.
Initializing Devices.

No DPN
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.60.13.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29007: 200MHz
Total memory: 0x2000000 bytes (32MB)

Total memory used by CFE:  0x80300000 - 0x8043DF60 (1302368)
Initialized Data:          0x803381D0 - 0x8033A580 (9136)
BSS Area:                  0x8033A580 - 0x8033BF60 (6624)
Local Heap:                0x8033BF60 - 0x8043BF60 (1048576)
Stack Area:                0x8043BF60 - 0x8043DF60 (8192)
Text (code) segment:       0x80300000 - 0x803381D0 (229840)
Boot area (physical):      0x0043E000 - 0x0047E000
Relocation Factor:         I:00000000 - D:00000000

Boot version:  ==> v3.3
The boot is CFE

mac_init(): Find mac [00:0F:66:C7:9F:F2] in location 1
Update lan mac from [00:90:4C:60:00:2A] to [00:0F:66:C7:9F:F2]

No eou key find
Committing NVRAM...donÿ

CFE version 1.0.37 for BCM947XX (32bit,SP,LE)
Build Date: Sat Jul  3 18:38:57 CST 2004 (root@localhost.localdomain)
Copyright (C) 2000,2001,2002,2003 Broadcom Corporation.

Initializing Arena.
Initializing Devices.

No DPN
et0: Broadcom BCM47xx 10/100 Mbps Ethernet Controller 3.60.13.0
rndis0: Broadcom USB RNDIS Network Adapter (P-t-P)
CPU type 0x29007: 200MHz
Total memory: 0x2000000 bytes (32MB)

Total memory used by CFE:  0x80300000 - 0x8043DF60 (1302368)
Initialized Data:          0x803381D0 - 0x8033A580 (9136)
BSS Area:                  0x8033A580 - 0x8033BF60 (6624)
Local Heap:                0x8033BF60 - 0x8043BF60 (1048576)
Stack Area:                0x8043BF60 - 0x8043DF60 (8192)
Text (code) segment:       0x80300000 - 0x803381D0 (229840)
Boot area (physical):      0x0043E000 - 0x0047E000
Relocation Factor:         I:00000000 - D:00000000

Boot version:  ==> v3.3
The boot is CFE

mac_init(): Find mac [00:0F:66:C7:9F:F2] in location 1
Update lan mac from [00:90:4C:60:00:2A] to [00:0F:66:C7:9F:F2]

No eou key find
Committing NVRAM...

--END DUMP--
Maybe you can find out why this is happening.

Kr,
crash

Ok, I have been trying for days, but was using the wrong pins. On the GS, with the leds towards you, start counting from the lower left hand corner from left to right... pins 5 & 6.

As soon as I shorted the right pings, it immediately started pinging on boot (192.168.1.1) and downloaded the .bin right after that. I was able to telnet after a few minues. Hope this helps someone else. Thanks for the great support guys, keep it up.

i can confirm the 5-6 pin trick working on my 54gs.  though, i think it might technically be counted the other way around, i.e., 19-20 (i think).

De-bricking does work on my dell truemobile as well, but you need to short Pins 9 & 10 to get it waiting and then tftp to 192.168.2.1

mrverbose

Ah, and by the way: If you want to avoid unnecessary  debricking on your Dell Truemobile 2300 box do not flash any newer snapshot then snapshot-20040827.

Since 20040827-1 something about the reset button changed in openwrt that leaves your box not responding to any network activities (at least set boot_wait=on before you do so, because then you still can flash another firmware via tftp on boot then).

mrverbose

Do the developers already know this?

I told [mbm] about it in the wrt54g channel on freenode.

Okay, here's a good one...  Router is unresponsive (v2).  I get link lights on all ports, even WAN.  Power light blinks incessantly.

I thought I had boot_wait set but if I did it isn't working.  I begrudgingly opened the WRT to try shorting pins 15-16.  When I do so the DMZ light comes on -- I read that it is expected behavior.  However never can I ping or get ANY type of response from the router (ran Ethereal to see, all I am getting is a bunch of ARP queries from the host, nothing from the WRT).

One thing I noticed...  I can get the DMZ light to turn on in the same fashion as shorting the pins by holding the reset button while powering the bugger on.  Does that trick have the same effect as shorting the pins (booting failsafe)?

I'm flat out of ideas short of attaching a serial port and trying to actually "see"what is going on, but I'm even skeptical about that...  Does anyone else have any suggestions about this?

Thanks.

hi!

One of the possible debricking solution is using serial console and send CRTL-C sequence to CFE boot. Plug the power and hold down CTRL and C. If this not helps, repeat. If you get lucky, you see CFE> command prompt. After that, nvram set_boot=wait and nvram commit.

I have also sucessfully debricked my WRT54GS by shorting pin 5 and 6, and I'm confident pin 1 is the one near the bigger marking. LEDs towards yourself, start counting from the left on the side of the flash IC towards yourself.

Thanks for the tip. That's $100 saved ;-)

/Spiff

I guess this is related to the size of the firmware. The OpenWRT firmware is much smaller than the normal LinkSys firmwares, which I think accounts for the progress bar not going all the way.

/Spiff

thanks the pin 5 and 6 works for me too.
I send a new firmware to the WRT with TFTP now the unit reboot and the power is not blinking anymore but I can't access it or ping it on 192.168.1.1
Any idea ?

I have been struggeling with a related problem for most of the weekend. My findings are these:
At one point I was able to load the LinkSys firmware with TFTP, and then load a SveaSoft firmware with the web-interface. No matter which OpenWRT firmware I tried to load, the box wouldn't come up after rebooting.

Now, I've come to the conclusion that what was happening was the OpenWRT starting up, detecting a JFFS-filesystem, trying to boot from it, but then failing because the FS is broken. Aparently the JFFS-filesystem is not entirely wiped when installing the LinkSys or SveaSoft firmwares.

To solve this you need to boot OpenWRT in failsafe mode. On the GS timing is crucial, since you need to hold the reset-button at the correct time, but if you hold it for too long, the nvram wil reset and turn off boot_wait (if this happens you will probably need to do the debricking trick by shorting pin5 & 6 on the flash during bootup - at least that's what I had to do).

What I did was to flood-ping the box during boot:
[root@spiffship]# ping -f 192.168.1.1
This prints a "." each time a packet is lost. When the tftp-server is up, the router also replies to our ping-requests, so it will stop printing dots for 2 sec (assuming boot_wait is set). When it starts printing dots again, wait 1 sec then hold reset for 3 sec, and you should be getting into failsafe mode. At least this worked for me, but remember not to hold the reset-button for too long.

BTW: This flood-pinging also makes sure your APT-table is updated, so one might have better success with TFTP'ing after first flood-pinging and rebooting the router, then rebooting the router again and doing the TFTP.

I read somewhere that setting boot_wait to off still gives you a small time window to hit the TFTP-server, but in this case only like 0.5 sec. Can anyone confirm this?

/Spiff

i have a dead? wrt54gs here too, tried all that stuff with the pins, reset button aso.. nothing worked, power-led still flashing. sometimes power led and dmz led lights green, but i get no lan connection. i noticed that the broadcom chip gets very(!) hot after a few seconds, my second wrt just gets warm.

any ideas?

about this corrupted jffs2 assertion, is there anything like a signature or what which can indicates that it is valid or not ? If that is the case, why not just create a firmware that is significantly larger than the previous one so it would overwrite the jffs2 signature and make openwrt starts all over again from fresh ?

Doing so I would have a more or less constant growing firmware file.

The better way is - if in doubt about the integrity of file system - to make a failsafe boot and do a manual "firstboot". This will reformat the jffs2 file system and keep your firmware as small as necessary.

I'm looking for a firewall script similar to the one in the org. WRT54 firmware.

I used to write my own ipfilter rules, but that was a long time ago and there is a reason why i know like SuSEfirewall2...

I like to do runtime changes to the firewall and shorewall is not the answer - like other iptables rules generator it includes many stuff not needed on the WRT54.

The advantage (or weakness) of the org. firewall(.c) in the firmware is, that it does create the iptables rules direct from strict predefined (nvram) values, which is of course much faster than a nice readable config file.

Has anyone written a fast iptables script?
May be it would make it also easier for the web front end to read the firewall config, if the rules are created from similar base values as the org. firewall.

A (possible) fast generator with a readable config file s is:
http://freshmeat.net/projects/agt/
It is written i C and runs also on openwrt. But i had to fix the iptables flush code (for openwrt), and i am not so sure about the quality of the code/ipfilter rules.

just curious, why shorewall is not suitable other than that it stores things in /etc rather than nvram ?