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...

Software:
Optional (for Meshtastic CLI testing):
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.
┌─────────────┐ ┌──────────────┐ ┌──────────┐
│ 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.
The internet stops at the cell tower. deadmesh starts where it ends.
Meshtastic networks are incredible for messaging and telemetry, but they weren't designed for general Internet access. Each protocol (HTTP, SMTP, DNS) 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:
Result: Your phone/computer just works, email clients, web browsers, CLI tools, API services; everything works without modifying a single line of code.
This very blog runs on infrastructure designed for these conditions. (Media-heavy browsing not recommended over LoRa, current page is deliberately light.)
