Mitigate Direct Routing Instability from One-Byte Hop Hash Collisions

[robekl]

Summary

This change introduces a protocol-compatible mitigation for direct-routing instability caused by one-byte hop-hash ambiguity.

Problem

Direct paths currently identify each hop using only a single byte of node identity.
A one-byte space has only 256 possible values, so collisions are not edge cases in realistic meshes:

• As node count grows, repeated hop-byte values become common.
• In mixed repeater/client environments, multiple nearby forwarders can share the same byte.
• Mobility and changing RF conditions increase the chance that an unintended forwarder is the one that sees and acts on traffic.

When this happens, direct-routing behavior can degrade in several ways:

• Wrong-hop forwarding or path drift.
• Direct packets failing repeatedly despite a nominally known path.
• Retry churn and fallback traffic bursts.
• Reduced delivery reliability and higher airtime contention in busy areas.

Preferred long-term fix

The robust fix is a protocol evolution that carries larger hop identifiers (for example 2+ bytes per hop, ideally versioned with capability handling).
That would reduce hop aliasing at the source instead of handling ambiguity heuristically at runtime.

Why this change is a mitigation

This implementation does not alter packet format or route encoding.
Instead, it reduces harm by detecting when a stored direct path is likely ambiguous and avoiding direct transmission in those cases.

Mitigation behavior

The routing decision now distinguishes between:

• Unambiguous known direct paths: keep direct behavior.
• Ambiguous known direct paths: avoid direct and use flood-based delivery pathing.

This reduces the chance of direct-path misforwarding and avoids wasting retries on routes that are likely unstable due to hop-byte aliasing.

Scenarios where this helps

• Medium/large meshes where multiple known peers share hop-byte prefixes.
• Areas with overlapping repeater coverage where multiple potential forwarders can claim the same hop byte.
• Mobility-heavy environments where stale direct paths and collisions combine to produce intermittent failures.
• High-contention periods where failed direct attempts amplify congestion.

Implementation overview

The change adds a direct-path ambiguity check in contact-routing logic and applies it consistently across outbound behaviors that rely on stored direct paths:

• message and command sends,
• request/login style sends,
• acknowledgment path choice,
• direct response decision points,
• keep-alive traffic,
• return-path retry handling.

When ambiguity is detected for a known direct path, direct send is skipped and flood/scoped-flood is used instead.

A lightweight internal metric is also maintained for observability of “direct avoided due to ambiguity,” helping operators and maintainers evaluate how often this mitigation is active.

Expected impact

• Fewer direct-route dead ends caused by one-byte hop aliasing.
• Fewer repeated direct retries before eventual fallback.
• More stable message delivery in collision-prone topologies.
• No protocol break and no interoperability risk with existing nodes.