What's talking to what?

The recent broadband issues we've been having exposed me to some of the network diagnostic capabilities of our router. One of which is a table of sessions the router is managing between devices in our home and the big wide internet. I made the mistake of delving into this a little deeper, with the result that I'm now paranoid about what servers on the internet my smart home systems are talking to on a regular basis.

Unfortunately the router's sessions table lists only which internal IP addresses are talking with which external IP addresses. Converting the internal addresses is relatively straight forward, as I've set up the router to bind all of the expected devices on the network to specific IP addresses. For the external IP addresses a reverse DNS is required to find out who owns them and where they are. I used www.ipinfo.io manually for several reverse DNS enquiries, until I noticed that it offers an API to process IP addresses, at which point I decided to write a Python script to automate the whole analysis.

The code is fairly straight forward. First read in the IP binding list from file and build a dictionary with the device names and internal IP addresses. Then read in the sessions, again from file, and parse each line to extract the internal IP address and external IP address into a list. Converting this list to a set effectively eliminates any duplicates. Then send a call off to ipinfo.io with each external IP address from the set to get a JSON response, from which the organisation and location of each IP address can be extracted. And finally create a CSV file to dump out the resultant list of internal device names and external organisations. The results look something like this:

All of this looks pretty much okay. Our HP printer talks to HP servers (and only HP's servers, it is nice to see) as we've got cloud printing turned on. It is slightly interesting to see that Philips are using Rackspace to host their Hue system back-end, but not totally surprising. I'd not come across Google's use of the 1e100.net domain name, but a quick search reveals that Google consolidated their back-end systems under a single domain back in 2009. 1e100 is the scientific notation for 1 googol. And the various devices talking to BT is also expected, as BT provide our broadband (sometimes).

The stuff I'm not so happy about is my IP cameras. They're chatting away with a whole range of people which don't immediately seem relevant. One of the IP cameras is even talking to NIST in Boulder, Colorado. Another appears to have ambitions of becoming an autonomous car when it grows up, as it is connecting to www.quickdrivingtestcancellations.net to arrange a driving test. The only two things outside my network I want my IP camera talking to are an NTP time server, and an email server. So I think I might enable these on my NAS to send all that traffic through one pipe, and block all other traffic using the router's firewall.

Broadband issues

Every so often our broadband connection, provided by BT, has a bit of a wobble. Yesterday was one of those days, and after it was down for a couple of hours I gave BT a call to see if there were any problems at their end. One long call later on a Friday lunchtime, and the customer service rep had booked a technician to go out to the exchange and take a look... on Monday afternoon. As he explained, the technicians don't work on the weekend, but if the system sorted itself out he would be happy for me to phone back and cancel the booking. (As it happened, the broadband came back at 5.30pm, and has been up ever since.)

Working from home is a regular thing for us, and a day without broadband is a major headache. So I looked at options for increasing the resiliency of our internet connection, and decided to add a cellular modem as a backup to our ADSL modem. On the opposite side of the gorge from our house is the cell base station for the town, which was upgraded to 4G last year. So there should be plenty of bandwidth available from the cellular connection, if the landline connection goes down.

As we've been having broadband issues for a while, we've long since ditched the BT-supplied Home Hub 4 and have been using a DrayTek Vigor 2860ac ADSL2+ router. This has enabled us to get the maximum speed from our connection, and has plenty of manual configuration for other services such as VPN, IP binding, QoS, etc.

The Vigor 2860 also has load balancing and auto-failover for multiple WANs. By adding a USB cellular modem, it is possible to configure the Vigor 2860 to switch over to that when it detects the ADSL has gone down. So I bought a ZTE MF823 and EE PAYG data SIM, and hooked them up to the Vigor 2860.

Within the Vigor 2860 administrative interface (firmware 3.8.4.2_BT from 7-Dec-2016) the USB modem needs to be enabled.

The Active Mode is set to 'Failover' and Load Balance in unchecked, as I only want the cellular connection used when there's a WAN failure, specifically when WAN1 (BT Broadband) goes down.

The next thing is to set up the USB cellular modem itself.

The Vigor 2860 supports the MF823 when in DHCP mode, as opposed to PPP mode.

The only configuration information the MF823 needs is the APN for the EE network, which is 'everywhere'. With the MF823 configured, the Vigor 2860 reports that it has a potential 42Mbps symmetric internet connection.

Which rather puts our ADSL2+ speeds of 20Mbps/1Mbps to shame.

So the final step is to test that the Vigor 2860 switches over from the ADSL connection to the cellular connection, and back again, when the BT landline goes down. Disconnecting the RJ11 modem cable from the BT master socket triggers the failover behaviour in the Vigor 2860, and after a short delay as the MF823 connects to the network the internet is restored.

There is a break in the internet connection, so this isn't a seamless failover setup. The Vigor 2860 could be setup with the MF823 always on, but with load balancing rules sending all the traffic down the ADSL connection. When the ADSL goes down there wouldn't be the delay while the MF823 connects to the network. However it would still confuse the hell out of any VoIP and streaming connections as the packet routing transitioned from ADSL to cellular, and keeping the MF823 permanently connected would slowly eat through its data allowance. So on balance, I'm happy with the small disruption in connection with the current setup.

(I also note that Openreach is now accepting orders for fibre connections from the Ironbridge WNIB exchange! We're connected to 'cabinet 2', which is currently is in the Build phase, and the guidance is that connections to homes should be available within 5 months.)