Trifecta bridge — beta 5
Pre-releaseTrifecta repeater firmware (real LoRa + ESP-NOW bridge + IP bridge, all at once) — beta 5.
Built from commit 7ca989a8 on the espnow-ip-bridge branch. Covers the companion, Heltec V3, Heltec V4, and Xiao S3 WIO.
Two builds per board, same code, different tradeoff:
_debugfiles —BRIDGE_DEBUG,MESH_DEBUG,MESH_PACKET_LOGGING,WIFI_DEBUG_LOGGINGall on. Noisier serial output, and debug logging has a real (small) timing/CPU cost on a busy repeater, but gives full visibility into bridge/routing decisions. Use this for testing, troubleshooting, or pairing withwatch_boards.pybelow.- Plain files (no
_debugsuffix) — functionally identical, debug logging stripped out. Quieter and slightly leaner/faster, since nothing is spending time formatting and pushing log lines out over serial every packet. Use this once you're done actively debugging and just want the repeater running.
What's new since beta 4
- The IP bridge now runs over TCP+TLS-PSK instead of UDP+DTLS-PSK. UDP gave no delivery guarantee — a dropped datagram on the IP hop was silently invisible on both ends, with no way to tell it apart from a real failure elsewhere. TCP's own retransmit/ordering now covers that.
mbedtls_net_connect()has no non-blocking TCP variant, so the client-side connect is done manually (non-blockingsocket()/connect(), polled to completion) to keep the bridge's synchronous, single-threaded design intact — no new FreeRTOS task. - A new incoming connection can no longer preempt an active session just by connecting. A bare TCP
connect()(a port scanner, or any random connection attempt) now has to complete its own TLS-PSK handshake — proving it holds the real shared secret — before it's allowed to replace the currently active peer. This also fixes a real operational issue found during testing: previously, if a peer's IP changed (e.g. after a network switch), the other side needed a manual reboot to accept the new connection; now a legitimately reconnecting peer gets back in automatically once it re-authenticates. - Added TCP-level keepalive (30s idle, 10s probe interval, 3 probes) as a backstop alongside the existing app-level ping/pong heartbeat — catches some dead-link cases the app-level heartbeat alone might be slower to notice, and incidentally keeps NAT/router connection-tracking state alive on a port-forwarded link.
- If you're reaching a repeater through port-forwarding / DDNS for the IP bridge, the forwarded port now needs to allow TCP, not just UDP. This is the one real deployment-facing change — update your router's forwarding rule for the bridge port if you're using this over the internet rather than a local network.
- Housekeeping: binaries no longer embed the build machine's local file paths (a standard but easily-avoidable side effect of compiling, unrelated to any of the above). Also added the companion firmware and
set_bridge_params.pyto this release — every file ever shipped across any beta now lives in every new one, so nothing requires digging through older releases.
Repeaters (Xiao S3 WIO, Heltec V3, Heltec V4)
Which file to flash:
-merged.bin— for a blank/fresh board. Flash at offset0x0:
esptool.py --chip esp32s3 write_flash 0x0 <file>-merged.bin- plain
.bin(no-mergedsuffix) — app-only, for upgrading a board that's already running MeshCore. Preserves identity, WiFi credentials, and BLE bonds. Flash at offset0x10000:
esptool.py --chip esp32s3 write_flash 0x10000 <file>.bin
After flashing, configure over the standard MeshCore serial CLI (set bridge.channel, set bridge.secret, set wifi.ssid, set wifi.pwd, set ip.host, etc.) — no custom tooling needed.
Monitoring multiple boards at once
python3 watch_boards.py
Auto-detects every connected board, connects to all of them, and streams their debug output live in one terminal. Press n to dump neighbors.all, b to dump bridge status, c to toggle watching companion boards, from every connected board at once. See the script's own --help for details.
Full writeup, use cases, and setup details: https://smellyspice.github.io/MeshCore/
This is an unmerged personal fork, not reviewed by MeshCore maintainers — a developer/beta release for testers who want to help shake it out, not something to run on a mesh anyone actually depends on, debug logging on or off. If your mesh matters to you or to other people using it, wait for something further along than this. See the writeup for known limitations before flashing.