# Network Troubleshooting

# Diagnosing Meshtastic Network Problems

This guide covers systematic diagnosis of common Meshtastic network issues: nodes that can't hear each other, poor range, network congestion, and routing failures.

## Diagnostic framework

Work from the bottom up: radio layer first, then routing, then application.

1. **Radio layer:** Can the nodes physically hear each other? Check RSSI/SNR.
2. **Configuration:** Are both nodes on the same preset and channel?
3. **Routing:** Is the path between nodes working? Use Trace Route.
4. **Application:** Is the app connected properly? Is the message actually sending?

## Problem: Two nodes can't communicate

### Check 1: Same preset?

Nodes on different presets cannot hear each other. Verify the preset directly on each node:

```
meshtastic --get lora.modem_preset   # run this on each node
```

Both nodes must report the same preset (e.g., LONG\_FAST or MEDIUM\_SLOW). You generally cannot read a remote node's modem preset from a node-list dump - check each node on its own connection. If they differ: change one to match the other.

### Check 2: Same channel and PSK?

Nodes must be on the same channel with the same PSK. The default public channel (LongFast) uses the well-known default PSK `AQ==` (a publicly known, weak key) - it is *not* an empty/no-encryption key. If you've customized your channel, the other node needs the same configuration.

```
meshtastic --info # Shows channel list with PSK hashes
```

PSK hash mismatch = nodes won't communicate even if physically in range.

### Check 3: Physical range and line of sight

