Skip to main content

ROUTER vs ROUTER_CLIENT vs REPEATER Role: Deep Dive

Meshtastic provides three infrastructure-orientedseveral device roles for infrastructure nodes that exist to extend network reach rather than serve end users. On current firmware the relevant roles are ROUTER, ROUTER_LATE, and REPEATER (with CLIENT being the right choice for the overwhelming majority of ordinary nodes, since CLIENT nodes already rebroadcast via managed flooding). Choosing the wrong role wastes resources, creates unnecessary air-time, or silently breaks the capabilities operators expect. This page dissects each role at the firmware level so you can make an informed decision for every node you deploy.

Important deprecation notice. The ROUTER_CLIENT role referenced in this page's title was retired in firmware 2.3.15 and is no longer a selectable device.role value. Do not attempt to set it. If you need a node that both relays and is used interactively by its operator, use CLIENT (which already relays) or ROUTER. Separately, the REPEATER role has itself been deprecated as of firmware ~2.7.x; for new infrastructure prefer ROUTER or ROUTER_LATE. The valid current device.role values are CLIENT, CLIENT_MUTE, CLIENT_HIDDEN, ROUTER, ROUTER_LATE, REPEATER, TRACKER, SENSOR, TAK, TAK_TRACKER, and LOST_AND_FOUND. The historical ROUTER_CLIENT material below is retained for context only and clearly marked as legacy.

The Three Infrastructure Roles at a Glance

Capability ROUTER ROUTER_CLIENTROUTER_LATE REPEATER (deprecated)
Rebroadcasts all received packets (once, with higher priority than CLIENT roles) Yes Yes (rebroadcasts last, after other nodes) Yes
KeepsPower-saving radiosleep behaviour
Forced on continuouslyautomatically (ESP32); cannot be disabled YesConfigurable via power.is_power_saving YesDoes Yesnot force sleep by default Can originate user messages (text, position) No Yes No Maintains a node database (neighbor list) Yes Yes No Appears as a named nodeVisible in the node list / sends NodeInfo Yes Yes No (anonymous relay)relay, sends no NodeInfo) SendsApp periodicconnectivity NodeInfo(BLE broadcasts/ WiFi / Serial) by default YesOff by default YesOn (client-style) NoOff Relative RAM/CPU overhead MediumStandard MediumStandard LowMinimal overhead (per docs)

All of ROUTER, ROUTER_LATE, and REPEATER rebroadcast each packet once with higher priority than ordinary CLIENT nodes. The retired ROUTER_CLIENT role has been omitted from this table; it is not settable on current firmware.

ROUTER Role

A ROUTER node is the canonical fixed-infrastructure role.role, designed for stationary, well-placed nodes. When you set a node to ROUTER it immediately adjusts its behavior in the following ways:

  • ROUTER automatically enables power-saving sleep (ESP32) via power.is_power_saving, and this cannot be turned off. The LoRa radio stays in standby to wake on full-timeincoming -packets no— sleepit modes,is nonot duty-cyclea restrictionsnode beyondthat regulatoryignores limits.power management.
  • EveryIt receiveddefaults packetBLE that/ passesWiFi the/ Serial connectivity off, so you don't normally connect to it to text directly.
Received packets are rebroadcast once, with higher priority than CLIENT roles, subject to duplicate-detection filterand isthe rebroadcast,hop regardless of packet type (text messages, position updates, telemetry, node info, traceroutes, etc.).counter. The device is visible in the node list and sends its own NodeInfo advertisement(and onposition, theif configured broadcast intervalconfigured) so other nodes know it exists and can display it on the map. TheA ROUTER maintainsrelays standard packets, including traceroute responses, like any non-mute node. (NeighborInfo is a fullseparate, nodeoptional databasemodule -any role can enable — it tracksis neighbours,not a defining trait of the ROUTER role.) A ROUTER can respondstill originate and receive messages at the protocol level. What's true is that its app connectivity (BLE/WiFi/Serial) is off by default, so in current firmware it does not present an interactive messaging UI and you typically won't have an app connected to traceroutesend packetsfrom withit. hop-by-hopThis path information, and participates in neighbour-info exchanges. The ROUTER does not originate user-level messages. You cannot sendis a textconnectivity fromdefault, not a pure ROUTER node. The device has noremoved "Send" capabilityfeature in the app because— the firmware intentionallydoes omitsnot thatomit the send code pathpath. forIf thisinteractive role.messaging at the site is needed, use CLIENT or ROUTER_LATE rather than ROUTER.

Setting the ROUTER role via CLI

meshtastic --set device.role ROUTER

Verifying the role was applied

meshtastic --get device.role

The --get verb is the standard counterpart to --set for reading any config field in the Python CLI.

ROUTER_LATE Role

