Build a Multi-Interface
Reticulum Node Box

Why Multi-Interface

Your first RNode proved the concept. You got packets on the air, cryptographic identities working, and maybe a kilometer or two of real range. That single LoRa link is genuinely useful — but it's an island.

A multi-interface node changes what the device is. Instead of a radio that Reticulum happens to use, you're building a network junction — a point where LoRa radio, local WiFi, internet TCP, and optionally anonymous I2P tunnels all converge. Reticulum treats every interface as an equal peer and routes packets across all of them automatically. No special configuration. No routing tables to manage. You add interfaces; Reticulum figures out paths.

Practically, here's what this unlocks:

How Reticulum
Routes Between Interfaces

Reticulum's routing model is fundamentally different from IP routing. There are no routing tables you configure. Instead, every node maintains a path table — a live map of which interface a given destination hash was last heard from. When a packet needs to go somewhere, it goes out the interface where that destination was most recently announced.

This means adding an interface is genuinely as simple as adding it to your config. Reticulum will immediately start learning destinations from it and routing packets through it as paths are discovered.

When a packet arrives on, say, the 915 MHz LoRa interface destined for a hash that was last seen via TCP/IP, Reticulum will re-transmit it on TCP. The interfaces are completely transparent to each other. The node running rnsd with enable_transport = True is the relay engine that makes this work.

Path Discovery

Destinations announce themselves periodically with a signed announce packet. When your node hears an announce on the 433 MHz interface, it records that destination hash → 433 MHz in its path table. Later, if another node on the 915 MHz side sends a packet to that destination, your node knows where to send it.

Paths time out if a destination goes silent. The network continuously re-discovers routes as announces propagate. There is no central authority and no static configuration needed.

Interface
Reference

Each interface type has a different role in the network stack. Most deployments use LoRa + TCP as their foundation, with WiFi and I2P added as needed. You do not have to run all of them — pick the combination that fits your situation.

Hardware Bill
of Materials

The multi-interface node requires a proper host computer — not just a microcontroller. A Raspberry Pi 5 is the current recommended choice: fast enough for AES-256 crypto at wire speed, has USB 3.0 ports for multiple RNodes, built-in WiFi, an optional PCIe NVMe slot for SSD storage, and good thermal headroom for enclosed deployments. The Pi 4B remains a solid and cheaper alternative but should be considered the floor, not the target.

Core Hardware

Antennas

Optional but Useful

Assembly

This assumes both T-Beam boards are already flashed as RNodes per Vol. 1. If not, flash them first before proceeding — it's easier to do on a laptop than to debug firmware on a Pi.

• 1
  Flash both RNodes (if not already done)

  On a laptop with rnodeconf installed, flash each board individually. Verify each board with rnodeconf /dev/ttyUSB0 -i before moving to the Pi. Label them — a piece of tape marked 915 and 433 avoids a lot of confusion later.
• 2
  Prepare the Raspberry Pi

  Flash Raspberry Pi OS Lite (64-bit) to the microSD using Raspberry Pi Imager. In Imager, pre-configure SSH, your hostname, and WiFi credentials so the Pi is accessible headlessly. Boot it, find its IP, and SSH in.
• 3
  Install Reticulum on the Pi

  Use a virtual environment — global pip installs with --break-system-packages are no longer best practice on modern Debian/Ubuntu-based systems and can conflict with OS packages.

  $ sudo apt update && sudo apt install -y python3-pip python3-venv
  
  # Create a dedicated venv for Reticulum
  $ python3 -m venv ~/.venv/reticulum
  $ source ~/.venv/reticulum/bin/activate
  
  # Install Reticulum and optional extras
  (reticulum) $ pip install rns
  (reticulum) $ pip install nomadnet lxmf  # optional
  
  # Verify — should show 1.1.x
  (reticulum) $ rnsd --version
  Reticulum 1.1.4 ready.BASH

  To use the venv tools in your systemd service (see Step 8), point ExecStart at the venv binary path: /home/pi/.venv/reticulum/bin/rnsd. No need to activate the venv in service files.
• 4
  Add user to dialout group

  $ sudo usermod -aG dialout $USER
  $ sudo rebootBASH

  Without this, rnsd cannot access serial ports for the RNodes.
