DD-WRT

Okay, so I very much misunderstood what DD-WRT does and is. I thought I'd heard that it was a linux distro for the WRT54G, whereas Tomato is a replacement GUI, both of which offered more functionality than the stock firmware. As it turns out, they're both replacement firmwares that offer more features through a GUI; CLI interface doesn't come into play for either of them.

Breaking it down, DD-WRT offers more slightly functionality, Tomato offers cleaner functionality, and better reporting. DD-WRT installs onto more versions of hardware. Tomato is AJAX-y, and restarts services; DD-WRT is Web1.0, and restarts to catch new settings.

Dunno. I'm now running both in the house, as I have a router that won't take Tomato. Both get the job done, and both seem stable. If you don't need the extra functions in DD-WRT, and Tomato will install on your hardware, I'd say go that way.

Tomato Router, WRT54G

So, Linksys makes a lot of little blue boxes. One of them, the NSLU2/Slug, I talked about here before; it's a cigarette-pack sized solid state box with two USB ports and a 10/100bT NIC. It has Linux on it, which you can replace with a fairly stock Debian install, and off you go with anything involving Linux with USB; external drives, printers, and so on.

The WRT54G is Linksys's regular wireless router, and costs about $40. It has four 10/100bT ports, and (obviously) a wireless networking card built in, and you can replace the firmware with a fairly stock installation of Linux, DD-WRT. DD-WRT gives you a ssh/terminal login, and a lot more functionality in the router; it becomes something akin to a slightly underpowered $600 machine, instead of the $40 you dropped for it.

I've avoided DD-WRT, mainly because the stock firmware has always done enough for me, and having another Linux box around seems like an administrative hassle. But then, while wading through docs to install Apple's WDS to a Linksys primary router, I stumbled on Tomato. Tomato has most of the core functionality enhancements from DD-WRT, but is almost entirely done in a HTTP GUI. The GUI is easy, and does a wonderful job of showing me what the router is doing, who's connected, how much bandwidth is being used, and so on. It also has huge updates from the stock firmware involving QoS routing, DDNS, access restriction, and pretty much all of the other heavierweight routing tasks you expect from Linux.

A+++. Twenty second installation, two minute learning curve, and a much wider range of tools should I need them.

Weave, WebDAV

So, Mozilla Weave is a very Alpha project. It's intent is to sync a bunch of your applications settings and data across multiple machines, via a backend WebDAV server. Currently, it replaces the functionality of Google Reader for Firefox, and seems to be more secure. (Your data is encrypted locally, and the files on the server are provably encrypted/secure at all times.)

However, the backend WebDAV server that Mozilla is running isn't that good. They do let you pick your own WebDAV server, so I decided to put one together. I shouldn't need to back it up; if the central server dies, I'll still have the data on two or more endpoint computers.

