What is Meshtastic?

Meshtastic describes itself as a project that lets you use inexpensive LoRa radios as a long range, off-grid communication platform in areas without existing or reliable communications infrastructure. It is community driven and open source; the firmware is on GitHub under GPL-3.0.

The project lists its main features as long range, no phone required for mesh communication, decentralised communication with no dedicated router, text messages between members of the mesh, and optional GPS-based location. A radio can also be paired with a phone, which then sends and reads messages through it. The documentation notes that each device supports a connection from only one user at a time, and the radio decrypts messages before passing them to the client app over Bluetooth LE, serial, or Wi-Fi and Ethernet.

That pairing is the key difference from a phone-only mesh. The long range comes from the LoRa radio, not the phone, so every participant carries a radio.

Meshtastic runs on a range of development boards and finished devices, from bare boards to handhelds with a screen, keyboard and GPS. Its hardware page lists boards built around Nordic nRF52840, Espressif ESP32 and Raspberry Pi RP2040 microcontrollers, paired with Semtech LoRa transceivers.

The project gives two pieces of buying advice. It strongly recommends the newer Semtech SX126x or LR11xx transceivers over the older SX127x series. And it notes that nRF52-based devices use less power than ESP32-based ones, so they are generally preferred for solar and handheld use, while ESP32-based devices are typically cheaper and suit setups with mains power or a need for Wi-Fi.

Meshtastic’s routing is built around flooding, refined in a few ways that its documentation explains.

• Listen before talking. Radios use carrier sense with collision avoidance: before transmitting, a node checks for channel activity and waits a random number of slot times if the channel is busy.
• Managed flooding. A node that hears a packet with a hop limit above zero decrements the limit and rebroadcasts, but first listens briefly and stays quiet if another node has already rebroadcast it. Nodes with a weaker signal wait less, so the farther nodes tend to rebroadcast first and extend the reach. Nodes in the ROUTER and REPEATER roles rebroadcast regardless.
• Hop limit. The hop limit defaults to 3 and cannot be set above 7.
• Next-hop routing for direct messages. Since version 2.6, direct messages start with managed flooding, then remember which neighbour relayed a successful exchange and send later packets through it, falling back to flooding on the last retry.

Packets are small. The documented layout has an unencrypted header carrying destination, sender, packet ID, flags and relay information, followed by at most 237 bytes of data.

LoRa runs in licence-exempt bands with different rules in each country, so the firmware will not transmit until the user sets a region. Its region table gives each region’s frequency range, duty cycle and power limit. The European 868 MHz region, for example, uses 869.4 to 869.65 MHz with a 10% duty cycle limit, which the firmware enforces on a rolling one-hour basis by pausing transmission.

Modem presets trade speed against range. The default, LONG_FAST, balances the two; the documentation describes VERY_LONG_SLOW as the slowest with the longest range and highest airtime, and SHORT_TURBO as the fastest with the shortest range, not legal in every region because of its 500 kHz bandwidth. Every radio in a mesh needs the same region and preset to communicate.

Meshtastic encrypts each packet’s payload with AES256-CTR, using a key per channel. The header stays in the clear so that nodes can relay packets they cannot decrypt. The default primary channel uses a publicly known key, so the documentation tells users to change it, or create a new channel, for real privacy.

The project is candid about what this does not provide:

• No forward secrecy for channels. Anyone who later obtains a channel key can decrypt traffic captured earlier.
• No integrity check on channel messages. The documentation states that channel messages are not verified against tampering.
• No sender authentication on channels. Node IDs come from hardware MAC addresses, and anyone with the channel key can claim to be anyone else.

Version 2.5 improved direct messages. Each node now has a public and private key pair, direct messages are encrypted to the recipient’s public key and signed by the sender, and admin messages gained similar protection. Messages to devices on firmware 2.4 or older do not get this.

A Meshtastic node can connect to the internet through MQTT, which the project uses to connect a node to the internet and to link separate meshes to each other. It runs a public MQTT server with restrictions to protect local LoRa meshes: traffic from it reaches directly connected nodes but, under a zero-hop policy, does not spread further through the local mesh. For a comparison with LoRaWAN, which uses the same radios with gateways and a network server, see mesh networking vs LoRaWAN.