2 Commits (9aaebce77c868df48efdcd7d8c9bc9e91b4c65da)

Author	SHA1	Message	Date
Strycher	b28f3b36cb	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>	5 days ago
Strycher	31f850530b	fix(#115): decode multi-byte path hashes at the device width ... Packet Path mis-identified repeaters: a 2-byte path hash like 6A3D was sliced into two 1-byte hops (6A + 3D), so the first byte collided with an unrelated repeater (Freemasons 6A..) and the second matched nothing ("Unknown Repeater"). - meshcore_protocol: realHopCount() converts the firmware path BYTE length to true hops via the device hash width. - channel_message_path_screen: slice/count/match at the device pathHashByteWidth (not the unreliable per-message high-bits); bucket and match on the full w-byte hash (mirrors _pathMatchesContact), not hash[0]. - channel_chat_screen: same width fix on the per-message via-line + hop badge. - settings: show the build number alongside the version name. - bump 1.1.2-beta.4+36. - test: realHopCount regression coverage. Gemini review (llm-consult): fix-then-ship; 2 findings clarification-only (_formatHash is canonical hex used identically both sides; pathHashByteWidth is static per-connection). Part of epic #112. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	4 weeks ago