How Fast Does Claude, Acting as a User Space IP Stack, Respond to Pings?

Here is a fun thought: if we ask Claude Code to act as a user space IP stack, how quickly will it be able to respond to a ping?

That is, we instruct Claude to read IP packets, byte by byte, and process them as a normal IP stack would do. With the end result being that we can ping Claude and have it reply to us with a properly formed ping reply.

Ridiculous? Yes. Wasteful of tokens? Sure. Fun? Oh yeah!

I asked Claude to develop a command, ping-respond.md, that would act as such a native LLM IP stack, and this is what it came up with:

ping-respond.md (click to expand)

# Ping Respond — Process one ICMP echo request from tun0

You are acting as a userspace IP stack. The TUN helper is already running in FIFO mode (`sudo python3 scripts/tun_helper.py --fifo`). Your job: read one packet, parse it, construct a valid ICMP echo reply, and write it back. All IP logic happens in your reasoning — no libraries, no scripts.

## Step 1: Read a packet

Run this bash command to read one packet from the TUN device:

echo "READ" > /tmp/tun_cmd && timeout 35 cat /tmp/tun_resp

You will get back a hex string (or "TIMEOUT"). If TIMEOUT, report it and stop.

Save the hex string — this is the raw IPv4 packet.

## Step 2: Parse the IPv4 header

The packet is a sequence of hex bytes (2 hex chars = 1 byte). Parse these fields:

| Offset (bytes) | Length | Field                                                     |
| -------------- | ------ | --------------------------------------------------------- |
| 0              | 1      | Version (high nibble) + IHL (low nibble, in 32-bit words) |
| 1              | 1      | DSCP/ECN                                                  |
| 2–3            | 2      | Total length                                              |
| 4–5            | 2      | Identification                                            |
| 6–7            | 2      | Flags (3 bits) + Fragment offset (13 bits)                |
| 8              | 1      | TTL                                                       |
| 9              | 1      | Protocol (must be 0x01 = ICMP)                            |
| 10–11          | 2      | Header checksum                                           |
| 12–15          | 4      | Source IP                                                 |
| 16–19          | 4      | Destination IP                                            |

IHL tells you the header length: IHL × 4 bytes. Standard is IHL=5 → 20 bytes.

If protocol is not 0x01, report "not ICMP, ignoring" and stop.

## Step 3: Parse the ICMP header

The ICMP header starts right after the IP header (at byte offset IHL×4):

| Offset (from ICMP start) | Length   | Field                              |
| ------------------------ | -------- | ---------------------------------- |
| 0                        | 1        | Type (must be 0x08 = echo request) |
| 1                        | 1        | Code (must be 0x00)                |
| 2–3                      | 2        | ICMP checksum                      |
| 4–5                      | 2        | Identifier                         |
| 6–7                      | 2        | Sequence number                    |
| 8+                       | variable | Payload (copy unchanged)           |

If type is not 0x08, report "not echo request, ignoring" and stop.

## Step 4: Construct the echo reply

Build the reply packet by modifying specific fields. Work in hex throughout.

### 4a: IP header for the reply

Start with the original IP header bytes and change:

- **Byte 8 (TTL):** set to `40` (decimal 64)
- **Bytes 10–11 (header checksum):** set to `0000` temporarily
- **Bytes 12–15 (source IP):** set to the original **destination** IP
- **Bytes 16–19 (destination IP):** set to the original **source** IP

Now compute the IP header checksum:

1. Take the IP header (IHL×4 bytes) with checksum field = 0000
2. Split into 16-bit words (2 bytes each)
3. Sum all words as unsigned integers
4. While the sum exceeds 0xFFFF: add the carry (sum >> 16) to the lower 16 bits (sum & 0xFFFF)
5. Take the one's complement: result = 0xFFFF - folded_sum
6. Write this value into bytes 10–11 (big-endian)

### 4b: ICMP payload for the reply

Start with the original ICMP data (from ICMP start to end of packet) and change:

