fix(protocol): implement partial DLE stuffing for 0x10 bytes in params to prevent request corruption

2026-05-05 18:28:28 -04:00
parent eefec0bd64
commit a27693242d
3 changed files with 108 additions and 4 deletions
@@ -4,6 +4,55 @@ All notable changes to seismo-relay are documented here.

 ---

+## v0.14.3 — 2026-05-05
+
+### Fixed
+
+- **`build_5a_frame` — DLE-stuffing rule for 0x10 bytes in params (the
+  long-standing >1-sec event 0 "won't open in BW" bug).**
+
+  Previously `build_5a_frame` wrote params bytes RAW with no DLE stuffing,
+  based on the incorrect assumption that the device handled all `0x10`
+  bytes in params literally.  It does not.  The device's actual de-stuffing
+  rule for the params region is:
+
+    - `10 10`             → de-stuffs to `10`
+    - `10 02/03/04`       → kept literal (inner-frame markers)
+    - `10 X` for other X  → de-stuffs to just `X` (drops the `0x10`)
+
+  When the counter passed in params has `0x10` in the high byte (e.g.
+  counter=`0x1000` produces params bytes `... 10 00 ...`), the device
+  silently corrupts the request to counter=`0x__00` and responds with
+  whatever lives at that wrong address.  For counter=0x1000 the wrong
+  address was 0x0000, so the response was a copy of the file header +
+  STRT record.  That STRT block then got embedded in the assembled body
+  at file offset `0x1016`, and Blastware refused to open the file
+  (interprets the second STRT as a malformed multi-event file).
+
+  This explains the entire >1-sec event-0 failure pattern:
+
+    - 1-sec events have `end_offset < 0x1000`, so the chunk walk never
+      requests counter `0x10__` and the bug never triggers.
+    - 2-sec / 3-sec / longer events all need a chunk at counter `0x1000`
+      (and longer events also need `0x1200`, `0x1400`, etc., none of which
+      have `0x10` in the high byte except `0x1000`).  Just one corrupted
+      response is enough to embed STRT in the body and break the file.
+
+  Verified against BW 5-1-26 "copy 3sec" capture: all 17 5A request
+  frames (probe + 2 metadata pages + 13 sample chunks + TERM) now match
+  BW's wire output **byte-for-byte**, including the doubled `10 10 00`
+  for counter=0x1000.
+
+### Notes
+
+- `0x10` bytes in `offset_hi` (the standalone offset field at body[5])
+  are still written RAW — confirmed correct per the 1-2-26 capture.
+- BW's actual encoding of `10 02` / `10 04` for meta pages 0x1002 /
+  0x1004 is *not* doubled — it relies on the device keeping `10 02`
+  and `10 04` as literal pairs.  This is preserved by the fix.
+
+---
+
 ## v0.14.2 — 2026-05-04

 ### Fixed