WRT54GL and OpenWRT

Warning!

Do not forget to set the boot_wait nvram option. Without you will certainly brick your device sometime. You have been warned.

Also test that the failsafe mode works for you before doing some things. If it fails, you must re-start from scratch using the ugly TFTP method (which only works with said boot_wait option). Trust me, you don't want to do this ever.

Install

Here is how to install OpenWRT to a WRT54GL.
As always: I am not liable for anything. If you break it, you own all parts.
  • Download downloads.openwrt.org/backfire/10.03/brcm-2.4/openwrt-wrt54g-squashfs.bin
  • Plug your Linksys into a network interface of your computer, use network socket 1 on the Linksys
  • Computer automatically discovers its IP address and perhaps changes default route to the Linksys (this means, it looks like you are disconnected from the Internet)
  • Open 192.168.1.1/Upgrade.asp
  • Upload openwrt-wrt54g-squashfs.bin to the router
  • Wait a while
  • Open LuCI at 192.168.1.1/
  • There is no password yet!
  • The WiFI side is down by default.
  • Open telnet://192.168.1.1/, this is a TELNET console (hint: Try PuTTY) to 192.168.1.1
  • Set a root password with following lines:
    passwd && sync && reboot && exit
  • Now open the SSH console (again, you can use PuTTY) to ssh://192.168.1.1/, your login is "root", the password is the password you entered in the last step
  • Enter following lines:
    nvram set boot_wait=on
    nvram set boot_time=10
    nvram commit && reboot && exit
    If you are puzzled, this sets the bootloader to wait for boot interception in case you mixed up your device. Without, you would not be able to intercept the boot, thus bricking your device by chance. The boot takes about 10 seconds longer if you activate this.
  • The SSH link breaks, reopen another SSH console, enter
    nvram get boot_wait; nvram get boot_time
    The result must be
    on
    10
  • Now you are ready to install any other version of OpenWRT if you like

Test the failsafe mode

This step is most important. If this step does not work, chances are high (90% and higher) that you will loose your device as you brick it. I bricked mine before having tested that failsafe mode works, and afterwards it was too late. The first configuration trouble bricked my device.

How to test failsafe mode:

  • Be sure to give the router a password as told above.
  • Give it a simple single letter password such that you cannot forget it.
  • DO NOT CONFIGURE THE DEVICE ANY FURTHER as chances are that you misconfigure and brick your device.
  • Reboot the router.
  • Make sure that the device now can be still accessed as 192.168.1.1 using SSH, username root and the given password.
  • Make sure that the device cannot be accessed with telnet 192.168.1.1 as before!
  • Now enter failsafe mode as advertised (see next paragraph)
  • Do a telnet connection to 192.168.1.1
  • If you cannot telnet there after entering failsafe mode, STOP HERE IMMEDIATELY and DO NOT USE THIS FIRMWARE as it is BROKEN. Wait for a new firmware to come out which fixes this issue, or use some elder firmware which does not have this problem.
  • If you can telnet there, failsafe mode works as advertised, so you can recover your device if you accidentally mix up something.
  • Try it some times again to be sure you know how to enter failsafe mode. Trust me, you will be glad to have done so if you ever need it.
How to enter failsafe mode:

  • Unplug your router completely
  • Plug in the router's power cord
  • Wait until the DMZ LED lights up
  • Again: DO NOT PRESS THE BUTTON IF THE DMZ LED IS NOT ON!
  • When the DMZ LED comes to light, wait a fraction of a second
  • Then immediately press the "Cisco Systems" logo (this is the "Easy Setup button").
  • If you press it too early (immediately) it does not work.
  • If you press it too late it does not work.
  • Keep it pressed for 3 seconds, then release.
  • If everything works, the DMZ LED starts flashing. It flashes with 3 Hz (this is 3 times a second).
  • The flashing can either happen while you are pressing or a short time (up to 5s) after.
  • The Power LED blinks in a very unusual way and it stays blinking all the time, same is true for the DMZ LED but if flashes regularily.
  • Plug in your PC's ethernet cable
  • Note that the ethernet cable can be plugged into any of the router's Interface, even the WAN interface pings on 192.168.1.1
  • Give your PCs interface a static IP 192.168.1.X where X is 2 to 253
  • ping 192.168.1.1
  • It should nearly immediatelty ping (max. 3 seconds) provided your Interface keeps the static IP and does not try DHCP
