Revisiting Making Your Own Internet Router In 2026

After my recent misadventures setting up an OpenWrt installation on a scruffy e-waste-level x86 PC, quite a few people chimed in with feedback, criticism and friendly hostility regarding things like a presumed ‘x86 bias’. There were also some system-related things that simply didn’t seem to want to work, such as booting from an SD card with a USB adapter, which cut short a lot of the actual OpenWrt testing that I had intended. This made it mostly an enlightening look at what issues you can run into when ‘quickly’ throwing an OpenWrt router together with some junk parts these days.

In this second article I’ll try to address as many of these points as possible, as well as attempt to show off an actual working OpenWrt installation in action. In addition, since just using random junk x86 PC parts was the way to go back in the late 90s/early 2000s doesn’t mean that this is still the way in 2026, so I’ll be taking a look at alternatives that exist today. This includes everything from mini PCs, to ancient business PCs being sold for peanuts, as well as more dedicated (ARM-based) hardware solutions.

Continue reading “Revisiting Making Your Own Internet Router In 2026”

How The Banana Pi BPI-R4 Pro Violates The First Rule Of OpenWRT Club

As fun as ARM and RISC-V single-board computers (SBCs) are, all too often getting the most out of the hardware requires the use of an unofficial firmware image. So too with the Banana Pi BPI-R4 Pro router SBC that has been out for a while, as OpenWRT support for it still very much unofficial. This is where [Interfacing Linux] goes on a bit of a rant while assembling one of these puppies into a sleek metal enclosure.

The first rule of OpenWRT Club is of course that you never run an unofficial image on any hardware that’s part of any network you care about. This is somewhat upsetting, as the testing shown in the video below reveals that performance is great when running it.

Currently OpenWRT support is painfully working its way through development, per the OpenWRT PR thread, so there’s hope that official support will appear at some point. As with all of such SBCs the question is always whether official support appears before the hardware has been rendered firmly obsolete. Until then the community Debian 13 image might actually be safer.

Continue reading “How The Banana Pi BPI-R4 Pro Violates The First Rule Of OpenWRT Club”

Between-Device Sharing Still Sucks

Once upon a time, computing was simple. You had files on a floppy disk. If you wanted to take them to a different computer, you ejected the disk from one machine and put it in another. It wasn’t fast, but it was easy and intuitive. Besides, you probably only had one computer of your own, anyway.

Life has since gotten a lot more complex. You’ve got a desktop, a laptop, a work laptop, your personal and business phones, and a smart watch to boot. You live amongst a swirling maelstrom of terabytes of data. Despite all the technical advances that got you here, it’s still a pain to get a file from one device to another, even when they’re sitting on the same desk. Why?!

Continue reading “Between-Device Sharing Still Sucks”

The 8-bit Web Server

Even [maurycyz] doesn’t think it is a good idea, but it is possible to use an AVR 8-bit CPU to serve web pages. Of course, it is a vastly simplified web server, but it does serve pages — OK, technically just one page — to the public Internet.

Working backward, it is fairly easy to get the microcontroller to note an HTTP request and then simply spit out a prerecorded HTTP response to provide the page. The hard part is connecting the little processor to the network. The server is dead simple, just a CPU and a scant number of components like filter caps and LEDs. The trick is to use SLIP, an ancient protocol used to connect dial-up modem terminals to the network.

Linux supports SLIP, so the MCU connects to a Linux computer via SLIP. Then the Linux computer uses WireGuard to network with the remote web server that serves [maurycyz’s] site. The SLIP implementation assumes that IP packets aren’t fragmented, which is normally true these days. TCP was a bit more complicated since you have to track the connection state and possibly re-transmit lost packets. Still, nothing the AVR with 8 K of RAM and 64 K of flash can’t handle.

Practical? No. Cool? Sort of. Funny that a disposable vape has more CPU power. Of course, something like an ESP32 is an obvious choice.

A black screen with green text is shown. The green text logs events from a VPN gateway.

Running A VPN Gateway On An ESP32

If you need a VPN gateway to access your home network, the fastest and most cost-effective way is probably by using a Raspberry Pi Zero. But in [Samir Makwana]’s view, an ESP32-S3 is just as capable for moderate use, and in some respects even superior.