ROUTER_LATE is the modern infrastructure role for a node that should rebroadcast only after other nodes have had a chance to, rather than with top priority. It is useful within a local cluster where you want a relay that fills gaps without dominating airtime. Unlike ROUTER, it does not force power-saving sleep on, and it keeps client-style app connectivity available. For most stationary backbone infrastructure prefer ROUTER; choose ROUTER_LATE for nodes that should defer to the rest of the mesh first.

ROUTER_CLIENT Role (retired — legacy reference only)

ROUTER_CLIENT was retired in firmware 2.3.15 and is not a settable role on current firmware. Historically it was described as a "superset of ROUTER.ROUTER" Itthat retainsretained everyROUTER's relay behaviour of ROUTER (radio always on, rebroadcast all packets, full node database, NodeInfo broadcasts) while also enablingletting the node to originate messages as a first-classclient. client:This is preserved here only for operators encountering older documentation or very old firmware:

  • TextIt was described as allowing text messages canto be composed and sent from the devicedevice. On current firmware, if you need a relay that an operator can also message from, use CLIENT (which relays via app,managed web UI, or serial CLI)flooding).
  • PositionIt datawas described as broadcasting position from the device's own GPS (or manually configured coordinates)coordinates. isThat position-broadcast onbehaviour thenow positionapplies updateto interval.CLIENT-family roles.
  • TheIt was promoted for an operator atwho thewanted repeater site canto use the node for voice-channel communicationinteractively during events or emergency activations without compromising the relay function. Today, use a CLIENT node for that. (Note: Meshtastic carries text, position, and telemetry — it does not carry voice — so "voice-channel communication" was never accurate terminology.)

TheDo trade-offnot use the legacy command below on current firmware — it will fail because ROUTER_CLIENT is marginal:no originatinglonger positionan andaccepted telemetrydevice.role packetsvalue. increases local air-time slightly. OnFor a busyrelay channelthat thisan addsoperator aalso fewuses percentageinteractively, pointsset ofdevice.role channelCLIENT utilisation compared to a pure ROUTER.instead.

Setting theLegacy ROUTER_CLIENT roleCLI via(no CLIlonger valid)

# Retired in firmware 2.3.15 — this command fails on current firmware.
# Use:  meshtastic --set device.role ROUTER_CLIENTCLIENT
# (legacy:  meshtastic --set device.role ROUTER_CLIENT)

REPEATER Role (deprecated)

The REPEATER role is the most minimal relay option. It isoption, designed for nodes that should retransmit packets butwith consumeminimal the absolute minimum resourcesoverhead and produce no additional air-timebroadcasts of their own:own. Note: REPEATER was deprecated as of firmware ~2.7.x; for new infrastructure consider ROUTER or ROUTER_LATE. Its documented behaviour:

  • Received packets are rebroadcast afteronce, thewith standardhigher forwardingpriority delaythan -CLIENT identicalroles — similar to ROUTER in thisthe respect.act of relaying.
  • TheIt is not visible in the node list and does not maintain a node database. It does not track neighbours, does not respond to traceroute requests, and does not build a picture of the mesh topology.
The node does not broadcastsend NodeInfo advertisements.— Itit is effectively anonymous fromon the rest of the network's perspective.mesh. It will not appear in the node list of clients that have not heard it directly. NoIt does not originate its own broadcasts (telemetry, position, NodeInfo); per the docs it "only responds to other nodes' packets instead of originating of user messages - same restriction as ROUTER.messages." Because there is no node database to maintain and no periodic announcements to schedule,Per the firmware'sdocs memoryit and CPU footprint is reduced, which matters on resource-constrained platforms like the ESP32rebroadcasts with limitedminimal RAM.overhead. (It does not force power-saving sleep, unlike ROUTER.)

The anonymity of the REPEATER role is a deliberate design choice: pure relay nodes that cannotaren't beindividually addressed individually produce less management overhead on the mesh. However, this also means you lose visibility - you cannot pingBecause a REPEATER by node ID, and it willis not show signal-strength data for incoming packets in the node list, you generally cannot select or ping it by node ID in the app the way you can a ROUTER does.ROUTER.

Setting the REPEATER role via CLI

meshtastic --set device.role REPEATER

Hop Count Handling Across Roles

All threerelaying roles participate in hop-count decrement identically. When a packet arrives with a remaining hop count of N, the forwarding node decrements it to N-1 before rebroadcasting. If N is already 0, the packet is consumed locally but not forwarded. NeitherROUTER roleand hasREPEATER ahave bypassrebroadcast forpriority the(they hopmay counterrebroadcast -sooner, and defer less to other rebroadcasters) but they still decrement and honour hop_limit — there is no hop-counter bypass or "always forward regardless" mode.

