Constructing a Bespoke Network Stack

Running Your Own ISP PH II (DN42): Everyone Should Build Their Own Internet~~(x)~~ Category: ISP@home | Date: 2026-06-14 | Author: lyc8503

[!IMPORTANT] This text is a rewritten version of an experimental translation. For the absolute source of truth, please consult the original Chinese publication.

This post serves as a tangential entry in the ISP@Home series. At this point, the project has officially transitioned into ~~meme territory~~ experimental art. If you find the technical context lacking, I suggest revisiting my previous entries.

🌐 The Philosophical Preface

Consider a nightmare scenario: an LLM or a malicious actor discovers a critical Remote Code Execution (RCE) vulnerability within the mainstream Linux kernel's network stack.

Because Linux is the backbone of the modern web, a single flaw would create a systemic collapse. Every single host would be vulnerable simultaneously. To counter this, I propose a radical solution: True Decentralization.

In an ideal world, every user would implement their own unique network stack. If one implementation is compromised, the rest of the global network remains resilient.

$\text{Network Resilience} \propto \frac{1}{\text{Homogeneity of Implementations}}$

This curiosity started during my time at NJU, where I felt a sudden impulse to build a network stack just for the sake of it. Since DN42 wasn't chaotic enough, I decided to deploy my custom stack there—and perhaps one day, on the IANA-assigned internet—to host actual services.

🛠️ Project: DNet

I previously documented some of this under the name DNet (available at https://github.com/lyc8503/DNet-core). The project's core milestones included:

Establish a Linux TAP device for raw frame I/O.
Implement Ethernet frame parsing.
Handle ARP (Address Resolution Protocol) requests and replies.
Parse IPv4 packets and manage ICMP echo requests (ping).
Facilitate the transmission and reception of UDP packets.

The Current State of Play

After four years of dormancy, I've revived the project, fixed several bugs, and implemented a rudimentary DNS server. This server now acts as the authoritative DNS for my DN42 domain: 42420167.xyz.

Proof of Concept

If you execute the following command from any connected machine: dig TXT sgp1.dn42.42420167.xyz

You will receive a response generated entirely by my hand-coded stack:

# dig TXT sgp1.dn42.42420167.xyz
; DiG 9.18.39-0ubuntu0.24.04.5-Ubuntu TXT sgp1.dn42.42420167.xyz
;; global options: +cmd
;; Got answer:
;; - HEADER - opcode: QUERY, status: NOERROR, id: 21546
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION: ;sgp1.dn42.42420167.xyz.

20 IN TXT PubKey: 8BKrEUrqba9mCzYHqWD2uTNtvrcYcKAls3vBQrY6dxE= sgp1.dn42.42420167.xyz.
20 IN TXT Looking Glass: http://sgp1.dn42.42420167.xyz:5000/ sgp1.dn42.42420167.xyz.
20 IN TXT Endpoint: sgp1.dn42.42420167.xyz:2xxxx (xxxx is the last 4 digits of your ASN)
;; Query time: 11 msec
;; SERVER: 223.5.5.5#53(223.5.5.5) (UDP)
;; WHEN: Sat Jun 13 22:22:39 CST 2026
;; MSG SIZE rcvd: 397

For those already inside the DN42 network, you can interact with the stack directly via IP 172.20.42.224 (e.g., ping 172.20.42.224).

Logic Flow of DNet

🏗️ Infrastructure Evolution

Recently, I attempted to migrate my VPS fleet to NixOS using what I call "vibe coding" (coding by intuition/guessing). Because I don't actually master the Nix language, the configuration became an unmaintainable disaster that broke unpredictably during deployments.

I have since performed a total wipe and returned to Debian.

Comparison of Approaches

Feature	NixOS (Vibe Coding)	Debian + pyinfra
Stability	📉 Unpredictable	📈 Solid
Maintainability	❌ Nightmare	✅ Manageable
Deployment	Random Failures	Consistent
Tooling	Nix Expression	`pyinfra` (Python)

I am now utilizing pyinfra (found at lyc8503/infra) and managing all DN42 services via Docker Compose. This strategy allows me to leverage Docker's network namespaces to ensure each service starts in a pristine environment, effectively eliminating configuration drift.

🏁 Afterword

And that is the end—this post concludes as abruptly as it started. This was simply a showcase of my latest "troll project" rather than a deep technical dive into the source code.

Lately, I've noticed that DN42 feels a bit empty. Most of the traffic consists of basic BGP and ICMP; there aren't many actual applications running, which leaves little room for creative mischief.

Unless a new spark of inspiration hits me, the DN42 series will likely end here.

License: CC BY-NC-SA 4.0 Author: lyc8503 Original Link: blog.lyc8503.net

If you enjoyed this madness, consider buying me a coffee ¬_¬