• 5
  Plug in the powered hub, then both RNodes

  Connect the powered hub to the Pi via USB. Then connect both T-Beams to the hub. Identify which port each board landed on:

  $ ls /dev/ttyUSB*
  /dev/ttyUSB0  /dev/ttyUSB1
  
  # Confirm which board is which:
  $ rnodeconf /dev/ttyUSB0 -i
  $ rnodeconf /dev/ttyUSB1 -iBASH

  Note which /dev/ttyUSB path corresponds to which frequency board.
• 6
  Make serial port assignments persistent

  USB ports can change numbering on reboot. Create udev rules to pin each board to a stable name:

  # Get serial numbers for both boards
  $ udevadm info -a -n /dev/ttyUSB0 | grep ATTRS{serial}
  # Note the value, e.g.: "0001" or "0002"
  
  # Create udev rules file
  $ sudo nano /etc/udev/rules.d/99-rnodes.rulesBASH

  # /etc/udev/rules.d/99-rnodes.rules
  SUBSYSTEM=="tty", ATTRS{serial}=="YOUR_915_SERIAL", SYMLINK+="rnode_915"
  SUBSYSTEM=="tty", ATTRS{serial}=="YOUR_433_SERIAL", SYMLINK+="rnode_433"UDEV

  $ sudo udevadm control --reload-rules && sudo udevadm trigger
  # Now /dev/rnode_915 and /dev/rnode_433 are stable symlinksBASH

• 7
  Write the config and start rnsd

  See Section 06 for the full config file. Once written, start rnsd manually first to verify all interfaces come up before enabling the service.
• 8
  Enable rnsd as a systemd service

  # Create service file
  $ sudo nano /etc/systemd/system/rnsd.serviceBASH

  [Unit]
  Description=Reticulum Network Stack Daemon
  After=network-online.target
  Wants=network-online.target
  
  [Service]
  Type=simple
  User=pi
  # Point at the venv binary, not the system Python install
  ExecStart=/home/pi/.venv/reticulum/bin/rnsd
  Restart=on-failure
  RestartSec=5
  
  # Systemd hardening — see Section 12 for full options
  NoNewPrivileges=yes
  ProtectSystem=strict
  ProtectHome=read-only
  ReadWritePaths=/home/pi/.reticulum
  
  [Install]
  WantedBy=multi-user.targetSYSTEMD

  $ sudo systemctl daemon-reload
  $ sudo systemctl enable rnsd
  $ sudo systemctl start rnsd
  $ sudo systemctl status rnsdBASH

Full Config
File

This is the complete ~/.reticulum/config for a node with all five interface types. Edit the sections marked in comments to match your setup. You do not need all interfaces — comment out or remove any blocks you don't want.

# ~/.reticulum/config
# Multi-Interface Node — Node Star Field Guide Vol. 2
# ──────────────────────────────────────────────────

[reticulum]
  enable_transport        = True      # REQUIRED for multi-interface relay
  share_instance          = True
  shared_instance_port    = 37428
  instance_control_port   = 37429
  panic_on_interface_error = No       # Stay up if one interface fails