WebDAV works on Apache 2. It doesn't work on the (perhaps still more common) Apaache 1.3. Using the NSLU2, follow these instructions to install Apache 2 and Webdav. Debian/NSLU2 still isn't supporting Digest Authentication, but for something of this scope, Basic Auth should be just fine. (The encryption of passwords is more secure with Digest.) These instructions explain basic auth. (Edit: mod auth-digest seems to also cause problems with a limited amount of entopy on the NSLU2. This tutorial gets around it, but doesn't properly update the runlevel, documented over here.)

Meanwhile, the Ubuntu folks have an SSL wiki, which is the reference to use to enable SSL in Apache 2. This was very useful, as the "apache2-ssl-certificate" referenced by every other site was deprecated and removed from Debian/Ubuntu awhile back. For my configuration, I also had to specify the ServerName attribute in httpd.conf, explicitly give the www-data user ownership of the SSL cert, and add Listen 443 to ports.conf.

After that, using Cadaver as a client, WebDAV works just fine. Unfortunately, it appears that the current client for Weave also has some issues, so I'm putting this on hold for a few days, while making the Charlie Brown "arggggh" noise.

SSH Problems

So, I've written about automatically logging in with stored ssh keys and also about the Linksys NSLU2 Slug with Debian. Today, the combination of the two are important, as CERT alerted me to a new security hole in Debian and Ubuntu, and the fix for it.

When an SSH key is created, it generates a random number, and then builds the key based on that number. The problem is that the random number generator in Debian wasn't producing completely random numbers, and that meant the secure keys aren't completely random, and aren't completely secure. Ubuntu is based on Debian, so this applies there as well.

Anyways, the fix is simple enough; update the machine, and re-generate your keys.

The NSLU2 Slug

One of the reasons I wanted to start writing something down about my experiences with tech is the Linksys NSLU2, otherwise known as the Slug.

It's about the size of a deck of cards, draws 10w of power from the wall, and has two USB 2.0 ports and one 10/100bT networking jack. As shipped, it shares drives connected to those USB ports as if it were a Windows machine. This isn't bad, but feels a bit thin for the $85 it costs.

Enter the good folks at NSLU2-linux.org. As it turns out, this is a 266 MHz ARM processor with 32 MB of RAM... which is more than enough to run Linux.

Following the directions provided by the amazing Martin Michlmayr, you need a 1 gig or better external flash memory stick, and optionally, an external USB hard drive.

Flash the unsupported installer image onto the slug. SSH into the box. Install the five packages Michlmayr mentions. You now have a running version of Debian Linux up and running. This takes between an an hour and an afternoon, and should be doable with minimal admin skills.


So, there were a few updates worth making to the slug right away. Opening the case and using this simple hardware kludge to overclock the box from 133 to 266 MHz was trivial, only took a pair of fingernail clippers or an exacto knife, and doubled the speed of every other step.

It's worth looking at are the additional instructions on reducing Debian's memory usage.

If you installed to a flash drive and not a hard disk, you can look into ways to reduce the drive usage. Especially worthwhile is moving the swap partition off of the flash drive, and onto an external hard drive, if possible. Basically, flash media only gets a limited number of writes, and after that, that sector of the drive is permanently dead. Since swap space may be written to many, many times, it's the prime candidate for burning out the flash media.

Additionally, there are ways to make the box automatically upgrade itself every night.

As a side note, if your connections regularly die, the slug includes a small magnet that wraps around the Ethernet cable, to cut down interference. I'm assuming the size of the slug prevents them from building this into the unit. That said, without this magnet, my connections died fairly regularly. With this magnet, connections are stable for days.


I should have started with the most important detail, though. Why would you want Linux on this piece of hardware?

• My slug at home still runs as a drive server, but it can now use USB hubs to have more than two drives connected.
  
• Instead of just having Windows file sharing (Samba), it also supports AFS (Apple) and NFS (Unix/Linux).
  
• MT-DAAPD, which lets other computers in the house running iTunes see the slug as if it were running iTunes as well, and shares out the music on the external drive.
  
• rTorrent, a full-feature text-based Bittorrent client. Here's a link on autostarting it, and how to add an script to Linux to run on boot.
  
• OpenVPN, to allow VPN networking from anywhere back to my house. Including securely tunneling traffic from an iPhone over unsecured wireless networks.
  
• SSH tunnel endpoint, securely transmitting my chat and web requests from my public desk at work to my relatively private connection at home. Browsers and chat clients support this pretty easily as a SOCKSv4 proxy.
  
• DynDNS client, in order to report back it's public IP address to my DNS server, so that I can access it by name from anywhere.
• Apache, to serve static webpages (and MT-DAAPD).

And, what *doesn't* it do?

• It doesn't have enough power to run a database application well.
• Due to that, it doesn't work as a dynamic webserver.
• It won't even run Ruby on Rails with SQLite, actually. It's tiny.
• It didn't support a Squeezebox server.
• MT-DAAPD (above) will choke if you give it too large of an MP3 library.

There are ways to add memory to the box, but at that point, you're into fairly serious hardware tinkering. (ie, a soldering iron) That was too far for me, so I stopped with the overclocking modifications.

All in all, A+. I've actually bought a second one to leave at another location, for when my home connection is down.