[Bug]: BLE RNode support (RNodeInterface over ble://) is broken on macOS — bundled RNS 1.4.2 has 3 fixable bugs #67

Summary

RNodeInterface's BLE support (port = ble://...) doesn't work at all on macOS in the bundled rns==1.4.2. I ran into this trying to connect a T-Deck-based RNode over BLE instead of USB, and tracked it down to three separate bugs in RNS/Interfaces/RNodeInterface.py's BLEConnection class. None of these are MeshChatX-specific — they're all in the vendored RNS dependency — but since Reticulum's upstream repo is now a mirror with no further public development or PR intake, I wanted to flag it here in case you'd consider patching your own vendored copy rather than waiting on upstream.

The three bugs

1. device_bonded() always returns False on macOS, blocking every BLE connection before it even starts (no OS pairing prompt ever shown). It checks device.details["props"]["Bonded"], a structure specific to bleak's BlueZ (Linux) backend. On macOS, bleak's CoreBluetooth backend populates device.details as a (CBPeripheral, manager) tuple with no such structure, so the check silently fails shut every time.

2. connection_job()'s retry loop calls asyncio.run() fresh on every retry, which tears down and recreates the event loop each time. bleak's CoreBluetooth backend holds a persistent delegate bridging OS callbacks to asyncio Futures, so a callback completing late (e.g. during an OS-level pairing prompt) can fire against an already-closed loop from a previous attempt, raising RuntimeError: ... got Future <Future pending> attached to a different loop and failing the connection.

3. self.connected is set True before service discovery/notify-subscription actually finish, and RNodeInterface.configure_device() starts the KISS detect handshake the moment it sees that flag, against a fixed timeout — eating into that timeout with GATT setup work that hasn't completed yet, so the device rarely gets a real chance to reply before the host gives up.

Fix

All three are fixed in my fork, based on current upstream master (which is version-equivalent to rns 1.4.2):

https://github.com/Rudedog415/Reticulum/tree/fix/ble-bonding-check-macos

Diff: Rudedog415/Reticulum@5362c80f

Verified against a real LilyGo T-Deck Plus running RNode firmware over BLE — the interface now reliably bonds, connects, and stays up with real bidirectional traffic.

(Related, but separate: if you're testing against T-Deck using the RatSpeak (rsDeck) RNode specifically, there's also a firmware-side bug where the BLE RX characteristic doesn't accept "Write Without Response," silently dropping every write from the host — fixed here: ratspeak/rsDeck#68. Not relevant to MeshChatX's own code, just flagging in case it's useful context.)

Disclosure

Per your Generative AI policy: this investigation and fix were done with significant assistance from Claude (Anthropic), used interactively throughout a live debugging session against real hardware (not a thin/one-shot prompt) — it helped read the bleak/CoreBluetooth source, correlate live device+host logs, and draft the actual patch, which I reviewed and tested end-to-end before writing this up.

Happy to help test if you decide to vendor a patched copy.