- ripe-atlas - mailman.ripe.net

Re: Your probe 1008669 has disconnected
by Ernst J. Oud 06 Jun '26

06 Jun '26

Yes, my three software probes that are down are on 5G connections that have a forced renew of their IP address every 24 hours. The controller in Dublin I believe has some fault. Hope RIPE corrects this asap. Met vriendelijke groet, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud > On 6 Jun 2026, at 17:11, via ripe-atlas <ripe-atlas(a)ripe.net> wrote: > > Hi again, > > My number keeps going up. Looks like whenever a probe gets disconnected for some other reason, it is not able to connect back to the system. > > And my earlier count was too low already. It seems e-mail notifications aren't sent reliably. At least I didn't get one for some probes that are definitely down longer than the timeout configured (mostly default of 30 minutes). > > Cheers, > > R. > >> On 6/6/26 17:06, Ernst J. Oud wrote: >> Hi, >> Same here. Three of my software probes have disconnected this morning. Nothing wrong with internet at those locations. One of these locations also has a hardware probe that runs fine. >> In the logs it says: >> —- >> /var/atlas-probe/status/reginit.vol does not exist try new reg >> Ping failed >> start reg >> ATLAS registration starting >> there is WAIT, REG_WAIT_UNTIL , now is 1780758142 >> REG_WAIT_UNTIL expired go re-reg 1780758077 now 1780758142 >> REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 >> ssh -p 443 atlas@2001:67c:2e8:11::c100:13f6 INIT >> 255 REGINIT exit with error >> condmv: not moving, destination '/var/atlas-probe/data/out/v6addr.txt' exists >> condmv: not moving, destination '/var/atlas-probe/data/out/simpleping' exists >> —- >> Something definitely wrong with the controller infra! >> Regards, >> Ernst J. Oud >>>> On 6 Jun 2026, at 14:16, via ripe-atlas <ripe-atlas(a)ripe.net> wrote: >>> Hi, >>> Same thing is affecting five of my probes since yesterday, also with repeated messages of being asked to wait, or there having been an error: >>> 2026-06-06T12:13:24.673341015Z reg server asked us to wait or there was an error. REG_WAIT_UNTIL 1780748131 >>> I understand that you "updated [y]our controllers so all probes disconnected for a short while" yesterday, but that is now more than a day ago? >>> Thanks! >>> Kind regards, >>> R. >>>> On 6/6/26 00:14, Marek Küthe via ripe-atlas wrote: >>>> Hello, >>>> My probe has disconnected. Could someone take a look at this? >>>> The message in the log is as follows: >>>> ``` >>>> Jun 06 00:12:48 laplace ripe-atlas[113935]: condmv: not moving, destination '/var/spool/ripe-atlas/data/out/

1 0

Controller error?
by Ernst J. Oud 06 Jun '26

06 Jun '26

And to add insult to injury… three probes down, only one gave me a status message to that effect. So never received a notification that the other two were down too. The change to the new status email template introduced some error perhaps? Regards, Ernst J. Oud

1 0

Global timeout event root DNS
by Jesse Prins 06 Jun '26

06 Jun '26

Hey all! For the final research project for my bachelor I am researching timeouts involving the Root DNS servers using RIPE atlas measurements. In my research I stumbled upon (in my opinion) a weird event that I can’t find any causes for. On the 23rd of December there was a spike (ranging from 10% - 60% depending on the server) in timeouts involving all root servers except F, G and H which don’t show any spike at all (see https://rootviz.sidnlabs.nl/public-dashboards/f81c02c68d7a4986ba1674fd7eb87…) My main question is if there were any problems with RIPE atlas itself around this time (causing an artifical spike)? and if not: Does anyone know what could have caused such a global spike in timeouts? Thanks in advance. Kind regards, Jesse Prins

1 0

Probe disconnect and reconnect emails with missing data
by Johan ter Beest 05 Jun '26

05 Jun '26

Hello Atlas friends, We recently changed the templates for the probe disconnect and probe reconnect messages. Unfortunately, there was a small mistake in the message parameters causing the email to appear essentially empty (no probe ID, no since, no probe description). This error has been fixed now. Apologies for the mistake, Kind regards, Johan ter Beest RIPE Atlas Team

1 0

Spam?
by Ernst J. Oud 05 Jun '26

05 Jun '26

Hi, Just received an email from atlas+e76c0ca5(a)ripe.net saying: —- Probe is disconnected () Ernst J., Your probe has been disconnected from the RIPE Atlas infrastructure since 2026-06-05 09:23:26 UTC. —- As shown above, no probe ID is mentioned and the sender’s email address is a bit weird since normal status messages come from no-reply(a)ripe.net. Also all my probes are functional. A test run at RIPE gone wrong? Regards, Ernst J. Oud

2 1

Atlas UI updates for 2026-05-27
by Stephen Suess 27 May '26

27 May '26

Hello Atlas friends, We have just updated the UI with a new and improved LatencyMON, as well as various other fixes and changes that you can read about here: https://atlas.ripe.net/docs/releases/website_index/2026-05-27 Please let us know if you have any questions or feedback. Kind regards, Stephen Atlas UI

1 0

Controller ctr-dub-sw01 problem?
by Ernst J. Oud 17 May '26

17 May '26

My software probe 1004467 disconnected from controller last ctr-dub-sw01 night. The CentOS VM it is running on has no problems. It has internet access. I rebooted it but that didn’t change anything. Problem with this controller not accepting connection requests? Other probes on this controller still work.. Regards, Ernst J. Oud

1 2

probe migration
by Marco Moock 17 May '26

17 May '26

Hello! In case of a hardware switch, is it reasonable to migrate the software probe to the new machine? In cases of that, which files need to be migrated? -- kind regards Marco Muell und Spam bitte an abfalleimer2000(a)stinkedores.dorfdsl.de

2 1

RIPE Atlas Credit Request — Student at UCLA conducting CGN measurement research
by Sarah 14 May '26

14 May '26

Hi all, My name is Sarah Zhao and I am a Computer Science and Engineering student at UCLA. I am currently conducting undergraduate research in computer networking at the UCLA Connection Lab under the mentorship of Professor Leonard Kleinrock. As part of my research I am studying the deployment and impact of Carrier-Grade NAT (CGN) at Internet scale. I plan to use RIPE Atlas traceroute measurements to detect CGN presence via 100.64.0.0/10 address leakage in hop paths, and TCP connect measurements to probe inbound reachability from CGN and non-CGN ASes as comparative vantage points. I need geographically diverse probes across networks in developing regions where CGN deployment is most concentrated. As a new user I have no credits and kindly ask for a donation to get started. An allocation of 200,000 credits would cover my planned measurement phases. My RIPE Atlas account is registered under: sarahzhao01(a)gmail.com I am very eager to share my findings with the community. Thank you in advance for any help! Best, Sarah Zhao UCLA Computer Science

6 7

Rollout of software probe anti farming measures
by Francesco Iannuzzelli 11 May '26

11 May '26

Dear RIPE Atlas users, Some of you may remember earlier discussions about this topic. We’re now ready to enable a feature to address this issue. Supporting each probe requires resources from the system; at the same time having too many probes in the same network and location does not provide much new information (that is, more probes in the same location or network would provide similar measurement results). Therefore we have controls in place to limit the amount of /software/ probes that are connecting from particular networks: 1. Each probe host can connect up to 2 software probes from the same IP address. 2. Each probe host can connect up to 4 software probes from the same IP prefix (as seen in BGP). 3. At most 32 (or 64) probes from the same IPv4 (or IPv6) prefix (as seen in BGP), regardless of the host. Software probes that connect from networks beyond these limits will not be allowed to connect, unless and until other software probes drop out. Note that we may also adjust the particular maximums over time. We realise that in some cases multiple probes belonging to the same user can come seemingly from the same network, violating rule 2 (mostly), yet they arguably still provide enough value for the community. This may be for example because they are in fact geographically widely distributed. In such a case the host can reach out to us via atlas(a)ripe.net with an explanation and we will consider relaxing this limit. While in the past we observed surprising corner cases, the particular limits described above are set partially taking into account the current software deployment. Therefore only a handful of probe hosts should be impacted by this (as I write this, 71 probes from 13 hosts). As I mentioned above, we’re open to adjust the limits if needed. Regards, Francesco Iannuzzelli

5 5