One repeater, three legs running at once: real LoRa stays primary, an ESP‑NOW side-channel lets Sidecar boards attach with no second LoRa radio, and an encrypted IP bridge links out to another repeater over WiFi. Each leg is opt-in and independently configured — turn on only what you need.
local LoRa mesh
|
v
+-------------------------+
| Trifecta repeater |---- ESP-NOW ---> Sidecar (no LoRa radio)
| (real LoRa radio) |
+------------+------------+
|
IP bridge, DTLS
|
v
another Trifecta repeater — anywhere with
WiFi and a route back to it
Unmodified — this is still a normal MeshCore repeater first. Nothing here changes how it behaves on the LoRa mesh.
Lets a Sidecar (companion, room server, or another repeater) attach over 2.4GHz WiFi hardware — short range, no internet path at all.
Links to exactly one configured peer repeater over TCP+TLS-PSK — not a public broker anyone can join, just two repeaters that already agreed to connect.
Drop a repeater somewhere with no LoRa neighbors yet, and link it to an established Trifecta repeater over IP so it's useful from day one — not sitting idle waiting for the mesh to grow into it. Once real repeaters go up nearby and start hearing each other over actual RF, the IP link quietly steps back into a backup role instead of staying load-bearing.
Same IP bridge, different wire underneath: point it over a private LAN, a VPN, or whatever point-to-point radio link you've already got (microwave, 60GHz, take your pick) and join two sites into one mesh with nothing exposed to the outside internet at all.
The fair question with any bridging feature: does it let traffic behave worse than it would over real RF? Three things specifically prevent that.
Local, ESP‑NOW-bridged, and IP-bridged traffic all funnel through the same duty-cycle-based transmit budget on the real radio. Nothing gets to bypass it just because it arrived over a different transport.
MeshCore's existing broadcast-domain controls (region/transport-code scoping) sit in the same receive pipeline regardless of whether a packet arrived over LoRa or over a bridge. An operator can turn either bridge into a hard broadcast boundary with existing CLI config — nothing new to learn.
The IP bridge deliberately holds back new-path traffic briefly whenever a real RF neighbor is present, giving a genuine multi-hop LoRa path a chance to win the race before falling back to IP. See the deep-dive below for exactly how.
MeshCore's routing keeps whichever return path arrived most recently for a contact, not whichever is "best" — and an IP link is inherently lower-latency than a multi-hop LoRa path. Left alone, IP would tend to win that race every time, quietly making a contact prefer the bridge even when a perfectly good RF path exists.
Route-establishing traffic — first contact with a new peer, and any reply that teaches a return path — gets held for a short, hop-count-scaled delay before being mirrored onto the IP bridge, but only when this repeater has recently heard a real RF neighbor directly. If a genuine RF path completes within that window, the IP copy that eventually goes out just arrives as a harmless duplicate, absorbed by normal dedup. The delay is skipped entirely when the destination is already confidently known to have no LoRa radio at all (an ESP‑NOW-only Sidecar, say) — there's no RF alternative to wait for in that case.
Two failure directions, and they're not symmetric. Holding a packet when no RF path actually existed just costs a bit of latency — self-correcting, never a delivery failure. The other direction is the real limitation: the "is RF nearby" signal only counts directly-heard repeater adverts, not companions, and isn't destination-specific. In a narrow scenario — a genuine alternate repeater path exists but its advert hasn't reached this repeater recently — the delay gets skipped and IP can win the race unnecessarily. The mesh still delivers the message either way; the only cost is that contact's cached path leaning toward IP a bit more than ideal in that one case.
Closing this fully would mean inventing a path-advertisement mechanism MeshCore doesn't have today — floods are destination-blind by design, with no routing table and no propagated reachability info beyond direct neighbours. That's a real protocol extension, not a local fix, and a bad tradeoff against staying close to stock MeshCore. Left as a known, bounded, honestly-documented tradeoff instead.
The IP bridge is one repeater to one configured peer, meant for greenfield bootstrapping and backup/failover — not a general-purpose way to chain many meshes together over the internet.
Both bridges depend on ESP32-specific WiFi/ESP-NOW hardware — not available on other supported chip families.
Live-tested on real hardware, but unmerged upstream and not an official MeshCore release. Don't run it on a mesh you depend on.
Ready to configure a repeater?
Setup & config →