ROUTER vs ROUTER_CLIENT vs REPEATER Role: Deep Dive
ROUTER vs ROUTER_CLIENT vs REPEATER Role: Deep Dive
Meshtastic provides three infrastructure-oriented device roles for nodes that exist to extend network reach rather than serve end users. 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.
The Three Infrastructure Roles at a Glance
| Capability | ROUTER | ROUTER_CLIENT | REPEATER |
|---|---|---|---|
| Rebroadcasts all received packets | Yes | Yes | Yes |
| Keeps radio on continuously | Yes | Yes | Yes |
| Can originate user messages (text, position) | No | Yes | No |
| Maintains a node database (neighbor list) | Yes | Yes | No |
| Appears as a named node in the node list | Yes | Yes | No (anonymous relay) |
| Sends periodic NodeInfo broadcasts | Yes | Yes | No |
| Relative RAM/CPU overhead | Medium | Medium | Low |
ROUTER Role
A ROUTER node is the canonical fixed-infrastructure role. When you set a node to ROUTER it immediately adjusts its behavior in the following ways:
- The radio stays on full-time — no sleep modes, no duty-cycle restrictions beyond regulatory limits.
- Every received packet that passes the duplicate-detection filter is rebroadcast, regardless of packet type (text messages, position updates, telemetry, node info, traceroutes, etc.).
- The device sends its own
NodeInfoadvertisement on the configured broadcast interval so other nodes know it exists and can display it on the map. - The ROUTER maintains a full node database — it tracks neighbours, can respond to traceroute packets with hop-by-hop path information, and participates in neighbour-info exchanges.
- The ROUTER does not originate user-level messages. You cannot send a text from a pure ROUTER node. The device has no "Send" capability in the app because the firmware intentionally omits that code path for this role.
Setting the ROUTER role via CLI
meshtastic --set device.role ROUTERVerifying the role was applied
meshtastic --get device.roleROUTER_CLIENT Role
ROUTER_CLIENT is a superset of ROUTER. It retains every relay behaviour of ROUTER (radio always on, rebroadcast all packets, full node database, NodeInfo broadcasts) while also enabling the node to originate messages as a first-class client:
- Text messages can be composed and sent from the device (via app, web UI, or serial CLI).
- Position data from the device's own GPS (or manually configured coordinates) is broadcast on the position update interval.
- The operator at the repeater site can use the node for voice-channel communication during events or emergency activations without compromising the relay function.
The trade-off is marginal: originating position and telemetry packets increases local air-time slightly. On a busy channel this adds a few percentage points of channel utilisation compared to a pure ROUTER.
Setting the ROUTER_CLIENT role via CLI
meshtastic --set device.role ROUTER_CLIENTREPEATER Role
The REPEATER role is the most minimal relay option. It is designed for nodes that should retransmit packets but consume the absolute minimum resources and produce no additional air-time of their own:
- Received packets are rebroadcast after the standard forwarding delay — identical to ROUTER in this respect.
- The node 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 broadcast
NodeInfoadvertisements. It is effectively anonymous from the rest of the network's perspective. It will not appear in the node list of clients that have not heard it directly. - No originating of user messages — same restriction as ROUTER.
- Because there is no node database to maintain and no periodic announcements to schedule, the firmware's memory and CPU footprint is reduced, which matters on resource-constrained platforms like the ESP32 with limited RAM.
The anonymity of the REPEATER role is a deliberate design choice: pure relay nodes that cannot be addressed individually produce less management overhead on the mesh. However, this also means you lose visibility — you cannot ping a REPEATER by node ID, and it will not show signal-strength data for incoming packets in the way a ROUTER does.
Setting the REPEATER role via CLI
meshtastic --set device.role REPEATERHop Count Handling Across Roles
All three 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. Neither role has a bypass for the hop counter — there is no "always forward regardless" mode.
The practical consequence is that placing a REPEATER mid-path does use a hop. Plan your
network so that the number of infrastructure hops between any two end clients does not exceed
your configured hop_limit minus 1.
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, responds to traceroutes), but it should not be generating traffic of its own. Operators can still access the serial console locally for configuration without enabling ROUTER_CLIENT.
meshtastic --set device.role ROUTERHam operator's home station that also relays
Use ROUTER_CLIENT. You want the relay capability of ROUTER but also need to participate in mesh conversations — sending emergency alerts, coordinating with your community, or running net check-ins from the same hardware.
meshtastic --set device.role ROUTER_CLIENTMinimal-overhead anonymous relay
Use REPEATER. Ideal for a small ESP32-based node tucked into a building to bridge two otherwise disconnected areas, where you do not need topology visibility and want the lowest possible firmware overhead.
meshtastic --set device.role REPEATERPower Consumption Comparison
All three roles keep the radio on continuously, so the dominant power draw is similar. The differences arise from background processing:
- REPEATER wins on idle CPU and RAM usage because it skips node database maintenance entirely. On an ESP32 running at 240 MHz this typically saves 20–40 kB of heap and eliminates periodic database serialisation. In heavily node-dense networks this can be the difference between stable operation and heap exhaustion.
- ROUTER and ROUTER_CLIENT use similar power. ROUTER_CLIENT adds negligible overhead unless GPS is active, in which case GPS module draw (typically 20–50 mA for an active patch antenna) dominates everything else.
- All three roles draw roughly 100–160 mA at 3.3 V during LoRa TX (actual value depends on TX power setting and frequency). Receive mode is typically 10–15 mA. Idle-radio sleep, which only CLIENT role devices use, is not applicable to any infrastructure role.
Quick CLI power-related settings for infrastructure nodes
# Disable Bluetooth to save ~5 mA continuously
meshtastic --set bluetooth.enabled false
# Disable the screen backlight if present (saves 20-80 mA when display is on)
meshtastic --set display.backlight_secs 0
# Set a lower TX power if nodes are nearby (reduces TX draw and channel utilisation)
meshtastic --set lora.tx_power 17
No comments to display
No comments to display