V4 probe registers hourly to ctr-dub-hw02 but never connects (similar symptoms to June 2025?)

My v4 probe #54764 (firmware 5080) was redeployed in July 2026 after about 2.5 years unpowered. Since 2026-07-22, it has registered hourly via reg01/reg02 over both IPv4 and IPv6, always receiving ctr-dub-hw02, but it has never produced a Connected event or an SOS.

Checks completed so far:

  • The probe boots, obtains IPv4 and IPv6 addresses, and continues to register reliably every hour.
  • A write-off/re-registration and a full power cycle made no difference.
  • Eleven v4 probes running firmware 5080 are currently connected in Réunion, so neither v4 itself nor 5080 appears generally end-of-life.
  • Probe 65431 (v5, firmware 5080, same Orange/AS3215 network) connects successfully to ctr-dub-hw02.
    This is only a control: it confirms that the controller is reachable and accepts a probe from this network, not that v4 and v5 must behave identically.
  • Another probe of mine had also been stored for roughly 2.5 years and connected within seconds when redeployed, so storage time alone does not explain the behaviour.
  • From Réunion, ctr-dub-hw02.atlas.prod.ripe.net:443 is reachable and advertises the legacy SSH algorithms used by older probes.

The publicly available probe software indicates that a controller-stage failure, including an INIT response of WAIT, can cause quiet retries without an SOS. I cannot inspect the v4 firmware directly, but that behaviour is consistent with this probe’s event log.

The remaining plausible explanations seem to be specific state or authorisation for probe #54764 on ctr-dub-hw02, such as a repeated WAIT response or a public-key authentication problem after registration.

This has some similarities to the June 2025 thread about ctr-dub-hw01/2, which RIPE NCC said it was tracking as an infrastructure issue:

Is anyone else currently seeing the same pattern: successful hourly registration, assignment to a Dublin hardware controller, but no Connected event and no SOS?

A support ticket is open in parallel; I am posting here in case other affected hosts can help establish whether this is isolated or controller-related.

Hi,

i have some problem with my v5 probe #64441 (firmware 5080). similar with your problem, my probe stuck in registration (reg1/reg2) status to ctr-dub-hw02 (not connect to controller)

here my posting a few weeks ago

already create ticket but nothing from their side they can do regarding the probe.
i tried disable ipv6 dan use ipv4 only, but same result. for now i’m desperate and next will try replace the probe, and i already contact the ambassador that give me the probe.

Thanks

RIPE NCC identified a DNS failure on probe #54764. The probe could reach the registration servers, but registration normally supplied the controller as a hostname; its DNS was not resolving that hostname, so no SSH connection to the controller was ever attempted.

RIPE normally detects this situation and applies a system-dns-problem-suspected state, which causes registration to provide the controller IP directly. That automatic detection did not trigger for #54764. Once RIPE applied the state, the probe connected immediately.

@rengga, I noticed that probe #64441 is now also Connected: it returned on 13 August at
16:07:39 UTC, only 49 minutes after #54764. Both probes currently carry the system: Doesn't Resolve A and system: Doesn't Resolve AAAA tags. I cannot confirm the root cause for #64441, but the timing and symptoms strongly suggest that the same DNS-detection issue may have affected it.

Thanks to Trix and the RIPE Atlas team for investigating this. This resolves my case.