survive disconnect during BLE MTU lookup

2026-08-18 14:26:11 -04:00
parent d86212be9d
commit 4bf00eb583
5 changed files with 35 additions and 3 deletions
@@ -100,7 +100,9 @@ cumulative uint32 counters:
 The header's cumulative dropped-sample count remains the sum of sensor read
 failures and queue overflows, preserving version-1 receiver compatibility while
 the status payload makes the causes independently observable. USB-specific BLE
-counters remain zero.
+counters remain zero. The rejected-ACK total can also include a harmless valid
+duplicate that arrives after its frame has already completed, so a nonzero value
+does not by itself prove corruption or a hostile receiver.

 ## Buffering

@@ -50,10 +50,19 @@ therefore compare the sequence and raw bytes with their last persisted frame,
 avoid writing a duplicate, and ACK the replay again. The reference
 `tools/capture_ble.py` implements this ordering.

+The rejected-ACK counter is diagnostic, not a pure corruption count. A valid
+duplicate ACK can arrive after the output task has already completed that frame
+and begun the next one; firmware then rejects and counts the now-stale write.
+
 BLE notification success only means the fragment entered the stack. The `ACK1`
 write is the end-to-end boundary. It deliberately confirms application
 persistence rather than radio or ATT delivery alone.

 Version 1 is an unauthenticated, single-connection prototype service. It does
 not yet provide pairing, authorization, or confidentiality against a nearby
-peer; those are separate from the loss/replay guarantees above.
+peer; those are separate from the loss/replay guarantees above. A nearby peer
+can also deny availability by subscribing and never acknowledging: firmware
+correctly retains and replays the owned frame, but the RAM queue eventually
+fills while the legitimate receiver remains excluded. Pairing and connection
+authorization are required before treating this as a hostile-environment
+logger.