Was tested with:

Windows Vista 32, GBit Ethernet configured to 192.168.1.77/255.255.255.0 on the "alternate IP settings" screen

Backfire (10.03.1-rc3, r22796)
Linux OpenWrt 2.6.32.16 #1 Thu Aug 26 05:07:27 PDT 2010 mips GNU/Linux

KAMIKAZE (8.09.2, r18961)
Linux (none) 2.4.35.4 #12 Tue Dec 29 15:30:20 UTC 2009 mips unknown

Alternate variant (tested with Windows Vista):

  • Same as above but only the Router's power cord is removed.
  • While you do it the computer sends pings to the router.
  • After the router LEDs start flashing, it may take up some minutes(!) until your router pings.
  • I really have no idea why this is the case (ARP-Retry, Interface issues?)
  • I had more problems to find the right time to press the Cisco button in this case (router processes ethernet frames?)
Failsafe troubleshooting:

  • Is your interface on 192.168.1.X with X between 2 and 253?
  • Does "arp -a" show the correct(!) MAC address for 192.168.1.1? (The MAC is on the label on label with the serial number.)
  • Can you successfully ping another device?
  • Did you try a 100 MBit Switch between the router and your interface?
  • Make sure there is no other computer etc. on the Ethernet used to connect to the router.
  • Reboot your computer
  • Be sure you know how to bring the router into the blinking phase, then unplug the router for 5 minutes before trying
  • Plug in your computer into another Ethernet hook until the computer displays that it uses IP 192.168.1.X (this differs by each OS).
  • If you are unsure, buy a cheap ethernet switch which has an uplink port or is 1 GBit. Plug the computer into the switch and the router into the switch's uplink port, on 1 GBit each port is auto-uplink.
  • There are tons of methods to unbrick the Linksys on the net. Some are extreme and seem to be fake but are very reasonable. If anything else did not work (consult your local computer guru friend first!) and you have nothing to loose, you might even try things like in the link section below.
  • One last note: If you do a "fast ping" (more often than 1 ping per second, Linux and a switch are your friends) you might observe some packets the router answers as 192.168.1.1. If so, your router is not totally brick and it is very likely that you can recover it without using a screwdriver (this includes using the reset pin).
ARP help:

If ARP entries are missing, there are several ways to gain them. If your router is not totally brick it might answer RARP requests if you normally boot it.

Another way is to enter ARP entries manually. Please RTFM arp.

What to do in failsafe mode:

  • The root filesystem is mounted readonly, so you cannot change anything in /etc
  • To make the root filesystem writable use:
    mount_root
  • Then you can reset the password
    passwd
    sync
  • Or you can look into the configuration
    cd /etc/config
    ls -al
    cat network
  • You can edit files using VI
    vi network
    If you are lost in VI and want to abort your edit press ESC twice, then enter
    :q!
    and hit the ENTER key. If you do not know VI, then try to Google a "vi reference card", the important key sequences are:
    h j k l  cursor movement
    :0       (this is number zero) first line (other numbers jump to the line-nr)
    :$       last line

    x        delete character under cursor (left character for inter-character-cursors)
    i        enter (insert) text at cursor position until you press ESC
    A        (uppercase!) like i but append text to the end of line
    dd       delete current line

    ESC      leave current mode (twice to abort nearly any state to a sane state)
    :w       and press ENTER: write to file (:w! to force write)
    :q       and press ENTER: quit vi (:q! to leave VI even if data not written)
    You might hate VI, but it is small and fast even over the slowest network links.
How to exit failsafe mode:

You cannot use "reboot" command. Just "sync", wait a second and turn of the power.

Flashing with TFTP to unbrick your Linksys

This method does not work if boot_wait is not enabled or boot_time is too short.