[interfaces]

  # ──────────────────────────────────────────────
  # INTERFACE 1: LoRa 915 MHz — Primary Radio
  # ──────────────────────────────────────────────
  [[LoRa 915 MHz]]
    type            = RNodeInterface
    enabled         = yes
    port            = /dev/rnode_915   # or /dev/ttyUSB0
    frequency       = 915000000        # 915.0 MHz — US/AU/NZ (ISM band)
    bandwidth       = 125000
    txpower         = 17               # 17 dBm — legal on 915 MHz ISM (US Part 15, max 30 dBm EIRP)
    spreadingfactor = 8                # SF8: good balance
    codingrate      = 5
    id_interval     = 1800             # Announce every 30 min — good for infra nodes
    id_callsign     = YOURCALL         # Optional: FCC callsign

  # ──────────────────────────────────────────────
  # INTERFACE 2: LoRa 433 MHz — Secondary Radio
  # Remove this block if not using a 433 board
  # ──────────────────────────────────────────────
  # ⚠ POWER LIMIT: In the US, 433 MHz (Part 15) is limited to 1 mW ERP (0 dBm).
  # 433 MHz is NOT an ISM band in the US — unlicensed use is strictly limited.
  # 17 dBm on 433 MHz requires an amateur radio license (Technician or higher).
  # EU/UK: 433 MHz is an ISM band — 10 mW ERP (10 dBm) allowed unlicensed.
  [[LoRa 433 MHz]]
    type            = RNodeInterface
    enabled         = yes
    port            = /dev/rnode_433   # or /dev/ttyUSB1
    frequency       = 433000000        # 433.0 MHz
    bandwidth       = 125000
    txpower         = 10               # 10 dBm — legal in EU/UK; reduce to 0 for US unlicensed
    spreadingfactor = 8
    codingrate      = 5
    id_interval     = 1800             # See airtime note below

  # ──────────────────────────────────────────────
  # INTERFACE 3: AutoInterface — LAN / WiFi
  # Peers automatically with other Reticulum nodes
  # on the same network segment via multicast
  # ──────────────────────────────────────────────
  [[LAN AutoInterface]]
    type        = AutoInterface
    enabled     = yes
    group_id    = Node StarLAN    # Arbitrary group name — nodes must match

  # ──────────────────────────────────────────────
  # INTERFACE 4: TCP Client — Internet Backbone
  # Connects outbound to a Reticulum hub on the internet.
  # PREFERRED: your own VPS (cheapest tier is fine) or a
  # regional community hub. reticulum.network:4242 is the
  # historic public entry point but has seen load and abuse
  # issues — don't point new infrastructure at it by default.
  # ──────────────────────────────────────────────
  [[Reticulum TCP Hub]]
    type            = TCPClientInterface
    enabled         = yes
    target_host     = your-vps-or-community-hub.example  # Replace — see note above
    target_port     = 4242
    kiss_framing    = False
    outgoing        = True   # Allow sending packets out this interface
    incoming        = True   # Accept incoming packets; set False to reduce abuse surface

  # ──────────────────────────────────────────────
  # INTERFACE 5: I2P — Anonymous Overlay
  # Requires i2pd running locally first:
  #   sudo apt install i2pd && sudo systemctl start i2pd
  # Then restart rnsd — it will auto-configure I2P
  # ──────────────────────────────────────────────
  [[I2P Anonymous Interface]]
    type    = I2PInterface
    enabled = yes
    peers   = # Leave blank — auto-discovers I2P Reticulum peersCONFIG

Verifying the Config

After writing the config, start rnsd in verbose mode and watch for each interface initializing:

$ rnsd -v

[rnsd] Loaded config from ~/.reticulum/config
[rnsd] RNodeInterface LoRa 915 MHz ready   [/dev/rnode_915]
[rnsd] RNodeInterface LoRa 433 MHz ready   [/dev/rnode_433]
[rnsd] AutoInterface  LAN AutoInterface    [multicast group Node StarLAN]
[rnsd] TCPClientInterface Reticulum TCP Hub [reticulum.network:4242]
[rnsd] I2PInterface   I2P Anonymous Interface [i2p:...]

# Check live interface status anytime:
$ rnstatusBASH

Transport Mode

Transport mode is what makes the node useful as infrastructure. Without it, your Pi receives packets on all interfaces but doesn't relay them — it's just a passive listener. With it, your node becomes an active router: it reads the path table, determines the best outbound interface, and re-transmits packets toward their destination.

What Transport Nodes Do

When a packet arrives from a node on the 915 MHz interface destined for a hash known to be reachable via TCP, the transport node:

• Receives the packet on the 915 MHz interface
• Checks its path table for the destination hash
• Finds that the destination was last announced via the TCP interface
• Retransmits the packet on the TCP interface toward the next hop
• Updates the path table if a better route is discovered in either direction

This happens for every interface pair automatically. A packet can traverse LoRa → TCP → I2P without any manual configuration on any of the nodes involved.

Only Run Transport on Stationary Nodes

Transport nodes are infrastructure. Running transport on a mobile device (a phone, a handheld node) can cause routing instability as the device moves in and out of range while holding path table entries. Keep enable_transport = False on mobile or intermittently-connected nodes.

Antenna Selection
& Placement

The antenna is the most impactful hardware variable in your node's reach. A $12 5 dBi omni mounted at rooftop height will dramatically outperform the stubby stock antenna from inside a building. The radio physics are unforgiving: every obstruction between you and another node costs real dB.

Placement Principles

