Networking Is Magic

Good Morning from my Robotics Lab! This is Shadow_8472, and if you missed last week’s post, feel free to check it out. It… was a minor disaster. I tried setting up PiHole network adblocker, but my home router unexpectedly moved its local IP address in the process. I cleaned up what I could really quickly and noticed my little hackjob of a subnet router was running an end-of-life operating system. Today, I am fixing that oversight. Let’s get started!

Replacing My Hackjob Router

Hackjob Router was my consolation prize after a failed quest to implement the open source router firmware, OpenWRT, onto my Raspberry Pi 4B in early 2020 and another in 2021. Both times, the exact version I needed was still under development. Dealing with testing versions was too advanced of a magic spell for me. I did, however, find an easy tutorial within my reach, but it did little to advance me beyond an aspiring networking mage with smoke and mirrors, but no fire or glass. When I looked this week, the beta warning was lifted.

I downloaded OpenWRT and flashed it over Hackjob Router’s SD card. Sure enough, the web interface was complete. I’ve used at least half a dozen ranging from limited config options to full access. OpenWRT’s “Lu-Ci” web interface puts everything on display with a helpful tool tip. It is comparable to other network devices I’ve worked with, but is simpler to look at, and has slightly more functionality.

My final configuration was surprisingly easy for a project that’s been hanging for almost three years now. At no point did I gain a key insight directly from an online search. But mistakes were made, and background information was researched and shelved for later.

My first mistake was a wrong Wi-Fi password. When I finally located and corrected it, my connection to OpenWRT died. I quickly learned how to assign a static IP in KDE’s settings thanks to intuitive interface design. I researched br-lan, a virtual network interface used for assigning one IP to multiple physical interfaces, thinking I needed to add the physical Wi-Fi radio to the one automatically generated to host all of the one Ethernet port and “bridge” the two sides that way.

The problem was actually a bad netmask. IPv4 network addresses come in four eight-bit numbers between 0 and 255. Local networks mask off leading bits – typically in multiples of 8 (for example: 10.0.0.1/8). Routers can use DHCP to dynamically assign local IP addresses with in their assigned subnet. My subnet ranges between 192.168.1.0 and 192.168.1.255 – properly denoted 192.168.1.1/24. Originally, my trailing mask was /16, allowing DHCP to assign my workstation to 192.168.0.200. Correcting the mask made it behave.

An unanchored memory I have regarding this week’s research is that some devices can route packets directly between network interfaces as opposed to routing them manually. I doubt the Raspberry Pi 4 has this ability, but it would be nice to know for sure.

Takeaway

Networking is magic at times. I still have a long way to go before I understand enough to do everything I want to, but I’ve cleared a large and long-standing burrier toward that goal this week. This is in part thanks to OpenWRT’s Lu-Ci with its educational help tips about every drop-down menu, text field, and tick box.

Final Question

Do you ever study a known science and everything inside you insists it’s magic?

I look forward hearing your answers on in the comments below or on my Socials.

Family Photo Chest Part 13: Early Prototype Workflow

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am merging a couple projects into one and hoping they stick. Let’s get started!

Overview

I’ve been piecing bits of my photo trunk project workflow together now for way too long. Right now, the architecture is looking like I’ll be scanning sets of pictures to a directory on a Network Attached Storage, then I can use a cluster of dedicated microcomputers from another unfinished project to separate and deskew the raw data into individual files. These files will then live permanently on the NAS.

Progress is rarely linear though. My end goal for this week hopped around quite a bit, but in the end I felt like I did nothing but figuring out how not to proceed: ground work with no structure. Routers are hard when you’re trying to learn them on a schedule!

Lack of Progress

In a perfect world, I would have been well on the way to configuring a cluster node by now. In a less unreasonable one, I would have had my Pi 4 OpenWRT ready to support the cluster. Late-cycle diagnostics chased me into an even more fundamental problem with the system: Wi-Fi connectivity.

