Lessons Learnt
Expanding the Mesh: Heltec Nodes, Meshtastic Bridging, and the Problems Nobody Warns You About
This is a continuation of Part 1, which covered flashing an RNode and setting up a Raspberry Pi relay. If you haven't read that first, start there.
At this point the setup is: a Pi running Reticulum with a LilyGo RNode attached, MeshChat accessible on the local network, and everything running as systemd services. The next step is expanding the network with Heltec LoRa32 v3 nodes — one for portable use, one for bridging to the Meshtastic network.
The Plan: Two Heltecs, Two Jobs
The Heltec LoRa32 v3 is a better choice than the LilyGo for new nodes. It uses the newer SX1262 chip (vs the LilyGo's SX1276), has higher transmit power (21 dBm vs 17 dBm), and is actively supported by the RNode firmware project. It's also cheaper and easier to source from AliExpress.
The two Heltec nodes have different roles:
Heltec #1 — Meshtastic bridge, stays home plugged into the Pi This node runs Meshtastic firmware and stays permanently connected to the Pi via USB. A bridge script running on the Pi translates between the Meshtastic and Reticulum protocols, giving your Pi visibility into the local Meshtastic network. Any Meshtastic nodes in your area can reach your Pi through this bridge.
Heltec #2 — Portable RNode, goes into the field This node runs RNode firmware and connects to an Android phone running Sideband over Bluetooth. When you leave the house, your phone communicates with the Pi relay over LoRa radio, giving you Reticulum messaging even without internet.
The architecture looks like this:
Part 4: Flashing the Heltec v3 as an RNode (Portable Node)
Step 1 — Flash Using the Web Flasher
The easiest way to flash a Heltec v3 is the RNode web flasher. Open Chrome and go to:
liamcottle.github.io/rnode-flasher
Select:
Product: Heltec LoRa32 v3
Model: 868/915 MHz (match your region — 915 MHz for North America)
Click Download Firmware, then Choose File and select the downloaded zip.
Click Flash Now and select the Heltec's serial port when prompted.
If you get a connection error, the Heltec v3 requires a specific sequence to enter download mode:
Hold the BOOT button
Press and release RST
Release BOOT
Then click Flash Now
Step 2 — Verify the Flash
After flashing, the Heltec's OLED screen should show signal strength and frequency information. Verify via command line:
You should see the Heltec listed with firmware version 1.85 or later and frequency range 850-950 MHz.
Note: You'll see a "Device signature validation failed" warning if you flashed on a different machine than the one you're verifying on. This is expected and not a real security issue — the signing key lives on the machine that did the flashing.
Step 3 — Configure in Reticulum
If you want to use the Heltec as a second RNode on the Pi (for example during testing), add it to your Reticulum config:
Add under interfaces — note the port will be different from the LilyGo:
Important: Never configure two RNode interfaces pointing to the same serial port. If both the LilyGo and Heltec are plugged in at the same time, check which port each is on with ls /dev/ttyACM* before configuring.
Part 5: Flashing the Heltec v3 as Meshtastic (Bridge Node)
Step 1 — Flash Meshtastic Firmware
Go to the Meshtastic web flasher:
flasher.meshtastic.org
Select:
Device: Heltec v3
Click Flash and follow the prompts. The flasher will download and install the latest Meshtastic firmware automatically.
After flashing, the Heltec's OLED will show "Meshtastic" and begin advertising as a Bluetooth device.
Step 2 — Basic Meshtastic Configuration
Use the Meshtastic app (iOS or Android) or the web app at client.meshtastic.org to configure the node:
Set a node name
Set region to ANZ (Australia/NZ) or US depending on your frequency plan — for 915 MHz in Canada, use US
Set the LoRa preset to Long Fast for best range
Plug the configured Heltec into the Pi via USB. Check it's visible:
You should see it appear as /dev/ttyACM1 (or /dev/ttyACM0 if the LilyGo isn't plugged in).
Part 6: Setting Up the Meshtastic-to-Reticulum Bridge
The bridge that connects these two networks is RNS Over Meshtastic by landandair. It works by running as a custom Reticulum interface — Reticulum treats the Meshtastic network as just another transport, exactly like it treats LoRa or WiFi.
Step 1 — Install the Meshtastic Python Library
Step 2 — Install the Bridge Interface
Clone the bridge repository:
Copy the interface file to your Reticulum interfaces folder:
Step 3 — Add the Bridge to Your Reticulum Config
Add this interface, adjusting the port to match your Heltec's serial port:
The data_speed = 8 setting uses Short-range Turbo mode, which is the recommended setting for best performance. Do not use Long Fast (which would be data_speed = 7) — it's too slow for Reticulum packets.
Save and restart rnsd:
Check that the Meshtastic interface shows up:
You should see a Meshtastic_Interface entry in the list.
What the Bridge Actually Does
It's worth being clear about what this bridge does and doesn't do, because expectations matter here.
What it does:
Your Pi can receive and relay packets from Meshtastic nodes within radio range
Reticulum nodes can route messages through the Meshtastic network as a transport
Your Pi appears as a node on the local Meshtastic network
What it doesn't do:
Meshtastic users can't seamlessly message Reticulum users by name — the addressing systems are different
The bridge is a transport layer, not a translation layer for messaging apps
A Meshtastic user using the standard Meshtastic app won't see your Reticulum identity
In practice, the bridge extends your network's reach by using existing Meshtastic infrastructure as additional radio coverage. If there are active Meshtastic nodes in your city, your Pi relay can route Reticulum packets through them to reach further than your own RNode antenna alone.
The ISP Port Blocking Problem — and How I2P Solves It
This is the part that took the most time to work through.
The goal was to connect the Pi relay to the global Reticulum network via a public testnet node — specifically dublin.connect.reticulum.network on port 4965. This would make the relay reachable by anyone running Reticulum worldwide.
What we discovered: Shaw (Rogers) in Canada blocks outbound TCP connections on non-standard ports. Testing confirmed that port 443 (HTTPS) works fine, but ports 4965, 4242, 2424 and others all time out completely. This isn't a DNS problem — the IP addresses are reachable via ping, but TCP connections on those ports never complete.
We also discovered that Shaw intercepts DNS queries regardless of which nameserver you configure. Setting 8.8.8.8 in resolv.conf has no effect because Shaw's infrastructure intercepts port 53 traffic before it reaches Google's servers.
Several fixes were attempted and failed: changing nameservers in resolv.conf, installing systemd-resolved with DNSOverTLS, installing dnscrypt-proxy, and trying Cloudflared proxy-dns (which was removed entirely in version 2026.2.0).
The solution: I2P
Reticulum has built-in support for the I2P network as a transport interface. I2P routes traffic through encrypted tunnels across a distributed network of volunteer nodes, and its traffic looks like normal encrypted internet traffic to your ISP. Shaw can't block it without breaking a lot of other things.
Install i2pd (the lightweight I2P daemon):
Then add the I2P interface to your Reticulum config:
Add this in the interfaces section:
Save and restart rnsd:
Check the status:
You'll first see I2P: Creating Tunnel — this is normal. I2P takes 5-10 minutes on first run to integrate into the network and negotiate paths. After that it will show I2P: Tunnel Active and Status: Up, confirming you're connected to the global Reticulum network.
Important: Once I2P is working, remove any dead TCP interfaces from your config (like the Dublin hostname or hardcoded IPs) to keep things clean. They won't connect through Shaw's port blocking anyway.
A note on I2P performance: I2P adds some latency compared to a direct TCP connection because traffic routes through multiple nodes. For Reticulum messaging this doesn't matter — messages aren't time-critical. But don't expect the speed of a direct connection.
Current Setup Summary
Services running on the Pi:
rnsd.service— Reticulum transport daemon, starts after network comes onlinemeshchat.service— MeshChat web interface, starts after rnsd
Both services restart automatically if they crash, and start on boot.
What's Next
VPN or I2P for global connectivity — the remaining piece to connect the relay to the worldwide Reticulum network
Android + Sideband setup — pairing the portable Heltec RNode to a phone for field use
Range testing — walking the city with the portable node to measure real-world LoRa range with the outdoor antenna
Expanding the friend group — each additional person needs a Heltec v3 (~$25 CAD) and an Android phone running Sideband
Lessons Learned
On hardware: The Heltec v3 is the better choice over LilyGo for new nodes. More power, newer chip, still actively supported. LilyGo works fine as a home relay node where transmit power matters less.
On ISPs: Shaw/Rogers in Canada actively intercepts DNS and blocks non-standard ports. If you're on Shaw, plan for this from the start. A VPN is the simplest workaround. Don't spend hours trying to fix DNS — it's not broken, it's being hijacked.
On the bridge: The RNS Over Meshtastic bridge is early but functional. Expect rough edges. The important thing is having dedicated hardware for each protocol — you cannot run Reticulum RNode firmware and Meshtastic firmware on the same device simultaneously.
On patience: Reticulum is not plug-and-play. The reward is a network that's genuinely yours — no accounts, no servers you don't control, no one who can shut it down. That's worth a weekend of troubleshooting.
