Meshtastic
Meshtastic
Meshtastic is a project that lets you use inexpensive LoRa radios as a long range off-grid communicator for areas without reliable cellular service. These radios are great for hiking, skiing, paragliding - essentially any hobby where you don't have reliable internet access. Each member of the mesh can send and view text messages and enable optional GPS based location features. The radios automatically create a mesh to forward packets as needed, so everyone in the group can receive messages from even the furthest member. The radios will optionally work with your phone, but no phone is required.
These devices are becoming more and more popular, firmware was even custom built for DEFCON. There's an excellent official app for mobile devices as well as a web client to interact with the mesh (send and receive messages).
Device Support & Details
For devices running Meshtastic (devices are called "nodes"):
There are three main ways to interact with nodes, all effectively offering the same capabilities:
Install the command line tool with:
# Using a venv
python3 -m pip install --upgrade "meshtastic[cli]"
# Using pipx
pipx install "meshtastic[cli]"
# Add yourself to the dialout group, likely required
sudo usermod -aG dialout $USER
From here you're ready to setup any device.
USB Class Codes
Common USB class codes include:
{ 02:??:?? 0a:??:?? }for CDC communication + CDC data{ 08:??:?? }for USB mass storage when in DFU mode.
Install & Upgrade
There are really two install / upgrade types: ESP32 and nRF52 & RP2040
Factory Reset Before Use
It's a good idea to factory erase and flash devices before first use
ESP32
You can flash ESP32 firmware and review all supported devices via the web tool: https://flasher.meshtastic.org/
nRF52 & RP2040
Drag & Drop
nRF52 and RP2040 based devices have the easiest firmware upgrade process (drag & drop). No driver or software install is required on any platform. It also appears to support OTA (over the air) updates through bluetooth
What this means is once you put the device into DFU (device firmware update) USB mode, a mountable storage space appears on the device. Simply drop the firmware binary into the root of that mount. Once the file is copied over, the device will automatically kick off the update.
Initial Setup
- Read the configuration tips first
- You can enumerate a device's info with
meshtastic --port /dev/ttyACM0 --info - Simiarly
meshtastic --get allwill list all preferences - You can watch a stream of device activity over serial with
meshtastic --noproto - A device can only be connected to one client application at a time (you cannot stream serial activity while also using the mobile app)
First Boot
- Factory erase and flash devices before first use
- Devices appear to have
region: UNSETby default until configured, so they aren't sending data until you complete setup - Change the default BLE static pairing PIN on any new / flashed device:
meshtastic --set bluetooth.fixed_pin <6_digit_pin>- The default PIN is often always
123456 - This is ideal for devices without a small display to print rolling codes on demand
- The default PIN is often always
Device
Configure your device role and rebroadcast mode based on usage and opsec requirements.
- Client roles + comparison, and what the rebroadcast mode means
- Tips on rebroadcasting traffic
The Default Channel
Connecting to any channel, or even sending a DM, reveals your node ID, username, device name, and other information in the headers of packets that traverse your device and the devices forwarding them. This will result in receiving numerous spam DM's which will flood your contact list. There is no way around this if you want to benefit from the larger mesh network, it's part of using Meshtastic.
One alternative, that does not prevent sniffing, is setting up a number of nodes running a private primary channel. For example, you and other park rangers install numerous nodes around a park using a custom primary channel, and not the Default public (AQ== base64 equivalent of hex 0x01) channel key. This is effectively creating your own private mesh network, while avoiding the spam DM's.
Rebroadcasting and Sniffing
Even without participating in a public or known channel, devices can be configured to simply rebroadcast packets on the LoRa band. The default rebroadcast setting is ALL. This appears to allow nodes to forward packets, even those they can't decrypt because they lack the key.
This will need tested and confirmed, but even having your own private mesh does not prevent mesh activity from being observed (in other words, node headers).
MUTE vs HIDDEN
Practically, CLIENT_MUTE is the passive "sniffing" setting. However, by being in any channel, all users of that channel (this applies particularly to the public defualt channel) will be able to see and DM your device.
Unintuitively CLIENT_HIDDEN will reveal your device details eventually by forwarding packets to participate in the network, though at a lower rate than the default CLIENT setting.
LoRa
The LoRa section of the documentation covers this.
Modem Preset
LONG_FAST is ideal for general use.
Default is unset which equates to
LONG_FAST. Presets are pre-defined modem settings (Bandwidth, Spread Factor, and Coding Rate) which influence both message speed and range. The default will provide a strong mixture of speed and range, for most users.
SHORT_TURBO is best for super-high density situations (like conferences).
SHORT_TURBO(Fastest, highest bandwidth, lowest airtime, shortest range. It is not legal to use in all regions due to it's 500kHz bandwidth.)
Channels & DMs
Messaging
The encryption overview provides the best walkthrough to how messaging works from a usability and security perspective.
- PKI exists per-device (user identity) and per-channel (group identity)
- You can wipe channel and direct messages via "Reset NodeDB" in the mobile application
- Configuration tips on node roles, (not) location sharing, rebroadcasting traffic, channels, and best practices
- MQTT is off by default, it's a bridge to the internet for meshtastic
Vulnerabilities
Privacy & Security
Meshtastic vs Other Platforms
While Meshtastic states this is not as secure as something like Signal, in other ways it's something that could be life saving in the right situation where you have no traditional network or cell service, and you're able to coordinate with your group or get a message to another node during an emergency. There are obviously no guarantees, as this is not designed to be an emergency service, but it's a use case one can imagine while hiking or camping in remote areas. Examples in the Wikipedia entry for Meshtastic suggest it's being explored as a backup communications system during natural disasters.
Device Triangulation
The FAQS page references a project to do just this: https://github.com/a-f-G-U-C/Meshtastic-ZPS. The accuracy of this tool has not been confirmed, but like any RF siganl, triangulation should be considered possible.
- Comparison to WPA3, TLS1.3, and Signal
- If you have physical access to a node via a client application, you can dump all the private keys and PINs
- Change your keys from time to time
- Rotating your device's private key does not rotate the user or device identity in the network
- Meshtastic does not implement network auth, so it is trivial to impersonate anyone else if you have access to the channel key
- DM's use PKC to encrypt and validate messages, which makes them harder to impersonate or modify
- Update your firmware regularly, follow any notices on GitHub and Discord
- You do not need to enable admin mode, or configure any remote administration to secure a personal (non-router) node
- Backup and restore your keys & config using any of the client applications