Meshtastic Roles Explained: Client, Router, and More

A Meshtastic device role tells a node how to behave in the mesh: whether it relays other people’s packets, how eagerly, and what it prioritizes sending. The official guidance is short: keep almost every node on CLIENT (or CLIENT_MUTE / CLIENT_BASE), and reserve ROUTER for rare, exceptionally well-placed sites.

This guide summarizes each role from the Device Configuration docs and two official blog posts. LoRa Mesh Atlas is not affiliated with Meshtastic.

The short answer

The Configuration Tips page says: “It is strongly recommended to keep your ROLE set to CLIENT, CLIENT_MUTE, or CLIENT_BASE. Only use other roles if you have a specific, well-understood reason to do so.” It adds that “a network of CLIENT nodes with a small number of well-placed ROUTERS is usually the most efficient and stable configuration.”

Every role at a glance

From the roles table:

Role	What it does	Typical use
CLIENT	Messaging device; rebroadcasts packets when no other node has done so	Default for nearly everyone
CLIENT_MUTE	Does not forward other devices’ packets	Extra devices near a better node; busy meshes
CLIENT_HIDDEN	Broadcasts only as needed, for stealth or power savings	Hidden deployments, low airtime
CLIENT_BASE	Always rebroadcasts packets from or to its favorited nodes; otherwise acts like CLIENT	Your attic or roof “base station”
TRACKER	Prioritizes GPS position broadcasts	Tracking people, vehicles, assets
LOST_AND_FOUND	Regularly broadcasts its location as a message on the default channel	Recovering a lost device
SENSOR	Prioritizes telemetry broadcasts	Weather and environmental sensors
TAK	Optimized for ATAK, fewer routine broadcasts	Use with the Meshtastic ATAK plugin
TAK_TRACKER	Automatic TAK position (PLI) broadcasts	Standalone ATAK position reporting
ROUTER	Infrastructure; always rebroadcasts once; visible in node list	Exceptional high sites only
ROUTER_LATE	Infrastructure; always rebroadcasts, but after other nodes	Covering a dead spot the main mesh can’t reach
REPEATER	Infrastructure; always rebroadcasts with minimal overhead; hidden from node list	Deprecated as of firmware 2.7.11

The docs also note that ROUTER_CLIENT was deprecated in firmware 2.3.15.

Client roles in more detail

CLIENT

The role-selection blog post calls CLIENT “a flexible, general purpose role” that “should serve the overwhelming majority of use cases.” It stresses a common misunderstanding: “Clients in Meshtastic do actually repeat / route messages.” That confusion has led people to pick ROUTER when they didn’t need it.

The tips page even lists rooftop installations, high-visibility locations, and remote outdoor trips as good fits for CLIENT.

CLIENT_MUTE

CLIENT_MUTE sends and receives its own messages but never relays. The blog recommends it for people with several devices: set one to CLIENT or CLIENT_BASE and the rest to CLIENT_MUTE “to keep your airtime usage more responsible.” The tips page also suggests it for indoor nodes that only talk to one outdoor node.

CLIENT_BASE

CLIENT_BASE is designed for a stronger node at your home. It gives priority (relaying in the early window, like a router) to packets from or to nodes you’ve marked as favorites, and treats all other traffic like a normal CLIENT. The setup the docs describe: set the roof or attic node to CLIENT_BASE, then favorite your other personal nodes on it.

TRACKER and SENSOR

These roles prioritize position or telemetry packets “even in the face of high channel utilization,” per the blog. Combined with power saving, they sleep between scheduled transmissions. The device docs note that in this sleep mode the LoRa radio does not stay in standby to wake the device, so they won’t relay while asleep. See our solar node guide for power settings.

Infrastructure roles: ROUTER, ROUTER_LATE, REPEATER

How they differ from clients

