Hacking the Linksys WRT54AG
I am now the (semi-)proud owner of a Linksys WRT54AG access point, and
I'm trying to work on making a custom firmware image that will boot on
This little device has an interesting story behind it.
You will notice that I said it is a WRT54AG and not a WRT55AG (the
model of their "flagship" wireless A+G router).
You will not find this model number on Linksys's listing of products,
although you can still find it available for sale here and there.
Having become wrapped up in the frenzy surrounding the WRT54G series, I
was originally looking to buy a WRT55AG version 1 because legend says
that this version of the WRT55AG is not only based on the same Broadcom
platform that the WRT54G/GS is built on but that it also has dual-radios (one for 11a,
the other for 11g/b) and thus dual MiniPCI slots! (Tragically,
the recently-released and quite abundantly available WRT55AG version 2
not only eliminates the dual-MiniPCIs and integrates the radio onto the
board, but it also runs on an entirely different hardware and software platform...it's
VxWorks-based.) Alas, it was not to be. After many aborted
eBay attempts, I was about to give up when I ran across the public FCC
certification documents for a device called the WRT54AG. The
internal pictures of the device shows a board that looks remarkably similar to the one in
the WRT55AG, except even though it has two physical MiniPCI slots, only
one of them is populated!
This seemed curious to me, especially given Linksys's apparent usual
product development strategy (phase 1: get the product out-to-market as
quickly as possible by using common components; phase 2: create a
custom mainboard with everything integrated onto it in order to reduce
the cost of producing that product). Other Linksys 'boards that
can be viewed on the FCC web site may oftentimes show a board with one
MiniPCI slot and a card to go in it along with a spare place on the
mainboard for a second MiniPCI slot to go (e.g., the WAP54G version 1), but
rarely do they actually go to the trouble of soldering on a MiniPCI
header if they aren't going to use it!
A couple of other interesting facts that I observed while perusing the
FCC site: the WRT54AG board seems to be a stock GemTek (a wireless ODM
in Taiwan) reference design; the markings on the PCB indicate that this
board design was probably originally produced for use in GemTek model
WX-5514. This board is identical
to the one in the old (and discontinued) Linksys WRT51AB.
The WRT55AG (version 1), on the other hand, has WX-5545 silkscreened
onto its PCB,
though the boards look like near twins.
Here's a theory: First, to my knowledge, no one has ever reported
obtaining a WRT54AG through any channel other than Fry's (which is also
where I ended up finding mine), so it was probably a Fry's
exclusive. This combined with the fact that the WRT54AG was never
actively advertised on Linksys's website and seemingly uses an older stock
GemTek board revision and has
never seen a firmware upgrade
from Linksys during its lifetime leads me to believe that Linksys used
this product as a means of ridding themselves of a bunch of old-stock
parts. Just thinking out loud here.
Now for the good stuff. Here's what this piece of hardware has to
Overall, a pretty nice piece of hardware for the price paid ($79).
- Broadcom BCM4702 MIPS32 processor @ 125MHz (?)
- 4MB of Flash ROM
- 32MB of RAM (or at least
it looks like it...2x 128Mbit chips)
- 2x MiniPCI slots
- Wireless card is based on the Conexant Prism "Duette" chipset
- Ethernet chipset is Broadcom
I should note that at the present time, it is hard to tell whether or
not all 32MB of RAM is addressable...once I get shell access, I'll be
able to tell you.
Wireless performance on this router wasn't half-bad. I haven't
tried using it as a router yet; I just bridged the LAN side of the
device into my own network and used it as an AP. In 802.11a mode,
large transfers took a very noticeably shorter period of time than they
ever have with my old 11b access point. I haven't sat down and
really benchmarked it yet, but at least on my ThinkPad T42 + Atheros
a/b/g card, I pulled a 700MB file across the network in minutes.
I haven't really stress-tested the range of the radio yet, either.
Here's the not-so-good stuff:
- The antennas are permanently mounted on the casing. They do
not unscrew. There is no RP-TNC connector that they attach to,
unlike the WRT54G. This seems to be the case on all of Linksys's
dual-band product offerings (probably because of FCC concerns about
abuse in the 5.2GHz spectrum).
- The FCC site both clearly states as well as shows in pictures
that the antenna pigtails are connected to the Prism Duette card using
UFL connectors. However, upon opening mine up, I discovered that
my card does not have UFL connectors and that the antenna cables are soldered
onto the card. Ugh.
- I don't know yet whether or not the second, unoccupied MiniPCI
slot works correctly or is usable. I moved the Conexant radio
over to it, and one of the radio LEDs went into alert upon bootup and
the configuration pages show all 0's for its MAC when it's in the other
slot. I won't be able to figure out what's going on until I have
- It would be nice if it
were running on the BCM4712 @ 200MHz (though I've yet to find a GemTek
board with the BCM4712 that has even a single MiniPCI slot on it, let
alone two of them).
- It would be nice if
the flash memory were 8MB like on the WRT54GSes :-)
- WRT54AG vs. WRT55AG: the dual-radio architecture of the 55AG
allows for you to have A and B/G service offerings simultaneously (with
separate SSIDs for each) from a single AP/router. The Conexant
Duette card, on the other hand, can only be in 11a mode or
in 11g mode; it can't swap back-and-forth between frequencies and
handle both at the same time. I guess that's why the 55AG box
says "A+G router" while the 54AG box calls it an "A/G router."
Theoretically, though, because there is another MiniPCI slot... :-)
- The stock firmware that comes with the unit (version 1.08, Mar.
12, 2004) is pretty bare-bones. One of the most annoying aspects
of it is that although there is a MAC-based association filter (which
doesn't seem to work properly), there is no way to tell who is
associated! Even my ancient BEFW11S4 version 1 has that
functionality. Also, "ping.asp" doesn't exist on here, thus there
is no (known) exploit that can be used to get a shell. The only
way would be to build yourself a custom firmware with telnetd or sshd
I faced somewhat of a Catch-22 in my attempts to load a custom firmware
version on this router, and Linksys's virtual lack of support for this
product did not help any.
First, Linksys only just this month released the tarball of the source
tree required to build the firmware for the WRT54AG; until 04/04/05,
this model was missing from the list. Second, the tarball is
incomplete; it is one of the LARGEST of the source tree tarballs on
Linksys's GPL code download center (weighing in at an astounding
168MB!!) and yet I got hit with...
...in the middle of unpacking it. I've redownloaded it three
times and the file size has remained the same as has the place in which
the error occurs, so I think it is safe to say that whoever posted that
file to their web server didn't manage to finish the job. I've
informed them of this, but they have yet to act on this information.
gzip: stdin: unexpected end of file
tar: Unexpected EOF on archive file
tar: Error is not recoverable: exiting now
Second, if you load a custom firmware image onto your WRT54AG, there is
apparently no going back...Linksys has never posted a copy of their
one-and-only version of official firmware for the unit for public
download. Their technical support department told me via e-mail
that firmware for the WRT54AG is "no longer available," which I'm
guessing really means "was never available" (I figure "why make it
available if there have never been any upgrades" is their reasoning,
and it is a point not entirely without merit considering that Linksys
probably never bargained for all of this custom firmware engineering on
the part of their customers). I'll still continue to pester them
about this since I'd personally at least like to have the option of
returning the router to the state that it originally was in when I
Third, once I finally got around to trying to load on a firmware image
that I had managed to build (which I'll get to in a second), I
discovered that the WRT54AG's 1.08 firmware has either a bug or an
intentionally-placed "feature" that prevents the flash process from
succeeding: if you try to upload the new image via the web interface,
you can tell that it gets transferred over just fine, but as soon as it
is received, the web browser throws back a "document contains no data"
message, and the router just sits there dumb and happy (?; the dumb
part is at least true). No flashing of the firmware occurs (which
became evident when I powercycled the WRT and found that none of the
changes that I had made could be seen anywhere). Furthermore,
there is no TFTP server running on the stock firmware either! I
know about the old adage "do not attribute to malice what can be
explained by stupidity," but it sure seems,
based on all of the above, like Linksys had no intention to release
firmware updates for this router.
In order to be able to explore the router in more depth, I figured that
the first step would be to roll my own firmware image with a telnetd on
it. There weren't many pre-rolled options at my disposal; one of
the WRT54G third-party firmwares might
have worked (with the exception of the wireless; they're all
Broadcom-oriented and I'm running a Prism Duette here), but the trouble
is that the WRT54G series didn't switch over to using a Broadcom
ethernet controller until recently; the majority of them are
ADMtek-based. OpenWRT has some builds labelled "experimental"
that claim to support the "new" ethernet controller, but rather than
spending time trying to get someone else's firmware to work on a model
that it was never intended for, I thought it would be easier to take
the existing Linksys firmware for the WRT54AG and modify it. (Hahahahahaha!! *wipes tears from eyes*
That's a good one!)
I was initially dismayed upon discovering that Linksys screwed up the
tarball for the newly-released WRT54AG source tree (and I've pointed
this error out to them multiple times over the past week, but it's like
talking to a brick wall), but a closer investigation of the contents
that I did receive from them
(especially compared to the archives from other firmware sources like
the WRT55AG) revealed that it was most likely just the sources for the
build tools that got left out, and that the majority of the files
required to actually build a functional firmware image were still
present. So I went ahead and followed the included instructions,
and came out at the other end with a brand-new TRX file! Score!
Now that I knew that I could at least fuild what looked like a complete
image from the stock sources, I decided to roll-my-own and include some
improvements. Here's what I ended up doing:
Now the trick was to get the new firmware onto the router. I
couldn't flash it the "normal" way because the current firmware image's
support for upgrading the firmware is utterly broken, I couldn't peek
in to figure out why it does
not work because there's no telnetd on the current firmware (and no
ping.asp to exploit), and I couldn't put a telnetd on there without
being able to write to flash. Grrr! I went through the
source code and found the section that dealt with accepting a new
firmware image and writing it to flash memory, but it didn't look any
different from the same section of code from the WRT55AG firmware.
- I downloaded a copy of batbox and took its
build of busybox (1.00-pre2, if I remember correctly) -- which included
a telnetd -- and replaced the busybox binary in the cramfs filesystem
of the WRT54AG firmware with this one. I also made a symlink from
/sbin/telnetd to /bin/busybox and a few other symlinks for busybox
utilities that I thought would be useful and that were included in this
build of busybox.
- I had to edit Linksys's (errr, excuse me, GemTek's) 'rc'
application in order to ensure that telnetd started up on bootup.
Rather than using a standard initd, GemTek wrote a custom program in C
(!!) that starts up all of the necessary programs and daemons that are
needed for the router's functionality. My patch can be downloaded
here. I took the new rc binary and replaced the old one in the
cramfs filesystem with mine.
- I then ran mkcramfs to make the actual filesystem, and ran trx to
assemble the final firmware image from the Linux kernel binary and the
new cramfs filesystem.
In the end, I had to resort to using the "short a couple pins on the
Flash ROM chip in order to trick the bootloader into thinking there
isn't any firmware to boot" trick, but this took a LOT of
trial-and-error to get working because shorting pins 15 and 16 on this
router did not work. Once I finally managed to prevent the
bootloader from booting the current firmware, I was able to tftp my new
custom firmware image up to the router. And...nothing
happened. It took the firmware image alright, but the router
refused to boot up anymore. I had just managed to "brick" it.
Fortunately, Linksys was kind enough to include a pre-built copy of a
firmware image built from the source tree in the tarball with the
sources. So after much patience in trying to reproduce the
"shorting the EEPROM" trick again, I finally managed to load on
Linksys's original firmware. This DID work, but once the router
booted up, I discovered that although the name of the tarball indicated
that the sources were for version 1.08 of the code (the version that my
WRT54AG shipped with), the firmware that I had just managed to put on
the router claimed to be: "1.07, Feb. 27, 2004"! When I went
through and examined the source code, I discovered that, sure enough,
these sources were for 1.07; they didn't just happen to include an old
firmware image by mistake. And 1.07 has proven to be buggier than
1.08: although it does
actually accept a new flash image correctly (which might explain why I
didn't see anything abnormal while looking through the WRT54AG's
sources...it's because this
version isn't broken in this
respect), it will not "remember" any changes that I make to the radio
settings. It is now eternally stuck on "802.11g mixed-mode"; I
can't swich it to be an 11a access point, and I can't turn off the 11g
radio or set it to "G-only" mode.
This hardware platform has a lot of potential: it's based on the same
hardware platform that the WRT54G and clones are based on, plus its
dual-MiniPCI slots give it a lot of extra flexibility. But two
things need to happen in order for this potential to be unlocked:
first, someone needs to tell me what I'm doing wrong :-), and second,
Linksys needs to correct the situation with the availability of a complete
source tree for this router.
And don't forget to check out the page I put together on the problem
association hijacking that I put together for my employer.
Thanks for reading!
-- Nathan Anderson <mailto:email@example.com>
-Help spread info on the 802.11 Association Hijacking Bug-
(last updated 04/23/05)