Getting my own Linux environment running on an ISP router was only half the experiment. Once I had the LAN port working, I finally had something useful to build on.
The obvious question was: How much can I actually do with this little box?
Quite a bit, as it turned out.
This is a summary of my original write-up. For the complete technical aspects, including the hardware investigation, UART access, bootloader exploration, firmware limitations, and the decisions that led to the final network architecture, read the original article: https://medium.com/@hiruthicsha/i-finally-hacked-my-isp-router-and-turned-it-into-a-mini-pc-part-1-ffc33cb81b1c
A website running on a router
I started with something relatively simple: hosting a website directly from the router.
Using BusyBox's HTTP server, I deployed my personal website onto the router's RAM-based filesystem. It wasn't just a proof of concept. I verified that all 122 files were being served and tested multiple concurrent downloads.
At one point, eight simultaneous downloads reached approximately 10 MB/s.
For a device originally intended to provide internet connectivity, that was a satisfying result.
Turning it into a monitoring dashboard
Next, I wanted to understand what was happening inside the device.
I started collecting information from Linux's /proc filesystem, exposing system metrics through JSON endpoints and building a dashboard to display them.
CPU usage, memory consumption, network activity, and other system information became accessible through a simple interface.
It was a useful way to monitor a device that otherwise offered very little visibility into its internals.
Building a DNS-based ad blocker
The next experiment was DNS-based blocking.
Rather than installing an entirely new DNS stack, I worked with the existing vendor-provided dnsmasq implementation and configured it to use a blocklist containing 71,492 domains.
The idea was simple: let the router handle DNS filtering for connected devices.
I also kept the blocking opt-in, rather than forcing every device on the network through it.
Wi-Fi, networking, and hardware limitations
Getting Wi-Fi operational opened up another set of experiments.
I wanted to go beyond simply providing wireless connectivity. Network isolation was one of the things I wanted to explore, particularly whether I could separate devices and control how they communicated.
This is where the proprietary Realtek networking implementation started becoming a challenge.
The hardware switch handled parts of the network traffic independently of the Linux networking stack. That meant some of the tools and configurations I expected to work didn't behave as they normally would on a conventional Linux machine.
I experimented with port isolation and other network controls. One attempt even left SSH hanging and forced me back to the serial console to recover the device.
Trying to control bandwidth
I also built a connected-device panel that combined the bridge's MAC address table with the ARP table to identify devices on the network.
The next step was per-device bandwidth control using Linux traffic control (tc).
The configuration appeared correct. The traffic-control classes and filters were created, and the configured limits looked right.
But the actual download speeds told a different story.
Realtek's hardware fast-bridge path was forwarding traffic without passing through the normal Linux networking path. My tc rules couldn't control traffic that wasn't reaching them.
I explored the available hardware bandwidth controls and driver interfaces but couldn't get reliable per-device bandwidth enforcement working.
It was a useful reminder that having root access doesn't necessarily mean having complete control over the hardware.
Running my own code on the router
Before building applications, I wanted to answer a simpler question: could I actually run a program of my own on this hardware?
I didn't even have a working cross-compiler at that point. So I hand-assembled a tiny MIPS executable, transferred it over the serial connection, and ran it directly from the router's RAM.
It was only a tiny program that printed a message and exited, but it proved something important: I could execute my own code on the router without modifying its firmware or replacing its kernel.
So, was it worth it?
The router didn't become a conventional mini-PC, and not every experiment worked.
But I managed to host a website, build a monitoring dashboard, implement DNS-based blocking, bring up Wi-Fi, and explore networking features that weren't exposed through the original interface.
More importantly, I learned how the vendor's proprietary networking stack interacted with the Linux environment underneath it.
Again, this is a summary of my original write-up. For the complete technical aspects, including the hardware investigation, UART access, bootloader exploration, firmware limitations, and the decisions that led to the final network architecture, read the original article: https://medium.com/@hiruthicsha/i-finally-hacked-my-isp-router-and-turned-it-into-a-mini-pc-part-1-ffc33cb81b1c
Top comments (0)