mirror of
https://github.com/meshtastic/firmware.git
synced 2026-11-07 06:44:33 -05:00
4c89b6937c
* Router: drop received packets that carry our own node number Every packet we transmit is recorded in PacketHistory when it is sent, so an echo heard back off the mesh is consumed by shouldFilterReceived(): the implicit ACK fires and retransmissions stop. A LoRa frame with our number that the filter does not recognise (one of ours that has aged out of PacketHistory, or that was sent before a reboot) was then processed as new inbound traffic: dispatched to modules and, when addressed to us, forwarded to the client as a fresh packet. MQTT and UDP ingress already drop from == us. Drop such packets in Router::perhapsHandleReceived() right after shouldFilterReceived(), so recognised echoes keep their implicit ACK and retransmission cancel. test_own_number_ingress pushes frames through the real ingress path: an unrecognised own-number frame to us and an unrecognised own-number broadcast reach neither modules nor the phone; a frame from another node still does; and a recognised echo of our own want_ack broadcast still yields the implicit ACK and clears the pending retransmission. Without the drop the two own-number cases fail; with the drop moved ahead of the filter the echo case fails. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y1BYe4ahUHxyhw3nGTX67D * FloodingRouter: skip dupe reprocessing for our own packets The first copy of an unrecognised own-number frame enters PacketHistory before Router::perhapsHandleReceived() drops it, so a second copy takes the dupe path. With hop_start == hop_limit that path reprocesses it as an originator retry (traceroute handling, and an ACK for a want_ack frame to us), and an "upgraded" copy with more hops removes our own queued transmission from the TX queue. Neither applies to our own packets: we never relay them, and their implicit ACK is generated earlier in ReliableRouter::shouldFilterReceived. reprocessPacket() now returns false for them, and perhapsHandleUpgradedPacket() leaves them alone, so the upgraded copy falls through to the own-number drop. test_own_number_ingress adds a repeated want_ack own-number frame (must not be ACKed) and an upgraded own-number copy (our queued packet must stay queued). Both fail without the guards. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y1BYe4ahUHxyhw3nGTX67D * FloodingRouter: consume upgraded copies of our own packets PacketHistory reports an upgraded copy as seen, so when perhapsHandleUpgradedPacket() returned false for an own-number copy it fell through to the ordinary dupe handling. With hop_start > hop_limit that reached perhapsCancelDupe(), which on a client cancels our own queued transmission. Return true for own-number copies instead, so they are consumed without touching the TX queue. test_own_number_ingress adds the hop_start > hop_limit upgrade case (our queued packet must stay queued); it fails without this change. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y1BYe4ahUHxyhw3nGTX67D * test_own_number_ingress: follow the implicit ACK to the phone The echo case only counted the ACK request through the harness's stub sendAckNak(). AuthPipelineRoutingModule gains a deliverAcks switch that also runs the real RoutingModule::sendAckNak(), so the ACK travels Router::sendLocal() -> RoutingModule -> MeshService to the phone queue. - The broadcast echo case now requires exactly one frame on the phone: a ROUTING_APP success ACK carrying the original request_id. - New case: an opaque echo of our own want_ack PKI DM (unknown channel hash, OPAQUE_RELAY_ONLY) must cancel the retransmission and deliver the same ACK. Filtering our number at phone delivery (as in #11487) fails both; skipping the opaque implicit ACK (as in #11502) fails the PKI DM case. The switch is off by default and cleared on reset, so test_rebroadcast_mode is unaffected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y1BYe4ahUHxyhw3nGTX67D --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: Ben Meadors <benmmeadors@gmail.com>