UDP Broadcasting And The Joys Of IPv4 Subnetting

July 14, 2026 by Maya Posch 33 Comments

In the previous installment on UDP broadcasting and service discovery, the basics of both were explored, including an implementation in the form of NyanSD and its protocol. Contained in the comment section was a very good demonstration of why one of the most exciting aspects of software development is the opportunity to share your latest creations with other people. This being the ability to get solid feedback on all the points – including any potential boneheaded omissions – that you really should address, whether intentional or accidental.

The most pertinent point raised was definitely that of broadcast addresses and IPv4 subnets, with the latter topic especially being something that the sysadmins at the office would talk about all the time, but which us software developers were always happy to ignore as something that didn’t concern us. Turns out the joke was on me and everyone else – like our esteemed readers – who thought that they could escape the fascinating world of subnets, as today we’ll take an in-depth look at what subnets are and how they are relevant to the world of UDP network discovery.

I somewhat alluded in the first article to the topic of ‘which broadcast address to use’ as being somewhat of a rough topic to figure out, which is clearly why I just stuck to a blatantly ‘works for me’ /24 subnet that usually will work on networks, until it does not.

Continue reading “UDP Broadcasting And The Joys Of IPv4 Subnetting” →

Linux Fu: The Local Phonebook

July 8, 2026 by Al Williams 30 Comments

I’ll admit it: I miss the simplicity of /etc/hosts. There was something elegant about it. You wanted laserprinter to mean 192.168.1.40, so you opened a text file and wrote:

192.168.1.40 laserprinter

Done. No cloud account, no discovery daemon, no dashboard with material-themed icons. Just a name and an address. The trouble, of course, is that /etc/hosts is only simple when you have one machine. The moment you have a desktop, a laptop, a Raspberry Pi, a NAS, a test box, and a phone or two, every little network change becomes a tiny distributed-database problem. Which copy of /etc/hosts is authoritative? Did you update the laptop? What about the machine you only boot once a month?

One Solution

Modern LANs solved this with mDNS, using Avahi on Linux. It resolves addresses that end in .local. Instead of asking a central DNS server “who is thing.local?”, a machine sends a multicast query on the local network: “who has thing.local?” The device that owns the name answers. This is why your Linux box named spock and usually be reached as spock.local on your LAN.

There are limits. mDNS is link-local; it is meant for the local LAN, not the whole Internet and shouldn’t route across subnets. Each device is supposed to publish its own name. That works fine when the device cooperates. But what about devices that do not publish mDNS? Or little embedded things that barely even have an IP address?

That is where I wanted the best of both worlds: keep a small authoritative /etc/hosts file on one Linux box, but publish selected entries onto the LAN using mDNS.

Continue reading “Linux Fu: The Local Phonebook” →

Homelab Gets Linksys Themed Aesthetic

July 5, 2026 by Zoe Skyforest 20 Comments

If you’re building a homelab rig, you could just use off-the-shelf hardware in standard cases and slap it all in a rack like the normies do. Or, you could follow the example of [Justin Garrison] and build a more oddball setup.

This particular homelab is, at its heart, built from familiar components. There are two Raspberry Pi 5s, two Raspberry Pi 4s, a GMKtec NucBox M6 Mini with an ASUS GeForce RT 2060 GPU, a LattePanda IOTA, an NVidia DGX Spark, and an HP Z4 G4 mini PC. These machines are all laced together with a TP-Link LS108GB PoE switch. [Justin] has the mini PC running the control plane components, with the rig as a whole running Talos and Kubernetes workloads. What makes this build particularly appealing, though, is the aesthetics of the rig. [Justin] documents how he hacked this hardware to fit into a bunch of old Linksys router cases, which provides a pleasant early 2000s look to the build. This included a bit of hackery to get status LEDs flickering as they should be. [Justin] also took the time to make the power buttons accessible.

If you want to stunt on your friends with a rad homelab, you either have to go for maximum power, or maximum style. This build would be the latter. Video after the break.

Continue reading “Homelab Gets Linksys Themed Aesthetic” →

This KVM Runs A P4 Instead Of A Pi.

July 3, 2026 by Tyler August 15 Comments

If you asked us to build you a KVM last week, we’d likely have reached for a Raspberry Pi. Now, thanks to [JonathanRowny], we’d seriously consider an ESP32-P4, because his IP KVM seems pretty capable.

He’s using the P4 hardware to its fullest, getting the supported 1080p graphics, and doing so in an interesting way– he’s got a commercial adapter board to try and translate HDMI signals to the camera input on his dev board. Conveniently enough, it’s the same ribbon-cable pinout as the RPi, which is not guaranteed by the CSI standard. Writing a driver to take that signal proved the hardest part– aside from the usual chip revision confusion that plagues this chip– and we can’t help but wonder if the client on the other side of the KVM-IP link might have an easier time doing the image processing that was required for a good image. Regardless, he’s got the code as it is now up on GitHub under the Apache license.

As of this this writing, there’s no audio, and ironically for an ESP32 project networking is wired-only– but much more importantly, there is no security. So it’s a work in progress, but great to see the P4 in the wild doing something other than emulation. Not that we haven’t seen the P4 at work before–the Tanmatsu handheld also makes use of Expressif’s most powerful chip for a handy little terminal. Between the KVM and the handhelds, we cannot help but wonder how many of the projects that were once the provenance of a Pi will get squeezed into these overpowered microcontrollers. Sure, they can’t even match the original Pi in horsepower, never mind a modern Pi5, but how many times have you seen a Linux SBC seriously under-taxed in a project like this?