During diagnostics, I’m learning about how different parts of the system work. Physical connection points can be bridged for a single logical interface, and Ethernet cables can support separate ipv4 and ipv6 connections. I can’t configure the Ethernet (on either logical interface) the way I want because that’s how I’m connecting to the Web UI and SSH. I end up stuck using two computers besides the two router Pi’s (OpenWRT and a Raspian hack router that actually works) because I don’t like switching my Ethernet cables around on the switch, but I need to do that anyway when I have to copy a large block of text. In short: the sooner Wi-Fi gets working, the better.

I understand I am essentially working with a snapshot. It’s been tidied up a bit, but bugs still exist. Wi-Fi is apparently one of those things that’s extra delicate; each country has its own region, among other complexities. On the other hand, I don’t know if that’s actually the case, as diagnostics are ongoing.

Takeaway

I’m probably going to work on this one in the background for a while. The OpenWRT help forum’s polish at least in part makes up for routers being dull to learn. If it takes too long, I do have other projects, so I may need to replace the cluster with a more readily available solution.

Final Question

Have you ever had upstream bugs that kept you from completing a task?

“Beowulf Cluster:” Part 6: OpenWRT Installed

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m installing OpenWRT Linux router distribution on a card for a Raspberry Pi 4. Let’s get started!

Background

A while ago, at the beginning of lockdown, I was gifted a few microcomputers I wanted to arrange into a cluster, maybe even turn them into a model supercomputer. I was planning on using OpenWRT, but it wasn’t –and technically still isn’t– available for the Pi 4 outside the use of snapshots. I compromised by configuring a minimal Raspian installation, but I’ve yet to figure out how to program the firewall to disallow computers on its Local Area Network (LAN) from going anywhere online without my say so in addition to keeping them hidden from the Wide Area Network (WAN).

My efforts back then were still possibly the most useful project I’ve done to date: I’ve been using that card as my main Wi-Fi receiver for my workstation. I conjecture it should be just fine with a Pi 4 (1 GB RAM), but since all my more qualified Pi 4’s are busy, my fancy Pi 400 has been serving in that capacity.

Installation

As noted above, OpenWRT for the Pi 4 is only officially available as a snapshot. These builds often lack recommended packages, including any GUI I might want to explore. This is where community builds come in. My research converged on one by wulfy23.

The GitHub’s readme’s took me a while to understand, in part because of all the options. I gathered that there were “factory” builds and “system” builds. Factory builds are for fresh installs, and system builds are for upgrading existing systems. At that time, there were as many as three builds for download, and choosing the right one seemed almost arbitrary.

My first time installing, I totally forgot to check the provided SHA256SUM before unzipping it and dd’ing it to SD card and booting. I landed in a terminal that kept mixing the prompt with other messages. Reaching out to a support thread on the OpenWRT forum, I learned about the web interface, and how to connect to it.

The URL I was given failed every time, even my workstation alone with the router on my switch. I ended up going directly for the IP: 192.168.1.1. I was met with an inadequate dark mode I couldn’t find the settings for. I expect they’re probably there, and I spent a small amount of time looking for them by tossing reasonable sounding URL’s around and hoping for the best, but comparing notes among other tabs in the interface, I think the chances of happening across the specific one I need are slim.

Installation Take Two

I went through the same process another day, and found only a single version for download from the same place. The SHA256SUM checked out, and instead of unzipping it first, I learned about zcat, a little command line utility that can unzip a file to be piped into another command. I piped it directly into dd per an example installation I spotted my first go around installing OpenWRT.

I provided a root password and found a different theme that didn’t force a partial dark mode on me in short order. I found built in tools for ad blocking network wide, settings for managing network interfaces, and most importantly to this project: a fire wall. Alas, the fire wall remains something I have little practical understanding of. I’d like to believe I have a mid-range understanding of what it can do, but my only real hope is copying lines and hoping they do what I want – the last thing one wants in a firewall intended for actual security. No. A custom firewall is at least a week in and of itself.

Takeaway

I really like trying to do two weeks worth of topics in a single week. It usually doesn’t work. Granted: I did have a rusty introduction to both parts of the topic I wished to fuse into one this week. I’m looking forward to remembering zcat in the future.

Final Question

What neat, little tips and tricks have you picked up during a larger project?