“Beowulf Cluster:” Part 5: DHCP and NAT

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am getting a head start on this post, so I don’t yet know where the end point for this segments. Let’s get started!

I hate networking. This router project is really taking a lot to learn. I’m losing track in my memory about what point I was on when the official break in weeks happened. Right now, I’m just looking forward to the time when I can say I have a custom router, and setting up the “Beowulf Cluster” I originally set out to build –not that I can really call it that anymore– should be one more week™ after that.

Once I had the network interfaces set up correctly, DHCP wasn’t far behind. I had a few semicolons missing after some lines, but that was about it. I plugged my laptop into the my little subnet and the Pi assigned it an IP in the range I had told it to. It just wouldn’t let me at the Internet at large, even though I haven’t changed iptables off its default of accepting everything yet. Of note: I was unable to use the Internet even while still connected wirelessly. Two weeks ago (Was it only that short ago?) I would have just poked around with “black box reasoning” before concluding that Ethernet superseded Wi-Fi because it is faster, all other factors being equal.

Further investigation led to believe I should look into NAT (Network Address Translation). It’s disabled by default, likely because if you need it, you’ll soon learn about it like I’m doing now.

A couple guides later, and I had uncommented a line in a config file to allow IP forwarding, but when I used modprobe ip_forward to add NAT abilities to the kernel, listing out my iptables gave a warning about legacy software.

***

Well, this write up is coming due, so here’s what I’ve got.

I worked with a couple friends on my private Minecraft server –yes the one I’ve covered here before– by the names of doflagie and TheRSC. We didn’t go messing around with NAT tables, but we did inspect the DHCP configuration files some more.

At least, that was the plan at first. I accidentally broke an interface by editing the file there. Rebooting cut off my connection. I SSH’ed in over the other interface and promptly broke that one too. I had to swap around cables to fix those config files, so it was all good.

With my little review from last week out of the way, I went to weed through the actual DHCP config file. I wasn’t sure where it was, but before I resorted to finding it again online, I noticed one terminal on my workstation was already in a local DHCP directory when it wasn’t SSH’ed into somewhere else.

As part of my workflow, I hooked BlinkyPie up to the Ethernet subnet. Thanks to the default Raspian settings, eth0 overrode wlan0 as the default network interface, so I didn’t have to disable or disconnect Wi-Fi. Otherwise, Blinky is standing in for a generic microcomputer on this micronetwork.

It took several hours, but when I rearranged the DHCP config on the Pi4 to reflect the subnet and not the wider home network, I was able to reach out from Blinky through the Pi4. However, I was only allowed to the gateway, and no farther.

These results are underwhelming. Each last problem feels like it is comprised of a chain of smaller problems, leading to another such chain. I’m making progress, but if feels like the goalpost is moving on me.

Final question: How hard should this really be? Sure, there are higher lever programs, but how long should a low-level approach like what I’m doing take to figure out?

Leave a Reply