Meshtastic

What it is

Meshtastic is firmware (and an ecosystem of clients) for LoRa radios on the unlicensed sub-GHz ISM bands (868 MHz EU, 915 MHz US, 433 MHz Asia). Each node has a 32-bit node number and, in current firmware, can advertise a public key for direct-message PKI. Nodes flood-route packets across a many-hop mesh; each hop re-broadcasts unless the packet has already been seen.

Use cases:

• Hiking, sailing, off-grid groups out of cell range.
• Neighborhood resilience networks.
• Festival and event comms.
• Disaster fallback (Hurricane Helene 2024 saw substantial Meshtastic deployment).
• Emergency-services ad-hoc coordination.

What it explicitly is not: a private mesh. The default channel is broadcast and observable by anyone in radio range with the channel key.

Hardware

The reference platforms are inexpensive (€20-€60) integrated boards:

Antennas matter more than the radio chip. A $5 stock antenna will give 1 km; a tuned 5 dBi at 5-10 m elevation reaches 30+ km line-of-sight.

Protocol mechanics

Packet structure

Every packet is a small Protobuf-encoded MeshPacket:

from        : node_id (32-bit)
to          : node_id (32-bit, broadcast = 0xFFFFFFFF)
channel     : 0-7 (selects channel key)
hop_limit   : starts at 3-7, decremented per relay
want_ack    : optional reliability flag
payload     : encrypted PortNum + bytes

LoRa airtime limits push payload sizes to ~230 bytes for the most common settings. The protocol frames messages, sensor telemetry, position reports, and routing control packets identically.

Routing: managed flood

Default mode is managed flood routing: each node retransmits packets it hasn't seen, with a randomized contention window to avoid collisions, and a strict hop limit. Routing is stateless; there is no neighbor discovery beyond passive observation.

Newer features:

• Next-hop routing (v2.5+): opportunistic learning of best-next-hop from received packets.
• MQTT bridge: a single node with internet uplink can bridge a regional mesh to a global MQTT broker for cross-mesh and integration with home automation.

Encryption

Per-channel symmetric AES-256-CTR with a pre-shared key. The default channel uses a well-known key (AQ==) that is broadcast-readable by intent so newcomers can join. Private channels use a user-generated 256-bit key shared out-of-band.

v2.5+ direct messages add public-key encryption: each node advertises a public key in NodeInfo, and DMs are encrypted to the recipient's key. Forward secrecy is not provided; keys are long-term. Public keys can be manually verified, and the protocol reports unrecognized, duplicate, low-entropy, or unauthorized keys as routing errors.

Channel hash and utilization

Each channel computes a 1-byte hash to deduplicate cross-channel traffic. The protocol intentionally rate-limits each node; one chatty node can saturate the entire mesh's airtime, so firmware enforces per-port caps.

Modes / presets

Trade-offs between range, throughput, and airtime. Current presets (US 915 MHz; rates checked against Meshtastic radio-setting docs and current protobuf presets):

Mismatched presets produce silent meshes, a common mistake. All nodes in a mesh must agree on preset and frequency. The older "Very Long Slow" preset has been removed.

Clients

A node is typically operated headless (battery + radio) and paired to a phone via BLE for messaging UX.

Privacy properties

For threat models that include radio surveillance, layer Meshtastic with Off-Grid Messaging patterns: short bursts, low duty cycle, mobile transmitters, mission-keys-only on participants' devices.

Operational patterns

Default channel + private channel

Run two channels: default for joining new participants and emergencies, a private channel for the actual group comms with a key shared in person.

Solar / battery node

A LILYGO T-Beam or Station G2 with a 5 W solar panel and 18650 cells is autonomous indefinitely. Place high (rooftop, hilltop) for range; low duty cycle minimizes draw.

MQTT bridge to internet

One node with a Wi-Fi or cell uplink and the MQTT bridge enabled connects the local mesh to the global Meshtastic MQTT topic. Useful for cross-region monitoring; breaks the off-grid model if compromised.

Position privacy

The want_position flag is on by default. Disable it for adversarial environments. A beacon transmitting position every minute is a homing signal.

Trade-offs

Strengths

• Very cheap; full kit under €60.
• Easy to deploy; flash firmware, pair phone, send.
• Self-organizing; no infrastructure, no admin.
• Multi-day battery and solar friendly.
• Open firmware, large community.

Limitations

• Tiny bandwidth; text, not media.
• Public protocol; no protocol-level metadata privacy.
• No forward secrecy.
• Channel key compromise reveals all past channel traffic.
• Direction-finding; emitting nodes are locatable.
• Channel utilization is fragile; one chatty bot can saturate a region.

Attack surface

Recent developments (2024-2026)

• PKI / DM encryption (v2.5+): Curve25519 keys per node for direct messages.
• Next-hop routing beyond pure flood.
• Range expansion with new firmware optimizations.
• Hurricane Helene 2024: substantial real-world deployment for relief coordination.
• Position obfuscation options expanded for safety in adversarial regions.

Primary sources

• Meshtastic — meshtastic.org
• Firmware repository — github.com/meshtastic/firmware
• Protocol spec — meshtastic.org/docs/overview/mesh-algo
• LoRa Alliance, LoRaWAN Regional Parameters.

Sibling project: MeshCore. MeshCore runs on the same LoRa boards but relays only through dedicated repeaters and learns direct routes instead of flooding. It is lighter on airtime, but its cryptography is thinner (AES-128-ECB with a 2-byte MAC, no audit) and its main phone apps are closed source. The MeshCore entry has a side-by-side comparison, and Building a Mesh helps you choose between them. For phone-only mesh chat with no radio hardware, see Bitchat.