tailscale-mpe-rust

How big is Tailscale itself? Under 500 kB.

Subtract the WiFi + esp-idf runtime any networked ESP32 project already has (a 998 kB baseline), and the Tailscale functionality alone adds:

A complete Tailscale node — control plane, WireGuard, NAT traversal and relay fallback — in under half a megabyte. The full demo (in-tunnel webserver, mDNS reflector, outbound, dual-core, …) adds +511 kB (~1.5 MB total). No tailscaled, no Go runtime.

And RAM? ~2 kB static.

Comparing total static SRAM is misleading — most of it (~116 kB here) is the shared esp-idf + WiFi framework that every networked ESP32 firmware already carries. On top of that baseline, the Tailscale layer adds only ~2 kB of static SRAM (its .data+.bss): the protocol runs from flash and the heap, not static RAM. (Runtime tunnel buffers + worker-thread stacks use heap on top, like any networked app.) So "how much RAM does adding Tailscale cost?" → about 2 kB.

How it compares

Other ESP32 Tailscale efforts, by static SRAM (the number this niche markets on). n/p = not published.

Total static SRAM is on par with the C client (~118 vs ~116 kB for a WiFi build — most of it is the shared esp-idf/WiFi framework both carry). The difference: Rust (memory-safe), a portable no_std core reusable beyond the ESP32, and a ~2 kB incremental RAM cost.

What works

• Control plane (ts2021): registers with Tailscale SaaS (browser auth or headless pre-auth-key), persists across reboots, goes green in the admin console. Frugal netmap parse that fits in ~287 KB of heap.
• WireGuard data plane (initiator & responder, multiple tunnels): LAN direct via disco; remote direct via STUN + CALL_ME_MAYBE hole-punching (with a birthday-paradox port spray for symmetric NAT); encrypted DERP relay fallback over real TLS.
• In-tunnel services: answers ping (IPv4) and ping6 (its fd7a:… IPv6 address), serves a small HTTP page, and can initiate ICMP/UDP/TCP out the tunnel.
• mDNS reflector across two LANs, packet-filter (netmap ACL), and subnet-router / exit-node route advertisement.
• Per-service TCP proxy (opt-in): a peer reaches one service on the dongle's LAN through the tunnel (no full subnet-router needed).
• Dual-core WireGuard decrypt for ~1.6× throughput.

Portable no_std core

Protocol logic lives in a platform-independent tailscale-core crate (#![no_std] + alloc); the ESP32 firmware is a thin adapter for the OS bits (WiFi/UDP/TLS, NVS, the ST7735 display). Migrated so far: icmp, stun, disco, wg, outbound, tcp, peers, and the pure parts of node. Proven genuinely std-less: the core + all crypto deps compile for a bare-metal target (riscv32imc-unknown-none-elf). The same wg.rs is reused unchanged by the host benchmark tool.

Benchmarks (T-Dongle S3 @ 240 MHz, both LX7 cores)

Measured with a host WireGuard load generator that handshakes directly with the dongle over the LAN (no path drift onto DERP), flooding inner UDP and reading the device's reflected RX rate.

Bottleneck: pure-Rust ChaCha20-Poly1305 on the LX7 (no hardware ChaCha). Dual-core decrypts on both cores in parallel with unchanged latency — a strict win. Great for control / IoT / SSH / discovery; not a bulk-transfer gateway.

Flash size

App image size (bytes written to flash), via espflash save-image.

~1.5 MB total — a small fraction of the dongle's flash. WiFi SSID / password (and an optional auth key) are build-time options you fill into src/config.rs (git-ignored).

Extra flash per feature

Build & flash

# 1. Provide your WiFi creds (git-ignored, never committed)
cp src/config.rs.example src/config.rs
$EDITOR src/config.rs        # set WIFI_SSID + WIFI_PASS

# 2. Build + flash (esp-rs Xtensa toolchain + espflash)
. ~/export-esp.sh
cargo build --release
espflash flash --monitor --port /dev/cu.usbmodemXXXX \
  --bootloader  target/xtensa-esp32s3-espidf/release/bootloader.bin \
  --partition-table target/xtensa-esp32s3-espidf/release/partition-table.bin \
  target/xtensa-esp32s3-espidf/release/tailscale-rust

First boot without an auth key prints a login URL on the serial console — open it to add the node to your tailnet. Then ping 100.x.y.z or browse http://100.x.y.z/.

Motivation — a low-latency nervous system for machines

Humanoid robots, vacuum cleaners, drones, self-driving cars and boats — the coming wave of autonomous machines has to coordinate, and coordination is bounded by latency. A cloud round-trip costs tens to hundreds of milliseconds; two machines in the same room, or across town over 5G, can reach each other directly in a few.

Tailscale already gives every device a flat, encrypted, NAT-traversing address space where peers connect directly, peer-to-peer (hole-punched WireGuard), relaying only when they truly must — exactly the substrate machines need: local-first, lowest-latency, no central server in the hot path.

The catch: the stock Tailscale stack (Go + tailscaled) is too heavy for the cheapest, most numerous devices — the microcontrollers that will live inside those robots and appliances. This project shows the whole client fits in under half a megabyte of portable, no-std Rust on a ~$10 chip. So the smallest, cheapest device can be a first-class mesh node — not a second-class thing tethered to a gateway or a cloud account.

If every machine can securely find and reach every other machine — directly, privately, at the lowest possible latency, on hardware anyone can afford — that is an enabler for an abundant, decentralized future for the benefit of all. Lifting all boats.