HydraIssues

The in-head probe (#397) can already target a body: it takes any address, and its path tag was built to distinguish lan, tunnel-direct and tunnel-hub precisely for this case. The pre-flight hook already aims at the address discoverBody chose. The only missing half is that a body has nothing to echo with, so a probe at a body today returns zero replies. #397 deliberately DROPS a zero-reply run rather than publishing it as an all-loss failure, because with no reflector that is indistinguishable from a dead path.

Why this matters more than the cloud reflectors

Right now we measure head to cloud-reflector with nothing to compare against, so the cloud question is being asked in absolute terms: "is 16 ms and 10 ms of jitter good enough?" That is the weaker question.

With a reflector on every body, the SAME instrument measures head to local body and head to cloud body. The question becomes "how does the cloud path compare to the on-prem path this venue already streams over and is already happy with". That is a far stronger basis for the #695 decision, and it is measured rather than argued.

It also delivers what #402 actually wants: per-session path quality for real streams, on the path the stream uses, not a proxy.

And it would have caught ad6's roughly 10 ms of LAN jitter (#724) as a matter of routine instead of by expedition.

How

Embed the reflector in hydrabody rather than shipping a second binary:

• hydrabody already runs as a service on every body and already auto-updates through hydrarelease. One binary, one lifecycle, nothing new to provision.
• The reflector is small and already written: hydraprobe's server package. It is currently internal/ because the head only measures and does not reflect; promote it to pkg/ the same way the engine was promoted in daca4da.
• Listen on UDP 2112, HMAC authenticated with the shared key, min-interval 0 so sub-10 ms clients are allowed. Bind on the mesh and LAN addresses.
• Config flag to disable it, default ON: it is a few hundred bytes per second at B1 and answers only HMAC-valid packets.

WDAC is NOT a blocker, contrary to earlier notes

The plan and the campaign runbook both say ad-hoc binaries cannot run on bodies because of WDAC. That is stale. WDAC policies were removed on all bodies on 2026-03-24 precisely because they broke the auto-updater, and binary updates work freely now. The operator memory index still carried the old wording and has been corrected.

Even so, embedding in hydrabody is the better route: it avoids a second binary and a second service entirely, so the WDAC history is moot.

Firewall

UDP 2112 inbound on the body, from the venue LAN and the mesh. Worth confirming against whatever already lets Moonlight reach Sunshine.

Related: #397, #402, #714, #724, #745, #695.