The default Linksys firmware is actually not bad, but dd-wrt just offers a ton more features: Multiple SSIDs, IPv6 support (including Sixxs tunneling), WAN volume monitoring, custom firewalling, traffic shaping, … So I decided to void my warranty and put my router on steroids! Mandatory note: this may very well turn your router in to a very expensive brick.

The initial flash

After reading through the dd-wrt forum (most notably these three posts) and the wiki page, I learned a few things:

• Apparently, this router has its reset button wired to the wrong GPIO pin. Therefor, the 30/30/30 reset DOES NOT WORK on this router! There is an alternative: use at least version 13493, power down the router, push and hold the WPS button (on top), power up the router, hold the WPS button for 10-12 more seconds, then release.
• The latest recommended firmware is BrainSlayer’s 14929

This is the procedure I followed, with success, starting from Linksys version v1.0.03 (build 010Jul 24, 2009):

1. Download the tailored build for the WRT320N (for the freaks, my binary MD5s to e1d7edd368bf5259c18a0874c5e761db).
2. Connect via wired ethernet to the router. That way, you can see the link going up/down.
3. In the Linksys firmware, upload this file.
4. Wait 5 very long minutes.
5. Configure yourself a static IP in the 192.168.0.0/24 network (I use 192.168.0.8)
6. Direct your browser to http://192.168.0.1/
7. Set a temporary password
8. Wait 1 minute
9. Reset the router: Power down, push & hold WPS button, power up, keep holding for 11 seconds, release.
10. Close & reopen your browser to flush all cached pages and credentials
11. Direct your browser to http://192.168.0.1/
12. Enjoy

The upgrade

After the initial flash, you can upgrade to any regular version, but keep in mind that this unit requires a 2.6 kernel. I choose the 14929-mini version (md5 af9ab2ff822ab69d26fa7308d47ad05a), not because it provided all I need (it doesn’t support IPv6 for example), but because it leaves the most free space for me to fiddle with.

To switch versions, I always follow this overly cautious procedure:

1. Reset to defaults: power down, push & hold WPS button, power up, keep holding for 11 seconds, release
2. Make sure your IP is in the correct range (192.168.0.0/24)
3. Set a temporary password
4. Upload the new firmware
5. Wait until the browser is again at the “Set password” page
6. Set temporary password
7. Reset to defaults again

The settings

Most configuration is fairly straightforward with the GUI. But setting up a second, routed SSID needed a little non-intuitive work:

• Go to Wireless -> Basic Settings and add a new Virtual Interface
  • Leave Network Configuration to Bridged
• Go to Setup -> Networking
  • Under Create Bridge, click Add
  • Name the new bridge “br1″ and disable STP
  • Apply Settings
  • Now add the desired IP and Subnet mask for this brigde-port
  • Apply Settings again
  • Click Add under Assign to bridge
  • Now assign the wl0.1 interface to this newly created bridge br1
• Optionally Add a DHCP range for br1. In this case, you need to use DNSmasq as DHCP-server.

Some guides tell you to configure it in Unbridged mode. Using Bridged mode gives the potential advantage that you can link a wired port to this IP-range easily.

Now you can easily firewall between the two WLANs by putting iptables-lines in the startup script.

In every network setup with some level of security, there are hosts that can’t be reached directly. Instead, you need to connect to some intermediate machine first, and hop further from there. If you have set up public key authentication, SSH can do all of this for you in the background, just add a few config lines to .ssh/config:

Host IP.or.fqdn.only.reachable.from.intermediate-host
ProxyCommand ssh intermediate-host nc %h %p

This will issue an SSH connection to intermediate host, launch a netcat process to realize the hop, and connect to your unreachable host. Obviously, netcat or similar is required on intermediate-host.

When using SSH in a script, most pages tell you to use public keys. While this is an excellent idea, it’s sometimes just not possible due to policy. This Expect script fakes a regular username-password login

#!/usr/bin/expect -f

set target [lindex $argv 0]
set password [lindex $argv 1]
set command [lindex $argv 2]

spawn ssh $target $command

match_max 100000
# Look for passwod prompt
expect “*?assword:*”
# Send password aka $password
send — “$password\r”
# send blank line (\r) to make sure we get back to gui
send — “\r”
expect eof

This script can be run like this:

./ssh-passwd.ex root@192.0.2.1 password “ls /root”

However, “ssh://” is not a standard registered protocol. I’d like Putty to handle this. Also, “telnet://” gets you the standard windows telnet client instead of putty. Putty can be called with command line arguments. Supplying the “telnet://” url as a parameter works, but “ssh://” does not.

Hence, I wrote a very small wrapper program to accept “ssh://” URL’s and convert them to Putty command line arguments:

• Source code in C: ssh-to-putty.c
• Compiled Windows executable: ssh-to-putty.exe
• Registry commands to set putty as telnet-handler: putty telnet url handler.reg
• Registry commands to set the wrapper as ssh-handler: putty ssh url handler.reg

Some notes:

• The registry commands assume Putty and the wrapper are installed in C:\Progs\SSH. If this is not the case, you need to change the .reg-files accordingly
• The wrapper-program assumes putty.exe to be in the same directory as itself

Besides the standard password authentication, ssh also supports public key authentication. This key-based authentication has the added bonus of having per-key options:

• you can restrict the source IP from which this key may be used
• you can force a command to be executed instead of allowing the connecting side to specify one

Combining the power of these tools gives very fine grained control over the rsync process: you can create a “backup key” that only allows you to rsync from the server and only from a specified directory. Any other command besides rsync is rejected; rsync to the server or from another directory is also rejected. This script does it all, it’s part of the rsync package, but not installed by most distro’s. An example authorized_keys entry (with an abbreviated key):

command="/home/boss/niels/bin/rrsync.pl -ro /home" ssh-rsa AAAAB[...]fE+8QrME= 20090329 rsync key

On my desktop system, this was automatically secure against theft. Since the key is stored in RAM (or encrypted swap), it is flushed the moment the computer looses power. Since it was a desktop system, it’s fairly safe to assume that the power will be cut when someone steels my computer.

On my new MacBook Pro, things are a bit different: most of the time, my notebook is in standby and has an integrated UPS (its battery). So I was looking for something to get me the same security.

Surfing around got me to this very interesting page describing the integration of an ssh-agent into Leopard. I must admit that I was fairly impressed: It automatically starts ssh-agent on-demand and reads in all identities using the standard Mac KeyChains. One thing however was missing: removing the keys when the notebook enters standby.

The follow-up article mentions one way to do it, but I found that SleepWatcher is a much more versatile way to do this. SleepWatcher can do other things as well, like unmounting (ejecting) external drives when going to sleep, remounting them when waking up again.

At work, using my Windows laptop, I have been looking for a feature like this. After some googling I found PuttyCS. It’s a standalone application which emulates this behaviour: It sends emulated keypresses to all (or a subset of) open putty sessions.

Configuring 8 blade-switches with PuttyCS is a breeze: just open all the putty sessions and start typing in PuttyCS!