Claude as a User-Space IP Stack: A Deliberately Absurd Ping Experiment

Adam Dunkels takes one of the stranger ideas you could try with Claude Code and runs it all the way down the stack: can an LLM act like a user-space IP stack and respond to a ping? The answer is yes, and the result is both technically real and gloriously inefficient, which makes it exactly the kind of experiment that tells you something interesting about the boundaries of Claude-based systems.

Key Points

The core idea is to ask Claude Code to read a raw IPv4 packet from a TUN device and generate a valid ICMP echo reply.
The setup uses a small helper around /dev/tun0 to make packet I/O workable in FIFO mode.
Claude is prompted to do all the packet parsing and checksum arithmetic itself, without external code or calculator tools.
The generated command, ping-respond.md, walks through:
- reading one packet,
- parsing the IPv4 header,
- confirming the protocol is ICMP,
- parsing the ICMP echo request,
- swapping source and destination IPs,
- recomputing the IP and ICMP checksums,
- writing the reply back.
The article includes a concrete example packet and Claude’s step-by-step reasoning for building the reply.
The resulting ping works: a ping to 172.16.0.2 gets a response, but with an absurd round-trip time of about 45 seconds.
The author notes this was run with Haiku 4.5, and calls out that it is “pretty fast” for this kind of task, which is a funny sentence in context.
The point is not practicality; it is to stress-test the idea that Markdown can be treated like code and an LLM can be treated as the processor executing that code.

My Take

What strikes me is that this is both a joke and a genuine systems demo. I think that combination is where a lot of the interesting Claude Code work lives right now: you start with a playful constraint, then discover that the model can actually follow a low-level protocol well enough to do something that looks like infrastructure.

I also think the checksum walkthrough is the most interesting part. Not because anyone should build a production network stack this way — obviously not — but because it shows how far you can push structured reasoning when the task is fully spelled out. If you are a Claude Code user, the real lesson is not “replace your kernel with an LLM”; it is “Claude can sometimes execute precise, multi-step procedural logic if you constrain the interface hard enough.”

What worries me a bit is how easy it is to mistake a successful demo for a scalable pattern. This is a very controlled environment with one packet at a time, explicit instructions, and a helper process doing the ugly plumbing. I’d be curious whether the same pattern stays reliable under load, with noisy inputs, or with more complex protocol behavior. My guess is that the answer gets messy quickly.

Still, I’d absolutely try this kind of thing as an experiment. Not because I want a ping responder that takes 45 seconds, but because it is a sharp way to explore what Claude is good at when the task is narrow, formal, and highly inspectable. For developers building with Claude, that is the real takeaway: use the model where clear structure can substitute for breadth, not where you need raw systems performance.

The punchline is simple: an LLM can be coaxed into acting like a network stack, but the latency reminds you exactly what kind of machine you’re talking to. It’s a clever proof of concept, and a very good reminder to keep your expectations grounded.