Note that a Pi-hole can't currently block ads in YouTube as these ads come from the same DNS addresses as the content (the Pi-hole forum has numerous questions relating to this).
Download Etcher. Download the server version of Armbian for Ordoid C2. Install the image on the C2's eMMC card and attach it to the C2.
Note: the resulting eMMC card will be formatted as ext4 and so will not be readable on Macs and other systems that do not have native ext4 support. This is fine - just eject the card properly.
Use the Fing app to find a generic device with a Wibrain MAC address, i.e. starting with 00:1E:06, or search for it with nmap:
$ sudo nmap -sn 192.168.0.0/24
Starting Nmap 7.80 ( https://nmap.org ) at 2020-10-04 16:12 CEST
...
Nmap scan report for 192.168.0.150
Host is up (0.00069s latency).
MAC Address: 00:1E:06:33:CE:52 (Wibrain)
...
Replace 192.168.0 with the first three octets for your network, if they're different.
Then log in:
$ ssh root@192.168.0.xyz
The default password is 1234. Say no when it asks you:
Do you want to set locales and console keyboard automatically from your location [Y/n]
It's one of those stupid situations where it gives you no option but to accept what it determines via geolocation, e.g. it suggests just de_CH, fr_CH and it_CH if you've got a Swiss IP address.
Then update and upgrade the system. This is actually essential, the Pi-hole install failed until I'd done this:
# apt update
# apt upgrade
# reboot now
At the moment your C2 is getting it's address etc. via the existing DHCP service that we want to replace (along with DNS). Before we do that, record some of the existing details:
# nmcli dev show
...
IP4.ADDRESS[1]: 192.168.0.150/24
IP4.GATEWAY: 192.168.0.1
...
IP6.ADDRESS[1]: 2a02:aa16:577d:df80:7afd:8230:4843:9a37/64
IP6.ADDRESS[2]: 2a02:aa16:577d:df80:ab3f:44a9:9051:9655/64
IP6.ADDRESS[3]: fe80::6b66:2497:3f03:f8da/64
IP6.GATEWAY: fe80::3a43:7dff:fe3f:baae
We're interested in the IP4.GATEWAY and IP6.GATEWAY values. And, we're only interested in the link-local IP6.ADDRESS, i.e. the one starting with fe80:: (this is the IPv6 equivalent of the 192.168.x.y IP4.ADDRESS).
Update: as it turns out, if you do everything right during the setup, you don't need any of these values. But record them anyway (see the final section on hair pulling).
The Pi-hole setup will take care of configuring your C2 to use a static IP address rather than DHCP. It suggests using the device's current IP address as its static IP address. Instead, if the shown gateway address is something like 192.168.0.1, I'd suggest choosing something like 192.168.0.5 (as DHCP generally allocates from 10 upwards, so choose a value between the gateway address and 10).
The Pi-hole docs cover installation. We need to add PIHOLE_SKIP_OS_CHECK as the Armbian build of Ubuntu isn't recognized as generic Ubuntu:
# curl -sSL https://install.pi-hole.net | PIHOLE_SKIP_OS_CHECK=true sudo -E bash
I selected Cloudflare as the DNS provider, specified the static IP address and accepted everything else, including the installation of the web UI and web server.
Important: towards the end of the installation process, you should see something like:
[i] Web Interface password: abcdefgh
[i] This can be changed using 'pihole -a -p'
[i] View the web interface at http://pi.hole/admin or http://192.168.0.5/admin
Make sure to note down the displayed password (there's no way to recover it later, though you can reset it). Once finished, reboot and confirm that you can access the device via the static IP address that you gave it:
# reboot now
...
$ ssh root@<static-ip-address>
The above has set up the device to act as a DNS server. You could manually configure the devices on your network to use it, but it'd be nicer to have this happen automatically. This is done by replacing your network's existing DHCP server with the Pi-hole (as described in the next section).
If all looks good, i.e. it's available on the given address, then open the web interface (i.e. the URL shown above, use the numerical version), select Login and enter the password noted above. Go to Settings and then the DHCP tab.
Note: once you've switched over using the C2 as your network's DHCP server, you'll be able to access it via the name pi.hole and the name found in its /etc/hostname (odroidc2 by default).
TODO: see if I got an answer to dnsmasq-dhcp server requesting its own lease
On the DNS tab, tick the two IPv6 checkboxes, for Cloudflare, in the DNS tab under Settings. Note: on going to DNS tab initially, these seemed to be already ticked but, on switching to another tab and back, they became unchecked (this is probably some simple UI bug).
On the DHCP tab:
- Tick DHCP server enabled.
- Change the From range from 201 to 10.
- Tick Enable IPv6 support.
Leave everything else as it is. But, before you click Save, complete the next section on disabling the existing DHCP server. Once that's done, complete the setup here by pressing Save. See the Notes section below on the fairly dramatic effects this may have on the machine you're working on or other devices on the network.
I have a NAS, so additionally, under DHCP leases, I set up the NAS to retain its current address after the switch so as to avoid having to reconfigure anything that expected it at that address (a bit unintuitively the Save just button is only for the main DHCP settings, it's the plus icon that adds lease settings).
The Pi-hole is going to provide DHCP, so you need to disable the existing provider.
For the UPC Connect Box this involves opening the gateway address in your browser, logging in with the password on the sticker under the box, going to Advanced Settings, then DHCP and clicking Disabled for the DHCPv4 server (apparently, you can leave DHCPv6 as it is, i.e. Stateless, according to this post - there's no option to disable it).
The piercingly bright LED of the C2 is fairly unpleasant. You can get it to do something useful:
- During boot up, flash on and off until the system is ready to accept ssh connections.
- During shutdown, flash on and off until the system is safe to power down.
And at all other times it should be off. To setup this behavior, log into the C2 and:
# curl -O https://gist.githubusercontent.com/george-hawkins/cf77f059a9e86900b428870349497eb7/raw/1ea6b686f332a35327e9f22b5fe26dd26a00b720/blue-led.service
# mv blue-led.service /etc/systemd/system
# systemctl daemon-reload
# systemctl enable blue-led
# systemctl start blue-led
TODO: it would be nice to similarly turn off the bright yellow LED on the ethernet connector (that tells you that it's operating in gigabit mode).
That's it as far as setting up the C2 is concerned. You'll now have to reboot all the devices on your network.
Important: I didn't do this for some of my devices, as they seemed to be functioning fine, but they all eventually started displaying odd issues - just reboot immediatelly.
The IPv6 behavior works in some completely different way to that for IPv4. Even after enabling DHCP on the Pi-hole and rebooting devices, they still showed the same IP6.DNS value as before (while the IP4.DNS value clearly pointed to the Pi-hole). Despite this filtering worked properly for both IPv4 and IPv6 addresses. However, any slight change regarding the Pi-hole, e.g. moving it between switches, seemed to negate the IPv6 filtering and ads reappeared until the relevant devices were rebooted.
So plug the Pi-hole in where you want it, then reboot all your devices and leave the Pi-hole alone forever.
After running everything for about 2 weeks the only site that I've white-listed is www.googleadservices.com. This allows me to follow Google Shopping links and the shopping links shown at the top of Google search results. White-listing this site doesn't seem to enable any additional advertising (it simply stops the shopping links from being invalid). Before white-listing a site you can search for it in the the query log available via the Pi-hole web UI. If it appears lots of times then it's probably used for serving ads but, if like www.googleadservices.com, it just appears occassionally (corresponding to your attempts to click links involving it) then it's probably OK.
All my wired devices seemed to work fine but my wireless devices took a long time before they also stopped showing ads.
My wireless access point seemed to have its own DHCP server - I disabled that.
On the Pi-hole, I used nmtui to set the IPv6 configuration to manual and set just the IP address and the gateway (to the values recorded up above when initially setting up the C2). And after more reboots and this failing to work, I removed the file my nmtui changes had created under /etc/NetworkManager/system-connections, leaving the directory empty.
Then, on rebooting the Pi-hole and the wireless device, everything started working for no obvious reason. Perhaps, I'd inadventantly created an entry etc/NetworkManager/system-connections already (when using nmtui so check what, if anything, the Pi-hole installation process had changed) and removing that completely resolved things.
Initially, nothing seemed to work. It turns out that Switzerland is number 2 in the world in the take up of IPv6 and far more of my traffic was IPv6 than I expected (in fact, I hadn't expected any of it to be IPv6). And as noted above the IPv6 filtering seems to be much more sensitive to small changes than the IPv4 filtering (so I'd see some ads filtered and others not).
When I enabled DHCP the first time, I hadn't ticked Enable IPv6 support and, when I eventually ticked it, I got confused by things not seeming to work initially and ended up configuring static IPv6 settings with nmtui, along with various other configuration changes. In the end, it turned out that these changes weren't necessary at all.
When going through the Pi-hole terminal-based installation wizard, it lets you set a static IPv4 address. It gives you no such option for IPv6 and generates an IPv6 address itself - this seems to be fine. Oddly, if I run nmtui afterwards the IPv4 and IPv6 configurations still show as Automatic - I took to mean non-static but clearly this isn't the case as the Pi-hole ends up with the expected static IPv4 and IPv6 addresses.
Changing the network's DHCP server had a much more dramatic effect on some of the devices on the network than I expected. I thought that, at most, they might lose their ability to resolve addresses but some devices lost network connectivity altogether. I went through this process twice, in neither case were devices happy at the switch but in the case where I pressed Save for enabling DHCP before disabling the existing DHCP service, the result was more dramatic - the machine on which I was running the browser lost connectivity (and just waited for a response to pressing Save that it was never going to get). Having said that, other factors, than the order of enabling and disabling things, may have affected things.
Initially, I had the Pi-hole connected directly to my cable modem. After enabling DHCP, things didn't seem to work properly until I moved it onto the separate switch to which I have all my other devices connected. I can't see any reason this should matter - maybe the cable modem had simply become "confused" or the network cables needed to be plugged in and out (i.e. voodoo) or the Pi-hole needed to be rebooted.