meshtastic

  1. services

After reading this LWN review and being poked a few times by friends, I started playing around with meshtastic.

  1. Range
  2. Hardware
    1. SenseCAP Card Tracker T1000-E
      1. Fun story
    2. T-Deck Plus
    3. Other devices
  3. Software
    1. Flashing special firmware
    2. Linux
    3. Mobile apps
  4. MQTT
    1. Public gateways
  5. Privacy and security
  6. Relays
  7. Monitoring
  8. Maps
  9. Links
  10. Fellow meshes
  11. Alternative LoRa networks

Range

I have, for a brief moment, seen a couple of nodes 20km away. I suspect it's because a fellow meshtastic user was traveling nearby and relaying those signals, as I haven't seen any more signals in a while.

I assume I can reach about 1-2km away in the city, but I have yet to get solid confirmation on this. I don't have an antenna high up yet so this is just with handheld devices.

In theory, range is line of sight which, if you're on top of mountains across the Adriatic sea, is over 300 kilometers. Meshtastic keeps track of records like those.

In practice, you can expect single or double-digit range depending on your hardware and prominence.

The site planner can help you show what you should be able to see. Combine with one of the maps, you should get a good idea of what you should be seeing.

Hardware

Below are some Meshtastic-compatible devices I found interesting.

Those are mostly taken from official device list, which you should consult for recommendations, particularly on chipset tradeoffs (e.g. ESP32 uses more battery, but is cheaper).

I explain below some tests I've made with various devices.

SenseCAP Card Tracker T1000-E

The SenseCAP Card Tracker T1000-E is a neat little device:

It has no display or keyboard, only a single button, a LED, and a "buzzer", kind of like the old PC speakers.

It's about the size of a credit card, but thicker (it won't fit in your wallet, but will definitely fit in your pocket).

My first battery test run lasted 3 days at which point it dropped from about 50% battery to zero in about an hour. Possibly the battery controller learning some things about itself. Their website specs it at 2 days battery. The battery recharged in a little over an hour (1h15m or so).

Only downside is it requires a phone, but it's a great device to start with as you can just shove it outside for three days and see what you pick up.

Make sure you configure the device: this will bring you environment sensors and a neat trick to find the device if lost, see below.

Fun story

I lost that device one day! I had put it on top of a doorframe on the second floor to get better range, but when i came back at lunch, it wasn't there! I looked around on the floor, couldn't find it... but my phone could reach it over Bluetooth, so it was still around somewhere!

So i followed the upstream guide to setup the sensors, which includes a setting to use the "buzzer" to make sounds when new messages are received. So I started sending messages to the card from another Meshtastic device (the T-Deck+), which made the thing "buzz", and I could hear it!

It wasn't on the second floor anymore though. After about 2 minutes and 10 "ping" messages sent, I found it! It had fallen two floors down, in the basement stairwell, and here it was ringing... phew!

Seems like it survived the fall too. Amazing little device, and Meshtastic success!

T-Deck Plus

The T-Deck Plus is another unique platform:

The "meshtastic" firmware that comes with it is just bad, definitely not worth paying for. There's a "pre release" "technical preview" (2.6.0.f7afa9a) that is much better (see below), although writing this I have just noticed than the 2.6.3 "alpha" release.

I couldn't use the GPS at first, and filed an issue which was promptly fixed: you need to enable it in the Meshtastic app.

There seems to be an issue with the remote control interface: I have found that I need to reboot in "programming mode" to get access to the Bluetooth interface to control it from my phone. According to this issue this might be fixed in newer firmware, but I have a fairly recent one and it didn't work. It could be a conflict with WiFi as well. According to the Meshtastic docs though, it's just the way it is.

All in all, this is a pretty amazing machine and one of the rare systems that allows communication without any other external device (like a phone or computer), which is really great.

Other devices

Those I haven't tested yet:

Devices without cases typically have 3D designs that can be downloaded and printed or bought, see this list.

Software

Flashing special firmware

There are special "technical preview" or "pre-release" firmware available at https://flasher.meshtastic.org but only after you enter the Konami code (yes, really), which is, of course:

