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,nodes the two mosthistorically 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

• ActivelyAlways participatesrebroadcasts ineach floodingpacket andonce rebroadcasting(does allnot packetsdefer to a neighbor that rebroadcasts first), with prioritized routing. The scope of what it hears.rebroadcasts is governed by rebroadcast_mode (default ALL), not by the role itself.
• Maintains a node position - appears on the map at meshmap.net andAppears in the app node list.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.
• CanAt the protocol level a ROUTER can still originate and receive andmessages, displaybut messages;BLE/WiFi/Serial someoneapp inconnectivity theis fieldOFF canby default, so you do not normally text the nodeit directly to check status.status without first enabling an interface.
• HigherUses more airtime usagethan deferring roles because it retransmitsalways morerebroadcasts aggressively.(it never skips when a neighbor already did), not because it sends extra copies of a packet.
• PrioritisesRebroadcasts rebroadcastingwith packetspriority thatby stillusing havea maximumshorter hopscontention remaining.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 that also serveacting as monitoringbackbone points, nodes with a screen or GPS that need to appear on maps,relays; medium-traffic networks.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.

• OptimisedLike purelyROUTER, forit is a preferred relay that always rebroadcasts each packet relay - rebroadcastsonce with lowera overhead.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 - willit is anonymous on the mesh and does not appear onin maps,the node list, which reduces network traffic.
• DoesIs not receivenormally messagesaddressed for "self" - cannotyou bedo textednot text it directly. This is a default-configuration behavior, not the firmware omitting a send code path.
• LowerDoes not force power-saving sleep, so it keeps its LoRa radio on. Baseline power consumptiondraw is therefore similar to ROUTER; differences between the two roles are marginal (self-generated airtime, CPU/RAM) rather than ROUTERone indrawing practicedramatically becauseless it generates fewer self-broadcasts.

Firmware configuresthan the device as a "hop maximiser" - prioritises packets that still have hops remaining.other. Good for:for (legacy): permanent unattended infrastructure,relay-only solarinfrastructure deployments,where maximisingthe batterynode life,should reducingstay self-generatedanonymous traffic.on the mesh. For new builds, use ROUTER instead.

When to Use Each Role

Scenario	Recommended Role
Temporary deployment or field relay that doubles as a usable client	ROUTERCLIENT
Node needs to appear onin the mapnode list for coordination	ROUTER
Permanent mountaintop or rooftop installation	REPEATERROUTER
Solar-powered, unattended backbone node	REPEATERROUTER
MaximiseOrdinary batteryuser life and minimise self-generated trafficnode	REPEATERCLIENT

CLIENT_MUTE Role

CLIENT_MUTE is the opposite of a repeater - it prevents a regular client device (phone, laptop) from rebroadcasting mesh traffic.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, ConfigSettings → Device Config→ Role; on iOS/macOS, Settings → Device Configuration → Device → Role. →The selectexact menu path can vary by app version.

Via the CLI: meshtastic --set device.role ROUTER or(the REPEATERkey 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.