Back in 2011 I switched ISPs to A&A, primarily because they support native IPv6. Incidentally, 3 years on I see that you still can’t get IPv6 from Zen, so I made the right choice by switching.
Windows has had IPv6 support included by default since 2006 (i.e. Vista onwards), so the missing piece of the puzzle was my wireless router (a Linksys WRT320N). Unfortunately, the built-in firmware doesn’t support IPv6. (Source: Linksys devices that support IPv6.)
So, I investigated open source alternatives. There are a few different firmware projects out there, which all seem to be based on Linux. According to the OpenWRT wiki, it isn’t supported on the WRT320N. However, the WRT320N is listed in the dd-wrt router database, so I chose that instead. JP Hellemons wrote about this in 2010 (How I upgraded my Linksys WRT320N to DD-WRT v24); he also checked Tomato and HyperWRT, and neither of those were compatible. However, apparently the NoUSB edition of Tomato USB does support the WRT320N.
Update (2019-03-15): OpenWRT does now claim to support the WRT320N, although they don’t recommend it. Meanwhile, the Tomato USB website is now inactive, because the developer has ceased work on that distribution.
Just to forewarn anyone else who’s in a similar position, this isn’t a simple process. Here’s a good (valid) rant about how complex it is. I heard a good phrase a while ago: “Open source software is only free if your time is worthless.” I.e. if you assume that your time is valuable, consider how long it will take you to get a system working. Is it worth paying money to save yourself some time? For instance, in this case I could replace my router with a different model that has IPv6 support built in. (You will still need to invest some time in learning any system, but maybe you could reduce that from a day to an hour.)
In brief, I (eventually) got the router working fine with dd-wrt over IPv4. IPv6 took a bit longer; I’ve elaborated on that in another post (Native IPv6 in dd-wrt).
The first step is to choose which version(s) to download and install. In fact, this involves a series of questions.
Digressing for a moment, there were 6 editions of Windows 7:
- Starter
- Home Basic
- Home Premium
- Professional
- Ultimate
- Enterprise
Some people criticised Microsoft for making it all far too complicated (e.g. this Joy of Tech comic for Vista), so that’s probably why they reduced it to 4 options for Windows 8 and 8.1:
- Windows RT 8.1
- Windows 8.1
- Windows 8.1 Pro
- Windows 8.1 Enterprise
The RT edition only comes pre-installed (e.g. on a tablet) and the Enterprise edition is only available through volume licensing, so in practical terms that reduces it to 2 options for anyone who’s buying a desktop/laptop for home use. Personally, I think it was a bad idea to have an option that’s simply called “Windows 8” or “Windows 8.1”, because that can cause confusion between the specific edition and the product family, but it’s still fairly simple to get to grips with.
By contrast, there are 31 options for dd-wrt! According to the router database, the WRT320N has a Broadcom chipset (specifically the BCM4717A). Looking at the wiki, there are 2 kernel versions available: 2.4 and 2.6. There are 18 dd-wrt types for kernel version 2.4, and 13 dd-wrt types for kernel version 2.6. Confusingly, these are all called “V24_pre_sp2”, and they’ve been called that for at least 3 years; I’m not sure if/when SP2 will be released. However, there are various build numbers.
So, that means that I initially had to answer 3 questions:
- Which kernel version do I want?
- Which build number do I want?
- Which dd-wrt type do I want?
Aside from the wiki, you need to refer to the forum. In particular, start with the Peacock post. (It has nothing to do with peacocks; that name was just chosen so that it would be easy to search for it. Unfortunately, searching the forum for “peacock” now returns almost 7000 results, and that post isn’t even on the first page. I assume that this is because other people keep saying “Check the peacock post for details.”)
Anyway, the router database says that the WRT320N is supported by builds 21061 (released on 2013-04-19) and 14896 (released on 2010-08-09). If I choose either entry from the drop-down list, it gives me a short list of files. All those files have “K2.6” in the name, which implies that my router supports kernel version 2.6.
NB The files for build 14896 have “NEWD” in the description, whereas the files for build 21061 don’t. However, the files for both builds all have “NEWD-2” in the filename. According to the wiki, NEWD means “NEW Driver” (intended for a relatively modern router), as opposed to “VINTage” files (intended for older routers). Various forum posts make a further distinction between “NEWD” (for kernel version 2.4) and “NEWD-2” (for kernel version 2.6).
The peacock post then says:
“DON’T USE THE ROUTER DATABASE! The router database has recommended some less stable builds, including SP1 and 13064 (10/10/09) build. I suggest using the builds that are recommended here or in Redhawk’s announcement above, rather than the ones in the router database. SP1 is full of bugs, and while 13064 is not nearly as bad, some are reporting connection issues fairly regularly. Sometimes the router database also has had the wrong build type. The router database is being worked on improve the recommendations but it still contains errors and bad builds. Do not skip over reading the install wiki for your router just because you got the files from the router database. You need to KNOW what to do with those files. The wiki usually has the right builds for particular routers. READ THE WIKI!“
“Redhawk’s announcement above” isn’t included in the peacock post. I think that at one point it was a “sticky” (pinned) post, so it would show up higher in the list when you looked at the forum. However, it’s now been unpinned. There’s a separate post called Stickies of the past – that were retired back to the forum. (This is actually below the peacock post, but never mind.) That post has a list of other posts, including Firmware Recommendations – Still 14929 – 09/15/13 (posted by “redhawk0”). So, I think that this is the announcement which the peacock post referred to. As the name suggests, they recommend build 14929.
The redhawk0 post also says:
“We are very aware of the confusion users have finding builds. The Database was intended to simplify the process but “NewMedia-NET GmbH” has done a poor job of maintaining the Database. We forum moderators have already brought it to their attention long ago and they have begun asking for our feedback before uploading new builds to the Database. For the time being there are still bad builds in the Database and it is still recommended by the forum moderators to use our recommended builds in this thread. When all the kinks are worked out of the organizational process to select builds for the Database then this thread may go away.”
Since the thread is no longer sticky, does that mean that it’s gone away? I.e. is the advice no longer up to date? Or is the advice still current, and it’s just been moved to a list to avoid overwhelming the first page of the forum? It’s certainly not obvious, and this isn’t a great start… I spent hours (spread across days) reading through various threads on the forum so that I could understand the issues. There are dire warnings about “bricking” your device if you install the wrong firmware version. This means that the device completely stops working, and you can’t even install a different version to get it working again, so you can only use it as a novelty paperweight (i.e. it has effectively turned into a brick). There are ways to recover a bricked device, but you need special equipment.
Going back to the wiki, there’s a page for the WRT320N. That says:
“Linksys WRT320N is now supported – please use only special _wrt320n.bin builds (based on kernel 2.6).”
So, the router database and the wiki do at least both agree that the WRT320N supports version 2.6 of the kernel, and I can confirm that from my own subsequent testing. However, you might notice that none of the filenames in the router database ended in “_wrt320n.bin”. This is because you need 2 files to install dd-wrt. Firstly, you need a “trailed build” which is specific to your router. These aren’t released for every build, so you then need a non-trailed build (which works with any router) to upgrade to the version that you actually want. Aside from that, the wiki is fairly flexible about build numbers, and simply says: “It is advised to use build 13493 or later”.
When I looked at this in 2011, the router database only recommended build 14896 (since build 21061 hadn’t been released yet), so that’s the one I went for.
Based on that, I can move onto the third question: which dd-wrt type do I want? Looking at the feature table on the wiki, kernel version 2.6 gives me 13 options, and since I want IPv6 that narrows the choices down to 6.
So, these 6 types support IPv6:
- STD NoKaid Small
- STD USB NAS
- VOIP
- Big
- Mega
- (Giga)
I think that Giga is in brackets because it hasn’t been released yet. Someone speculated on the forum that this file would be bigger than 8 MB. According to the router database, the WRT320N has 8 MB of flash memory, so the Giga build would be too big for my router to handle.
Anyway, cross-referencing that list with the downloads that are available for my router in build 14896, I have 3 choices:
- NEWD K2.6 Big Generic (6.82 MB)
- NEWD K2.6 Standard-USB-FTP Generic (4.77 MB)
- NEWD K2.6 VoIP Generic (3.97 MB)
I’ve included the file sizes just to confirm that they’re all small enough to fit on my router, i.e. they’re all less than 8 MB. Based on that, VOIP seemed like the best choice for me. It’s the smallest file, and hopefully has a reduced attack surface (by excluding features that I don’t need). Another advantage of a smaller file is that it gives me more space for other files; this is particularly relevant if you use JFFS (Journalling Flash File System) to install extra tools later. I don’t know why the router database doesn’t list the other types for this build, but I’ll err on the side of caution by just picking a type from this subset.
So, I downloaded 2 files:
- dd-wrt.v24-14471_NEWD-2_K2.6_mini_wrt320n.bin (trailed build)
- dd-wrt.v24-14896_NEWD-2_K2.6_voip.bin (non-trailed build)
(The trailed build is linked from the wiki page for the WRT320N; if you have a different model, you should go to that model’s wiki page instead.)
I made a note of my current router settings (in the Linksys firmware), since I would need to re-enter them later. Specifically:
- Internet connection (PPPoE, username, password)
- Local IP address and DHCP server configuration
- Wireless network (SSID, security level, passphrase)
- Port forwarding
I then unplugged the patch cable between the WRT320N router (Internet port) and the VDSL modem, and plugged a laptop into one of the 4 Ethernet ports.
NB According to JP Hellemons’ post, you have to make sure that there’s only a single network cable plugged in, otherwise the process won’t work. I haven’t verified it myself, but since nobody will be able to use the router while you wipe/reinstall it, there’s no harm in doing things this way.
I restored the Linksys firmware to factory settings (Administration | Factory Defaults), turned it off, waited for a minute, then turned it back on. After that, I had to log in with the default credentials (admin/admin) rather than my usual password.
NB The router’s IPv4 address reset itself to 192.168.1.1. Make sure that the laptop is configured as a DHCP client, otherwise you may wind up on the wrong subnet and be unable to communicate.
I then replaced the Linksys firmware with the trailed build (Administration | Firmware Upgrade).
Once I clicked Start to Upgrade the progress bar went up to 98% pretty quickly (in under a minute). It then stayed at 98% for about 40 seconds before it finished, and displayed a “please wait” message. That screen said “a few seconds”, but it actually took 3½ minutes before it loaded the new website. So, you need to be patient!
After that, I entered a new username/password for the admin account. I then went to the status page, and confirmed that it was displaying the correct build number. (In my case, this was 14471.)
Next, I did a hard reset (as described in the wiki), logged back into the router’s website, and upgraded the firmware to the non-trailed build. I checked the status page again, which confirmed that the build was now “DD-WRT v24-sp2 (08/07/10) voip – build 14896”.
I then restored my original settings.
- Local IP address: Setup | Basic Setup, then Network Setup.
- Internet connection: Setup | Basic Setup, then WAN Setup.
- Port forwarding: NAT / QoS | Port Forwarding.
- Wireless network: Wireless | Basic Settings.
I plugged all the original cables back in, and confirmed that it worked ok. So, at this point I was basically back where I started: I could connect a client device to my wireless network and get IPv4 internet access.
By default, the built-in website only supports HTTP, not HTTPS. You can configure this on the Administration | Management page, in the Web Access section. Here are the initial settings:
I checked the Info Site Password Protection box, based on the advice in this blog post: DD-WRT, I Know Where You Live.
As for HTTPS, that’s a bit more complicated. As you’d expect, dd-wrt starts out with a self-issued certificate. That’s normal behaviour, and so it would be up to me to issue a new certificate from a trusted authority. However, the self-issued certificate uses an RSA key which only has 512 bits, and Microsoft no longer accept RSA keys which are smaller than 1024 bits (see security advisory 2661254). Firefox implemented the same policy in version 33. That means that you can’t simply ignore the warning and click through to the website anyway.
Someone changed this in the dd-wrt source code on 2013-09-05 (Changeset 22285) so that it now uses a 1024 bit key instead. I’m not sure which build(s) include this change, but that’s more recent than any of the supported builds that I mentioned earlier, i.e. the new functionality may not be compatible with my model of router.
Also, the website is using SSL 3.0 rather than TLS 1.x. In the wake of POODLE, that is now equivalent to sending the information in plain-text. I found a discussion of this issue in the dd-wrt forum. According to that: “TLS has been supported for long in all builds that come with openssl. But it does not fit in 4MB builds.” Funnily enough, this wasn’t mentioned in the feature table which I used to select the type. In fact, I can’t find anything about that in the wiki.
So, I think I’d need to install new firmware to solve this problem, probably the “Big” build. For now, I’ll just stick to HTTP; since I’m using it on my internal network at home, I’m not too worried about anyone intercepting the traffic, but this obviously isn’t ideal.
Anyway, my general advice in a situation like this is to make gradual changes:
- Start out with HTTP only.
- Enable HTTPS, but keep HTTP enabled.
- Test HTTPS. If it works, disable HTTP; if it doesn’t work, revert back to your previous settings.
That way, if something goes wrong then you won’t lock yourself out.
Finally, I configured SSH, so that I could configure the router through a command line. (As I recall, the original Linksys firmware would only allow you to use a web browser, so this is one advantage of the new firmware.)
Telnet is enabled by default, but you need to use different credentials. More specifically, the username is “root” for telnet/SSH and “admin” for the website, but it’s the same password for both; see the wiki for more info (Telnet/SSH and the command line).
Using the website, I went to Services | Services, then scrolled down the page. By default, telnet is enabled and SSH is disabled.
When you enable SSH, extra options appear:
There are 2 security options here: Password Login and Authorized Keys. The dd-wrt wiki recommends that you disable Password Login, then generate a public key on each machine which needs to use SSH. So, I used PuttyGen to generate a public/private key pair on my laptop.
NB You need to copy and paste the public key from the dialog box. If you click Save Public Key, then open the text file, it’s in a different (incompatible) format.
The dd-wrt wiki also says:
“It is recommended that you don’t secure your key pair with a password, as this will make things easier for you, although somewhat less secure.”
So, this means that the SSH client (e.g. PuTTY) will only prompt you for a username (root) and you don’t have to type in a password. You can also store the username in PuTTY (under ConnectionData), and then you don’t have to type in anything at all.
Just to be clear, the dd-wrt SSH server doesn’t support 2 factor authentication, i.e. you can’t use a public key and a username/password together. Even if you do use a passphrase to access your private key (as the PuTTY author recommends), that happens on your local computer and the server only sees the public key.
Based on my testing, the SSH process goes like this:
- The router looks at the list of authorised keys. If your client has a key in that list, you are logged in as “root”.
- If the list is empty, or you don’t have a key in that list, the router checks whether Password Login is enabled. If so, it will prompt you for a username and password; if not, the connection fails.
So, if you enable Password Login, that’s an alternative to a public key rather than an extra layer of security. However, the dd-wrt wiki says: “please be aware that this method is much less secure! (passwords may be truncated to 8 characters or less)” Since dd-wrt uses the same password for the website, that makes me a bit concerned about allowing http(s) access to the router!
OpenSSH supports multiple levels of authentication (as of version 6.2): you can specify a comma separated list of methods, e.g. to say that people need a public key and a password. OpenBSD includes this, and according to a comment on ServerFault it’s also in RedHat and Ubuntu. However, dd-wrt uses Dropbear as an SSH server rather than OpenSSH. The dd-wrt wiki mentions ways to change this (Sshfs and OpenSSH on R7000) but I haven’t investigated this in detail so I don’t know whether this method would work on my router.
For now, public key authentication is good enough for me, especially since I’m the only person who needs to access my home router and I won’t enable remote access (via the internet). However, in a work environment I’d definitely prefer to have separate accounts (to preserve an audit trail) rather than have everyone sharing the root account.
Once I’d confirmed that SSH was working correctly, I disabled telnet. (This is similar to what I said about HTTP and HTTPS.)