• Height beats gain. 10 meters of height gives more range than 3 dB of antenna gain. Mount as high as safely possible.
• Keep the antenna outside the enclosure. Use SMA pigtail extensions to route coax out to a weatherproof bulkhead connector. Metal enclosures especially will attenuate signal significantly.
• Use low-loss coax for long runs. RG-58 is fine up to 5 meters. Over 5 meters, use LMR-400 or equivalent to avoid coax loss eating your link budget.
• Never transmit without an antenna connected. Operating a LoRa transmitter without an antenna will damage the radio front-end. Even during testing, keep the antenna attached.
• 915 and 433 antennas must be separated. Co-locate them on the same mast but space them at least 30 cm apart to avoid coupling and desensitization.

For Backbone Links

If your multi-interface node is also serving as one end of a long-distance point-to-point link, pair a Yagi antenna with SF11 or SF12 on the relevant band. Two ridge-mounted nodes with directional Yagi antennas can bridge entire valleys, achieving 10–30+ mile links at high spreading factors.

Enclosure
& Power

An outdoor-capable node needs three things beyond the electronics: weatherproofing, reliable power, and thermal management. Cutting corners on any of these is the most common reason a node goes offline at the worst moment.

Enclosure Options

Power Strategy

A Pi 4 with two RNodes draws approximately 4–7W under typical load. For a fixed indoor node, this is trivial. For outdoor or off-grid deployment, plan accordingly.

• Indoor / AC power: Official Pi PSU + quality USB-C cable. Use a UPS hat (UPS-Lite or PiJuice) if power reliability is important — they provide 4–8 hours of runtime from a small LiPo battery.
• Solar off-grid: 10W panel + 18650 pack + TP4056 charge controller is sufficient for the Pi's average draw. Ensure the battery is sized for your worst-case consecutive cloudy days.
• PoE (if co-located with networking gear): A PoE hat for the Pi 4 lets you run a single Ethernet cable to the enclosure for both power and network. Clean and reliable.

Thermal Considerations

A Pi 4 in a sealed enclosure in direct sun can reach temperatures that trigger thermal throttling. At minimum, install passive heatsinks on the SoC. If the enclosure is sealed or in sun, add a small 5V fan controlled by the Pi's GPIO. The RPi OS includes raspi-config settings for fan temperature thresholds.

Testing &
Verification

After assembly and configuration, verify each interface is working before calling the build done. A systematic test catches problems before the node goes into service.

Step 1 — Interface Status

$ rnstatus

Interface           Status   TX       RX       RSSI   SNR
LoRa 915 MHz        Up       1.2 kB   847 B    -92    9.1
LoRa 433 MHz        Up       0 B      0 B      —      —
LAN AutoInterface   Up       512 B    1.1 kB
Reticulum TCP Hub   Up       2.4 kB   1.9 kB
I2P Interface       Up       0 B      0 B

# All interfaces should show "Up"
# RX activity on LoRa 915 indicates you're hearing other nodes
# Zero RX on 433 is normal if no 433 nodes are nearbyBASH

Step 2 — Verify Cross-Interface Routing

# From another device on the LAN (with Reticulum installed),
# probe your node's local destination hash:
$ rnprobe <destination_hash>

Probing [abc123...] via LAN AutoInterface... OK  12ms
Probing [abc123...] via LoRa 915 MHz...       OK  430ms

# If routing works, you'll see responses arriving from different
# interfaces as the path table populatesBASH

Step 3 — Verify Transport is Working

# On a LoRa-only device (no internet), attempt to reach a
# Nomadnet node on the internet. If transport is working,
# packets will route: LoRa → your node → TCP → internet.

$ rnpath <nomadnet_destination_hash>

Path to [xyz789...] found via transport node [your_node_hash]
Hops: 2  First hop: LoRa 915 MHz  Next hop: TCPBASH

Step 4 — Confirm systemd Auto-Restart

# Simulate a crash and confirm the service restarts cleanly
$ sudo systemctl stop rnsd
$ sleep 10
$ sudo systemctl status rnsd

● rnsd.service — Reticulum Network Stack Daemon
   Loaded: loaded (/etc/systemd/system/rnsd.service; enabled)
   Active: active (running) since ...
   Restart: on-failureBASH

Ongoing Monitoring

For permanent infrastructure nodes, consider a simple monitoring loop via cron or a lightweight service that periodically runs rnstatus and alerts you if an interface goes down. A down interface won't crash rnsd (thanks to panic_on_interface_error = No), but you want to know about it.

Interface Access
Control (IFAC)

By default, any Reticulum node that hears your interface can send through it and participate in your network segment. For most community deployments this is fine — and desirable, since openness enables the mesh to grow. But there are scenarios where you want to restrict a specific interface to a known group: a private organizational network, a security-sensitive segment, or a community network that wants to prevent abuse.