If you’re swapping Pi for P4– or doing anything else interesting– please let us know on the tips line.

Continue reading “This KVM Runs A P4 Instead Of A Pi.” →

UDP Broadcasting And Easily Finding Network Services

July 1, 2026 by Maya Posch 25 Comments

Local area networks (LANs) that use technologies like Ethernet and Wi-Fi are incredibly useful for letting devices talk with each other. Yet a core problem here is knowing which devices are where on the network, as anyone who has ever tried to add a network printer or network share to their system can probably attest to. Unless you happen to know the IP address of the LAN device, the port, and protocol, the target device may as well be located on the Moon without further help, such as automatic network discovery in lieu of waddling over to the device and reading the label listing its IP address.

Over the decades quite a few ways have been developed to enable such network discovery, with many of them using UDP broadcast as the first step. By broadcasting a global message on the entire LAN, any device that has an actively listening UDP socket on that particular port can parse said message and decide whether it’s feeling sociable enough to reply.

The topic of UDP broadcasting is however not as straightforward as it may sound if you’re just getting started, including the existence of many opinions on the ‘right way’. There is also a massive divide between a sprawling service discovery protocol like mDNS and a light-weight one like that one that I had to implement a few years ago for an open source project.

Continue reading “UDP Broadcasting And Easily Finding Network Services” →

Linux Fu: Upcycling An Old Router

June 23, 2026 by Al Williams 28 Comments

You’re wandering through a thrift store and spot an old router for ten bucks. Worthless, right? But in this case, it was a Google OnHub, which, at the time, was pretty premium and still isn’t anything to sneeze at. Of course, Google abandoned it long ago, and it runs Chrome, so pass, right? Of course I didn’t. In fact, I bought two for less than $20. The question is always the same: what do you do with it?

OpenWrt will run on the device. That’s a good start, but merely replacing the firmware isn’t much of a project. The more interesting question is whether the hardware can still do something useful. I had a specific need: connect a wired workstation to a reasonably distant WiFi network without running cable and without suffering the usual double-NAT headaches that come from turning the router into yet another subnet. For this, the OnHub turned out to be nearly perfect.

The Hardware

The OnHub was Google’s first Wi-Fi router, built by TP-Link and ASUS in different versions. Mine was the TP-Link model, and one was missing a bit of plastic cowl trim. Under the hood, it has a Qualcomm IPQ8064 dual-core processor — a dual-core ARMv7 — multiple radios, gigabit Ethernet, and enough memory to run OpenWrt comfortably: 1 GB of RAM and 4 GB of flash. The processor also has two network offload processors, but it isn’t clear to me that the stock OpenWrt build uses them.

These devices were expensive when new, but now show up regularly at thrift stores and surplus sales. Installing OpenWrt was straightforward. You do need to remove a screw that covers the magic switch at the bottom, but that’s not a big problem. You can just peel the rubber foot back if you don’t want to remove it. However, the interesting part came afterward.

Continue reading “Linux Fu: Upcycling An Old Router” →

Autopsy Of A Freshly Cooked 10Gbit SFP+ Network Adapter

June 20, 2026 by Maya Posch 20 Comments

With the advent of affordable 2.5 Gbit, 5 Gbit, and 10 Gbit consumer networking gear, more and more people are taking advantage of these higher networking speeds, with [This Does Not Compute] having used 10 Gbit SFP+ modules over regular Cat-5e copper to connect to a NAS in the next room. Only problem was that after a while these SFP+ modules began to start dropping frames. On taking a closer look at these modules, he found that they were running pretty hot: 40°C while idle. A teardown of one of these modules showed severe discoloration due to heat.

Side view of the SFP+ module's PCB. (Credit: This Does Not Compute, YouTube) — Side view of the SFP+ module’s PCB. (Credit: This Does Not Compute, YouTube)

Inside these 10Gbit modules is the Marvell-branded Alaska X 88X3310/40P PHY, which despite the ‘low-power’ claims have a metal heatsink glued onto the actual IC and thermally coupled to the module’s metal enclosure. The other side of the PCB was quite discolored, further indicating how hot these modules run in operation. Some digging revealed that this can go up to around 2.5 watts.

Perhaps the most fascinating part of this teardown is the discovery of an 8051-based MCU that’s responsible for telling the switch the module is put into that it is a 30-meter multi-mode fiber module, presumably for compatibility purposes. It’s definitely an interesting feature of these FS-branded SFP+ modules.

These old modules were replaced with Wiitek-branded modules that are supposed to use only up to around 1.5 watts in operation courtesy of a newer chipset, in the hope that these wouldn’t fry themselves. At idle these do however still run at 30 °C. As noted in the comments, it might be a good idea to have active airflow over high-speed networking gear like this, as they generally can get pretty hot and sometimes crispy.

The final solution for the video’s networking problem was to just run single-mode fiber to the room and use appropriate SFP+ modules for that, also because these run noticeably cooler. If you still have room in your cable ducts, that would seem to be the optimal solution.

Continue reading “Autopsy Of A Freshly Cooked 10Gbit SFP+ Network Adapter” →