Part I: Meshtastic Node Roles and Network Design: Building an Efficient LoRa Mesh

Part II: Infrastructure Nodes, Routing Priorities, and Best Practices in Meshtastic

Part III: Relay Policies, Power Management, and Practical Node Configuration in Meshtastic

Part IV: Optimizing Meshtastic Radio Configuration: Hop Limits, LoRa Presets, and Custom Modem Settings

Fine-Tuning Packet Forwarding

Selecting the appropriate device role is only part of the configuration process. Several Meshtastic roles also allow administrators to define exactly which packets should be forwarded through the mesh.

This forwarding policy can have a significant impact on overall network efficiency, especially in large public deployments where devices belonging to different communities may share the same radio frequency.

By limiting unnecessary retransmissions, operators can reduce channel congestion while preserving bandwidth for traffic that actually belongs to their network.

The optimal policy depends on network size, traffic volume, and operational objectives.

Relay Mode: ALL

The default forwarding mode is ALL.

In this configuration, every received packet that satisfies normal routing rules becomes eligible for retransmission, regardless of whether it belongs to the local encrypted network or another Meshtastic deployment using compatible radio settings.

This provides maximum interoperability and generally works well for small community networks where channel utilization remains low.

However, in crowded environments it may also result in forwarding packets that have little relevance to local users.

For most new deployments, ALL remains the safest choice because it preserves maximum compatibility.

Relay Mode: LOCAL_ONLY

LOCAL_ONLY limits forwarding to packets that belong to the local encrypted channels configured on the node.

Messages from unrelated networks are ignored, as are packets that cannot be decrypted.

This policy reduces unnecessary retransmissions and is particularly useful for private deployments where interoperability with neighboring meshes is not required.

Typical applications include:

• company-owned infrastructure
• industrial monitoring
• private emergency communication systems
• closed organizational networks

Because unrelated traffic is filtered before retransmission, LOCAL_ONLY generally produces lower channel utilization than ALL.

Relay Mode: KNOWN_ONLY

KNOWN_ONLY applies even stricter filtering.

In addition to requiring local channels, the transmitting node must already exist in the device’s internal node database.

Unknown devices are ignored entirely.

This approach can significantly reduce unwanted forwarding in environments where many unrelated nodes periodically appear within radio range.

The tradeoff is that newly discovered devices may require additional time before becoming active participants in the mesh.

KNOWN_ONLY is therefore best suited for relatively stable networks where participating nodes change infrequently.

Relay Mode: CORE_PORTNUMS_ONLY

Meshtastic transports multiple categories of application traffic, each identified by a port number.

CORE_PORTNUMS_ONLY forwards only the protocol messages required for normal mesh operation.

Examples include:

• text messages
• node information
• position updates
• routing packets
• telemetry

Packets generated by optional applications such as experimental plugins, range testing utilities, or third-party integrations are excluded from retransmission.

This configuration helps reduce airtime consumption while preserving the core communication features expected by most users.

Large public meshes often benefit from this mode when optional application traffic begins competing with ordinary messaging.

Relay Mode: NONE

The NONE policy completely disables retransmission.

Only direct communication initiated by the local node continues to function.

This option is available only for several specialized roles, including TRACKER and SENSOR, where forwarding traffic from other devices would unnecessarily increase power consumption.

For battery-operated equipment that exists solely to transmit telemetry or GPS information, disabling retransmission often provides a worthwhile improvement in operating time.

ALL_SKIP_DECODING

A special forwarding mode known as ALL_SKIP_DECODING exists primarily for repeater-style behavior.

Instead of decoding received packets before forwarding them, the node immediately retransmits the raw radio frames.

By avoiding packet processing, CPU utilization decreases slightly.

Although technically interesting, this mode has limited practical value in modern Meshtastic deployments because the traditional REPEATER role is no longer recommended.

Choosing an Appropriate Relay Policy

There is no universally correct forwarding policy.

Instead, operators should periodically evaluate network activity and adjust filtering based on actual channel conditions.

Questions worth asking include:

• Is the node forwarding large amounts of unrelated traffic?
• Are optional applications generating excessive airtime?
• Does the network primarily serve one organization or many independent users?
• Is congestion becoming noticeable during busy periods?

