Shower Thoughts: Hackable Pocket Router

Something I started as a work project but got a little obsessed over was the idea of a Hackable Pocket Router.

This isn’t a raspberry pi or an off-the-shelf router you installed OpenWRT onto. This is a bona-fide Linux system you have ssh access into with multiple native NICs that can do more complex and interesting interactions over a network than just provide a NAT and wireless AP. But how much more?

The Problem

Most of this stems from a question of infrastructure. Working on an engineering network means living in an ever changing space constantly being influenced by devices external to your own.

The network I’m referring to is a /23 that has a DHCP server and a route to the internet, but it doesn’t really have a lot of top-down management beyond that. IT is resistant to govern it because engineers are resistant to being locked in. This is a specific network, but there are many like it. Now you add a bunch of plucky engineers and their stuff. Each one has a managed switch (mostly Extreme) and devices they plug in. The devices are a hodge-podge of development boards, prototypes, production devices, random Single Board Computers (SBCs) that are getting used to make pocket routers, and so on. Many of the devices are themselves networking appliances too, with their own ports and networking services.

Discovery

Most network devices do mDNS discovery on the network. The little m stands for multicast. Multicast is a UDP-based mechanism where you send out packets to lots of devices on the network, and not just from device A to device B (like TCP or UDP unicast). This is great for sharing a lot of information with a lot of network clients, like you would when trying to fan the same data out to a bunch of devices. A discovery daemon uses this by establishing a ‘service’, which it then notifies anyone running an mDNS client about.

Metaphorically, this is like the blue service signs on the interstate that you drive by and see the gas stations or restaurants available at a given exit. It lets you just look where the service is on the network, and then the service you care about will identify the devices capable of that service. This is handy because it saves you from something I’ve previously called “typing in burdensome technical jargon like IP addresses”. This remark was said dripping with sarcasm at the time.

TCP traffic, like a webserver, is from point A to point B. This scales fairly simply and one-dimensionally. If I double my requests to your website, I will go from n requests worth of packets to 2n requests worth. Multicast traffic, however, is Heavy. When I send a multicast packet, I’m not sending it to a single point B. I’m sending it to an entire set of i devices, where i is the number of multicast listeners on the network. Now it’s n*i requests. If I double the number of requests, I don’t go from n to 2n, I go from n*i to 2n*i. It’s still linear but it’s scaling in multiple dimensions, and not favorably.

To make things even worse, after a certain amount of network saturation and packets start to get dropped. Remember that UDP is not inherently protected against loss. There’s no 3 way handshake in the protocol like TCP has. This means that you wind up with situations where response packets get dropped, leading devices to issue more packets doing manual rerequests, which also might never arrive or might never see a response packet. Now consider that it’s not just your one device doing this, but i devices, which occupy half of the damn network.

This is called a multicast storm, and it is unpleasant. Many things can cause it, but it’s frequently slow consumers (CPU or NIC) and overtaxed infrastructure. The problem is ultimately a bottleneck. The solution is either throwing bigger pipes at the problem, or reducing traffic somehow.

RADIUS

FreeRADIUS is a server that provides 802.1x authorizations based on cryptographic details. Odds are you’ve used it even if you haven’t heard of it; WIFI effectively makes use of 802.1x for its authentication scheme. It’s also used to secure network ports against intruding devices, though typically only in corporate networks. I don’t think I’ve seen a serious home implementation of 802.1x over LAN and frankly, I wouldn’t want to have to use one.

I, even with the full leverage and awesome power of the almighty Claude AI at my complete disposal (sarcasm), can not find a way to get an Extreme switch to connect to a RADIUS server reliably when the switch is set to DHCP on that network. The reason for this is because the command requires setting the IP address of the switch as the originator of the request. Fine, but we’re on DHCP on a short lease, because this test network is mercurial if not ephemeral. So even after I set it, a week later it might be off if there’s any power disruption to the switch or the network goes down enough that leases end up getting reset.

If I could guarantee the switch a static IP that wouldn’t collide, then we might have something here, but I can’t and we don’t.

Admittedly not great.

I wonder if I could make a “product” for this for internal work-stuff. Get a cheap board and slap together some firmware to set up the basics. The most basic solution would just be an sdcard image with like, DHCP enabled and iptables set up for NAT forwarding. I could do that over a lunch break. I just need to pick a board and bring the board up first.

(to be continued maybe)