In the [Meshtastic app](https://wiki.meshamerica.com/books/hardware-guide/page/meshtastic-app), check if the node appears in the node list with any RSSI/SNR value. Do not assume a low or negative SNR means a bad link: LoRa decodes well below the noise floor, with per-spreading-factor demodulation limits running from about −7.5 dB (SF7) to about −20 dB (SF12). At Long Fast / Long Slow, an SNR of −10 to −18 dB is routinely decodable, not "at the noise floor." A link only becomes marginal as SNR approaches the per-SF demod limit (for example below about −17 dB at SF11/Long Fast), or as RSSI approaches the receiver sensitivity floor (the SX1262 is sensitive to roughly −137 dBm at SF12). If the node doesn't appear at all, no packets are being received.

Test: bring both devices to within 100 feet of each other (no obstacles). If they communicate at that distance, it's a range/obstruction problem. If they still can't communicate at 100 feet, it's a configuration problem.

## Problem: Intermittent message delivery

### Check: Hop count

Messages requiring more hops have higher failure rates. Check your hop limit setting:

```
meshtastic --get lora.hop_limit
```

Default is 3 (the maximum is 7). Before raising it, verify with a traceroute that the path actually needs more hops. Raising `hop_limit` increases airtime and channel utilisation and can worsen congestion rather than fix dropped messages — the preferred fix for a long path is usually to add infrastructure to shorten it. If a traceroute confirms the path genuinely needs more hops, raise it incrementally (for example to 4) and monitor channel utilisation:

```
meshtastic --set lora.hop_limit 4
```

See [Hop Limit Configuration for Repeaters](/books/meshtastic-repeaters/page/hop-limit-configuration-for-repeaters) for the full caveats on high hop counts and channel utilisation.

### Check: Network congestion

In dense networks (20+ nodes), Long Fast preset can cause congestion. Symptoms: high message drop rate even with good RSSI, large delays. Solution: migrate to Medium Slow or Medium Fast preset. Requires coordination with all network participants - all nodes must change at the same time.

### Check: Router node availability

If a critical router node goes offline, messages that depended on that path fail. This is a design red flag, not just a diagnostic finding: if a single router node failing kills delivery for part of your network, that node is a single point of failure — see [Designing for Reliability (N+1 Redundancy)](/books/meshtastic-repeaters/page/designing-for-reliability-n1-redundancy). For emergency use, no incident-critical route should depend on one node. Use Trace Route before and after to confirm the path change:

```
meshtastic --traceroute !nodeId
```

## Problem: Poor range from a new repeater

1. **Antenna connected?** An unconnected antenna transmits into the PCB and can damage the radio front-end. Verify the antenna is finger-tight. Some boards have a separate BLE antenna and LoRa antenna - ensure both are connected.
2. **Correct antenna type?** Most boards use SMA or u.FL connectors. Verify your antenna has the correct connector type and is rated for your operating band - use a 915 MHz (902-928 MHz) antenna in North America. An 868 MHz antenna will radiate at 915 MHz but with a shifted resonance and elevated VSWR; for a broadband whip the penalty is usually small (a fraction of a dB), but for a narrowband tuned antenna the loss and reflected power can be significant, and high VSWR stresses the power amplifier. Note that antenna gain also bears on legal power limits — antennas over 6 dBi require a dB-for-dB reduction in conducted power per FCC 47 CFR 15.247(b)(4).
3. **TX power set correctly?** Check that TX power hasn't been set to an unusually low value: `meshtastic --get lora.tx_power`
4. **Obstructions:** Even a metal enclosure, HVAC equipment, or tree canopy directly around the antenna can reduce range significantly. Test with the antenna in the clear before committing to a location.

# Repeater Performance and Maintenance

A deployed repeater requires periodic attention to maintain performance. This page covers the key maintenance tasks and performance metrics for Meshtastic infrastructure nodes. Throughout, "infrastructure node" means the general concept; **ROUTER** and **REPEATER** refer to the specific device roles (which behave differently - a ROUTER appears in the node list, a REPEATER does not).

## Key performance indicators

The targets below are **recommended operational goals set by the author**, not official Meshtastic or manufacturer specifications. Treat them as starting points, not hard specs.

<table id="bkmrk-metrichealthy-rangea"><thead><tr><th>Metric</th><th>Healthy range</th><th>Action if outside range</th></tr></thead><tbody><tr><td>**Node uptime**</td><td>&gt;95% over 30 days (baseline only)</td><td>&gt;95% is a baseline health indicator, not a reliability guarantee - it still allows ~36 hours/month offline, and says nothing about *when* the downtime falls. For nodes an emergency operator depends on, investigate ANY unexplained downtime and treat repeated outages as disqualifying for sole-path infrastructure. Redundancy, not a high uptime number, is what guarantees coverage during an incident.</td></tr><tr><td>**Average RSSI to neighbors**</td><td>−70 to −100 dBm typical</td><td>RSSI down to roughly −120 to −130 dBm can still be decodable depending on spreading factor (SX1262 sensitivity ~−137 dBm at SF12). Judge link health by SNR margin and packet success, not RSSI alone; a sudden RSSI drop versus a known baseline is the useful warning sign, not a fixed −110 dBm threshold.</td></tr><tr><td>**SNR to nearest neighbor**</td><td>SNR margin above the per-SF demod limit</td><td>LoRa decodes well below 0 dB SNR - demod limits run from ~−7.5 dB (SF7) to ~−20 dB (SF12). What matters is SNR margin above the per-SF limit. For Long Fast (SF11, limit ~−17.5 dB), SNR down to about −12 dB is comfortable and approaching −17 dB is marginal. A backbone link at −10 to −12 dB SNR is normal and healthy, not a fault - do not treat SNR &lt; 0 dB as "noise floor / unreliable."</td></tr><tr><td>**Battery voltage (solar)**</td><td>Depends on pack configuration</td><td>State your battery configuration before reading these numbers. A *single* LiFePO4 cell has a working range of roughly 3.2 - 3.6 V; a 4S LiFePO4 pack is ~12.8 V nominal; a single Li-ion runs 3.0 - 4.2 V. Use the per-chemistry, per-configuration cutoff for your pack and align it with the cutoffs on the remote-monitoring page (e.g. ~11.5 V for a 12 V lead-acid pack, ~3.0 V per cell for LiPo). Repeated readings near the low end of *your* pack's range indicate an undersized power system.</td></tr><tr><td>**Packets forwarded per hour**</td><td>Varies by location</td><td>Sudden drop to 0 = node possibly offline</td></tr></tbody></table>

## Routine maintenance checklist (quarterly)

- Check the node appears on a current community/third-party map (such as the official Meshtastic map or a community MQTT-based map) - verify the service is still live, as these third-party maps come and go. Note that a node set to the REPEATER role will **not** appear on node maps (it is hidden from the nodes list); a ROUTER will. These maps only show nodes reporting to a public MQTT server and are not authoritative.
- Verify RSSI/SNR to neighboring nodes hasn't significantly degraded versus your baseline
- Check battery voltage logs if monitoring - look for downward trend
- Inspect solar panel: clean off debris, verify no shading from new growth
- Check antenna connector for corrosion or loosening (especially after winter)
- Verify firmware version - update if significantly behind current release
- Check enclosure for water intrusion - condensation inside is an early warning sign

## Firmware update process for deployed nodes

Flashing new firmware (reflashing the binary) on a deployed repeater requires physical USB/serial access. Configuration changes can be made remotely via Remote Admin over the mesh, but a firmware reflash cannot be done remotely. Prepare:

1. **Before taking ANY repeater offline for a firmware update, confirm an alternate path covers its users** (run traceroutes from both sides). NEVER update the only repeater serving an area without a tested spare on hand or a deployed temporary relay - a failed flash can leave the firmware in a crash loop, knocking out coverage with no rollback. Bring a known-good spare and a copy of the prior firmware so you can roll back on-site if the flash fails.
2. Schedule a maintenance window and notify the community (the node will be offline during update)
3. Bring: laptop, USB cable for your device type, and the firmware binary or web browser access
4. Before disconnecting: record current configuration (region, TX power, role, channel settings, position) with a restorable backup: `meshtastic --export-config > config_backup.yaml`. (Do **not** rely on `meshtastic --info` - that is only a human-readable status dump and cannot be re-imported.)
5. Flash new firmware via web flasher (flasher.meshtastic.org)
6. Verify settings after flash - firmware updates occasionally reset some settings to defaults
7. Confirm node reappears on the network before leaving the site

## Common hardware failures

<table id="bkmrk-symptomlikely-causef"><thead><tr><th>Symptom</th><th>Likely cause</th><th>Fix</th></tr></thead><tbody><tr><td>Node gone offline after storm</td><td>Water intrusion, lightning strike, blown fuse</td><td>Inspect enclosure, check fuse, examine for burn marks on PCB</td></tr><tr><td>Range suddenly reduced</td><td>Antenna connector loosened or corroded</td><td>Re-seat antenna, check connector for oxidation, replace if needed</td></tr><tr><td>Frequent reboots</td><td>Power supply instability (low battery/solar)</td><td>Check battery voltage, check charge controller output</td></tr><tr><td>Firmware crash loop</td><td>Corrupted flash or incompatible firmware</td><td>Factory reset and reflash</td></tr><tr><td>BLE not discoverable</td><td>BLE antenna loose (V3 only); software issue</td><td>For V3: reseat u.FL BLE antenna. Otherwise reflash.</td></tr></tbody></table>

## When to replace vs. repair

LoRa boards are inexpensive ($15 - 75). General guidance:

- Physical damage to SMA connector or RF front-end: replace board. Repair costs often exceed replacement.
- Software issue (firmware bugs, configuration corruption): reflash before considering hardware replacement.
- Battery degradation (LiFePO4): replace battery after 5+ years or when capacity drops below 70% of original.
- Solar panel degradation: typical panels lose 0.5% efficiency per year. Replace if output is more than 20% below original spec after 10+ years.