How to observe direct radio neighbors and build a cautious picture of mesh connectivity.
Neighbor Info allows a node to report the zero-hop neighbors it can hear and the SNR associated with those links. When reports from several nodes are combined, operators can draw a graph of observed direct relationships. This is useful for understanding topology, but it is not a routing table and it does not change how packets are forwarded.
What a neighbor means
A reported neighbor is a node recently heard directly by the reporting radio under its current settings and environment. The observation is directional: A hearing B does not automatically prove that B hears A. Transmit power, antenna gain, feed-line loss, noise and placement can differ. A graph should therefore represent directed observations unless both directions have been confirmed.
SNR is attached to the observed reception. It is not a permanent rating for the link. Weather, foliage, interference, moving objects and packet timing can change it. The official Neighbor Info guide states explicitly that the module is informative only and does not affect mesh routing.
Local reporting versus LoRa transmission
The module is optional and disabled by default. Current documentation gives a minimum update interval of four hours and a default of six hours. By default, Neighbor Info is provided to MQTT and a connected app. Firmware 2.5.13 and later can transmit it over LoRa when enabled, but that option is not available on a primary channel using the public default name and key.
This restriction is helpful: a public default mesh should not automatically receive topology lists from every participant. A coordinated community may enable over-LoRa reports on selected infrastructure nodes and a private primary channel, but it should first estimate packet size, interval and rebroadcast cost.
Building an honest topology graph
- Record the reporting node, observed neighbor, timestamp and SNR.
- Keep each direction separate.
- Expire old edges rather than displaying them forever.
- Distinguish direct observations from inferred connectivity.
- Mark mobile nodes and temporary test nodes.
- Do not expose exact private-site coordinates merely to draw an edge.
A useful map can show “recently observed,” “historically observed” and “confirmed both ways.” The absence of an edge does not prove there is no radio path: the nodes may not have transmitted during the observation window, Neighbor Info may be disabled, packets may have been lost or the collector may lack the relevant data.
Topology is not message routing
Meshtastic uses managed flooding. It does not consult a centrally assembled Neighbor Info graph before forwarding each normal message. A packet may reach a destination through different relays at different times, and duplicates can traverse several paths. Use the graph to find likely weak areas, plan tests and understand observation coverage—not to claim deterministic routes.
Traceroute complements Neighbor Info by asking a particular packet to record the hops on the first successful path. Even then, the result is a snapshot. See Meshtastic traceroute explained.
Useful public-network questions
- Which infrastructure sites have recently confirmed bidirectional direct links?
- Does a region depend on a single observed bridge?
- Which apparent links are old or based only on mobile nodes?
- Are observers concentrated in one city, making the rest of the graph incomplete?
- Did a firmware, antenna or site change alter the neighbor set?
Recommended deployment
Enable Neighbor Info first on a few maintained infrastructure nodes. Keep the six-hour default unless there is a demonstrated reason for another value. Prefer MQTT or local collection when available. If over-LoRa transmission is necessary, use a coordinated channel and document which nodes participate. Review channel utilization after enabling it.
For MeshAtlas, topology should be evidence with a timestamp, not decoration. A thin or missing edge should invite a range test, while a strong historical edge should not prevent operators from building redundancy. Combine neighbor observations with commissioning results, traceroutes, packet-loss tests and maintainer reports.