I finally got a few hours free this morning to check an item off my home system administration checklist: upgrading the wireless router's firmware to OpenWRT. There were a couple motivations for this, including the fact that my SoundBridge Radio couldn't maintain a connection to my firefly server using the built-in firmware, and I had read that OpenWRT would work better.
Since this is posted on Planet Debian, I should mention why I didn't use DebianWRT. The basic answer is this text at the top of the DebianWRT homepage:
Currently the most common methods used to run Debian on these systems is to install OpenWRT or a similar firmware, add disk space either by USB storage or NFS, create a debian chroot by either running cdebootstrap from inside OpenWRT or debootstrap --foreign on a PC, and running Debian from this chroot. For example, instructions for the WLHDD.
I'm not sure whether this is because DebianWRT is experimental, or because its goal is to use routers as cheap general computers. Either way, it sounds way too complicated and/or fragile for what I'm interested in (i.e., a wireless router with better software). The goal here is to get something that does a better job than the built-in WRT firmware, but doesn't require too much tinkering to get working or to maintain. I have plenty of outlets for my tinkering urges already.
Nothing here was exactly difficult, but it was hard to find all the information I needed to get things working. Hopefully documenting the steps I went through here will save someone else some time.
Step 1: acquire the firmware
This was trickier than you might think. If you click on the
download
link at the OpenWRT web site, you end up at the
top of an FTP server populated with a vast quantity of stuff. Worse,
when you find the actual firmware images, you'll quickly discover that
there are piles and piles of them divided between sixteen directories,
and no guidance as to which one to pick. And picking the wrong one
will turn your beautiful router into a doorstop.
Luckily, the OpenWRT documentation contains a section called "Getting Started". Unluckily, that section consists of the following text:
1.1 Getting started
1.1.1 Installation
1.1.2 Initial configuration
1.1.3 Failsafe mode
Whoops, someone forgot to execute on a TODO. 
Undeterred, I consulted the usual fallback reference, Google. It pointed me at several references, some of which were hidden on other parts of the OpenWRT site. Armed with these, I was able to determine that:
- My WRT54GL v1.1 probably uses a Broadcom 5352 chipset.
- The correct firmware, according to multiple sources, is probably
in the
kamikazetop-level director, the latest version's subdirectory, and thebcrm-2.4directory under the version (the link is to 8.09.2, which is current as of March 6, 2010). Apparently thebcrm47xxdirectory doesn't have wireless support; it helpfully contains a file calledNO-BROADCOM-WIRELESSto warn you off, but unhelpfully doesn't include any additional information in that file (like what exactly is broken or that you can find a working firmware in a sibling directory) ... oh well. - The firmware file that you want is
openwrt-wrt54g-squashfs.bin, even though it doesn't match the model number of the router. This directory could use a README file explaining which hardware is supported by each of the dozen or so firmware files it contains.
Step 2: install the firmware
After Step 1, this was a real relief. I just used the built-in Linksys firmware installer, pointed it at the .bin file, and it went.
Step 3: configure the router
The installation guide I followed was pretty much silent about what to do after I got the firmware on. Luckily, this is just a software problem, meaning it's much more familiar territory for me.
First things first: I checked that I could still get a DHCP lease. It worked.
Armed with that, I tried telneting to the router. I used the resulting root prompt to set a password on the root account.
I logged out and tried telneting in. Apparently the router is configured to disallow root logins over telnet if you don't have a password. Good for them (although why allow telnet at all?); oops for me.
Luckily, an ssh server was installed by default. I like using keys to log in, so I tracked down the documentation on configuring the server to use public-key authentication; it turns out there's a single global key file named
/etc/dropbear/authorized_keysthat's exactly like OpenSSH's per-userauthorized_keysfile. No idea what would happen if I had multiple users, but I won't.The next obstacle: I didn't have an Internet connection. For some reason, my cable modem didn't want to give the router a DHCP lease. On the off-chance that it was remembering too much, I rebooted it and ran
ifup wan. That fixed the problem. I still don't know why.Not a step, but a useful note: in the process of figuring the above out, I found
readlog. It's basicallydmesg for syslog files
; it shows the most recent lines written to syslog. This is useful because there isn't a real syslog file, due to the fact that there would be no room to store it on the 54GL.Finally, I had to get wireless working. The documentation is very helpful when it comes to describing the syntax of the wireless configuration. Unfortunately, I read the list of encryption options and missed the section right below where their meanings are explained (although, to be honest, I might not have understood the implications of the explanation without the research I did anyway).
option encryption none, wep, psk, psk2, wpa, wpa2
I wanted WPA2 encryption, so I entered
. And nothing worked. After a good hour of trying different options on the client, swapping software components in and out on the router, experimenting with the encryption key syntax, and crawling Google, I finally found my answer. If you just want WPA2 encryption, you must not usewpa2
as the encryption type. Instead, usewpa2
. It turns out out thatpsk2wpa2actually meansuse WPA2 and also use an external RADIUS server for authentication
.psk2is the system you're familiar with from a typical consumer wireless router.
Step 4: enjoy
And with that, it works.
Unfortunately, contrary to what I wrote here originally, my Roku still
doesn't work. On the other hand, having a real Linux installation is
helpful for debugging it. Currently my suspicion is that the router
isn't passing multicast packets between the wired and wireless
interfaces (broadcast works fine, multicast doesn't). That said, it
seems like if I restart Firefly just before I start playing music, I
can play reasonably reliably -- as long as I don't stop, because if I
do, the Roku forgets
that the music server is there. Either
way, I've spent about as much time fighting this as I can afford. 
One lingering worry I have is security; unlike Debian, which has both
a security mailing list and tools to inform me when I need to install
a security update, the OpenWRT firmware doesn't seem to have any
mechanism for distributing security notices. True, there is an
openwrt-security-announce list, but it
appears to be entirely unused, as is openwrt-announce. Something to
keep an eye on, then.
Also (file under note to self
), I need to remember to verify
that the router isn't exposing services to the outside world. The
default iptables configuration is hideously complex; with just a
quick glance, it could be setting up a floral shop for all I can tell.
I'll need to test this empirically and maybe analyze the rules in more
depth.