Meshtastic Configuration Tips

Best Practices for Configuring Meshtastic Nodes

Unfortunately, a Meshtastic client node cannot be configured to selectively repeat signals based on the sending node’s role (such as only repeating CLIENT_MUTE nodes). [1, 2]

At the packet level, a CLIENT_MUTE node sends standard mesh packets. The network firmware treats its outbound messages exactly like those from any other node role. A standard CLIENT node will automatically attempt to repeat all valid incoming mesh traffic that still has available hops left, regardless of whether the original sender was a client, a tracker, or a mute device. [1, 2, 3, 4]

However, depending on what you are trying to accomplish, there are a couple of native Meshtastic alternative features that might help you restrict traffic:

1. The CLIENT_BASE Role (Personal Filtering)

If your goal is to have a well-positioned node (like on your roof) prioritize or focus on specific handheld devices, you should use the CLIENT_BASE role. [1, 5, 6]

• How it works: You assign a standard node to CLIENT_BASE and mark your personal handheld nodes as “Favorites” in its configuration.
• The behavior: The node will actively give priority to rebroadcasting messages coming from or going to your favorited devices while handling the rest of the general mesh traffic much more conservatively. [5, 6, 7]

2. Device Rebroadcast Filters

If you want to stop a node from repeating general neighborhood chatter, you can adjust the Rebroadcast Mode settings in the Radio Configuration: [8]

• KNOWN_ONLY: The node will completely ignore and refuse to repeat packets from any node ID that isn’t already saved in its local NodeDB.
• CORE_PORTNUMS_ONLY: The node will ignore and drop high-bandwidth utility packets (like Range Tests, PaxCounters, or TAK tracking data) and will only repeat essential text messages, positions, and telemetry. [8]

---

---

---

Zero Cost Hops

Because the core Meshtastic routing firmware processes packets based on network metrics (like hop counts and SNR) rather than the sender’s configuration role, there is no switch or software setting to natively filter out “Client” nodes while favoring “Client_Mute” nodes. At a protocol level, packets sent from a CLIENT_MUTE node look identical to packets sent by a standard CLIENT. [1, 2]

However, you can accomplish your exact goal—giving preferential treatment to specific CLIENT_MUTE nodes while ignoring or penalizing arbitrary standard clients—by utilizing Meshtastic’s Zero-Cost Hops (Favorites) feature. [3]

---

The Best Solution: CLIENT_BASE + Favorites List

The CLIENT_BASE device role acts exactly like a regular client to the general public, but shifts into an aggressive, guaranteed router role for specific devices you designate. [4, 5]

If you configure your primary relay node (e.g., your rooftop base or home station) as a CLIENT_BASE, you can manually add your chosen CLIENT_MUTE devices to its Favorites list. [1, 3]

🛠️ How to Set This Up:

1. Configure the Relay: Connect to your main relay node using the Meshtastic Web UI or mobile app. Go to Radio Configuration > Device and set the Role to CLIENT_BASE. [1, 6]
2. Configure the Handhelds: Set your personal or group handheld devices to the CLIENT_MUTE role. This prevents them from wasting their own battery trying to repeat traffic for the neighborhood. [1, 2]
3. Build the Favorites List: On your CLIENT_BASE node, open your NodeDB (the list of active nodes). Find your specific CLIENT_MUTE devices and toggle them as “Favorite”. [1, 3, 7]

🌟 How This Solves Your Problem:

• The “Favoritism” Mechanic: When your CLIENT_BASE node sees a packet sent by or destined for your favorited CLIENT_MUTE devices, it instantly prioritizes repeating it. In recent firmware versions, favorited node connections often utilize “zero-cost hops,” meaning they don’t consume the packet’s total hop count, ensuring maximum mesh distance for your favored nodes. [3, 4, 8, 9]
• Ignoring Regular Clients: Any standard public CLIENT nodes that transmit nearby will not be in your favorites list. Your base station will treat them with standard, conservative client rules, meaning it won’t go out of its way to favor them or prioritize their airtime. [4]

---

Alternative: Channel Isolation

If you want to completely block out public CLIENT nodes rather than just deprioritize them, the most effective route is Channel Isolation.

Instead of relying on device roles to filter traffic, move your CLIENT_MUTE devices and your base station to a Private Primary Channel with a custom pre-shared key (PSK). By removing the default public LONG_FAST channel, your node will physically ignore and refuse to repeat any standard public client nodes because it cannot decrypt or read their packets. [10, 11]

If you decide to try the CLIENT_BASE route, let me know:

• Are you managing a private team/family group, or trying to optimize a local public mesh?
• What hardware models are you currently configuring for your base and handhelds?

---

Community Guides – Meshtastic Configuration Tips

---

---

More community guides

---

[1] https://meshtastic.org

[2] https://openelab.io

[3] https://www.reddit.com

[4] https://www.seeedstudio.com

[5] https://openelab.io

[6] https://www.youtube.com

[7] https://meshtastic.org

[8] https://meshtastic.org

ABSTRACT:

LINKS:  | | |

AI OVERVIEW:

• Use Cases: Ideal for communities, hiking, biking, disaster preparedness, or secure, private communication, utilizing 915 MHz frequencies.

SPONSORS:
–
ACTIVE NODES:
– MeshMap.me/node/(add listing)
– MeshMap.me/node/(add listing)