Set up a Reticulum Transport Node on a Raspberry Pi to relay traffic, propagate announces, and bridge LoRa radio to your local network. Be the backbone for your community mesh.

Run a Transport Node (Be a Relay for Your Community)

This is Part 8 of a 12-part series on building private, resilient communication networks with Reticulum, LoRa, and associated tools.

So far, every device in this series has been an endpoint — sending and receiving its own messages. A Transport Node is different. It's a relay: it forwards traffic for other nodes, propagates announces across the network, maintains path tables, and serves as a distributed cryptographic keystore. It's the backbone that makes multi-hop communication possible.

Without transport nodes, two Reticulum devices can only communicate if they're directly in radio or network range of each other. With transport nodes, messages can hop across multiple relays to reach destinations far beyond any single radio's range.

When to Run a Transport Node

Not every node should be a transport node. The official guidance is clear: a network should have enough transport nodes to provide coverage, and not many more.

Good candidates for transport nodes: - Stationary devices (not mobile) - Always-on (or nearly always-on) - Well-connected (multiple interfaces, good antenna placement) - Sufficient resources (a Raspberry Pi is more than enough)

Bad candidates: - Phones and laptops that sleep or move around - Devices on intermittent connections - Every node on the network (this degrades performance)

The Setup

We'll configure a Raspberry Pi (or any always-on Linux box) as a transport node with two interfaces: 1. AutoInterface — serves local WiFi/Ethernet clients 2. RNode LoRa Interface — provides radio coverage for the area

This creates a node that bridges local network users to the LoRa mesh and relays traffic between them.

Step 1: Install Reticulum

On a Raspberry Pi (64-bit OS recommended):

sudo apt install python3 python3-pip python3-cryptography python3-pyserial
pip install rns --break-system-packages

Step 2: Configure as Transport Node

Edit ~/.reticulum/config:

[reticulum]
  enable_transport = yes
  share_instance = yes
  respond_to_probes = yes

[logging]
  loglevel = 4

[interfaces]
  # Local network — serves devices on your WiFi/Ethernet
  [[Default Interface]]
    type = AutoInterface
    enabled = yes

  # LoRa radio — provides wide-area coverage
  [[RNode LoRa Interface]]
    type = RNodeInterface
    enabled = yes
    port = /dev/ttyUSB0
    frequency = 867200000
    bandwidth = 125000
    txpower = 7
    spreadingfactor = 8
    codingrate = 5

    # Set as access point so it stays quiet
    # until clients actually connect
    mode = access_point

    # Airtime limits for regulatory compliance
    airtime_limit_long = 1.5
    airtime_limit_short = 33

The key settings:

enable_transport = yes — this is what makes it a transport node. It will now forward packets, propagate announces, and serve path requests for other nodes.
respond_to_probes = yes — allows other nodes to ping this transport node using rnprobe for connectivity testing.
mode = access_point — the LoRa interface stays quiet (no announce rebroadcasting) until clients are actively using it. This conserves precious airtime.

Step 3: Use Fixed Serial Port Names

If you have multiple serial devices, use the fixed device path instead of /dev/ttyUSB0 (which can change between reboots):

ls /dev/serial/by-id/

You'll see something like:

usb-Silicon_Labs_CP2102_USB_to_UART_Bridge-if00-port0

Use the full path in your config:

port = /dev/serial/by-id/usb-Silicon_Labs_CP2102_USB_to_UART_Bridge-if00-port0

Step 4: Run as a System Service

Create /etc/systemd/system/rnsd.service:

[Unit]
Description=Reticulum Network Stack Daemon
After=multi-user.target

[Service]
Type=simple
Restart=always
RestartSec=3
User=pi
ExecStart=rnsd --service

[Install]
WantedBy=multi-user.target

If rnsd isn't in systemd's PATH:

sudo ln -s $(which rnsd) /usr/local/bin/

Enable and start:

sudo systemctl enable --now rnsd

Step 5: Verify

Check that everything is running:

rnstatus

You should see both interfaces Up, and a line at the bottom:

Reticulum Transport Instance <5245a8efe1788c6a1cd36144a270e13b> running

That hash is your transport node's identity. Other nodes will reference it when routing traffic through you.

Test probe response:

rnprobe rnstransport.probe <your_transport_hash>

What a Transport Node Does

Once running, your transport node automatically:

Receives announces from nodes on all interfaces and caches their public keys and paths
Rebroadcasts announces to other interfaces (respecting bandwidth limits and announce caps)
Forwards packets between interfaces — a message from a LoRa client can be relayed to a WiFi client, or vice versa
Serves path requests — when a node asks "how do I reach destination X?", your transport node answers if it knows the path
Maintains a path table — a distributed routing table built from announce traffic
Stores public keys — acts as a distributed keystore so nodes can look up encryption keys for destinations they want to reach

All of this happens automatically. There's nothing to configure beyond enabling transport.

Adding a TCP Interface for Internet Connectivity

To connect your transport node to the wider Reticulum network over the internet, add a TCP interface:

  [[RNS Testnet Dublin]]
    type = TCPClientInterface
    enabled = yes
    target_host = dublin.connect.reticulum.network
    target_port = 4965

Now your transport node bridges three networks: local WiFi, LoRa radio, and the internet testnet. A phone connected via LoRa can reach destinations on the other side of the world through your node.

Interface Modes for Transport Nodes

The mode setting on each interface controls how the transport node behaves:

Mode	Use Case
`full`	Default. All transport features active. Good for most interfaces.
`gateway`	Like full, but also resolves unknown paths on behalf of clients. Use on the interface facing your clients.
`access_point`	Stays quiet until clients connect. Good for LoRa interfaces serving a wide area.
`boundary`	For interfaces connecting to significantly different network segments (e.g., a LoRa node's internet uplink).

A typical transport node config:

  # LoRa interface facing clients
  [[RNode LoRa Interface]]
    mode = access_point
    # ... LoRa settings ...

  # Internet uplink
  [[RNS Testnet Dublin]]
    mode = boundary
    # ... TCP settings ...

  # Local WiFi
  [[Default Interface]]
    mode = gateway
    # ... AutoInterface settings ...

Monitoring Your Transport Node

Useful commands for ongoing monitoring:

# Live interface monitoring
rnstatus -m

# View the path table
rnpath -t

# View announce statistics
rnstatus -A

# Check traffic totals
rnstatus -t

Remote Management

You can manage your transport node remotely from another Reticulum device:

Generate a management identity: bash rnid -g ~/.reticulum/management_identity
Get its hash: bash rnid -i ~/.reticulum/management_identity -p
Add it to the transport node's config: ini [reticulum] enable_remote_management = yes remote_management_allowed = <hash_from_step_2>
From your remote device, query the transport node: bash rnstatus -R <transport_node_hash> -i ~/.reticulum/management_identity

What's Next

Your transport node is relaying traffic for your local community. In the next guide, we'll take this further — bridging an isolated LoRa network to the internet so off-grid users can reach the wider Reticulum network.

Previous: [Part 7 — Build a Handheld RNode] Next: [Part 9 — Bridge Your LoRa Island to the Internet]