If you can, abstain from this method, ever. It is horrible and far from working as advertised. I tried with Windows (Cygwin) and it failed. Following setup worked for me:

  • Linux
  • Either using a scriptable TFTP client such that you can delay the TFTP execution to manage to keep the correct timing or a second person who operates the return key such that the TFTP transfer can be started in the right sequence after plugging in the power cord, or you have 3 hands, one to hold the linksys, a second to plug in the power cord and a third to operate the return key. I used my big toe instead of a third hand to press the enter key.
  • Managing to find the exact timing between start of TFTP and plugging in the power cord to the Linksys
The bootwait was set to 10, whatever this is. I think this are milliseconds or even worse, such that the TFTP packet nearly must hit the Linksys in just the right CPU cycle to be able to start the TFTP transfer. Your mileage may vary.

For me I think it worked as follows (I do not get this each time):

  • Connect the Linksys using port 1
  • Plug in the power cord into the Linksys
  • Wait until all the LEDs start to settle after the initial illumination (this is Power blinks and Port 1 is on, all else should be off)
  • And nearly immediately but not immediately start the TFTP
  • If I start the TFTP before inserting the power cord (as described) it does not work for me
  • If the TFTP is started too early the TFTP does not work for me
  • If the TFTP is started too late the TFTP does not work for me
  • Between too-early and too-late seems to be a duration of less than a second AND it seems to be a bit random, too.
Perhaps following could help:

Use an Ethernet-Switch with Linux on the downlink port and the Linksys on the uplink port, such that the Linux does not see the interface coming up and down. I used the direct cable (which came with the Linksys), perhaps this is the cause of all the trouble.

Here is a copy on how TFTP is done:
tftp 192.168.1.1
binary
trace
put openwrt-wrt54g-squashfs.bin

For this to work, your computer must have a static (secondary) IP in the range 192.168.1.x with x=2 to x=254 with subnetmask 255.255.255.0.

Flashing the 2.6 firmware

After you have done and verified everything using the Kernel 2.4 image, you should upgrade to 2.6, because with 2.4 some things are seriously broken currently (packages do not install due to wrong checksums etc.).

  • *.bin images are useless.
  • Download the *.trx file instead, like downloads.openwrt.org/backfire/10.03.1-rc3/brcm47xx/openwrt-brcm47xx-squashfs.trx
  • Upload this to LuCI. (I really do not get it. Why doesn't the router downloads the proper image itself?)
  • Verify the md5sum. (I really do not get it. This is pre historic. Today we must expect that a modern flash image is cryptographically signed and this signature is checked by the running firmware against a buildin public key. The outcome of this check then must be presented to the user. So I would expect a proper "OK" on the screen, not a note to verify!)
  • WHEN UPGRADING FROM 2.4 TO 2.6, DO NOT KEEP THE CONFIGURATION FILES, ELSE YOU WILL BE STUCK IN SERIOUS TROUBLE.
  • Click Proceede
  • Wait until the data is flashed (hopefully no blackout in this time!)
  • Wait until the router starts up again and is up and running. Some older firmwares do not manage to reboot. If you waited long enough - 10 minutes minimum, you have been warned - and the device still did not reboot, unplug it.
  • power cycle the router (when upgrading something fails so the router setting is interpreted incorrectly)
  • After this second reboot you hopefully have a working router.
  • TEST IF FAILSAFE MODE STILL WORKS (See above: "How to enter failsafe mode")
What I observe:

  • When switching from 2.4 to 2.6 the WLAN interface changes configuration from "WL0" to "RADIO0". I really do not understand.
  • Due to similar changes the old configuration does not work anymore.
  • Erase the config and create it from scratch because there is no proper way to fix this issue.
  • It is not nice from the OpenWRT team that it is not possible to keep the wLAN configuration etc.

Configuring the system

  • Open LuCI via 192.168.1.1/ (if you haven't changed the IP address yet)
  • Or open SSH to console, there enter something like "ipkg install PACKAGE" or "opkg install PACKAGE"
  • Usually LuCI is more easy to use, but if something goes wrong, LuCI does not tell you what happened (it just says Error 255). For example miniupnp was broken on the download archive, so I was unable to install it. LuCI did not tell me that the package fails MD5SUM check.

Notes

The links to 192.168 are borken on this page due to some bugs on my CMS, dunno why so cannot fix it.

Links

At your own risk:

-Tino, 2010-09-12 updated 2010-10-26