↑ ↑ ↓ ↓ ← → ← → b a

Yes, on your keyboard. Yes, in the web browser. The back of the page will turn black and the extra firmware will be shown in the second column. Funky.

In any case, flashing firmware like this only works in Chromium because Firefox doesn't support WebUSB (which is perhaps a good thing).

Note that you can also flash firmware without a web UI, but the flasher web UI is still useful to download the right firmware.

Linux

There's a commandline client and Python library that can be used to talk to devices. There's even a rudimentary GTK client. Both are packaged in Debian.

There's also TUIs like contact (messaging), connect (LoRa-less client), control (configuration).

Mobile apps

There's also an Android app, also shipped on F-Droid.

And yes, there's also an iOS app.

Note that those won't work without a LoRa transmitter, to which you typically connect over Bluetooth.

MQTT

Meshtastic devices can typically connect to a MQTT gateway or broker, see the MQTT module configuration. This allows meshtastic users to connect to other users not reachable over LoRa through the internet instead, essentially.

This can be used to extend the mesh around obstacles (like a mountain) or across cities (or stupid things like borders).

In MQTT, you can "scope" traffic by using a "topic". Those are hierarchical. For example, by default meshtastic will setup the topic msh/US if you're in the US region, but you could make that msh/CA or msh/CA/YUL to restrict your scope to YUL (Montreal) nodes. Someone looking at msh or msh/CA would see your traffic, but you wouldn't see theirs.

You could use an entirely different hierarchy like foo/ for yourself, but you are relying on someone not guessing that topic to avoid discovery.

Note that you can still encrypt packets as they go through, but packets have a signature that can reveal metadata.

For MQTT to work, your device needs to have internet access, either through WiFi or Ethernet. If you're connected over Bluetooth, you can also enable the "Client Proxy" mode which will make your phone relay the traffic to the MQTT server instead of the device.

You can run your own MQTT server with opensource implementations. Debian ships with mosquitto (C, well maintained), for example. See also Wikipedia's comparison page, which includes, of course, a Rust rewrite called RMQTT (not packaged in Debian).

Note that brokers can typically relay messages between them. For example, mosquitto supports the concept of bridges so you could use a local broker for your own purposes and relay messages to the official brokers (or a subset of them).

The mqtt(7) manual page provided by mosquitto is pretty good as well.

Public gateways

Privacy and security

Default security is pretty much non-existent: in the default channel, packets are encrypted, but with a known key.

Other channels seem to use pretty solid encryption, but there's likely metadata leakage ("who is talking to who") in cleartext over the airwaves that can be easily sniffed by anyone in range. Joining a MQTT server makes that even easier to sniff.

Also note that Meshtastic only does encryption: you don't get things like forward-secrecy, authentication, or integrity, see the encryption section. This sounds minor, but this is a significant threat vector as, for example, if someone knows you wrote "hi" to a channel, even if they don't have the encryption key, they can replay that "hi" by sending the exact same encrypted packet. Security is hard. It seems like Reticulum does this better.

Nodes often transmit other telemetry like GPS location, temperature, and other sensors, by default. GPS location precision can be reduced (say "I'm in Montreal" instead of "I'm at 1234 boulevard Saint-Laurent") or completely turned off, but it might still possible to triangulate device's positions, as with any typical radio transmission. LoRa signals are "bursty" and low power, so that's more difficult than, say, classic ham radio signals though.

There's a Meshtastic ZPS project that tries to implement GPS-less localization, but it's using external positioning systems and WiFi/Bluetooth scans instead of a GPS, so it's not triangulation per se.

Weak default Bluetooth pairing codes (the "PIN") are often luggage-strength like 1234 or 123456. They should be changed unless you're okay with anyone within range taking control of your devices.

Physical access to the devices also likely leads to full compromise as devices can generally be put in "DFU" (Device firmware upgrade) mode relatively easily.

Relays

Monitoring

Maps

Links

Fellow meshes

See also the official list of local groups.

Alternative LoRa networks

Created . Edited .