well, that didn’t work very well

Two posts back I documented my attempt to reuse an old Raspberry Pi to run Pi-Hole. It didn’t turn into the roaring success I’d hoped it would. The Pi booted and started Pi-Hole well enough, but it was during testing that the Pi-Hole went sideways on me.

Using the fixed IP address I’d assigned to the RPi/Pi-Hole system, I changed my WiFi router to use that address as my primary DNS address, leaving the secondary at 8.8.8.8. I then went to another system and brought up Chrome with Adblock Plus and turned it off on a few pages that I knew were running ads. When I refreshed those pages the ads were still gone off the pages.

I then went back to look at the Pi-Hole dashboard running on one of my Macs in Vivaldi. When I hit refresh on the page to see the latest stats the page, or should I say, the site, froze. It would never come back. I checked the Pi and it was still doing just fine at the prompt (I’d used raspi_config to have it come up at a text prompt, not the graphical desktop, to save memory usage). So then I rebooted the Pi. When it came back up I reloaded the Pi-Hole dashboard and I got the following:

It looked like it was working until I somehow managed to lock up its built-in web server for the dashboard.

Oh well. I felt the probability of failure with that refurbished Raspberry Pi was high enough. My next step will be to take one of my Raspberry Pi 4’s (either the 2GiB or 4GiB) I have mounted in Flirc cases and do a clean install of Raspberry Pi OS (bullseye), purge CommMan, and then install Pi-Hole. A clean setup from start to finish. Then I’ll try this all again.

pi-hole on a raspberry pi 3 model b+ rev 1.3

These are my notes on upgrading a Raspberry Pi 3b+ operating system and then the installation of Pi-Hole for my home network.

Updating The OS

I upgraded the OS running on an old Raspberry Pi 3b+ from Raspbian to Raspberry Pi OS (Debian buster to bullseye basically). Because this was an older Raspberry Pi than the 4’s I’ve been working with, the update took a good long time with lots of stepping away to do house projects while the updating process proceeded. I followed the steps documented here: https://www.linuxuprising.com/2021/11/how-to-upgrade-raspberry-pi-os-10.html . I will stress that you follow all the steps, especially the step calling for the installation of GCC 8 support libraries. Once completed the system will be running Raspberry Pi OS bullseye.

Updating a Raspberry Pi operating system on this version of the Raspberry Pi is a long, slow process requiring a lot of patience to finish. Unless you have a special environment you want to leave in place rather than trying to find and save all the important bits, you’re better off downloading the latest image, flashing a new boot micro SDHC/SDXC card with it and then customizing it to your needs. I had a complex, scattered environment I wanted to bring forward so I gave the update a shot. That’s the first and last time I’ll ever do that. From here on out I’ll always flash for a fresh, clean OS and then set everything up; it’s so much faster.

Disabling ConnMan DNS

After checking that the update was functioning correctly I installed Pi-Hole. But before you do that, we need to take a moment and discuss ConnMan, and how to disable a part of it that starts its own process and sits on port 53, the DNS port.

CommMan is a new package that contains tools and services to manage all the various communications resources. It’s intended to run on embedded systems, which are usually like the Raspberry Pi. Its laudable goal is to act as a central control system, using as minimum of system resources to do its job. It sounds all laudable in theory, but in practice under bullseye (in which it showed up) it was nothing but a pain, taking over port 53 for DNS and preventing Pi-Hole’s tools and services from working properly.

In order for the installation of Pi-Hole to be a complete success, you need to perform the following actions.

First, check to see if connmand is running.

$ sudo lsof -i -P -n | grep LISTEN

connmand   364     root   13u  IPv4  13435      0t0  TCP 127.0.0.1:53 (LISTEN)
connmand   364     root   14u  IPv6  13439      0t0  TCP [::1]:53 (LISTEN)
sshd       528     root    3u  IPv4  10693      0t0  TCP *:22 (LISTEN)
sshd       528     root    4u  IPv6  10695      0t0  TCP *:22 (LISTEN)
lighttpd  1279 www-data    4u  IPv4  17674      0t0  TCP *:80 (LISTEN)
lighttpd  1279 www-data    5u  IPv6  17675      0t0  TCP *:80 (LISTEN)
cupsd     8747     root    6u  IPv6 128149      0t0  TCP [::1]:631 (LISTEN)
cupsd     8747     root    7u  IPv4 128150      0t0  TCP 127.0.0.1:631 (LISTEN)

Unfortunately in this example it is. So now we have to disable connmand so it won’t start and take over port 53.

Under /etc/systemd/system create a new directory named connman.service.d.

cd into connman.service.d and create the file disable_dns_proxy.conf.

Open that file with a text editor and add the following lines:

[Service]
ExecStart=
ExecStart=/usr/bin/connmand -n --nodnsproxy

I’m sure there is a more “elegant” way to do this, but I didn’t find any “elegant” help, only the brute force steps I’ve just outlined. Once you’ve saved the file reboot the Raspberry Pi, then check again for connmand:

$ sudo lsof -i -P -n | grep LISTEN

cupsd     508     root    6u  IPv6  11622      0t0  TCP [::1]:631 (LISTEN)
cupsd     508     root    7u  IPv4  11623      0t0  TCP 127.0.0.1:631 (LISTEN)
sshd      539     root    3u  IPv4  11651      0t0  TCP *:22 (LISTEN)
sshd      539     root    4u  IPv6  11653      0t0  TCP *:22 (LISTEN)
lighttpd  573 www-data    4u  IPv4  12791      0t0  TCP *:80 (LISTEN)
lighttpd  573 www-data    5u  IPv6  12792      0t0  TCP *:80 (LISTEN)
pihole-FT 618   pihole    5u  IPv4  13654      0t0  TCP *:53 (LISTEN)
pihole-FT 618   pihole    7u  IPv6  13656      0t0  TCP *:53 (LISTEN)
pihole-FT 618   pihole   10u  IPv4  11828      0t0  TCP 127.0.0.1:4711 (LISTEN)
pihole-FT 618   pihole   16u  IPv6  12897      0t0  TCP [::1]:4711 (LISTEN)

The reason you’re seeing pihole-FT in the output above is because I had to figure all this out after installing Pi-Hole and not seeing the Pi-Hole FTL service running. I felt it was important to put these steps first.

Installing Pi-Hole

The instructions are here ( https://github.com/pi-hole/pi-hole/#one-step-automated-install ) and are clear enough. I chose Alternative Install Method 1 because the one-step install refused to work for me. Alternative Install Method 1 has you clone the Github repo locally, then run the installation out of there. Not a problem, especially if you want to look at the code a bit and see what it’s doing.

I chose to use the wlan0 interface, and I also made sure that the IP address was static on my home router as well as defined within the Raspberry Pi. During installation the installer will warn you to make sure your IP is static and will survive a reboot. I chose WiFi because in the next stage of testing I wanted the Raspberry Pi on my desk, instead of next to my router. When I’m ready to finish up I’ll physically plug the Raspberry Pi directly into the router and make the necessary changes to the software, specifically the interface being used.

After all that work, this is what the Pi-Hole dashboard looks like on my home Raspberry Pi.

Everything seems to be working on the dashboard as it is. When FTL isn’t working, sections of the dashboard show a constant spinning busy wheel, and some sections aren’t even displayed, indicating the little local website can’t get status information from a non-running FTL to display.

After I finally get this integrated into my home network and running, there’ll be more to document.