The Mesh Broadcast Algorithm page explains that most nodes cancel their rebroadcast if they hear another node relay the packet first. “The exception is the ROUTER and ROUTER_LATE roles, which rebroadcast even if they hear another node rebroadcasting.” CLIENT_BASE does the same, but only for its favorites.

The ROUTER_LATE blog post describes three non-overlapping timing windows:

Window	Who uses it	Effect
Early	ROUTER, REPEATER, CLIENT_BASE (favorites only)	Relays first and can cause other nodes to cancel their own relay
Default	All other roles	Normal relaying
Late	ROUTER_LATE	If it heard another node relay first, it still relays, but last

ROUTER: when to use it (and when not)

The blog says ROUTER is “ONLY suitable for stationary devices placed in extremely strategic locations.” It suggests imagining “a tower on mountain peak rather than a tall building,” and recommends collecting real-world data on the mesh and using line-of-sight viewshed tools before choosing a site. Routers also try to save power and send telemetry less often. On ESP32 boards, the ROUTER role turns on power saving automatically and it cannot be turned off, which disables Bluetooth; the docs recommend using remote admin to change settings (Device config, Power config).

The blog lists three harms from badly placed routers:

1. More packet collisions. Neighboring routers all relay at once.
2. Less range. A poorly sited router “hop gobbles,” spending a hop before the packet reaches a better-placed node.
3. One-way links. Some groups can send to others but replies can’t make it back, which tempts users to raise hop limits and worsens congestion.

The tips page adds: coordinate with your local community before changing from CLIENT.

ROUTER_LATE

ROUTER_LATE is for sites that are important for a cluster of nodes but aren’t positioned to serve the whole mesh, such as nodes on the far side of a hill or in a canyon, per the ROUTER_LATE post. It acts like a CLIENT until it hears someone else relay first, then defers its own relay to the late window instead of canceling.

The same post is clear about what it’s not for:

• “It is not intended as a rooftop node to extend the range of devices inside your house.” Use CLIENT_BASE for that.
• If you use it anyway, watch channel utilization; the post asks you to stop if ChUtil goes above 25% or your node’s AirUtilTX above about 7–8%.
• It’s not a mobile role. A temporary vehicle relay for a hiking party can be appropriate, but switch it back afterward.
• If your node can receive but nobody hears it, deploy a CLIENT nearby rather than a ROUTER_LATE.

REPEATER

REPEATER behaved like ROUTER but turned off its own broadcasts such as telemetry and didn’t appear in node lists. The docs mark it deprecated as of firmware 2.7.11. If you have one, review whether ROUTER, ROUTER_LATE, or CLIENT fits better.

Rebroadcast mode

Separate from the role, the rebroadcast mode controls which packets a node relays:

Mode	Behavior
ALL (default)	Relays everything on matching modem settings, even packets it can’t decrypt
ALL_SKIP_DECODING	Like ALL but doesn’t decode; only with the REPEATER role
LOCAL_ONLY	Relays only traffic on its own channels
KNOWN_ONLY	Like LOCAL_ONLY, and ignores nodes not in its node database
NONE	No relaying; only for SENSOR, TRACKER, TAK_TRACKER
CORE_PORTNUMS_ONLY	Relays only core packet types (NodeInfo, text, position, telemetry, routing)

Choosing a role: a practical checklist

• One handheld or a phone-paired node: CLIENT.
• Several devices in one place: best-placed one CLIENT or CLIENT_BASE, the rest CLIENT_MUTE.
• Roof or attic node for your household: CLIENT_BASE, with your other nodes favorited.
• Asset or person tracker: TRACKER.
• Weather or sensor station: SENSOR.
• Mountaintop or tower site coordinated with your local mesh: possibly ROUTER.
• Fixed site serving a blocked pocket of users: possibly ROUTER_LATE.

Roles work alongside modem presets and hop limits; a good role on the wrong preset won’t help. For hardware suited to fixed sites, see /devices/ or the finder, and for siting, the range guide.