- **Byte 0 (type):** set to `00` (echo reply)
- **Byte 1 (code):** keep `00`
- **Bytes 2–3 (ICMP checksum):** set to `0000` temporarily
- **Bytes 4+ (identifier, sequence, payload):** keep unchanged

Now compute the ICMP checksum using the same algorithm as the IP checksum:

1. Take the entire ICMP message (type through end of payload) with checksum field = 0000
2. Split into 16-bit words. If odd number of bytes, pad with one zero byte at the end for checksum computation only.
3. Sum all words as unsigned integers
4. Fold carries: while sum > 0xFFFF, do sum = (sum >> 16) + (sum & 0xFFFF)
5. One's complement: result = 0xFFFF - folded_sum
6. If result is 0x0000, use 0xFFFF instead
7. Write into ICMP bytes 2–3 (big-endian)

### 4c: Assemble the reply

Concatenate: IP header (with correct checksum) + ICMP message (with correct checksum)

## Step 5: Write the reply

Run this bash command with your assembled hex string:

echo "WRITE <your_hex_here>" > /tmp/tun_cmd && timeout 5 cat /tmp/tun_resp

You should get "OK" back.

## Step 6: Report

Print a summary:

- Source IP → Destination IP
- ICMP echo request seq number
- Packet sizes (request and reply)
- "Reply sent successfully" or any error

## Important rules

- Do ALL arithmetic yourself. Do not use Python, bc, or any calculator tool.
- Show your work for checksum calculations so errors can be debugged.
- Every hex value you produce must have the correct number of digits (pad with leading zeros).
- If anything looks wrong (bad version, unexpected protocol), report it and stop rather than sending a malformed packet.

The command reads bytes from a /dev/tun0 device, with a thin Python helper to get all the stty options right, then computes the IP checksum and, if it sees an ICMP echo message, it responds with an ICMP echo reply message, with all the checksums computed correctly.

Running this will make Claude produce output like this:

  Received packet: 45000054812840004001615dac100001ac100002080054f5000d0001a1fb006a0000000041c4000000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637

  Parsing the IP header (first 40 hex chars = 20 bytes):
  - 45 → version=4, IHL=5 (20 bytes)
  - 0054 → total length = 84
  - TTL=40 (64), Protocol=01 (ICMP)
  - Source: ac100001 = 172.16.0.1
  - Dest: ac100002 = 172.16.0.2

  ICMP: type=08 (echo request), code=00, id=000d, seq=0001

  Now constructing the reply. IP header: swap src/dst, TTL=64, recompute checksum. ICMP: type=00 (echo reply), recompute checksum.

  IP header checksum — header with zeroed checksum and swapped IPs:
  4500 0054 8128 4000 4001 0000 ac10 0002 ac10 0001

  Sum: 4500+0054+8128+4000+4001+0000+ac10+0002+ac10+0001 = 0x29F20
  Fold: 0x9F20+0x2 = 0x9F22
  Complement: 0xFFFF-0x9F22 = 0x60DD

  ICMP checksum — type changed 08→00, checksum zeroed:
  Original checksum 54F5 corresponded to folded sum 0xAB0A. Changing type 08→00 reduces sum by 0x0800: 0xAB0A-0x0800 = 0xA30A.
  Complement: 0xFFFF-0xA30A = 0x5CF5

  Reply packet: 4500005481284000400160ddac100002ac10000100005cf5000d0001a1fb006a0000000041c4000000000000101112131415161718191a1b1c1d1e1f202122232425262728292a2b2c2d2e2f3031323334353637

And we get results!

$ ping -W 300 -c 1 172.16.0.2
PING 172.16.0.2 (172.16.0.2) 56(84) bytes of data.
64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=42593 ms

--- 172.16.0.2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 42592.723/42592.723/42592.723/0.000 ms

This one was run with Haiku 4.5, which is a pretty fast model. But with a round-trip time of 45 seconds, that’s a slow ping. Not quite as slow as these ones though.