Device Roles Explained
Meshtastic devices can be assigned one of several roles that control how they participate in the mesh. Choosing the right role for your repeater affects network behavior, power consumption, and visibility.
CLIENT (default)
The standard role for personal devices, and the role official Meshtastic guidance recommends for the overwhelming majority of ordinary nodes. A CLIENT node sends and receives messages via the app and participates in relaying (managed flooding): it rebroadcasts a packet only when no other node has already done so. If a CLIENT hears another node rebroadcast a packet first, it defers and will not rebroadcast it itself.
A CLIENT also ignores any packet (tracked by Packet ID) it has already received, so a given packet is never relayed twice by the same node. This managed-flooding behavior is what prevents broadcast storms.
Best for: personal devices carried by users, and most ordinary stationary nodes.
REPEATER
A dedicated relay node. REPEATER is deprecated as of firmware ~2.7.x and is no longer recommended as the default for new infrastructure (see "Which role should I choose?" below). Key behaviors:
- Rebroadcasts each valid packet once, with higher priority - it does not defer to other nodes the way a CLIENT does - subject to channel-activity detection (it still waits for the channel to be clear)
- Does not appear in the node list - it sends no NodeInfo, so it is anonymous on the mesh and keeps the network list clean
- Does not broadcast its own GPS or node info (saves network bandwidth)
- Does not force power-saving sleep (its radio stays active)
- Can be paired with the
ALL_SKIP_DECODINGrebroadcast mode for maximum efficiency (see below)
Note: ALL_SKIP_DECODING is a device.rebroadcast_mode value - a separate setting from the device role - that relays packets without decrypting them, so a REPEATER can forward traffic on channels whose PSK it does not hold. Role and rebroadcast mode are independent settings; REPEATER is not "formerly ALL_SKIP_DECODING."
Best for: legacy deployments on older firmware where an anonymous, node-list-invisible relay is specifically wanted. For new infrastructure, prefer ROUTER.
ROUTER
The recommended role for stationary, well-placed community infrastructure nodes. A ROUTER is visible in the node list and originates its own NodeInfo (and GPS position if configured), which makes it trackable and useful for network monitoring. A ROUTER automatically enables power-saving sleep (this cannot be turned off) and defaults its app connectivity - BLE, Wi-Fi, and Serial - to OFF, so you don't normally text it directly even though it can still originate and receive messages at the protocol level. It is designed for stationary, well-placed nodes.
Best for: fixed community infrastructure and backbone relay nodes where you want visibility on the network and reliable rebroadcasting.
ROUTER_LATE
A relay role that rebroadcasts only after all other nodes have had a chance to do so - it is not a prioritized router. It defers to every other node and relays last, which reduces redundant transmissions in dense areas while still ensuring coverage in gaps. Use it for nodes that should rebroadcast only after others.
Best for: filling specific dead spots in a network that already has primary coverage, or as a deliberately low-priority backup relay.
Comparison table
| Role | Visible in node list | Rebroadcast strategy | Prioritized routing | Sends own data | Power |
|---|---|---|---|---|---|
| CLIENT | Yes | Deferred (managed flooding) | No | Yes (if set) | Moderate |
| REPEATER (deprecated) | No | Once, higher priority, no deferral | Yes | No | High (LoRa active, no force-sleep) |
| ROUTER | Yes | Once, higher priority, no deferral | Yes | Yes | Force power-saving sleep; app radios off by default |
| ROUTER_LATE | Yes | After all other nodes | No (relays last) | Yes | High (LoRa always on) |
Note: appearing on a public map such as meshmap.net is independent of role - it requires an MQTT uplink to the internet (a gateway), not a particular device role.
Which role should I choose?
- For most ordinary nodes, official Meshtastic guidance is to leave the role at CLIENT.
- Use ROUTER for fixed, well-placed community infrastructure that should rebroadcast reliably and appear on the network - this is the recommended choice for backbone nodes.
- REPEATER is deprecated as of firmware ~2.7.x and is no longer recommended as a default; reserve it for legacy firmware or the narrow case where you specifically want an anonymous, node-list-invisible relay.
- Use ROUTER_LATE for a backup node in an area that already has primary coverage, where you want it to relay only after every other node.