Chapter 5 — Connections & Networking

The Connections screen (reached from Settings) is where administrators manage how the device reaches the mesh. A connection is a network interface: Stolo runs every enabled connection simultaneously and reroutes traffic automatically if one drops.

5.1 Connection types

Connection	What it is	Good for
Local WiFi	Automatic peer discovery on the local network segment, using link-local IPv6 multicast. No router configuration, no DHCP dependency, no setup.	Fast local communication anywhere devices share a WiFi network or hotspot.
LoRa Radio	An RNode-firmware LoRa radio attached over USB or Bluetooth.	Long range (~5 km typical, terrain-dependent) with zero infrastructure. Low bandwidth. Your off-grid lifeline.
Internet	A TCP link to a Reticulum node. Every install ships with a link to the Stolo Gateway (gw.stolo.io:4242) so distant teams can reach each other whenever any internet path exists.	Long-haul connectivity over WiFi/LTE.
Internet (hosting)	A listening TCP/backbone interface — this device becomes a meeting point other nodes can connect to. Used on relay/gateway deployments.	Fixed infrastructure nodes.

Out of the box, every install has Local WiFi and the Stolo Gateway enabled. Removing or disabling the gateway sticks — Stolo never re-adds it behind your back.

5.2 The Connections screen

Connections are grouped into ACTIVE (enabled) and AVAILABLE (disabled). Each card shows:

• Type, name, and a live status line:
• "Active · N peers nearby" (Local WiFi, with a live peer count)
• "Connected · ‹name›" (other types)
• "Not connected" — enabled but currently down
• "Off" — disabled
• Capability chips (e.g. ~5 km range, Low bandwidth, Auto-discovery, Fast) and the live link bitrate when known.
• An on/off toggle.

Changes require an engine restart. After any toggle or newly added connection, a banner appears: "Changes apply after a restart" with a Restart button that restarts the Stolo engine in place.

There is no delete action for connections — disable a connection to park it under AVAILABLE.

5.3 Adding a connection

Tap Add a connection and pick a type:

Internet node (TCP)

• Address — hostname or IP of the Reticulum node (e.g. testnet.reticulum.network).
• Port — defaults to 4242.
• Name — a label of your choice.
• Connect on startup (default on) — turn off to add the node but leave it disabled.

Local WiFi

Just give it a name — discovery is automatic.

Radio (RNode) — USB

1. Plug the RNode in over USB and tap Scan (or type the port directly, e.g. /dev/ttyUSB0 or COM9).
2. Pick the radio from the scan results.
3. Choose your Region preset (below), or expand Advanced to set raw radio parameters.

Bluetooth — RNode over BLE

1. Put the RNode in pairing mode and tap Scan. Only Bluetooth radios are listed.
2. Pick the radio (port takes the form ble://RNode-name).
3. Choose the Region preset as above.

Bluetooth and USB are mutually exclusive for the same radio — unplug USB before switching a radio to Bluetooth.

5.4 LoRa radio regions and parameters

All radios that need to talk to each other must use identical radio parameters. Region presets provide legal, interoperable defaults:

Region preset	Frequency	Bandwidth	Spreading factor	Coding rate	TX power
United States (915 MHz) (default)	915.000 MHz	250 kHz	8	4:5	17 dBm
Europe (868 MHz)	868.000 MHz	125 kHz	8	4:5	14 dBm
Australia (915 MHz)	915.000 MHz	250 kHz	8	4:5	17 dBm
Asia (923 MHz)	923.000 MHz	250 kHz	8	4:5	17 dBm

The Advanced disclosure exposes the raw values (Frequency in Hz, Bandwidth in Hz, Spreading factor 7–12, Coding rate 5–8, TX power in dBm) for operators with their own frequency plan.

Trade-offs to know: higher spreading factors increase range but dramatically reduce data rate; wider bandwidth increases data rate but reduces sensitivity. The presets balance range and usable messaging throughput. Always verify local regulations for your operating frequency and power.

5.5 Supported LoRa hardware

Stolo auto-detects RNode-firmware radios over USB on desktop and relay deployments, including:

• RAK4631 WisBlock
• LilyGO T-Beam, T-Beam Supreme, T3S3, T-Deck, T-Echo
• Heltec LoRa32 (V2 and V3)
• Generic RNode builds on ESP32-S3 and nRF52840, and FTDI-based RNodes/OpenModem

Radios must run RNode firmware (installable with the standard rnodeconf tool). When a configured radio moves to a different USB port, Stolo re-points its configuration automatically at the next engine start.

For Bluetooth use, the RNode must first be put in pairing mode (rnodeconf --bluetooth-pair) and bonded with the operating system.

5.6 How routing works (background for admins)

• Stolo's engine (Reticulum) maintains paths to peers across all active interfaces, preferring direct links and falling back to relayed paths automatically. There is no routing configuration to manage.
• Phones are not transit nodes by default: they send and receive their own traffic but do not route traffic for others. Dedicated relay nodes (see Chapter 11 — Deployment) run with transport enabled and carry traffic for the whole mesh.
• Local WiFi discovery uses UDP ports 29716 and 42671 — allow them through host firewalls on desktop deployments.
• Advanced interface options (interface modes, private-network IFAC name/passphrase) are available in Settings for segmented deployments; see Chapter 12 — Settings Reference.

5.7 Connection detail (per-peer)

From a chat header or a map pin, the Connection detail sheet shows how a specific peer is being reached: a route diagram (You → relays → Peer), plain-language signal quality, which connection is carrying the traffic, measured round-trip time, and when the peer was last heard. Deliberately, no raw RSSI/SNR jargon appears here — the same information is expressed in plain terms. (Raw RSSI/SNR readings for a peer are available on the Map screen's peer details.)