IFAC adds a shared credential to a specific interface. Only nodes that know the credential can participate on that interface segment. The wider Reticulum network's cryptographic identity layer is still intact — IFAC operates below it, as interface-level access control.

Adding IFAC to an Interface

  [[LoRa 915 MHz]]
    type            = RNodeInterface
    enabled         = yes
    port            = /dev/rnode_915
    frequency       = 915000000
    bandwidth       = 125000
    txpower         = 17               # 17 dBm — legal on 915 MHz ISM (US)
    spreadingfactor = 8
    codingrate      = 5

    # IFAC — Interface Access Control
    ifac_size       = 8                # bytes of IFAC signature
    ifac_key        = your_shared_passphrase_hereCONFIG

You can apply IFAC to some interfaces and not others. A common pattern: apply IFAC to the local LoRa radio interfaces for a private organizational network, while leaving the TCP and I2P interfaces open to the global Reticulum network. This creates a private radio segment that bridges to the public internet-connected network at your node.

Hardening &
Best Practices

A transport node sitting on LoRa + TCP is infrastructure. It stays up unattended, often in a location you can't quickly access. The following practices reduce attack surface, prevent the process from causing damage if something goes wrong, and make the system more observable.

Systemd Sandboxing

The service file in Section 05 included a few basic constraints. Here is a more complete hardened version. These options restrict what the process can do even if it's compromised.

[Unit]
Description=Reticulum Network Stack Daemon
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=reticulum
Group=reticulum

ExecStart=/home/reticulum/.venv/reticulum/bin/rnsd
Restart=on-failure
RestartSec=5

# Privilege containment
NoNewPrivileges=yes
CapabilityBoundingSet=
AmbientCapabilities=

# Filesystem restrictions
ProtectSystem=strict
ProtectHome=yes
ReadWritePaths=/home/reticulum/.reticulum
PrivateTmp=yes
PrivateDevices=no         # Must be no — needs /dev/ttyUSB* access

# Network and syscall restrictions
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
SystemCallFilter=@system-service
SystemCallErrorNumber=EPERM

# Misc
ProtectKernelTunables=yes
ProtectControlGroups=yes
ProtectKernelModules=yes
LockPersonality=yes

[Install]
WantedBy=multi-user.targetSYSTEMD

Firewall Rules for TCP Server Interfaces

If you add a TCPServerInterface (so other nodes can connect to your node rather than you connecting out), expose only the specific port, not the machine broadly:

# Allow inbound Reticulum TCP on port 4242 only
$ sudo ufw allow 4242/tcp comment 'Reticulum TCP server'

# Allow SSH (don't lock yourself out)
$ sudo ufw allow ssh

# Enable — default deny everything else inbound
$ sudo ufw enable
$ sudo ufw status verboseBASH

For a node running only TCPClientInterface (outbound connections only), you don't need to open any inbound ports at all — outbound TCP connections work through standard NAT.

Path Table Bloat on Busy Transport Nodes

A transport node sitting at the intersection of a public TCP interface and multiple LoRa interfaces will accumulate path table entries quickly in active networks. Reticulum handles this gracefully — paths expire if unheard — but on very high-traffic nodes with hundreds of interfaces (e.g., a large community hub), the path table can grow significantly and impact memory usage.

• Monitor memory periodically: free -h and ps aux --sort=-%mem | grep rnsd
• If you're running I2P simultaneously, budget an additional 200–400 MB RAM and watch for OOM kills in journalctl -u rnsd
• Consider whether a single node needs to bridge all interfaces, or whether splitting roles (a LoRa-only relay + a separate TCP/I2P bridge) is cleaner for your topology

Keeping Reticulum Up to Date

The 1.x series is under active development. Breaking changes between minor versions are infrequent but real — particularly around protocol compatibility with older clients. Best practice:

# Activate venv, update, restart service
$ source ~/.venv/reticulum/bin/activate
(reticulum) $ pip install --upgrade rns lxmf nomadnet
(reticulum) $ deactivate
$ sudo systemctl restart rnsd
$ sudo systemctl status rnsd

# Check what version you're now running
$ ~/.venv/reticulum/bin/rnsd --version

# Pin to a specific version on infrastructure (read changelog first)
(reticulum) $ pip install rns==1.1.4BASH

Troubleshooting