skippy dot net

For the last umpteen years I've been using a Linksys WRT54G (hardware version 2.2) wireless router. I've used OpenWRT, dd-wrt, and most recently Tomato custom firmware images to allow me to do things that the stock firmware didn't fully support. Through all of these permutations I've always had an open wireless network, both because I've always felt it's a pain to type in passphrases on client devices and because I think it's important to provide wireless access to neighbors in need. To date, no one has egregiously abused the wireless access I've made available to them.

But the WRT54G is getting long in the tooth. I have a couple of devices that can speak Wireless N, as well as a couple of gigabit capable devices. The WRT54G is limited to Wireless G and 10/100 Ethernet ports. I've also had a desire of late to split off our personal network traffic from that which I make available to my neighbors, so I've been looking at wireless routers that support a so-called "guest network" option. Finally, the WRT54G sometimes simply flakes out, and requires a power cycle in order to work properly. That's usually not a big deal, but it can be a real pain during the middle of a movie we're streaming from Amazon.

Today I bought a Linksys E3200. It has most of the features I want: A/B/G/N wireless support, 10/100/1000 Ethernet, and a guest network. It has support for Dyn dynamic DNS, a service on which I rely; though it sadly does not support DNS-O-Matic.

Setup was easy, and I was able to get everything configured without any real hassle. It wasn't until I was all finished that I noticed no local domain name was being supplied to clients. Indeed, there are no local DNS controls anywhere inside the E3200 configuration pages (that I could find) which means that none of my local clients could address one another by name. This meant my Sonos couldn't find my NAS to stream music, and the Mac connected to my TV couldn't find the NAS to stream movies.

With the WRT54G -- through all the custom firmwares I used -- I had a local caching DNS resolver that was able to arbitrate local client names. I used skippy.lan as my local domain name, and have come to rely on foo.skippy.lan being a resolvable address.

The workaround for this problem was to install and configure DNSmasq onto my Pogoplug NAS, and then to configure the E3200 to tell clients to use the Pogoplug as their primary DNS server. This somewhat defeats the purpose of the E3200, because it means that my network is now dependent on two devices for full (internal) functionality. It also places just a little more load on the Pogoplug, a device with extremely limited resources that I'm trying to maximize.

After a couple hours of use, the E3200 works as expected, so I'm moderately satisfied with it. I may try to flash a custom firmware onto it in the future, but for now I'm just going to stick with the stock image and see what happens.

I've been using OpenWRT for several years now, and have been quite pleased. It was easy to use, functional enough for my needs, and very stable. I know some folks report stability problems with OpenWRT, but I never had any problems. My installation was so stable that I hadn't flashed a newer version for several years: it Just Worked.

Until this week, that is. The router -- a Linksys WRT54G version 2.2 -- locked up the other night. No big deal: power cycle it, wait a bit, and we're back in action. Then it locked up again last night. I do not want to get into the habit of daily power cycles, and I had a growing interest in limiting my neighbor's use of my router, so I thought I'd upgrade to a different firmware. I'd heard good things about tomato, so decided to give that a shot.

I was unable to flash the tomato firmware onto my router using the OpenWRT web interface: OpenWRT complained that the firmware I uploaded was not a supported format. After a couple of tries, I finally got the TFTP transfer to work. Moments later I was logged into the tomato configuration screen and setting up my network.

Wow! The tomato interface is great: easy access to all the things I'll want to tweak, and then some. The bandwidth monitoring is interesting, and I was frankly surprised that my little router would be able to produce such great information. I quickly set up static DHCP addresses for the various devices in our house, defined the necessary port forwarding so that I can access internal machines from the outside world, and set up DNS-O-Matic and OpenDNS dynamic DNS updates. All in all, it took me less than 30 minutes to get everything (and more!) set up as I had it with OpenWRT. For comparison, configuring OpenWRT was a process that took considerably more effort, spread out over a couple of days.

Since I got my first wireless router, I've run open networks. I don't like to bother with WEP or WPA when I'm at home, and I don't mind providing WiFi access to neighbors in a pinch. So far, no one has really abused this: I've never had a bandwidth shortage as a result of a neighbor leeching my signal, and I've never received calls from law enforcement about illegal downloads from my IP addresses. The latter is something about which I don't worry at all, but the former is something of a concern. With OpenWRT, I had no easy way to ensure that I got first dibs on all my bandwidth, and any nearby guests got enough signal to be able to access the Internet without getting so much signal as to live off of it forever.

I don't want to require static assignments for all clients, because I want friends and family visiting to be able to easily use my WiFi from their smartphones or laptops or netbooks without me having to record their MAC addresses.

The tomato firmware has fairly simple QoS controls, so hopefully I can configure the network to prioritize all of my static DHCP clients, and give (much) lower priority to all dynamic DHCP clients. I don't want to become a QoS expert, and the tomato controls are nice, but not great, so this may be a work in progress. In the worst case scenario, I'm no worse off than I was with OpenWRT, so I can't really complain too much.

All in all, I'm very impressed with tomato. I don't know why I waited so long to upgrade!

My home network consists of two Linksys WRT54G wireless routers, a Linksys NSLU2 network storage device, a Mac Mini running MythTV, and laptops for each member of the house. All but one of these devices use 802.11 wireless networking.