This was possible thanks to the MicroLink project, which is a full implementation of a Tailscale client for the ESP32 family. In some ways the ESP32 worked better than a Raspberry Pi: it boots in two seconds rather than thirty, draws 0.5 Watts rather than 1.5, and there’s no chance of it failing due to a corrupted SD card. Compared to a Raspberry Pi, however, which can be set up as a Tailscale client in a few minutes, this took several hours to get running. The biggest issue was making sure that there was enough memory available for TLS handshakes, which was solved by enabling the ESP32’s PSRAM.

Once the VPN client is running, the ESP32 can be used as an SSH jump machine to access other devices on the home network, without needing to expose those machines to the open Internet. The ESP32 also hosts an HTTP server which can send a wake-on-LAN magic packet to another device on the local network, letting unused devices sleep without impairing their availability.

The ESP32 doesn’t provide much bandwidth — streaming video would cause issues — but it works well enough for lightweight applications. If you’re wanting to stream video from an ESP32, though, it is technically possible.

Network Scanner Finds Every Raspberry Pi

DHCP is great for getting machines on the network with a minimum of fuss. However, it can also make remote administration a pain because you never know which IP you’re supposed to be SSHing into. [Philipp] ran into this problem quite often, so decided to whip up an app to make things easier. 

At it’s heart, the app is a simple network scanner—of which many already exist. However, [Philipp] had found that many options on Android were peppered with ads that made them highly undesirable to use. Thus, he whipped up his own, with a particular eye to working with the Raspberry Pi. It’s not uncommon for a hacker to have a few scattered around the home network, and it can be a real chore keeping track of where they all end up in IP land. The scanner can specifically single out the Raspberry Pi boards on the network via MAC-OUI and mDNS detection. Plus, just in case you need it, [Philipp] threw in some GPIO pinouts and electronics calculators just to make the app more useful.

If you’ve been looking for an open-source network scanner without all the ugly junk, this project might just be for you. You can also check out the source over on Github if that’s relevant to your interests. We’ve seen some interesting custom network scanners before, too. If you’re whipping up some fun packet-flinging software of your own, don’t hesitate to notify the tipsline!

Encrypting Encrypted Traffic To Get Around VPN Bans

VPNs, Virtual Private Networks, aren’t just a good idea to keep your data secure: for millions of people living under restrictive regimes they’re the only way to ensure full access to the internet. What do you do when your government orders ISPs to ban VPNs, like Russia has done recently?  [LaserHelix] shows us one way you can cope, which is to use a ShadowSocks proxy.

If you’re not deep into network traffic, you might be wondering: how can an ISP block VPN traffic? Isn’t that stuff encrypted? Yes, but while the traffic going over the VPN is encrypted, you still need to connect to your VPN’s servers– and those handshake packets are easy enough to detect. You can do it at home with Wireshark, a tool that shows up fairly often on these pages. Of course if they can ID those packets, they can block them.

So, you just need a way to obfuscate what exactly the encrypted traffic you’re sending is. Luckily that’s a solved problem: Chinese hackers came up with something called Shadowsocks back in 2012 to help get around the Great Firewall, and have been in an arms-race with their authorities ever since.

Shadowsocks is not, in fact, a sibling of Gandalf’s horse as the name might suggest, but a tool to obfuscate the traffic going to your VPN. To invert a meme, you’re telling the authorities: we heard you don’t like encrypted traffic, so we put encryption in your encrypted traffic so you have to decrypt the packets before you recognize the encrypted packets.

What about the VPN? Well, some run their own shadowsocks service, while others will need to be accessed via a shadowsocks bridge: in effect, a proxy that then connects to the VPN for you. That means of course you’re bouncing through two servers you need to trust not to glow in the dark, but if you have to trust someone– otherwise it’s off to a shack in the woods, which never ends well.

Don’t forget that while VPNs can get you around government censorship, they do not provide anonymity on their own. If, like tipster [Keith Olson] –thanks for the tip, [Keith]!– you’re looking side-eyed at your government’s “think of the children!” rhetoric but don’t know where to start, we had a discussion about which VPNs to use last year.