A while back, I managed to get XNET running on a Linksys WRT54G, and it worked. Like the Wii XNET relay experiment, it was mostly something I did to see if it was possible. Recently, I found another WRT54G v2.2 at my local Goodwill for $5 and decided to revisit the project. This time, instead of just getting it running and calling it a successful experiment, I want to turn it into something stable and reliable enough for other people to actually use. Once it's ready, the firmware, relay source, build process, and documentation will all be open source.
The hardware I'm developing this around is a Linksys WRT54G v2.2, one of the Linux-capable versions of the WRT54G from the original Xbox era. There's not much hardware to work with, which is part of what makes this project interesting.
| Component | Specification |
|---|---|
| Model | Linksys WRT54G v2.2 |
| SoC | Broadcom BCM4712 |
| CPU | 216 MHz, single-core |
| Architecture | 32-bit MIPS |
| RAM | 16 MB SDRAM |
| Flash | 4 MB NOR flash |
| Ethernet Switch | Broadcom BCM5325E |
| LAN | 4 × 10/100BASE-T |
| WAN | 1 × 10/100BASE-T |
| Wireless | 2.4 GHz 802.11b/g |
| Radio | Broadcom BCM2050 |
| Bootloader | Broadcom CFE |
| Serial | Internal 3.3V TTL |
| JTAG | Internal JTAG interface |
| Factory Firmware | Linksys v3.03.1 |
| Target OS | OpenWrt Backfire 10.03.1 |
| Target Kernel | Linux 2.4 |
| Target Relay Port | TCP 7777 |
That's the entire machine. There are 16 MB of RAM and 4 MB of flash for everything, including the operating system, drivers, networking services, configuration, and XNET itself. The CPU is a 216 MHz Broadcom MIPS processor from more than twenty years ago, so there isn't room for a modern runtime or a bunch of unnecessary services.
The WRT54G itself will operate as the XNET relay. It won't be acting as a gateway that forwards connections to another server, and your Xbox doesn't need to be physically connected to it or even be on the same network. Once the router is online and reachable, XNET users can connect to it over the Internet just like any other XNET relay.
Rather than trying to squeeze the existing relay stack onto hardware this limited, I'm building a dedicated implementation specifically for the WRT54G. The current approach uses OpenWrt Backfire as the base with a native POSIX C implementation of the XNET relay. It is being written around Linux 2.4 compatibility using non-blocking sockets, select() based networking, small fixed buffers, bounded memory allocations, and as few dependencies as possible.
There won't be Node.js, Python, a database, or a large runtime sitting in the background. The target is to keep the stripped XNET relay executable itself under 50 KB. The current design uses roughly 12 KB of send buffering and 8 KB of receive buffering per client, with the total relay buffer allocation for sixteen clients landing in the neighborhood of 330 KB. The implementation is being kept POSIX-only so it can be built against the historical OpenWrt toolchain without pulling in modern dependencies.
The initial target is four simultaneous rooms and sixteen connected clients. Those limits are intentional rather than arbitrary; I want resource consumption to remain predictable instead of letting a busy relay consume whatever little memory the router has available. Client tables, room tables, buffers, and other major allocations are bounded ahead of time. All client sockets use non-blocking I/O, the main event loop uses select(), and the daemon uses a simple one-second timeout for housekeeping instead of relying on newer Linux functionality that isn't available on this platform.
The relay itself handles the XNET handshake, room creation, joins, client state, timeouts, and packet forwarding. It also has to correctly handle partial socket writes, disconnected clients, room destruction, pending joins, rate limiting, and the other things that become important when the goal changes from "I got it running" to "I can leave this running." The WRT54G doesn't need to inspect the contents of the encrypted communications passing through it; its job is to manage the connections and move the traffic where it belongs.
The finished setup is intended to behave more like a small XNET appliance than a normal consumer router with some extra software installed. The relay will start automatically when the router boots, listen for XNET connections on TCP 7777, and run independently without another computer or XNET server behind it.
A console connecting from somewhere else on the Internet will be talking directly to the WRT54G. The WRT54G isn't forwarding that XNET connection to one of my normal servers. The WRT54G is the server.
Because resources are so limited, I'm also stripping away services the appliance doesn't need. The current plan is to disable Wi-Fi by default and remove or disable unnecessary web and network services where practical. Dropbear SSH can remain available for administration, while the XNET relay gets the majority of the available resources. The WAN interface will use DHCP, and the firmware configuration will automatically bring the relay online after the network is available.
I'm also planning an optional feature that I think could make these small relay nodes much more useful. Individual XNET relays will be able to report in to a master relay and announce that they're online. A WRT54G can still operate completely independently, but if you choose to associate it with a master XNET relay, it can periodically check in with information such as its address, port, status, and availability.
The master relay would maintain awareness of the nodes that have reported in and make those available to the XNET clients connected to it. If your client is connected to the master and several other relays are currently online, you'll be able to see those nodes and connect directly to one of them. The master isn't intended to proxy the resulting session or carry all of that traffic itself. It provides the discovery point, and once you select another relay, your client connects directly to that node.
This means someone running their own XNET infrastructure could have a normal Linux server acting as the master with several smaller relays reporting into it from different networks or locations. Those nodes could be WRT54Gs, Wiis, Linux machines, or other hardware I eventually get XNET running on. They could be public community nodes or an entirely private collection of relays operated by a group of friends.
The goal is to eventually spider-web XNET across a collection of cheap, independently operated relay nodes instead of making everything depend on a single central server. You might have a $5 WRT54G running in one location, an old Wii somewhere else, another WRT54G at a friend's house, and a few normal servers mixed in. Each can operate as a real XNET relay, while the optional reporting system gives them a way to announce themselves to a larger network.
That also makes it possible to build your own personal XNET network. You could run one master and deploy inexpensive sub-relays wherever you want them. If one relay disappears, the others are still independent nodes. If you don't want a node advertised, don't have it report in. The master provides discovery without becoming a requirement for the relay itself to function.
The original WRT54G project was about proving I could make it work. This version is about making it something other people can build, flash, deploy, and maintain themselves. Once I've finished stabilizing it and have enough real-world testing behind it, I'll release the WRT54G relay source, OpenWrt integration, build configuration, installation process, recovery information, and documentation on GitHub.
I'm also working toward making the firmware itself reproducible so someone with a compatible WRT54G doesn't need to understand the entire development process just to bring up a node. For anyone who does want to modify it, the native C source and OpenWrt build configuration will be there to experiment with.
The initial development target is the WRT54G v2.2 with the BCM4712, 16 MB RAM, and 4 MB flash, because that's the hardware I have in front of me and can actually test. Other WRT54G revisions will need to be evaluated individually rather than assuming a firmware image built for the v2.2 is safe to flash onto every blue Linksys router ever made.
The proof of concept has already been successful. The current work is focused on the native C relay, OpenWrt integration, memory management, connection handling, stability, and getting the deployment process to the point where I can hand it to somebody else without needing to stand over their shoulder.
The current target is TCP 7777, four rooms, sixteen clients, and a stripped relay binary under 50 KB. Once the core relay is stable on actual WRT54G hardware, I'll move on to the optional master reporting and relay discovery system and start testing how well multiple independent nodes can work together.
There are obviously much easier ways to host an XNET relay in 2026, but that's part of what makes this fun. I found a router from the original Xbox era at Goodwill for five bucks, and I'm turning it into an open-source XNET relay capable of handling connections between original Xbox consoles across the Internet.
If enough people decide to do the same thing, those cheap old routers stop being individual experiments and start becoming pieces of a much larger XNET network.