April 2024 - ripe-atlas - mailman.ripe.net

Understanding participating probes and probe requests
by Malte Tashiro 08 Apr '24

08 Apr '24

Hi, I'm currently looking at measurement metadata and am a bit confused about the different ways of getting the number of probes participating in a measurement and the number of probes requested by the user. I'd like to know how to... 1. get the number of probes _currently_ participating in a measurement (for ongoing measurements) 2. the number of probes that participated when the measurement finished (for stopped measurements) 3. the number of probes a user requested over the lifetime of a measurement The default response to /measurements returns a participant_count and a probes_requested value. However, there are also the optional fields current_probes and participation_requests and these do not add up. For example, this [0][1] measurement (not mine) has a participant_count of 0 (showing as "Actually Participating: None") in the web interface, but one probe listed in current_probes, which shows up in the "Latest Results" list and is still performing measurements (at least while writing this). So it seems like the current_probes list is more accurate to get the number of probes _currently_ (or when the measurement finished) participating in a measurement? Similarly, there are 35 probes_requested, which equals the sum of "requested" probes from the participation_requests, however, some request are actually "remove" actions, which should not be included in this count? Any hints on how to interpret these fields? I think the requested probes and participation requests are more a problem for long-running measurements, but the participant count is sometimes weird for one-offs as well. Thanks, Malte [0] https://atlas.ripe.net/measurements/67903255 [1] https://atlas.ripe.net/api/v2/measurements/67903255?optional_fields=current…

2 1

probe online but not doing any measurements [condmv: not moving, destination]
by Lukas Tribus 07 Apr '24

07 Apr '24

Hello, my probe 1007423 is online, however it does not appear to do any measurements (which is a silent failure one only notices when trying to use it's own probe unfortunately). It's running on OpenWRT 23.05.3 (installed atlas-sw-probe package). I'm not sure since when this is happening. After booting I can see that the sos dns request fails (probably when connectivity is not yet ready): evping: bad address 'U14.H484d19378dbf100f.sos.atlas.ripe.net' evping_ops.init failed And every 3 minutes I see: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/v6addr.txt' exists condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/simpleping' exists Any ideas on what could be happening here? Can I safely delete those files? Thank you, Lukas

1 0

Confused by the documentation
by Stephane Bortzmeyer 05 Apr '24

05 Apr '24

I confess I have a lot of problems finding something in the documentation in its current state. For instance, I assume that HTTP requests can have a "method" parameter to switch from GET, HEAD, etc but where is it documented? Not here: https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/types/type_sp… Not here: https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements

3 3

Empty responses for HTTP tests with a non-existing path?
by Stephane Bortzmeyer 05 Apr '24

05 Apr '24

It seems the anchors, when receiving a HTTP request for a non-existing path, instead of a 404, send a broken response: % curl -v http://fr-par-as2486.anchors.atlas.ripe.net/nonono * Trying 2001:67c:217c:4::2:80... * Connected to fr-par-as2486.anchors.atlas.ripe.net (2001:67c:217c:4::2) port 80 (#0) > GET /nonono HTTP/1.1 > Host: fr-par-as2486.anchors.atlas.ripe.net > User-Agent: curl/7.81.0 > Accept: */* > * Empty reply from server * Closing connection 0 curl: (52) Empty reply from server

2 2

RIPE Atlas maintenance on Wed 10 April
by Christopher Amin 05 Apr '24

05 Apr '24

Dear colleagues, On Wednesday 10 April we will carry out maintenance on a storage solution used by critical backend nodes of the Atlas infrastructure. Work start: 2024-04-10 08:00 UTC Work end: 2024-04-10 11:00 UTC What you should expect during the maintenance window: - The LIR Reachability Test will not work; - Newly connected probes may take longer than usual to connect to the RIPE Atlas system. All other parts of the RIPE Atlas service should continue to work as usual. Regards, Chris Amin RIPE NCC

1 0