deadmesh

New polished Web UI

v1.1.2

Deadlight Proxy UI v1.1.2

▶ Watch Demo Video on YouTube

Why This Exists

Meshtastic networks are incredible for messaging and telemetry, but they weren't designed for general Internet access. Each protocol would need custom mesh-aware implementations: a chicken-and-egg problem where applications won't add mesh support without users, and users won't adopt mesh without applications.

deadmesh sits in the middle:

Mesh side: Speaks fluent Meshtastic (protobuf over LoRa serial with proper API handshake)
Internet side: Speaks every protocol your applications already use
Bridges transparently: Fragments outgoing requests, reassembles incoming responses
Target result: Your mesh network works with everything: email clients, web browsers, update tools, API services; without modifying a single line of application code. The gateway proxy pipeline achieves this today; the remaining work is client-side packet delivery over LoRa.

Full pipe flowing

How deadmesh Works Under the Hood

deadmesh does one thing: it makes a Meshtastic LoRa mesh look like a normal internet connection to any application that uses it. No special clients, no modified apps, no mesh-aware software required.

Here's how that actually works.

Architecture

┌─────────────┐                  ┌──────────────┐                ┌──────────┐
│ Mesh Client │  LoRa Packets    │   deadmesh   │  TCP/IP        │ Internet │
│  (Phone /   ├─────────────────>│   Gateway    ├───────────────>│ Services │
│  Handheld)  │  (868/915 MHz)   │              │                │          │
│             │                  │ - Fragment   │                │  HTTP    │
│ Meshtastic  │                  │ - Reassemble │                │  SMTP    │
│    App      │<─────────────────┤ - TLS Proxy  │<───────────────┤  IMAP    │
└─────────────┘                  │ - Cache      │                └──────────┘
                                 │ - Compress   │
                                 └──────┬───────┘
                                        │
                                 ┌──────┴───────┐
                                 │  Serial API   │
                                 │  0x94 0xC3    │
                                 │  protobuf     │
                                 │  want_config  │
                                 └──────┬───────┘
                                        │ USB
                                 ┌──────┴───────┐
                                 │  Meshtastic   │
                                 │  Radio        │
                                 └──────────────┘

The gateway node sits at the boundary between two worlds. On the mesh side it speaks Meshtastic natively. On the internet side it speaks whatever protocol the client application is already using. Neither side needs to know anything
about the other.

Features

  • Universal Protocol Support: HTTP/HTTPS, SMTP/IMAP, SOCKS4/5, WebSocket, FTP. If it runs over TCP/IP, it works
  • Transparent TLS Interception: Inspect and cache HTTPS traffic with HTTP/1.1 ALPN negotiation to minimize mesh bandwidth
  • Intelligent Fragmentation: Automatically chunks large requests/responses into ~220-byte Meshtastic packets with unique per-chunk packet IDs — bypasses Meshtastic firmware's (from, id) deduplication that would silently drop all but the first chunk of multi-packet sessions
  • Serial API Handshake: Proper want_config initialization, auto-discovers node ID, receives full mesh state on startup
  • Robust Serial Framing: 0x94/0xC3 length-prefix state machine with sync recovery. If magic bytes are lost mid-stream, re-synchronizes automatically. This is what makes multi-hour uptime boring in the right way
  • Live Mesh Visibility: Decodes all Meshtastic packet types (text messages, positions, telemetry, node info, routing)

Getting Started

Prerequisites

Software:

  • Linux (Raspberry Pi, x86 server, or similar) — or WSL2 on Windows with USB/IP passthrough (see WSL)
  • GLib 2.0+, OpenSSL 1.1+, json-glib-1.0
  • GCC or Clang
  • Python 3 + pip (for nanopb protobuf generation during build)

Optional (for Meshtastic CLI testing):

  • Python meshtastic package (pip install meshtastic)

Hardware (see Hardware for details):

  • Meshtastic-compatible LoRa radio (ESP32-based or nRF52840 recommended)
  • Gateway node: Raspberry Pi, x86 Linux box, or Windows PC running WSL2
  • Client nodes: any Meshtastic device (phone, handheld, custom)

CLI Compile & Run

WSL (Windows Subsystem for Linux)

deadmesh works under WSL2 with USB/IP passthrough for the Meshtastic radio. This is a fully supported configuration — the reference gateway setup during development runs this way.

PowerShell (Admin) — install and attach USB device

winget install usbipd
usbipd list ...

Hardware

Tested Hardware

Device Chip Connection Notes
Seeed Wio Tracker L1 nRF52840 + SX1262 USB CDC (/dev/ttyACM0) ✓ Verified — reference gateway radio
Heltec LoRa 32 V3 ESP32-S3 + SX1262 USB CDC (CH9102) ✓ Verified — reference client radio
RAK WisBlock (RAK4631) nRF52840 + SX1262 USB CDC Expected to work
Heltec V4 ESP32-S3 USB CDC Expected to work
Lilygo T-Beam ESP32 + SX1276/8 USB UART (CP2104) Expected to work
Lilygo T-Echo nRF52840 + SX1262 USB CDC Expected to work
Station G2 ESP32-S3 USB CDC Expected to work

Federation Directory

deadlight

deadmesh

mobile.deadlight

thatch

threat-level-midnight