Device Roles Explained
What CLIENT, CLIENT_MUTE, CLIENT_BASE, ROUTER and TRACKER actually do — and why picking ROUTER wrongly hurts the whole mesh.
The single most important — and most misunderstood — Meshtastic setting is the device Role. It controls how a node participates in the mesh: whether it just sends and receives its own traffic, whether it repeats other people’s traffic, and how aggressively. Choosing the wrong role (especially ROUTER) is one of the most common ways to hurt a mesh, so it’s worth understanding.
This page explains the roles this fleet uses and why each node is set the way it is.
The core idea: who repeats traffic, and how eagerly
When a node hears a packet, it decides whether to rebroadcast it so the packet can travel further. Roles differ mainly in that decision:
- Some roles repeat other people’s packets (helping the mesh reach further).
- Some roles never repeat (they only handle their own messages).
- Among those that repeat, some wait politely (a random backoff, yielding if a neighbour already repeated it) and some always repeat immediately (aggressive — useful in the right spot, harmful in the wrong one).
A healthy mesh is mostly Clients with a few well-placed relays. Too many aggressive repeaters cause collisions, congestion, and fewer messages getting through — the opposite of what people expect.
The roles this fleet uses
CLIENT
The default, and the right choice for most personal devices you actively use. A CLIENT sends and receives your messages and intelligently repeats others’ packets — but with a random backoff so it doesn’t aggressively compete with better-placed nodes. It yields if it hears a neighbour repeat first. It appears on everyone’s node list.
Use it for: a device you carry and use, that should still help the mesh when it can.
CLIENT_MUTE
Same as CLIENT for sending and receiving your own traffic, but it never repeats other people’s packets. It participates without adding any rebroadcasts.
Use it for: extra nodes you own near a stronger node, or any node in a busy area where another repeat would just add congestion. If you have several nodes, the clean pattern is: one CLIENT/CLIENT_BASE, the rest CLIENT_MUTE.
CLIENT_BASE
For a personal base station — a node in a genuinely good spot (attic, upstairs window, rooftop) that helps your own devices reach the wider mesh. You favourite your personal nodes on it. It repeats, but it’s tuned around your own traffic rather than acting like general infrastructure.
Use it for: a well-placed home node that prioritises your other devices. (You’ll see many other operators’ nodes on the mesh using this role.)
ROUTER
Dedicated infrastructure. A ROUTER always repeats and cuts in ahead of other nodes — it doesn’t wait or yield. That makes it powerful for extending range, but only when the node is stationary and in a genuinely strategic, high location. In the wrong place it consumes hops and airtime and degrades the mesh.
Use it for: a fixed, well-sited relay only. This is not a role for a node you carry, and not one to pick just because it sounds powerful.
TRACKER
A position-reporting node. It focuses on sending its own GPS location and is excluded from routing — it doesn’t repeat others’ traffic.
Use it for: a GPS tag whose job is “where is this thing,” not relaying.
Meshtastic has other roles (REPEATER, ROUTER_LATE, ROUTER_CLIENT, SENSOR, CLIENT_HIDDEN, TAK, and more) for specialised cases. This fleet doesn’t use them, so they’re left out here. The official guidance is to stay on CLIENT / CLIENT_MUTE / CLIENT_BASE unless you have a specific, well-understood reason — and to coordinate with the local community before running a ROUTER.
How this fleet assigns roles — and why
Each node’s role was chosen deliberately for what it does and where it sits:
| Node | Role | Why |
|---|---|---|
| KYKM (handheld) | CLIENT | Carried everyday device. It should participate and help relay when it can, but with polite backoff so it doesn’t crowd better-placed nodes. |
| KYKN (travel/office) | CLIENT_MUTE (→ CLIENT at the office) | At home it sits near the router (KYKR), so it stays MUTE to avoid a redundant repeat right next to a dedicated relay. At the office — away from that router — it’s promoted to CLIENT so it can help the other office node. |
| KYKT (tracker) | TRACKER | Its only job is reporting its GPS position. It’s excluded from routing so it doesn’t add airtime. |
| KYKR (solar router) | ROUTER | A stationary, well-sited solar node (destined for an elevated piling) whose whole purpose is to relay and extend range. This is the one node where ROUTER is the correct choice — fixed, strategic, and coordinated. |
| KYKB (base/gateway) | CLIENT_MUTE | Indoor base near the router; it’s the MQTT gateway, not a relay, so it stays MUTE and doesn’t compete with KYKR on the air. |
The pattern behind the table: exactly one dedicated ROUTER (KYKR) in a strategic spot, and everything else kept as a quiet or polite client so nothing competes with it or clutters the local airtime. That’s the “mostly clients, a few well-placed relays” principle applied to one operator’s fleet — which is why the personal nodes near home are MUTE, the carried device is CLIENT, and only the solar node is a ROUTER.
The one warning worth repeating
Don’t set a node to ROUTER just because it sounds better. A ROUTER in a poor location (indoors, mobile, low, or crowded next to other routers) causes packet collisions, wastes hops, and lowers delivery rates for everyone nearby. If a node isn’t a stationary, well-placed, coordinated relay, it should be CLIENT, CLIENT_MUTE, or CLIENT_BASE. When in doubt, CLIENT.