OpenWRT and DD-WRT on the Linksys WAP54G 3.1
By Abhijit Menon-Sen <firstname.lastname@example.org>
We bought a
"Wireless-G Access Point" in August 2008.
This flat blue-and-grey device is a basic 802.11b/g access point with a
single Ethernet port and little besides: two adjustable rear antennae
and a front panel with some blinking lights. A sticker below the panel
says "Model No: WAP54G ver 3.1", and it shipped with firmware version
3.05, dated 2005-12-28. It has a 200MHz Broadcom BCM5352 CPU, 4MB of
Flash memory, and 8MB of RAM.
This page is about my experience with installing, using, hating,
breaking, bricking, reviving, and reconfiguring this device.
A brief overview of my network: the gateway has two Ethernet interfaces.
One is connected to a DSL modem, the other to a switch. The access point
is also plugged into this switch, and bridges between wireless clients
(of which there are two) and the rest of the network (of which there is
precious little). The gateway (which is also my workstation) provides IP
addresses via DHCP, and does NAT for the internal subnet. The wireless
network uses WPA2 encryption.
The WAP54G has a web-based configuration interface that works reasonably
well, but the absence of a telnet-based interface surprised me. I didn't
try the SuperEasySecurity (oops, I mean "SecureEasySetup") button, which
is said to do something magical to help set up Linksys clients (only).
Soon after installing it, we noticed that the wireless network would
disappear every now and then, and the access point would have to be
power-cycled to restore it. In the meantime, the front panel LEDs would
stay on, but the device would not respond to ping on any interface.
Sometimes the problem would occur after days; sometimes after only a few
minutes. There was no obvious correlation to network traffic. The access
point would survive many hours of “ping -f” on both wired and
wireless interfaces with no packet loss, but freeze under light load (no
BitTorrent). Sometimes it was dead in the morning, after eight hours of
inactivity (biological and electronic).
I have no way to measure the RF interference that the access point is
subject to; but the wireless connection, once established, is very
reliable, with none of the random packet loss that I associate with
interference. There is only one other wireless network in the area.
The device is fed clean power from a double-converting UPS, and lives in
a well-ventilated location (on my desk). The problem did not appear to
be related to overheating, because power-cycling even without any
cooling-down period would also fix the problem, sometimes for many
(I bought another WAP54G—also v3.1—more than a year ago, and
set it up in a similar configuration on a different network. That device
also suffers from the occasional lock-up, but nowhere near as frequently
as the new one.)
Useless technical support
I wrote to email@example.com to describe the problem,
and I was told to expect a response "within 24 hours". Eleven days (and
one reminder) later, I finally got a response asking for more details
and suggesting that I upgrade to "the latest firmware".
Unfortunately, the latest firmware offered for download on the Linksys
website is (still) 3.04, older than the 3.05 that was already installed.
I asked if they really wanted me to try downgrading the firmware.
A week later, a different person responded, saying she could not find
any v3.1 firmware either, agreeing that I should not downgrade to 3.04,
and asking me to explain my network setup. We exchanged a few messages,
but I have heard nothing from them after the 10th of October (despite
The latest firmware
An aside: although my WAP54G shipped with firmware 3.05, I could not
find any reference to this version on the Linksys site. Eventually, I
found the Linksys
"GPL Code Center",
which has source tarballs for 3.08 (and 3.05, and older versions). The
binary image included in the 3.08 release still identifies itself as
3.05 when installed, and still suffers from the same problem. I did not
try to build a new image.
I had heard good things about
OpenWRT, and found a
(and descriptions of the various hardware revisions on
the OpenWRT wiki
There was a report of successfully running the "White Russian" release
on a v3.1 device.
I downloaded the White Russian 0.9 image and used the firmware upgrade
option in the Linksys web interface to reflash the device. That's when
everything went horribly wrong.
From zero to brick in 6 seconds
The firmware upload seemed to hang at the halfway mark, so I restarted
it. It completed successfully, but when I rebooted, the lights flashed
for a while, and nothing else happened. I had forgotten to restore the
default factory settings before trying to upload the OpenWRT image (I
don't know if that caused the problem, but it seems likely, though other
people have gotten away with it), but resetting them now had no effect.
OpenWRT's failsafe mode didn't work for me either. I did see the "Press
reset now, to enter Failsafe!" message (broadcasted via UDP) while it
was starting up, but pressing reset had no effect whatsoever (and the
"Entering Failsafe!" message was never broadcasted).
The boot_wait NVRAM setting that instructs the boot loader to
wait for an image via TFTP was also switched off. (I was unable to find
a way to turn it on with the Linksys firmware. The configuration files
available elsewhere were all for different versions of the firmware.) I
read a suggestion somewhere to try the TFTP anyway, immediately after
powering on the device, but that didn't work either.
Lucky me, I had a brick!
Surgery and solder
Fortunately, many people had been down this path before me. There seemed
to be three things I could try, in increasing order of difficulty:
- Shorting pins 15 and 16 on the flash chip during boot would generate
a checksum error while trying to load the firmware, and the bootloader
would wait for a new image via TFTP.
- Soldering a header on the PCB and using a serial cable to talk to
the CFE boot loader via the serial console (and using it to switch on
boot_wait, among other things).
- Soldering a (different) header on the PCB and using a JTAG cable to
reflash the device.
Whatever I did, though, would involve surgery of some sort.
The WAP54G is a difficult box to open, but I found instructions on how
to "crack open" the very similar WRT54G by "forcefully pinching" the
front panel and pulling it away from the body. I hope I never have to do
It turned out that my v3.1 hardware had neither an Intel nor an SST chip
(as other revisions do), but a Spansion chip on the bottom of the PCB; I
needed to ground pin 16, rather than shorting pins 15 and 16 together. I
soldered one end of a thin wire to the metal shield of the "easy setup"
button (which acts as GND), and started counting pins.
With bated breath, I powered up the device, holding the end of the wire
in its precarious position against what I hoped was the right pin on the
right chip. But it worked exactly as expected the first time, and I was
able to TFTP the OpenWRT image again, and it booted correctly this time.
Once I had swapped the interface assignments (as described in the HOWTO,
the image assumes that it will run on a WRT54G, whose network interfaces
are configured differently), everything worked fine.
(If I had been able to find a 10-pin IDC cable header, I would have
connected a serial cable too. Pity, it would have been nice to use the
Once I got OpenWRT running, it was rock solid. I left “ping -f”
running against both wired and wireless interfaces for days (while also
using the access point as usual), and it never so much as blinked. I was
(I tried the more recent Kamikaze release too, but it didn't boot; and
since I knew that White Russian worked, I didn't investigate further.)
Unfortunately, the WAP54G just doesn't have enough memory to install any
of the OpenWRT add-ons, which means that there was no web interface, and
no WPA2. This was not entirely unexpected, and I decided that I could
live with it if I had to, but would experiment a little first.
(I could have tried to build a smaller custom image of OpenWRT, and it
may even have been possible to solder extra memory on to the PCB, but I
was looking for something simpler and faster to begin with.)
Tomato looked the most
promising of the other free third-party firmware projects, but would not
run on the WAP54G at all. DD-WRT was
the next-best alternative.
After my adventures with OpenWRT, installing DD-WRT was very simple. I
did a little reading, identified the "v24_generic_micro" image as being
the most likely to work, and reflashed the router; and it just worked.
WPA2 works fine with DD-WRT, but the really nice thing is that it also
manages to fit in a comprehensive Web interface in the default installation.
Unfortunately, DD-WRT has also locked up the WAP54G a few times, but not
at all frequently. It's been working properly for 19 days as I write
this—much longer than the old firmware ever managed. I would much
rather run OpenWRT, but DD-WRT works well enough for the moment.
I don't know what to think of the
about DD-WRT's licensing.
I couldn't find any way to make the built-in Linksys firmware work
reliably, and the Linksys technical support was useless. I got OpenWRT
working with some effort. It was stable, but the device does not have
enough memory to install everything needed to enable WPA2. DD-WRT has
locked up a couple of times, but it works well enough for me.
I will, however, try to avoid buying Linksys hardware in future.