meshtastic¶
Meshtastic LoRa nodes — T-Deck, T-Echo, RAK and WisMesh boards
Vendor: various (LilyGO, RAK Wireless, Heltec) · class: badgelife
Status: supported — the identifiers and setup recipe are believed correct.
Not maintainer-verified: nobody on this project has run this hardware yet. The two facts are recorded separately on purpose (D-027) — a correct recipe and a tested device are different claims.
What it is¶
Long-range low-power mesh networking over LoRa, running on a wide range of inexpensive boards. The node is the radio; the phone or computer is a client.
What you can do with it¶
Text messaging and position sharing over a mesh with no infrastructure, at ranges measured in kilometres, on licence-free ISM bands.
Setup¶
Both python3-meshtastic and gtk-meshtastic-client are in Debian 13 — measured, not assumed. Add yourself to dialout, attach the node, and talk to it over the serial port with the CLI.
Known problems¶
Regional frequency settings are the operator's responsibility and the defaults may not match where you are. ModemManager grabbing the serial port affects these boards as much as any badge. Firmware and client versions drift quickly.
How it identifies itself¶
| USB id | What | Confirmed | Node |
|---|---|---|---|
303a:1001 |
Espressif ESP32-S3/C3 native USB — the most common Meshtastic path | yes | serial |
239a:0029 |
Adafruit nRF52840 application mode | yes | serial |
239a:002a |
Adafruit nRF52840 application mode, second identifier | yes | serial |
239a:8029 |
Adafruit nRF52840 UF2 bootloader | yes | storage |
239a:802a |
Adafruit nRF52840 UF2 bootloader, second identifier | yes | storage |
239a:4405 |
Adafruit nRF52840 bootloader variant | yes | storage |
2886:1667 |
Seeed nRF52840 module | yes | serial |
⚠ 303a:1001 is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 49 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
⚠ 239a:0029 is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 41 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
⚠ 239a:002a is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 41 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
⚠ 239a:8029 is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 29 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
⚠ 239a:802a is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 25 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
⚠ 239a:4405 is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 16 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
⚠ 2886:1667 is not unique to this device (vendor_chip_default; also used by: see docs/reference/lora-inventory.md for the full list). Claimed by 6 different products in the upstream board metadata, which is what "shared" means measured rather than asserted. The pair identifies the module a board is built on, not the board.
What is not yet known¶
Not closable as a single record, and now for a documented reason rather than an unexplored one. The identifiers are confirmed from upstream board metadata covering 107 products; what no upstream source records is the manufacturer and product STRINGS a running board reports, because a flasher matches on VID:PID and never needs them. Those strings are the only thing that could make a per-board udev rule safe. So the remaining work is per-board captures, and it is a contribution ask rather than a task: the maintainer's boards were lost to flooding, and anyone with a T-Deck, a T-Echo, a RAK or a Heltec can close one board's worth in thirty seconds with scripts/identify-device.sh.
Who can close it: nobody on this project owns one — an operator who does can close it with one lsusb (how).
Access and permissions¶
Group membership required: dialout, plugdev — added at install, applies at next login.
Firmware modes¶
- esptool — tooling:
esptoolESP32-based nodes such as T-Deck flash with esptool over the serial port. - uf2 — tooling: — nRF52840 boards such as T-Echo use a UF2 bootloader — double-tap reset and the board mounts as a USB mass storage device you copy firmware onto. No flashing tool is needed, but the device enumerates as storage rather than serial while in that mode, so a serial udev rule will not match it.
Software that makes it useful¶
esptool, gtk-meshtastic-client, minicom, python3-meshtastic, screen, tio
Upstream: https://meshtastic.org/