One of the WRT54G routers lives in my bedroom, connected to the DSL modem there. This router runs the wonderful OpenWRT firmware, providing me a good old fashioned Linux command line with which to administer the router. I use iptables rules to enact network address translation, allowing all the computers in my house to have access to the internet.

The NSLU2 is the only device in my network that lacks built-in wireless networking. I could purchase a USB wireless adapter, but these aren't as cheap as I'd like, and the NSLU2 only has two USB ports, both of which I would prefer to use to connect to USB hard drives (though currently only one is in use). The NSLU2 instead connects to my other WRT54G, which in turn is running the dd-wrt firmware. This router acts solely as a wireless bridge, allowing wired-only devices to access my network and the internet, and provides no other services. I run Debian on the NSLU2, giving me a fully featured operating system on an itty bitty platform.

All of these Linksys products run Linux, and can be classified as "embedded systems" because they have very specific limitations with respect to storage and memory. As such, certain tradeoffs need to be made. The WRT54G routers have 16 and 8 megabytes of RAM, respectively, and they run the entire system in memory so there's no room left for extraneous services or wasted space. The routers, for example, all use Busybox to provide basic UNIX utilities without using a lot of space. The default installation of OpenWRT provides the Dropbear SSH daemon, which is a substantially smaller package than the more traditional OpenSSH. Dropbear works great, though, and provides everything I need to connect to and administer the routers.

The NSLU2 isn't as limited when it comes to storage, since I can (and do) use a USB hard drive to store an entire Debian installation; and it has (by comparison) a whopping 32 megabytes of RAM. Still, I need to be careful about memory usage so as not to cause the system to thrash swap space or have the kernel OOM killer forcibly terminate services. Taking a cue from the OpenWRT installation, I replaced the standard OpenSSH server on the NSLU2 with Dropbear, in order to free up more RAM. I also installed dash instead of bash as my primary shell, in order to eek out a little extra memory. dash lacks all of the handy features I like from bash, but I use the NSLU2 for pretty specific backup purposes so I don't miss the features all that much. I disabled all the unnecessary (for my use) services, like nfs-common, portmap, openbsd-inetd, etc. I replaced Exim4 with SSMTP. Finally, I installed thttpd. My intent with this is to use the NSLU2 to store large media files I might like to link from my blog without having to worry about bandwidth usage on my blog's server: serving the files from my home DSL line has no bandwidth cap, whereas the VPS hosting my blog does have a bandwidth cap.

For the past little while I've been contemplating OpenVPN on one or more device in my network. I find myself growing more and more uncomfortable using unencrypted wireless networks at coffee shops and hotels, and would like to be able to tunnel my connections through a secured channel to a host under my control. I've had tremendous success with OpenVPN at my previous job, and I advocate it all the time to people looking for VPN solutions. Its set up, while not hard, is non-trivial, and truthfully I worried about the resource drain the OpenVPN daemon might put on my limited resource Linksys devices.

During a conversation with Matt in #habari, I provided the link to using SSH as a SOCKS proxy. Duh! There was the answer I was looking for! So last night, I installed the full-blown OpenSSH daemon onto one of my WRT54G routers. I configured it to listen on TCP port 443, so that it wouldn't interfere with the currently running dropbear (should something have gone wrong, I still wanted to be able to access the system!) and because the proxied traffic will largely look like requests to an HTTPS website to the casual eye (and most firewalls). The two applications I most frequently use (Firefox and XChat) both support SOCKS proxies, so I was quickly in business. I defined the SOCKS proxy in XChat, established an ssh connection to the router, and watched as XChat reported

* Looking up irc.freenode.net
* Looking up localhost
* Connecting to localhost (127.0.0.1) port 2600...
* Connected. Now logging in...

I installed the FoxyProxy Firefox extension, and added my localhost proxy to its configuration. It was hard to test with certainty from home, but this morning at work there was no doubt: after selecting the localhost proxy from the FoxyProxy menu, I visited WhatIsMyIP and saw my home IP address displayed! Success!

Not every application I'll ever use supports SOCKS, so this might not be as robust a long-term solution as OpenVPN would have been, but it allows me to minimize the number of running services while re-using familiar applications.

I've been running OpenWRT on my Linksys WRT54G for quite some time now. It's one of those things you configure and then forget about. From a functionality standpoint, I have no complaints: I've never had to twiddle the configuration, or fuss with the device. When I do want to fiddle with the system, though, I always found it tedious: it's not a full-blown GNU/Linux system, but its close enough to always make me forget.

I found out today that the latest release of the OpenWRT firmware, Kamikaze 7.07 is now available for download. With Carina and the twins off shopping for school, I decided this was the perfect opportunity to upgrade without interrupting anything.

The upgrade was painless: I uploaded the new firmware using the web-based control panel, and waited as it rebooted. When the DMZ light went out on my router, I knew the upgrade was complete. I unplugged the Ethernet cable, and then re-connected it, after which my laptop got a new IP address. By default ssh is disabled, so I had to telnet into the unit. As soon as you provide a root password, telnet gets disabled and ssh gets enabled.

The entire configuration system has been modified in this latest firmware. All configuration items go in /etc/config/, a perfectly sane and GNU/Linux-friendly location. Setting the LAN, WAN, and wireless options was extremely easy and self-documenting this time. No more fussing around with nvram commands, and no more referring back to the OpenWRT wiki for details. Setting up port-forwarding so that I can ssh into my NSLU2 from outside of the house was a single directive. All in all, this is a marked improvement on an already superb product!