The federation fallback in the plain content-inline path wasn't enough —
mesh.transport-advice recommended the "resource-mesh" tier purely from our
own device being Reticulum-capable, without checking that THIS peer
actually has a radio route. For a federation-only contact (no radio twin)
that steered the frontend into send-content-inline's Reticulum
resource-transfer path, which has no dest_prefix to send to and fails with
"Peer is federation-only (no radio twin)" — reproduced after deploying the
first fix on a live node.
Adds MeshService::has_radio_route(contact_id), and gates both the
"resource-mesh" tier in mesh.transport-advice and the resource-transfer
branch in mesh.send-content-inline on it. Federation-only peers now fall
through to the has_tor branches, which route the frontend to
mesh.send-content (already correctly federation-aware) instead.
Landed from PR #133 (re-committed to drop private host details from the
original message; content identical).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The release gate's first real stage is `cargo fmt --check`, and it had
44 diffs across 15 files — enough to abort `create-release.sh` at step 0
before it touched a version number. Some of that drift is mine from the
last two days, some predates it in files I never opened
(bootstrap.rs, ghost_reaper.rs, openwrt/router.rs), and one is the
regenerated fips/app_ports.rs.
No behaviour change — rustfmt only.
Gate now: 8 of 9 green. The remaining red is cargo-test-weekly exiting
124, which is the 25-minute `timeout` expiring during a cold
CARGO_INCREMENTAL=0 rebuild on a loaded node — the tests never started.
Not a test failure.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Every Reticulum-heard peer surfaced as rssi=0 — indistinguishable from a
real 0 dBm reading and, worse, from "heard over the TCP bridge with no
radio involved at all", which made a TCP-fed mesh look like working RF
during the 2026-08-16 radio diagnosis.
- Sidecar: announce handler now uses the 4-arg RNS dispatch to get the
announce packet hash and reports per-announce rssi/snr from Reticulum's
packet-stat cache; LXMF deliveries report message.rssi/snr/q (LXMF
already populates them on direct RNode hops). All None over TCP or
multi-hop — the honest RF-vs-internet discriminator.
- Rust: ReticulumPeer caches last_rssi/last_snr from announce and recv
events (a TCP-relayed announce never blanks a real RF reading), and
get_contacts surfaces them so refresh_contacts propagates real values.
- Identity discovery no longer hardcodes rssi 0: unknown is now None
end-to-end and logged as such.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Three root causes from the 2026-08-16 framework-pt incident where a
replugged radio detected but never connected:
- detect_serial_devices scanned a hardcoded ttyUSB0-2/ttyACM0-2 list, so
a radio enumerating at index 3+ was permanently invisible. Now scans
/dev for all ttyUSB*/ttyACM* nodes (deterministic order, /dev/mesh-radio
alias still first and still wins the dedup).
- An operator rnode-rf-settings.json port override silently outranked the
device_path the user just chose in the detection modal. mesh.configure
now clears a stale override when a different device is configured
(symlink-resolved compare keeps /dev/mesh-radio aliases intact).
- Espressif native-USB boards (303a, ESP32-S2/S3/C3 RNodes) had no udev
rule, so they never got the stable /dev/mesh-radio alias and a persisted
alias path dangled after a port move.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
