Upgrading my Networking Gear (2022.3)
When I had left off with the last update, I had a few bits of pre-requisite infrastructure work left to be done most of which can be summarized as “run a bunch of ethernet cables all over the place”. Since then, this work has been completed and all of the major networking pieces are in place (for now). This means I can work on refining the configuration and usability of the network.
Networking Series
This post is part of a series, check out the other posts!
Quick Links
Hardware changes
Ethernet runs
At the end of the previous update, I was waiting on getting the rest of the house wired up; we had determined that the easiest/cleanest way to run the ethernet was via the outside of the house so I had run ethernet lines from my network hub to a staging area near the side of the house. Pre-terminating the ethernet ends and using couplers gave me two benefits:
I could finish getting the connections in the rack complete and get all of the runs in the ceiling tidied up beforehand and,
If there was ever a problem with a line running out of the house, I could troubleshoot more easily (rather than having to dig inside my rack) and if needed, I could (in theory), replace individual lines more easily
I made extensive use of Cord Dotz to ensure that all of the runs were as well-labeled as can be — in the event of failure, I didn’t want to have to sift through a sea of identical-cables to determined which was which.
Ultimately, I ran seven lines out of the house:
Three for cameras
One for an outdoor access point
Two going to my wife’s upstairs office
One going to the living room to provide a hardline to the living room TV
Pro-tip
When choosing conduit, always size up — trying to go with a smaller conduit to reduce the ‘aesthetic impact’ is totally not worth the exponential increase in effort trying to snake a crap-ton of ethernet cables around bends etc.
The final result
This is ultimately what we set out to do: get two ethernet lines into the office on the other side of the wall and mount an access point for outdoor coverage.
Electrical boxes always look so massive in-hand until you find yourself trying to wrangle four sets of ethernet cable and some couplers - then you’ll be cursing at just how tiny everything is!
Tuning the outdoor coverage
The one last step to do was to tinker with the orientation of the antennae to maximize coverage in the backyard. This was quite tedious actually as there were so many permutations to try out; I settled on trying the antenna at 45° intervals (angle and rotation) and for each configuration, I took a heatmap.
A few of the WiFi heatmaps I generated from walking around the yard, testing the signal out — I got my steps in!
It makes sense that tinkering with the angle and rotation of the antennae would make a difference in signal quality but I was quite surprised to see just how substantial the difference would be, visually. I used WiFiman app to take the heatmaps.
Something to note: while your first instinct might be to maximize the signal throughout the entire space, you may want to reconsider and have the fall-off happen as you start to near the edge of your property (both for security and general WiFi ‘tidiness’ reasons). This is where having a heatmap can really help you visualize where to start cutting off your signal.
Indoor APs
For the living room and the upstairs office, I made use of wall access points (specifically the TP-Link EAP-235 Wall) I primarily chose this as a means of ‘getting a bunch of connections to the wall with just a single cable’ and the increased overall wireless coverage was purely a side benefit. Obviously, connecting three downstream devices simultaneously would cut the available bandwidth down to (roughly) 333 MBit/s (at worst) but in some applications it may not matter.
For my applications, I was planning on only using one port at a time and the other two would just be a bonus; in the case of the upstairs office, I had a second cable run to provide 2.5G/10G as a dedicated higher speed line.
Ad-blocking
DNS sinkholing
Nobody likes ads and while I can understand the need for ads, what I dislike more are ‘bad’ websites - and I don’t mean “we’re going to hack you” (although those aren’t nice either) — I mean websites that are just done poorly. Also: why is it that the “important” websites (i.e., banking, government, taxes etc.) all just coincidentally happen to be built like crap? On the angle of ads, while I don’t mind the occasional ad, my god, some sites are just absolutely littered with them and it always seems to be super obnoxious ads too.
With the rest of the centralized networking in place, it made sense to finally look at centralizing ad- and malware-blocking. I went with a two prong solution of Pi-Hole and a private DNS provider like NextDNS.
Pi-Hole is a system that I manage/control and NextDNS (or similar) is a third party provider: both of these systems work by filtering web requests based on the domain-name: so for example, if you know that ads are being served by ads.somewebsite.com, you can block requests going to that url. The advantage here is that any device that connects through Pi-Hole (or NextDNS) will be ‘protected’ without any additional configuration.
Why use two systems?
The big differentiator here is that the Pi-Hole is really only [easily] accessible from within my network. For devices like my phone which I use in and out of the home, I wanted a solution that would provide me some ad- and malware-blocking out of the home as well.
It’s possible to use Pi-Hole out of the home but (at least for how I have it configured, using via VPN), it’s not a great experience. Next DNS has a free tier that allows for 300K queries per month which is perfect for running two phones.
Raspberry Pi
Pi-Hole can be run on a variety of platforms and a popular option is to run it using Docker however I opted to run Pi-Hole as a standalone appliance using a dedicated Raspberry Pi.
A love-hate (almost entirely -hate) relationship with Docker
I really like the idea of Docker: run a bunch of lightweight things that spin up and down easy-peasy. It’s all sunshine and rainbows except either [a] I want to encapsulate things that aren’t services (i.e., give me Photoshop as a Docker container) or [b] the stuff I want to run wants all-the-performance (i.e., video encoding) where the “low-power, low-footprint” ethos doesn’t really mesh well.
I like the idea of a dedicated, single-tasking thing that does one thing (DNS stuff) and does it well. I went with a Raspberry Pi 4 (8G) which I nabbed before prices went too stupid. I used a passive mountable enclosure to let me magnet-mount it to the side of the rack to keep the clutter down.
I didn’t need the top of the line model but with the inflated prices, it was only a few bucks to max out the RAM so it made sense. At some point, I’d like to get a second Raspberry Pi and run a second [dedicated] Pi-Hole instance: this way I can do updates/maintenance on one Raspberry Pi without impacting the network as a whole. Given the chip (and Pi-specific) shortage, it’ll be awhile before I can tackle this.
Getting sidetracked by tragedy
Once I got my Pi-Hole in a good steady state, I made the move to run it from a SD card to a USB key and then finally a SSD. I’m not a Linux expert by any means so one thing I did learn to do was to make sure I had multiple backup copies of everything.
When setting up initially, I went for the full-fat GUI experience — the only thing this Pi was going to do was run Pi-Hole so there was plenty of horsepower left to run VNC and a GUI. Leveraging the easy-mode “SD Card Copier” makes things so much less annoying than trying to brute-force copy SD-cards. Fully expecting SD cards, USB keys and even SSDs to fail, I made multiple copies of everything as cold-spares
Nevertheless, something did go wrong. One time, when I was powering down the Pi, I tried powering it back up and was in Kernel Panic, unable to mount partition mode. I was not in the mood to troubleshoot this (esp. as a relative noob), so I went with the nuclear option: just reimage the SSD back to a backup, I lose a bit of configuration but I’m back up and running shortly. This was a very long night and even though I ultimately got back up and running, I’m not entirely sure why it broke or how it is working again now with effectively no change..
Ultimately a very confusing night…
Super confusing
Ultimately, I have no idea why the initial drive stopped working, why the backup images and cold-spare drives (which were all tested previously) refused to work and then, magically, it started working again. At the end of the (very long) night, I was back up and running in the exact same configuration I had before this mess.
From previous testing with the equipment involved, I had determined the Raspberry Pi is unable to boot using the [SATA - USB B] and I quickly determined that this time, the SD Card Copier was unable to deal with [SATA - USB A]. After a handful of hours, I eventually got everything back and working again (albeit with a month old configuration). I had been meaning to get backups and synchronization setup but just didn’t get around to it. This was the push I needed 😉
To do this, I created a shared folder on the NAS as well as a new set of credentials with access to this share. Then, on the Raspberry Pi, create a convenient script (I put mine as /usr/local/bin/pi-backup) and I added the following:
#!/bin/sh
sudo umount ~/some_folder_name || /bin/true
sudo mount -t cifs -o username=NAS_user,password=NAS_password,uid=1000 //NAS_IP/NAS_shared_folder_name ~/some_folder_name
cd ~/some_folder_name/Pi1
pihole -a -t
This should mostly be straightforward, the only two things of note are:
- The || /bin/true is appended to ignore any errors unmounting the NAS drive (i.e., if the drive wasn't mounted in the first place)
- I added a subfolder Pi1 so that each individual Raspberry Pi could have its own distinct configuration backup
I modified the file for execute privileges (sudo chmod +x /usr/local/bin/pi-backup) and now I can quickly create a backup of the Pi-Hole configuration with just a simple call. Easily adjustable so that each [future] Raspberry Pi has a copy of this to be able to back it up. This leverages the built-in Teleport command to perform the configuration backup.
Looking ahead
I’d like to go down the rabbit hole of Raspberry Pi a bit more; at the very least, I’d like to run another unit as a failover — this way I can do maintenance/updates on one (or suffer some kind of failure) without being a pain on the network as a whole. I’d also like to get a couple more units to play around with Home Assistant and as a VPN box. With this many units, I’d be running out of space to magnet-mount them on the side of the rack so I would probably look at something like a POE rack-mount.
Over the upcoming year-end breal, I’d like to spend some time to tackle (or at least start looking at) two things:
Replacing the fans on my NAS units with some Noctua fans; nothing currently wrong with the fans on there but they are more than a few years old now and I’d like to get ahead of any potential problems while I have a break
Following the weirdness (for lack of a better word) with the Raspberry Pi and also as a follow up to my Data Loss, I’d like to spend some time to refine my data backup strategy to make it more robust.
All of this is me trying to avoid the big problem on the horizon: that I’ve effectively ran out of rackspace. At some point (next year perhaps?), I’ll consider going for a four-post rack and “finally” be done. Ish.
I have an idea for an upcoming [networking] mini-project thought, ‘Project Endurance’. That’ll be the next update!
Network Upgrade (2022.2)
In the second installment of my networking upgrades, I tackle redundancy and tidying up the overall network as I get ready for the final networking runs to be laid.
Product links may be affiliate links: MinMaxGeek may earn a commission on any purchases made via said links without any additional cost to you.