The practical consequence is that placing a REPEATERrelay mid-path does use a hop. PlanDefault yourhop_limit networkis so3 thatand the maximum is 7; "really, 3 is fine" per the docs. Ensure the number of infrastructurerelay hops between any two end clientsendpoints does not exceed your configured hop_limit. minusRaising 1.hop_limit to "fix" dropped messages can worsen congestion (more airtime and collisions), so pair any increase with a check on channel utilisation.

Choosing the Right Role

Community fixed repeater on a hilltop or tower

Use ROUTER. The node should be visible to the community (appears in node list, respondssends toNodeInfo, relays traceroutes), but it should not begenerate generatinguser traffic of its own. Operators can still access the serial console locally for configurationconfiguration. withoutFor enablinga ROUTER_CLIENT.node that should defer to the rest of the mesh before rebroadcasting, consider ROUTER_LATE.

meshtastic --set device.role ROUTER

Ham operator's home station that also relays

Use ROUTER_CLIENTCLIENT. YouCLIENT wantnodes thealready relayrebroadcast capabilityvia ofmanaged ROUTERflooding, butso alsoa needhome station set to CLIENT both relays and lets you participate in mesh conversations -— sending emergency alerts, coordinating with your community, or running net check-ins from the same hardware. (The old advice to use ROUTER_CLIENT here is obsolete; ROUTER_CLIENT was retired in 2.3.15.)

meshtastic --set device.role ROUTER_CLIENTCLIENT

Minimal-overhead anonymous relay

UseHistorically REPEATER. Idealwas the choice for a small ESP32-based node tucked into a building to bridge two otherwise disconnected areas,areas wherewith no topology visibility. Because REPEATER is deprecated as of firmware ~2.7.x, prefer ROUTER (or ROUTER_LATE) for new deployments; only use REPEATER if you do notspecifically need topologyan visibilityanonymous relay and wantunderstand theit lowestis possiblebeing firmwarephased overhead.out.

meshtastic --set device.role ROUTER   # preferred; REPEATER is deprecated

Power Consumption Comparison

AllIdle threepower rolesprofiles keepdiffer by role. A REPEATER keeps the radio onactive continuously,and does not force sleep, whereas a ROUTER uses forced power-saving sleep (ESP32) that cannot be disabled — so thetheir dominant poweridle draw is similar.not the same. The differences otherwise arise from background processing:

  • REPEATER winshas onminimal idleoverhead CPUper andthe RAMofficial usagedocs, because it skips nodeoriginating databasebroadcasts maintenanceand entirely.node-presence Onmaintenance. an(We ESP32do runningnot atcite 240a MHzspecific this typically saves 20 - 40 kB ofkilobyte heap andfigure, eliminatesas periodicno databasefirmware serialisation.source Inquantifies heavily node-dense networks this can be the difference between stable operation and heap exhaustion.it.)
  • ROUTER andforces power-saving sleep on (ESP32); ROUTER_CLIENTROUTER_LATE useleaves similarsleep configurable via power.is_power_saving. ROUTER_CLIENTIf adds negligible overhead unlessa GPS is active, in which case GPS module drawcurrent (typicallywhich 20varies -widely 50by mAmodule for— consult the module's datasheet) can dominate other draw.
LoRa TX current is board- and TX-power-dependent. For an activeSX1262-class patchradio antenna)alone, dominatesTX everything else. All three roles drawis roughly 100 - 160~118 mA at 3.3+22 VdBm duringand LoRaRX TXis roughly ~5 mA (actualSemtech valueSX1262 dependsdatasheet); boards with an external PA draw more, and total board draw (including the MCU) is higher than the radio alone. Treat any single current figure as approximate and board-dependent. Power-saving sleep is broadly available via power.is_power_saving to most roles (all except TRACKER and SENSOR). It is not exclusive to CLIENT: ROUTER forces it on TXautomatically, powerwhile settingREPEATER and frequency). Receive mode is typically 10 - 15 mA. Idle-radio sleep, which only CLIENT role devices use, isdoes not applicablesleep toby any infrastructure role.default.

Quick CLI power-related settings for infrastructure nodes

# Disable Bluetooth to save ~5power mA(figure continuouslyis approximate; verify against the Bluetooth config docs)
meshtastic --set bluetooth.enabled false

# DisableReduce the screen backlighton-time ifto presentsave (savespower. 20-80Note: mAthe whendocumented displayfield is on)display.screen_on_secs.
# A value of 0 is the 10-minute DEFAULT, not "off"; set a small nonzero value to dim sooner.
meshtastic --set display.backlight_secsscreen_on_secs 010

# Set a lower TX power only if nodes are nearby (reduces TX draw and channel utilisation).
# tx_power 0 is the default and means "use the region-legal maximum." Never set a higher fixed
# value than your region/antenna combination legally allows (note the >6 dBi gain-reduction rule).
meshtastic --set lora.tx_power 17
Back to top