Found 2026-09-15 while looking for a probe node at the venue.
On the hydraguard hub, the sint-niklaas peer (GL.iNet Slate 7 Pro, allowed ips 10.10.5.1/32 and 10.0.5.0/24, endpoint last seen 194.78.246.220:42730):
Every other venue peer on the same hub handshakes within seconds: 10.10.3.1 at 3 s, and the 10.10.100.x node peers at 5 to 45 s. So the hub is healthy and this peer alone is silent.
Independently, hydracluster reports all three iPad heads at the venue OFFLINE: ipad-head-map-35 (node-fe6e7808), ipad-head-map-37 (node-e0528a7e), ipad-head-map-39 (node-a57ee1a7).
A ping to 10.10.5.1 from pi-node-001 over the mesh gets 100 percent loss.
The neck and every head at the venue are unreachable together, which points at the site rather than at any one device: power, the upstream line, or the router itself. The recorded endpoint means it did reach the hub from 194.78.246.220 at some point, so the peer configuration is not obviously wrong.
Worth noting the hub has sent 144 GiB to this peer historically, so the venue was streaming normally before.
The cloud GPU campaign (#714, #732) needs a probe at every target venue. sint-niklaas has no Linux or macOS node, and its GL.iNet neck is the ONLY neck in the fleet we could run a probe on (the MikroTiks are Citymesh-managed read-only, the ad6 Omada is a closed appliance). That made the neck the obvious candidate, and checking it revealed the venue is simply down.
Someone on site, or whoever holds the venue contact, to confirm power and the uplink. Until then sint-niklaas cannot be measured for #732 and cannot serve visitors either, which is the more urgent half.