Router vs. Repeater Role — Which to Choose

Overview of Device Roles

Meshtastic firmware supports several device roles that control how a node behaves on the mesh. For infrastructure nodes the historically relevant roles are ROUTER and REPEATER, but note that REPEATER is deprecated as of firmware ~2.7.x. For most stationary, well-placed infrastructure the current recommendation is ROUTER (or ROUTER_LATE for a node that should rebroadcast only after others have had a chance); for the overwhelming majority of ordinary nodes the official guidance is simply CLIENT.

ROUTER Role

• Always rebroadcasts each packet once (does not defer to a neighbor that rebroadcasts first), with prioritized routing. The scope of what it rebroadcasts is governed by rebroadcast_mode (default ALL), not by the role itself.
• Appears in the app node list of nodes that hear it. It will only appear on meshmap.net if its packets reach the internet through an MQTT gateway somewhere on the mesh - merely being a ROUTER does not put it on the public map.
• At the protocol level a ROUTER can still originate and receive messages, but BLE/WiFi/Serial app connectivity is OFF by default, so you do not normally text it directly to check status without first enabling an interface.
• Uses more airtime than deferring roles because it always rebroadcasts (it never skips when a neighbor already did), not because it sends extra copies of a packet.
• Rebroadcasts with priority by using a shorter contention delay ("cutting in line") so it relays before other nodes, which helps extend range. It does not prioritize by remaining hop count.
• Automatically enables power-saving sleep on ESP32 (this cannot be turned off) and is designed for stationary, well-placed nodes.
• Good for: permanent, strategically placed stationary nodes acting as backbone relays; medium-traffic networks where a preferred relay improves reach.

REPEATER Role

REPEATER is deprecated as of firmware ~2.7.x. Prefer ROUTER (or ROUTER_LATE) for new infrastructure. The behavior below is retained for reference and for existing deployments.

• Like ROUTER, it is a preferred relay that always rebroadcasts each packet once with a shorter delay; it does not prioritize by remaining hop count and is not a "hop maximiser."
• Does not broadcast its own position or send NodeInfo - it is anonymous on the mesh and does not appear in the node list, which reduces network traffic.
• Is not normally addressed for "self" - you do not text it directly. This is a default-configuration behavior, not the firmware omitting a send code path.
• Does not force power-saving sleep, so it keeps its LoRa radio on. Baseline power draw is therefore similar to ROUTER; differences between the two roles are marginal (self-generated airtime, CPU/RAM) rather than one drawing dramatically less than the other.
• Good for (legacy): permanent unattended relay-only infrastructure where the node should stay anonymous on the mesh. For new builds, use ROUTER instead.

When to Use Each Role

CLIENT_MUTE Role

CLIENT_MUTE prevents a regular client device (phone, laptop) from rebroadcasting mesh traffic - a normal CLIENT still rebroadcasts under managed flooding, but CLIENT_MUTE does not relay at all. This is useful for devices that are on the mesh but should not consume airtime acting as relays, such as tablets used only for monitoring.

Setting the Role

In the Meshtastic app: on Android, Settings → Device → Role; on iOS/macOS, Settings → Device Configuration → Device → Role. The exact menu path can vary by app version.

Via the CLI: meshtastic --set device.role ROUTER (the key is device.role and the value is the bare enum name, e.g. ROUTER, ROUTER_LATE, CLIENT).

Via the web client at client.meshtastic.org: connect via USB, navigate to Device Config, and choose the desired role from the drop-down.