I’ve recently been setting up a new FTP server, and I wanted it to support FTPS. However, I ran into a few problems when I tested it, which turned out to be partly due to the client software I was using. I’ve been using CuteFTP for several years: I registered for version 1.0 back in 2001, and I’ve been using version 8 since 2007. However, I’m now abandoning that in favour of FileZilla.
As I mentioned in a previous post, I installed dd-wrt (kernel 2.6, VOIP, build 14896) on my wireless router (Linksys WRT320N), which connected to a VDSL modem using PPPoE. After that, it worked fine for IPv4, so I had the same functionality as the original Linksys firmware. However, the purpose of the exercise was to get IPv6 support: this turned out to be easier said than done. I was eventually able to get it working, so if you only want the short answer and aren’t interested in all the troubleshooting steps that I went through, scroll down to the Conclusion section at the bottom of this post.
Please refer to my IPv6 router post to get an overview of what I’m trying to achieve here. Most of the documentation that I’ve found assumes that you’re using a tunnel: this is similar to a proxy server, where you have an IPv4 connection to a machine on the internet, then that machine connects to your real destination using IPv6. However, I have native IPv6 connectivity from my ISP.
As I’ve mentioned before, I switched my home ISP to A&A so that I could get IPv6 on my internet connection. That gave me 2 pieces of the puzzle (OS support and internet connection), but I still needed to sort out my network infrastructure, specifically my router. This post says what I’m trying to achieve, and it would apply to any router, regardless of the hardware/software involved. I’ll save the details of how I actually went about it for other posts, which are specific to the particular equipment.
On the client side, this should all be invisible. Someone should be able to turn up with a suitable device (e.g. an iPad or a laptop running Windows) and automatically get IPv6 internet access without having to do anything extra. They may have to type in the key for the wireless network, but that’s the same for IPv4 and IPv6. Similarly, they shouldn’t notice whether they’re accessing a particular site (e.g. Facebook) over IPv4 or IPv6; the only visible difference should be that IPv6-only sites (e.g. Loops of Zen) are now available, whereas they weren’t before. I’ve bought an iPad app to help me with my testing (IPv6 Toolkit) but that’s just a diagnostic tool and you don’t need it to actually use IPv6. In fact, as of IOS 9, it’s a requirement for all iPad apps to support IPv6.
On the router side, I want feature parity between IPv4 and IPv6 (where it makes sense). For instance, NAT (Network Address Translation) is a necessary evil in IPv4 and I’ll be glad to see the back of it, so I don’t want an IPv6 equivalent (NAT66). However, if a router says that it supports IPv6 and PPPoE then I expect it to support IPv6 over PPPoE. I also expect to be able to ping IPv6 addresses; I’d prefer to use the same command (ping) for both IPv4 and IPv6, but I don’t mind if I have to use separate commands (e.g. ping6 in Red Hat Enterprise Linux 5) as long as the functionality is built in.
I would like to have some kind of firewall built into the router (e.g. ip6tables), but that’s not essential; if necessary, I’m willing to use a separate device for that.
When I set up a router for an IPv4 xDSL (ADSL/VDSL) internet connection, I don’t have to type in the public IPv4 address: that comes from the ISP. In a similar way, I would like an IPv6 router to pick up the equivalent IPv6 address range automatically. However, if I have to type in the router’s IPv6 address manually then I can live with that; this is just a one-off job until I change my internet connection, rather than something I’d have to do on a daily basis.
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 WRT320 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 does support the WRT320N.
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).
I’ve recently swapped ISP, from Zen to Andrew & Arnold. More specifically, I had an ADSL line from Zen, and I now have a VDSL line from A&A; this uses FTTC (Fibre To The Cabinet), which BT have just deployed in my local exchange. I’m happy with the new service, and it’s definitely faster than what I had before: according to Broadband Speed Checker my download speed is 24368 Kbps, whereas it was about 3500 Kbps before. Unfortunately, the transfer didn’t go smoothly, and I wound up with no internet connection for eight days; I had to rely on my Orange mobile broadband dongle, which is roughly equivalent to dial-up speed. I’m not quite sure what went wrong, but there was definitely a failure to communicate somewhere along the line. If you’re considering a similar move, this post should give you an idea of what to expect.