[khagele]

Closes #481

A trace-ping is the app's most effective probe. The firmware forwards a directed TRACE on a hash match with no rate limit anywhere in that path — Mesh::onRecvPacket (src/Mesh.cpp:41), and a repeater's allowPacketForward only tests disable_fwd for a direct packet — where a Discover answer is capped at 4 per 120 s and an anonymous request at 4 per 180 s. Since #455 the retransmission it provokes is captured instead of dropped.

It was stored with no sender. classifyReception refuses to read a TRACE packet's path bytes as node ids, correctly: they are per-hop SNR values. So the measurement of the node being hunted landed on the map as an anonymous point, and Locate never saw it.

What names it

We generate the tag, the firmware echoes it back in the retransmission, and the decoder already exposes it as payload.decoded.traceTag. A packet carrying a tag we sent is the reply to our own probe. app/src/tracetag.js remembers (tag → target) when the ping goes out and answers "whose reply is this" when one comes back.

Only where classifyReception found no sender, and only on our own tag: overheard trace traffic stays anonymous exactly as before.

The claim, and its edge

buildTracePathFrame addresses the first hop with one byte of the target's id, so any node whose id starts with that byte answers a trace addressed that way. The tag narrows the claim to "this is the reply to our probe" — it does not widen it to "this id is proven", and the code says so where it does it.

Where the ambiguity is visible the match is refused rather than guessed: two live pings addressing the same first byte produce no attribution at all. That is the same rule AGENTS §7 applies to prefix merging — ambiguity is evidence against, never for.

A ping expires after 30 s. That is generous by two orders of magnitude against a zero-hop reply, deliberately: a late match costs nothing (the reception is a real measurement of that node at wherever we were standing when it arrived) while a premature expiry throws the attribution away.

A regression this would have shipped with

selectedRepeaterIds reads only the newest record per id. Once the trace reply became that newest record, its sender_kind was no longer relay and its role was not Repeater, so the target dropped out of the ping set — a node stopped being pinged because it answered. Autoping would have pinged each target exactly once.

trace_reply now counts as forwarding behaviour, which is what it is evidence of: only a node that forwards packets retransmits a directed trace; a companion does not. Pinned by two tests that were red before the fix.

Verification

• app/: 41 files, 717 tests green. web/: 378 vitest plus all 147 Playwright specs with --fail-on-flaky-tests. npm run build and npx eslint src clean.
• Mutation-checked, each red for its own reason: the ambiguity refusal removed (1 red), the expiry boundary moved by one (1), the tag no longer zero-padded (1), the decoder's tag not lowercased (1). The two selectedRepeaterIds tests were red before their fix.
• A composition test runs the sequence processFrame runs — decode, classify, read the tag, match, buildRecord — over a TRACE packet built to the firmware's own layout, and asserts both halves: the row carries the target's id, and it carries no name (an id is an id).
• The HUD rendering is pinned too: a trace reply shows a 6-character id prefix, not a name and not "via" (it came from that node directly, not through it).

Note for whoever merges second

#478 edits the same two lines of processFrame. Whichever lands first, the other rebases — the resolution is mechanical (both turn const cls into let cls and add one branch).

Changelog entry added to both copies, where: "app".

[efiten]

Read the firmware rather than the citation, and the load-bearing claim is exactly right. simple_repeater/MyMesh.cpp:426:

bool MyMesh::allowPacketForward(const mesh::Packet *packet) {
  if (_prefs.disable_fwd) return false;
  if (packet->isRouteFlood()) { ...flood_max, region, loop detect... }
  return true;
}

Every throttle — flood_max, flood_max_unscoped, flood_max_advert, the region check, loop detection — sits behind isRouteFlood(). A directed TRACE is isRouteDirect(), so it passes on disable_fwd alone. And Mesh::onRecvPacket's trace branch has no rate limit in it either. So "the app's most effective probe" is a claim about the firmware and it holds.

The regression you caught is the better half of this PR. selectedRepeaterIds reading only the newest record per id means the trace reply becomes that newest record, its sender_kind stops being relay, and the node drops out of the ping set — a node stops being pinged because it answered. Autoping would have pinged each target exactly once and the symptom would have looked like autoping being broken, not like an attribution change. Counting trace_reply as forwarding behaviour is right: only a node that forwards retransmits a directed trace.

Refusing the match when two live pings address the same first byte is the right rule and the right precedent (§7: ambiguity is evidence against, never for). Being explicit that the tag narrows the claim to "this is the reply to our probe" and not to "this id is proven" is the honest framing of a one-byte address.

The 30 s expiry argument is sound in the direction it argues — a late match costs nothing because the reception is a real measurement wherever we were standing. Worth noting the asymmetry runs the other way too: with two orders of magnitude of slack, the ambiguity refusal is doing more work than the expiry is, which is the right way round.

One thing to carry into #484, not a change here. This establishes that our probe is unthrottled at every hop of the reply path. That is a good property for a hunt and a less good one for the network if the probe rate goes up — and #484 sweeps every audible repeater when no target is picked, which multiplies exactly this. Raising it there rather than here, since this PR only names one target at a time.

Approving.

[efiten]

Approved. Needs a rebase; #478 is ahead of it in the app queue.