-R hash transport identity hash of remote instance to get status from
-i path path to identity used for remote management
-w seconds timeout before giving up on remote queries
-d, --discovered list discovered interfaces
-D show details and config entries for discovered interfaces
-m, --monitor continuously monitor status
-I, --monitor-interval seconds
refresh interval for monitor mode (default: 1)
-v, --verbose
```
#### NOTE
When using `-R` to query a remote transport instance, you must also specify `-i` with the path to a management identity file that is authorized for remote management on the target system.
### The rnid Utility
With the `rnid` utility, you can generate, manage and view Reticulum Identities.
The program can also calculate Destination hashes, and perform encryption and
decryption of files.
Using `rnid`, it is possible to asymmetrically encrypt files and information for
any Reticulum destination hash, and also to create and verify cryptographic signatures.
**Usage Examples**
Generate a new Identity:
```text
$ rnid -g ./new_identity
```
Display Identity key information:
```text
$ rnid -i ./new_identity -p
Loaded Identity <984b74a3f768bef236af4371e6f248cd> from new_id
Public Key : 0f4259fef4521ab75a3409e353fe9073eb10783b4912a6a9937c57bf44a62c1e
--config path path to alternative Reticulum config directory
-i, --identity identity
hexadecimal Reticulum identity or destination hash, or path to Identity file
-g, --generate file generate a new Identity
-m, --import identity_data
import Reticulum identity in hex, base32 or base64 format
-x, --export export identity to hex, base32 or base64 format
-v, --verbose increase verbosity
-q, --quiet decrease verbosity
-a, --announce aspects
announce a destination based on this Identity
-H, --hash aspects show destination hashes for other aspects for this Identity
-e, --encrypt file encrypt file
-d, --decrypt file decrypt file
-s, --sign path sign file
-V, --validate path validate signature
-r, --read file input file path
-w, --write file output file path
-f, --force write output even if it overwrites existing files
-R, --request request unknown Identities from the network
-t seconds identity request timeout before giving up
-p, --print-identity print identity info and exit
-P, --print-private allow displaying private keys
-b, --base64 Use base64-encoded input and output
-B, --base32 Use base32-encoded input and output
--version show program's version number and exit
```
### The rnpath Utility
With the `rnpath` utility, you can look up and view paths for
destinations on the Reticulum network.
**Usage Examples**
Resolve path to a destination:
```text
$ rnpath c89b4da064bf66d280f0e4d8abfd9806
Path found, destination <c89b4da064bf66d280f0e4d8abfd9806> is 4 hops away via <f53a1c4278e0726bb73fcc623d6ce763> on TCPInterface[Testnet/dublin.connect.reticulum.network:4965]
--config path path to alternative Reticulum config directory
-v, --verbose increase verbosity
-q, --quiet decrease verbosity
-S, --silent disable transfer progress output
-l, --listen listen for incoming transfer requests
-C, --no-compress disable automatic compression
-F, --allow-fetch allow authenticated clients to fetch files
-f, --fetch fetch file from remote listener instead of sending
-j, --jail path restrict fetch requests to specified path
-s, --save path save received files in specified path
-O, --overwrite Allow overwriting received files, instead of adding postfix
-b seconds announce interval, 0 to only announce at startup
-a allowed_hash allow this identity (or add in ~/.rncp/allowed_identities)
-n, --no-auth accept requests from anyone
-p, --print-identity print identity and destination info and exit
-i identity path to identity to use
-w seconds sender timeout before giving up
-P, --phy-rates display physical layer transfer rates
--version show program's version number and exit
```
### The rngit Utility
The `rngit` utility provides full Git repository hosting and interaction over Reticulum, as well as many other useful features for software development, collaboration and publishing. It allows you to host Git repositories on Reticulum nodes, interact with remote repositories using standard Git commands through the `rns://` URL scheme, and to publish software releases.
The system consists of two parts: The `rngit` node that hosts and manages repositories, and the `git-remote-rns` helper that enables Git to communicate with rngit nodes. As soon as you have RNS installed on your system, you can transparently use Git with Reticulum-hosted repositories just like any other type of remote. Git over Reticulum uses URLs in the following format: `rns://DESTINATION_HASH/group/repo`.
If you set a branch to track a Reticulum remote as the default upstream, you can simply use `git` as you normally would; all commands work transparently and as expected.
#### WARNING
**The rngit program is a new addition to RNS!** This functionality was introduced in RNS 1.2.0. While great care has been taken to design a secure, but highly configurable and flexible permission system for allowing many users to interact with many different repositories on a single node, `rngit` has not been tested extensively in the wild! Be careful when hosting repositories, especially if they are public or semi-public.
For the full documentation on the rngit system, see the [Git Over Reticulum](git.md#git-main) chapter of this manual.
### The rnx Utility
The `rnx` utility is a basic remote command execution program. It allows you to
execute commands on remote systems over Reticulum, and to view returned command
output. For a fully interactive remote shell solution, be sure to also take a look
at the [rnsh](https://github.com/acehoss/rnsh) program.
**Usage Examples**
Run rnx on the listening system, specifying which identities are allowed to execute commands:
```text
$ rnx --listen -a 941bed5e228775e5a8079fc38b1ccf3f -a 1b03013c25f1c2ca068a4f080b844a10
Set specific baud rate when flashing device. Default is 921600
-N, --normal Switch device to normal mode
-T, --tnc Switch device to TNC mode
-b, --bluetooth-on Turn device bluetooth on
-B, --bluetooth-off Turn device bluetooth off
-p, --bluetooth-pair Put device into bluetooth pairing mode
-D, --display i Set display intensity (0-255)
-t, --timeout s Set display timeout in seconds, 0 to disable
-R, --rotation rotation
Set display rotation, valid values are 0 through 3
--display-addr byte Set display address as hex byte (00 - FF)
--recondition-display
Start display reconditioning
--np i Set NeoPixel intensity (0-255)
--freq Hz Frequency in Hz for TNC mode
--bw Hz Bandwidth in Hz for TNC mode
--txp dBm TX power in dBm for TNC mode
--sf factor Spreading factor for TNC mode (7 - 12)
--cr rate Coding rate for TNC mode (5 - 8)
-x, --ia-enable Enable interference avoidance
-X, --ia-disable Disable interference avoidance
-c, --config Print device configuration
--eeprom-backup Backup EEPROM to file
--eeprom-dump Dump EEPROM to console
--eeprom-wipe Unlock and wipe EEPROM
-P, --public Display public part of signing key
--trust-key hexbytes Public key to trust for device verification
--version Print program version and exit
-f, --flash Flash firmware and bootstrap EEPROM
-r, --rom Bootstrap EEPROM without flashing firmware
-k, --key Generate a new signing key and exit
-S, --sign Display public part of signing key
-H, --firmware-hash FIRMWARE_HASH
Set installed firmware hash
--platform platform Platform specification for device bootstrap
--product product Product specification for device bootstrap
--model model Model code for device bootstrap
--hwrev revision Hardware revision for device bootstrap
```
For more information on how to create your own RNodes, please read the [Creating RNodes](hardware.md#rnode-creating)
section of this manual.
## Discovering Interfaces
Reticulum includes built-in functionality for discovering connectable interfaces over Reticulum itself. This is particularly useful in situations where you want to do one or more of the following:
* Discover connectable entrypoints available on the Internet
* Find connectable radio access points in the physical world
* Maintain connectivity to RNS instances with unknown or changing IP addresses
Discovered interfaces can be **auto-connected** by Reticulum, which makes it possible to create setups where an arbitrary interface can act simply as a bootstrap connection, that can be torn down again once more suitable interfaces have been discovered and connected.
The interface discovery mechanism uses announces sent over Reticulum itself, and supports both publicly readable interfaces and private, encrypted discovery, that can only be decoded by specified *network identities*. It is also possible to specify which network identities should be considered valid sources for discovered interfaces, so that interfaces published by unknown entities are ignored.
#### NOTE
A *network identity* is a normal Reticulum identity keyset that can be used by
one or more transport nodes to identify them as belonging to the same overall
network. In the context of interface discovery, this makes it easy to manage
connecting to only the particular networks you care about, even if those networks
utilize many individual physical transport node.
This also makes it convenient to auto-connect discovered interfaces only for networks you have some level of trust in.
For information on how to make your interfaces discoverable, see the [Discoverable Interfaces](interfaces.md#interfaces-discoverable) chapter of this manual. The current section will focus on how to actually *discover and connect to* interfaces available on the network.
In its most basic form, enabling interface discovery is as simple as setting `discover_interfaces` to `true` in your Reticulum config:
```text
[reticulum]
...
discover_interfaces = yes
...
```
Once this option is enabled, your RNS instance will start listening for interface discovery announces, and store them for later use or inspection. You can list discovered interfaces with the `rnstatus` utility:
Sideband Hub Backbone ✓ Available 1h ago 16 46.2316, 6.0536
RNS Amsterdam Backbone ✓ Available 32m ago 16 52.3865, 4.9037
```
You can view more detailed information about discovered interfaces, including configuration snippets for pasting directly into your `[interfaces]` config, by using the `rnstatus -D` option:
In addition to providing local interface discovery information and control, the `rnstatus` utility can export discovered interface data in machine-readable JSON format using the `rnstatus -d --json` option. This can be useful for exporting the data to external applications such as status pages, access point maps and similar.
To control what sources are considered valid for discovered sources, additional
configuration options can be specified for the interface discovery system.
* The `interface_discovery_sources` option is a list of the network or transport identities from which interfaces will be accepted. If this option is set, all others will be ignored. If this option is not set, discovered interfaces will be accepted from any source, but are still subject to stamp value requirements.
* The `required_discovery_value` options specifies the minimum stamp value required for the interface announce to be considered valid. To make it computationally difficult to spam the network with a large number of defunct or malicious interfaces, each announced interface requires a valid cryptographical stamp, of configurable difficulty value.
* The `autoconnect_discovered_interfaces` value defaults to `0`, and specifies the maximum number of discovered interfaces that should be auto-connected at any given time. If set to a number greater than `0`, Reticulum automatically manages discovered interface connections, and will bring discovered interfaces up and down based on availability. You can at any time add discovered interfaces to your configuration manually, to persistently keep them available.
* The `network_identity` option specifies the *network identity* for this RNS instance. This identity is used both to sign (and potentially encrypt) *outgoing* interface discovery announces, and to decrypt incoming discovery information.
The configuration snippet below contains an example of setting these additional configuration options:
For more fine-grained control over how discovered interfaces are auto-connected, additional options are provided for configuraiton. These are not necessary to set in most cases, but can be useful in certain situations.
* The `autoconnect_announces_to_internal` option allows you to specify that auto-connected interfaces should propagate announces to `internal` mode interfaces, even if the auto-connected interface’s mode would normally not allow for this.
For a complete example configuration, you can run `rnsd --exampleconfig`.
## Blackhole Management
Reticulum networks are fundamentally permissionless and open, allowing anyone with a compatible interface to participate. While this openness is essential for a resilient and decentralized network, it also exposes the network to potential abuse, such as peers flooding the network with excessive announce broadcasts or other forms of resource exhaustion.
The **Blackhole** system provides tools to help manage this problem. It allows operators and individual users to block specific identities at the Transport layer, preventing them from propagating announces through your node, and for other nodes to reach them through your network.
#### IMPORTANT
There is fundamentally **no way** to *globally* block or censor any identity or destination in Reticulum networks. The blackhole functionality will prevent announces from (and traffic to) all destinations associated with the blackholed identity *on your own network segments only*.
This provides users and operators with control over what they want to allow *on their own network segments*, but there is no way to globally censor or remove an identity, as long as *someone* is willing to provide transport for it.
This functionality serves a dual purpose:
* **For Individual Users:** It offers a simple way to maintain a quiet and efficient local network by manually blocking spammy or unwanted peers.
* **For Network Operators:** It enables the creation of federated, community-wide security standards. By publishing and sharing blackhole lists, operators can protect large infrastructures and distribute spam filtering rules across the mesh without manual intervention.
### Local Blackhole Management
The most immediate way to manage unwanted identities is through manual configuration using the `rnpath` utility. This allows you to instantly block or unblock specific identities on your local Transport Instance.
**Blackholing an Identity**
To block an identity, use the `-B` (or `--blackhole`) flag followed by the identity hash. You can optionally specify a duration and a reason, which are useful for logging and future reference.
```text
$ rnpath -B 3a4f8b9c1d2e3f4g5h6i7j8k9l0m1n2o
```
You can also add a duration (in hours) and a reason:
Manually blocking identities is effective for immediate threats and annoyances, but maintaining an up-to-date blocklist across many nodes on a large network is impractical. Reticulum supports **automated list sourcing**, allowing your node to subscribe to blackhole lists maintained by trusted peers, or a central authority you manage yourself.
**Verify Before Subscribing!** Subscribing to a blackhole source is a powerful action that grants that source the ability to dictate who you can communicate with. Before adding a source to your configuration, verify that the maintainer aligns with your usage policy and values. Blindly subscribing to untrusted lists could inadvertently block legitimate peers or essential services.
When enabled, your Transport Instance will periodically (approximately once per hour) connect to configured sources, retrieve their latest blackhole lists, and automatically merge them into your local blocklist. This provides “set-and-forget” protection for both individual users and large networks.
**Configuration**
To enable automated sourcing, add the `blackhole_sources` option to the `[reticulum]` section of your configuration file. This option accepts a comma-separated list of Transport Identity hashes that you trust to provide valid blackhole lists.
```ini
[reticulum]
...
# Automatically fetch blackhole lists from these trusted sources
1. When enabled, the `BlackholeUpdater` service runs in the background.
2. For every identity hash listed in `blackhole_sources`, it attempts to establish a temporary link to its associated\`\`rnstransport.info.blackhole\`\` destination.
3. It requests the `/list` path, which returns a dictionary of blackholed identities and their associated metadata.
4. The received list is merged with your local `blackholed_identities` database.
5. The lists are persisted to disk, ensuring they survive restarts.
#### NOTE
You can verify the external lists you are subscribed to, and their contents, without importing them by using `rnpath -p`. See the [rnpath utility documentation](#utility-rnpath) for details on querying remote blackhole lists.
### Publishing Blackhole Lists
If you are operating a public gateway, a community hub, or simply wish to share your blackhole list with others, you can configure your instance to act as a blackhole list publisher. This allows other nodes to subscribe to *your* definitions of unwanted traffic.
**Enabling Publishing**
To publish your local blackhole list, enable the `publish_blackhole` option in the `[reticulum]` section:
```ini
[reticulum]
...
publish_blackhole = yes
...
```
When this is enabled, your Transport Instance will register a request handler at `rnstransport.info.blackhole`. Any peer that connects to this destination and requests `/list` will receive the complete set of identities currently present in your local blackhole database.
**Federation and Trust**
The blackhole system relies on the trust relationship between the subscriber and the publisher. By subscribing to a source, you are implicitly trusting that source to only block identities that are genuinely detrimental to the network.
As the ecosystem matures, this system is designed to integrate with **Network Identities**. This allows communities to verify that a published blackhole list is actually provided by a specific network or organization with a certain level of reputation and trustworthiness, adding a layer of cryptographic trust to the federation process. This prevents malicious actors from publishing fake lists intended to censor legitimate traffic.
For operators, this creates a scalable model where maintaining a single high-quality blocklist can protect thousands of downstream peers, drastically reducing the administrative.
## Improving System Configuration
If you are setting up a system for permanent use with Reticulum, there is a
few system configuration changes that can make this easier to administrate.
These changes will be detailed here.
### Fixed Serial Port Names
On a Reticulum instance with several serial port based interfaces, it can be
beneficial to use the fixed device names for the serial ports, instead
of the dynamically allocated shorthands such as `/dev/ttyUSB0`. Under most
Debian-based distributions, including Ubuntu and Raspberry Pi OS, these nodes
can be found under `/dev/serial/by-id`.
You can use such a device path directly in place of the numbered shorthands.
Here is an example of a packet radio TNC configured as such:
```text
[[Packet Radio KISS Interface]]
type = KISSInterface
interface_enabled = True
outgoing = true
port = /dev/serial/by-id/usb-FTDI_FT230X_Basic_UART_43891CKM-if00-port0
speed = 115200
databits = 8
parity = none
stopbits = 1
preamble = 150
txtail = 10
persistence = 200
slottime = 20
```
Using this methodology avoids potential naming mix-ups where physical devices
might be plugged and unplugged in different orders, or when device name
assignment varies from one boot to another.
### Reticulum as a System Service
Instead of starting Reticulum manually, you can install `rnsd` as a system
service and have it start automatically at boot.
#### Systemwide Service
If you installed Reticulum with `pip`, the `rnsd` program will most likely
be located in a user-local installation path only, which means `systemd` will not
be able to execute it. In this case, you can simply symlink the `rnsd` program
into a directory that is in systemd’s path:
```text
sudo ln -s $(which rnsd) /usr/local/bin/
```
You can then create the service file `/etc/systemd/system/rnsd.service` with the
following content:
```text
[Unit]
Description=Reticulum Network Stack Daemon
After=multi-user.target
[Service]
# If you run Reticulum on WiFi devices,
# or other devices that need some extra
# time to initialise, you might want to
# add a short delay before Reticulum is
# started by systemd:
# ExecStartPre=/bin/sleep 10
Type=simple
Restart=always
RestartSec=3
User=USERNAMEHERE
ExecStart=rnsd --service
[Install]
WantedBy=multi-user.target
```
Be sure to replace `USERNAMEHERE` with the user you want to run `rnsd` as.
To manually start `rnsd` run:
```text
sudo systemctl start rnsd
```
If you want to automatically start `rnsd` at boot, run:
```text
sudo systemctl enable rnsd
```
#### Userspace Service
Alternatively you can use a user systemd service instead of a system wide one. This way the whole setup can be done as a regular user.
Create a user systemd service files `~/.config/systemd/user/rnsd.service` with the following content:
```text
[Unit]
Description=Reticulum Network Stack Daemon
After=default.target
[Service]
# If you run Reticulum on WiFi devices,
# or other devices that need some extra
# time to initialise, you might want to
# add a short delay before Reticulum is
# started by systemd:
# ExecStartPre=/bin/sleep 10
Type=simple
Restart=always
RestartSec=3
ExecStart=RNS_BIN_DIR/rnsd --service
[Install]
WantedBy=default.target
```
Replace `RNS_BIN_DIR` with the path to your Reticulum binary directory (eg. /home/USERNAMEHERE/rns/bin).
Start user service:
```text
systemctl --user daemon-reload
systemctl --user start rnsd.service
```
If you want to automatically start `rnsd` without having to log in as the USERNAMEHERE, do:
