2 Commits (fix/309-path-len-decode)

Author	SHA1	Message	Date
Strycher	73d0fc9888	fix(#309): decode and encode path_len per firmware, not as a byte count ... The firmware path-len byte is packed and self-describing (src/Packet.h:79-84): high 2 bits = hash size - 1, low 6 bits = hash COUNT (hops), byte length = count * size. The app treated the low 6 bits as a byte count and ignored the width, on the strength of a comment asserting the high bits were "not reliably populated". Both halves of that comment were wrong. Receive: Contact.fromFrame read `count` bytes where firmware meant `count` hops, so at 2-byte width it kept HALF of every path and discarded the rest. DAYTON VA's 2-hop route became a 2-byte fragment, which is why every repeater login in Bandit's capture timed out. Send: buildUpdateContactPathFrame wrote the count raw, leaving mode bits 00. That tells the radio "1-byte hashes" while handing it 2-byte hash data, so it routed to nodes never on the route. This is the likelier cause of the observed "routes via c6 and 5c separately" behaviour. Also fixes a third unit inconsistency: setContactPath wrote customPath.length (bytes) into pathLength (hops) after every path set. Contact now carries pathHashWidth per path, so a stored path can never be re-sliced at a width it was not captured at. realHopCount() is removed rather than adjusted: it divided an already-correct hop count, halving it at 2-byte width, and every call site was compensating for a bug that no longer exists. Migration (Ben's call, option A): records written before this change have no pathHashWidth and hold truncated bytes that cannot be recovered by reinterpretation, so their path is dropped and the contact reverts to flood until the radio re-supplies it. Logged, not silent. Tests asserted the old semantics (expect(realHopCount(2, 2), 1)) and were rewritten against firmware truth rather than adjusted to keep passing. Added send-side encoding coverage, which did not exist. 456 tests pass. Refs #240, #279, #299 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 days ago
Strycher	7179d201c5	fix(#224): decode contact path-len byte (mask high bits + divide by width) ... The firmware path-len byte packs a hash-mode hint in the high 2 bits and the path byte-length in the low 6. Contact.fromFrame stored it raw, so a direct node at 2-byte mode (0x40) read as pathLength 64: "64 hops" in the UI, a ~195s ACK timeout, and up to 64 junk bytes pulled into contact.path that broke repeater status/telemetry/neighbors until the path was cleared (#222). - contact.dart: decode via pathHopCount (& 0x3F); keep 0xFF as the flood sentinel; use the decoded length for safePathLen so path bytes stay clean. - chat_screen _currentPathLabel: show realHopCount(pathLength, pathHashByteWidth) so 2/3-byte nodes read the correct hop count; 0 -> Direct. - Regression test for 0x40/0x00/0x03/0x44/0xFF; updated two model_changes tests that codified the old raw mapping. Part of #222 (stays open for on-hardware validation by the reporter). Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	1 week ago