Replacing a BT Homehub 5

In 2013 it took BT nearly four months in to connect up the phone line and get internet access enabled at the cabinet, blaming it on “one of those things” that happens when you buy a new build house (despite the rest of the road being connected just fine). When it was finally up and running I hoped that their newest revision of the HomeHub router, version 5 now with the VDSL modem built in instead of a separate BT Openreach device, would be better than the awfully unreliable HH3. It really wasn’t much better. Same poor UI, same poor UX, marginally better reliability. It’s unusual for it to keep the WiFi up and running for longer than a week without needing to reboot it.

Over the last few months it has been dropping connections, rebooting seemingly at random, refusing to respond to DHCP requests, and generally getting in the bloody way. Yesterday was the final straw when it rebooted no fewer than 8 times between 8:30am and 10am, and my itchy Amazon Prime trigger finger ordered an ASUS DSL-AC68U. If I had a little more patience, or if I could find the old BT Openreach VDSL modem I would have moved away from the all-in-one type router/WiFi/modem units and picked up something like the Ubiquiti EdgeRouter but I’ll save that for a bit more research.

Important note: If you’re replacing a HomeHub5 and you’re using on a BT Infinity FTTC connection you need to make sure your replacement has an integrated VDSL modem, like the ASUS DSL-AC68U, or that you have a separate VDSL modem. Most manufacturers make two (or more) versions of the same device. There is an ASUS RT-AC68U which is the same unit but as subtle and important difference, it doesn’t have the modem built in.

I’ve decided that I want to move as much responsibility away from the router as possible so that it can focus on just one job. That means providing local network services on another device, and using a dedicated WiFi hub – the Eero has caught my eye recently. I decided to start “small” as I was always going to have a lot of work to do, there are no fewer than 28 different devices on the home network ranging from NAS, thermostats and smoke/co2 detectors, lightbulbs, TVs, consoles, and music systems.
Starting small meant moving the core network services; DHCP, DNS, and NTP, somewhere other than the gateway. I spent a few minutes thinking about using the Synology NAS device to run them but my experience with the frequent DSM security updates (a very good thing) interfering with and breaking configs and settings on the NAS (a very bad thing) pushed me away. I didn’t want to risk the services being unavailable when I wasn’t around to fix them. My customers (aka my kids) would not appreciate the downtime 🙂

Luckily I have an abundance of Raspberry Pi devices from old projects that are no longer in use so I dug out a Raspberry Pi 2 model B, an 8GB microSD card and went about installing the latest version of Raspbian – Jessie. I was reasonably pleased to find that the latest release comes in a full desktop-mode version and a lite version for headless use, and even better than that was that the SSH server now runs by default. This means no scrambling around for a spare HDMI port and a USB keyboard, yay!

It made sense to me to do it in the following order. First, get DHCP up and running and switch the service off on the HomeHub5. Then get DNS served by the Pi, using Google’s public DNS servers on 8.8.8.8 and 8.8.4.4. Everything else after that, like NTP, would be relatively simple. I decided that it be simplest to keep the same network segment (192.168.1.0/24) and make sure the new router could function on the same IP (192.168.1.254) too.

My abridged steps:

Run raspi-config, expand disk, reset the default “pi” user password.

Set it to use a static IP.

The usual apt-get update and apt-get upgrade runs.

Used Aptitude to install the isc-dhcp-server package, dnsutils, and dhcpdump.

Rebooted to make sure that the services started up and I hadn’t screwed any interface settings.

Turned off DHCP on the HomeHub5 (Advanced Settings>Home Network>IP Addresses> set Enabled to NO).

Set the /etc/dhcp/dhcp.conf file to be authoritative by removing the # and restarted the service.

At this point all the existing clients still had their existing allocation so the change over should be seamless.

I ran dhcpdump on the Pi and manually renewed the DHCP lease on my iPhone. dhcpdump shows you the DHCP server activity and I was able to see the request and successful allocation, I could also verify the new lease on my phone because it was giving out the Google DNS servers instead of the HH5 default which uses itself as the DNS cache.

Satisfied that DHCP was working as expected, the next thing I wanted to do was get DNS caching implemented so that devices weren’t all going out to the internet for resolution.

Used Aptitude to install the unbound package.

Edit the /etc/unbound/unbound.conf file, using the manual for examples as, unusually, this file didn’t have a template in it:

Server:

interface: 0.0.0.0

do-daemonize: yes

do-udp: yes

do-tcp: yes

tcp-upstream: no

access-control: 192.168.1.0/24 allow

forward-zone:

name: “.”

forward-addr: 8.8.8.8

forward-addr: 8.8.4.4

restart the unbound service.

Test it locally with nslookup www.google.com 127.0.0.1 (you need to install the dnsutils package to get nslookup).

Test it from my laptop with nslookup www.hotmail.com 192.168.1.2.

Happy that’s all working, I changed the /etc/dhcp/dhcp.conf file to change the domain-name-servers value to use 192.168.1.2 (Pi) and 8.8.8.8 in the event that unbound doesn’t respond. Restart the DHCP service again and use dhcpdump to look at a new lease, you should see the Pi address in the DNS server part of the response.

The NTP service is part of the Raspbian distro so you just need to edit the /etc/ntp.conf file to add in your “broadcast 192.168.1.255” entry and restart it. You can now go back and (again) edit the /etc/dhcp/dhcp.conf file to pass out the Pi as the local NTP server with the entry “option ntp-servers 192.168.1.2”, restart the dhcp service (again) and check with dhcpdump (again) to see the new NTP option passed out as part of the lease.

At this point I have a pretty straightforward swap out of the router, simple WiFi set up and then the arduous task of updating every single device with the new access credentials because I simply refuse to have continue with the same BTHub* ssid.