F28-MT: No
Rationale
The selected firmware learns next hops from observed forwarding and responses. NextHopRouter::send sets next_hop from getNextHop for the destination; route checks can clear that preference, and the final retry falls back to managed flooding. This is automatic hop selection, not an endpoint-selected and enforced intermediary constraint.
Assessment method
Pinned firmware source and primary documentation; no runtime test
Source context
Selected Meshtastic ordinary CLIENT composition
Outstanding qualification
The next_hop header is explicitly considered: having that field does not itself expose sender control, and fallback does not preserve an exclusive relay choice. Destination selection, hop limits, role configuration and diagnostic traceroute remain available. No modified firmware or additional source-routing protocol is selected; this finding does not deny native multi-hop delivery.
Public sources
- https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/NextHopRouter.cpp
- https://raw.githubusercontent.com/meshtastic/firmware/8e6a88d06f44cad26f1e8d7cd402939ccacb9b4c/src/mesh/FloodingRouter.cpp
- https://meshtastic.org/docs/overview/mesh-algo/
Editorial evidence references
The following identifiers refer to research records not included in this public package; they are not public links.
- round482.html
- round482-sources.json