fix(mesh): meshtastic receive — drain frame batch per poll + rx diagnostics

Addresses the open Meshtastic parity bug (project_meshtastic_parity): the
running driver received nothing (`mesh.messages` stayed []) though the radio
got the packets and sends worked.

Root-cause candidate: `try_recv_frame` decoded ONE serial frame per poll and
returned Ok(None) for every non-text FromRadio frame, so the session loop slept
50ms between frames. Under Meshtastic's frequent NodeInfo/telemetry stream a
received text packet queued behind them, and read_from_radio's 64KB buffer cap
could drain (drop) it before it was ever decoded — reception silently dead while
sends kept working.

- try_recv_frame now drains a bounded batch (64) per poll, processing each
  frame's side effects and returning the first inbound text frame, so a text
  packet is decoded the same poll it arrives and the buffer never grows enough
  to hit the lossy cap. Bounded so a continuous flood still yields to select!.
- packet_to_inbound_frame logs every decoded packet (from/portnum/payload_len)
  and a "did not parse (dropped)" case, so one live radio pass is conclusive.

The rest of the decode path was verified correct by inspection (FROM_RADIO_PACKET
=2, wire-type-5 handled, parse_mesh_packet sound, 60s heartbeat present) — not a
parse bug. cargo check green. NEEDS a live radio pass on a rig that isn't .228
(off-limits: bitcoin testing) to confirm.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
archipelago 2026-06-29 05:04:09 -04:00
parent 11038cdcc9
commit 3c7c04a662

View File

@ -530,10 +530,25 @@ impl MeshtasticDevice {
}
pub async fn try_recv_frame(&mut self) -> Result<Option<InboundFrame>> {
let Some(frame) = self.read_from_radio().await? else {
return Ok(None);
};
Ok(self.handle_from_radio(&frame))
// Drain a bounded batch of frames per poll, processing EACH for its side
// effects (my_info/config/channel/node_info) and returning the first that
// yields an inbound text frame. The old one-frame-per-poll behavior
// returned Ok(None) for every non-text frame, so the caller slept 50ms
// between frames; under Meshtastic's frequent NodeInfo/telemetry stream a
// received text packet queued behind them and the read buffer's 64KB cap
// could drain (drop) it before it was ever decoded — silently killing
// reception while sends kept working. Draining keeps the buffer short so
// the text frame is decoded the same poll it arrives. Bounded to 64 so a
// continuous flood still yields back to the session select! loop.
for _ in 0..64 {
let Some(frame) = self.read_from_radio().await? else {
return Ok(None);
};
if let Some(inbound) = self.handle_from_radio(&frame) {
return Ok(Some(inbound));
}
}
Ok(None)
}
/// Whether we've learned `node_num`'s real PKI (Curve25519) key — from a
@ -700,7 +715,25 @@ impl MeshtasticDevice {
}
fn packet_to_inbound_frame(&mut self, data: &[u8]) -> Option<InboundFrame> {
let packet = parse_mesh_packet(data)?;
let Some(packet) = parse_mesh_packet(data) else {
// Diagnostic for the open receive bug (project_meshtastic_parity): a
// forwarded FromRadio.packet that won't parse (e.g. encrypted-only,
// no `decoded` field) is dropped here. Watch for this on the live pass.
debug!(
len = data.len(),
head = %hex::encode(&data[..data.len().min(12)]),
"Meshtastic FromRadio.packet did not parse (dropped)"
);
return None;
};
// Trace EVERY decoded packet so the live pass shows what actually arrives
// and why a text frame is (or isn't) surfaced.
debug!(
from = format!("!{:08x}", packet.from.unwrap_or(0)),
portnum = packet.portnum,
payload_len = packet.payload.len(),
"Meshtastic FromRadio.packet decoded"
);
if packet.portnum != TEXT_MESSAGE_APP || packet.payload.is_empty() {
return None;
}