Filtering unnecessary traffic often produces greater improvements than increasing transmission power or installing additional infrastructure nodes.

Understanding Power Consumption

Not every Meshtastic role consumes energy in the same way.

Some devices remain continuously active, while others spend most of their time in deep sleep.

Selecting an appropriate role therefore affects not only routing behavior but also battery life.

CLIENT

Standard CLIENT nodes remain fully operational.

Wireless interfaces, display updates, routing decisions, telemetry collection, and packet forwarding all remain active.

This provides maximum functionality at the expense of higher average power consumption.

CLIENT_MUTE

CLIENT_MUTE typically offers noticeably longer battery life.

Because retransmissions are disabled, the radio transmits less frequently, reducing overall energy consumption.

For portable handheld devices operating within established infrastructure, this role often provides the best balance between usability and endurance.

CLIENT_HIDDEN

CLIENT_HIDDEN further reduces radio activity by limiting routine transmissions.

Lower airtime translates directly into improved battery life, making this role attractive for portable equipment expected to operate for extended periods without recharging.

TRACKER and SENSOR

These specialized roles aggressively conserve energy.

The microcontroller spends much of its time sleeping, periodically waking to acquire GPS data or sensor readings before transmitting short telemetry bursts.

For solar-powered installations or remote environmental monitoring stations, these roles offer substantially lower energy requirements than general-purpose client modes.

ROUTER

Infrastructure routers represent the opposite end of the spectrum.

Maximum availability requires the radio to remain continuously active, often alongside elevated transmission duty cycles.

Many ROUTER deployments disable unnecessary peripherals such as displays or Bluetooth interfaces in order to dedicate system resources to networking.

Since these devices are normally installed in fixed locations with permanent power supplies, energy efficiency is rarely the primary concern.

Remote Administration Considerations

Before configuring a permanent infrastructure node, remote management should be fully operational.

Some infrastructure roles disable user interfaces or enter deep sleep modes that make local interaction difficult after deployment.

A rooftop installation requiring physical access simply to modify configuration parameters quickly becomes inconvenient.

Reliable Bluetooth, Wi-Fi, serial access, or remote administration should therefore be verified before final installation.

Comparing Device Roles

Although every role ultimately participates in the same mesh, their operational characteristics differ considerably.

General-purpose client roles prioritize user interaction and messaging.

Infrastructure roles prioritize packet forwarding and network connectivity.

Tracking and sensing roles prioritize battery life while minimizing unnecessary communication.

The following simplified comparison illustrates their intended purpose.

Role	User Interaction	Packet Forwarding	Power Usage	Primary Purpose
CLIENT	Full	Adaptive	Medium	General communication
CLIENT_MUTE	Full	Disabled	Low	Portable users
CLIENT_HIDDEN	Limited	Minimal	Very Low	Low-profile operation
CLIENT_BASE	Full	Priority for Favorites	Medium	Personal base station
TRACKER	Limited	Minimal	Low	GPS tracking
SENSOR	Minimal	Minimal	Low	Telemetry collection
TAK	Specialized	Standard	Medium	ATAK integration
ROUTER	None	Maximum priority	High	Backbone infrastructure
ROUTER_LATE	Full	Delayed forwarding	High	Coverage extension

This comparison highlights an important principle.

Infrastructure roles are not upgrades.

They simply solve different engineering problems.

Selecting the Right Configuration

For the overwhelming majority of users, the recommended configuration remains surprisingly simple.

If the device is handheld, mobile, or battery-powered, CLIENT_MUTE is often the best option.

If the node provides elevated coverage through an outdoor antenna, CLIENT usually offers the optimal balance between routing performance and network efficiency.

CLIENT_BASE becomes valuable when building a personal two-node deployment consisting of a fixed station and one or more portable devices.

Infrastructure roles should only be introduced after analyzing actual network topology and identifying specific coverage deficiencies.

Successful mesh networks are built through careful planning rather than aggressive retransmission.

The most efficient node is not necessarily the one that forwards the largest number of packets. It is the one whose transmissions provide the greatest improvement to overall network connectivity while consuming the least possible airtime.