rnstatus

Tells you: Every interface: Up or Down, and traffic in and out. Run this first.

rnpath -t <address>

Tells you: Whether your node knows a path to an address, how many hops, and via which interface. Add -t to ask the network if it does not.

rnprobe <address>

Tells you: Sends a probe and reports the round-trip time, proving the destination is actually there and answering.

If you installed Reticulum in a virtual environment, use the full path, for example ~/reticulum/bin/rnstatus. In MeshChatX the same information is on the Interfaces page and in its log.

• Status: Up means the connection is open. It does not by itself mean the far end is a working transport node; traffic climbing does.

• Traffic should rise within a minute or two of connecting, because announces arrive. Up with no traffic for five minutes is a fault.

• An interface missing entirely from the list was not loaded: usually indentation in the config file.

The TCP interface

Then: No route out, or a typo in the hostname or port. ping rns.scotmesh.net; check the status strip to see whether the node itself is down.

The I2P interface, in the first ten minutes

Then: Normal. Tunnels are still being built.

The I2P interface, for longer

Then: Is i2pd running, and is SAM enabled on port 7656? If i2pd keeps restarting, see Known bugs and workarounds.

An RNode

Then: Wrong port, or the board is not in the right mode. rnodeconf -i /dev/ttyUSB0 should answer; if not, check the cable and that nothing else has the port open.

The config file did not load that block. Check that it sits under [interfaces], that [[Name]] is indented two spaces and its settings four, and that enabled = yes is present. rnsd -v prints config errors on start.

You cannot reach what has not announced. Wait a couple of minutes after connecting, then rnpath -t <address> to ask for it. If a path never appears, either the address is wrong, the destination is offline, or nothing between you and it is a transport node.

The far end is not answering the link request. If it is our node, and other hubs work from the same client, you may have been locked out by the fast-flapping block; Known bugs and workarounds explains. Otherwise the destination has gone away since it announced; wait for the next announce.

• The recipient is offline and neither of you has a propagation node set. Set ours.

• You have one set but have not synced: ask your client to fetch from the propagation node.

• The recipient has never announced to you. Ask them to announce (every client has a button), or paste their address.

You are announcing too rarely. Nodes announce every six hours by default; set 30 to 60 minutes (how). Node maps such as rmap.world also need the node to be reachable from their side.

Frequency, bandwidth, spreading factor and coding rate must match exactly. A mismatch gives no error; the radios are simply deaf to each other. Compare against the ScotMesh profiles. Then check the antenna is for the right band and actually connected: transmitting into no antenna at 22 dBm can damage the radio.

Restart rnsd (or the app). Reticulum keeps paths and links in memory, and after a long run with interfaces coming and going a restart clears stale state. Then check the status strip: the node itself may have restarted.

rnsd -vv in a terminal shows what the daemon is doing in real time: interfaces coming up, announces received, paths learned, link requests. Most puzzles are solved by watching it for a minute while you try the thing that fails. As a service, journalctl -u rnsd -f shows the same.

Ask in the chat room if you can reach it, or on the ScotMesh Discord (discord.gg/ytxfyuDmSt) if you cannot. Include the output of rnstatus and what you expected to happen.