- ripe-atlas - mailman.ripe.net

Operational work on RIPE Atlas
by Robert Kisteleki 23 Apr '24

23 Apr '24

Dear all, A heads-up: we are just about to start scheduled maintenance work on RIPE Atlas. During the maintenance we expect scheduling of new measurements will be delayed and searching for measurements will not yield up-to-date information. Regards, Robert

1 0

Request RIPE Atlas Credit for Research
by Rolland 18 Apr '24

18 Apr '24

Hi all, I am sorry to spam this email. My name is Fengyan Han, a master's student at Tsinghua University, China. Recently, my research on RPKI requires conducting a large-scale measurement via RIPE Atlas. I have some credits but still need 50M more credits to carry out my study. unfortunately, time constraints prevent me from earning them myself. Therefore, I am reaching out here to ask for assistance. Is there anyone generous enough to offer me some RIPE Atlas credits (like, 1 million?) My account at RIPE NCC is hfy23(a)mails.tsinghua.edu.cn <>. Many thanks in advance! Regards, Fengyan Han

4 3

New default settings for Atlas measurement form
by Stephen Suess 17 Apr '24

17 Apr '24

Hello Atlas users, After an analysis of usage patterns in measurement creation, we have rolled out a couple of changes to the defaults in the measurement form (https://atlas.ripe.net/measurements/form/): - Under timing, the default is now one-off (instead of periodic as before) - Default probe selection is now 50 random, worldwide probes (instead of 10 as before) We hope you find these useful. Please let us know if you encounter any issues. Thanks! Stephen RIPE Atlas UI

4 7

Reverse traceroute
by Hank Nussbacher 16 Apr '24

16 Apr '24

https://pulse.internetsociety.org/blog/reverse-traceroutes-help-troubleshoo… "Measure at least one reverse path from 39,544 Autonomous System (AS) destinations, which host 92.6% of Internet users. As a comparison, RIPE Atlas vantage points can measure from 4,344 AS destinations, representing 67.1% of the Internet user base." Has anyone tried this and indeed found better visibility via their system? Thanks, Hank

3 2

Wohoo: Your RIPE Atlas Probe (ID: 12724) has reconnected
by Gert Doering 09 Apr '24

09 Apr '24

Hi, wohoo, "I'm back" notifications!! Thanks very much to whoever silently implemented this :-) (this was a provider outage, and the probe was indeed offline and came back, so when I got up I found the "it's back, all is well" note already in my mail). If you're bored and want to optimize this: add an "In-Reply-To:" to the original "it's gone"-mail, so there is threading (in case you only see the original mail when it's already back)... cheers, gert ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- Date: Tue, 09 Apr 2024 05:00:00 -0000 From: RIPE Atlas <no-reply(a)ripe.net> To: gert(a)space.net Subject: Your RIPE Atlas Probe (ID: 12724) has reconnected Dear RIPE Atlas probe host, We're just letting you know that your probe (#12724 ) has re-established its link to our network and we are again receiving data from it. For your own records, it appears that the reconnection took place at . If you have any questions, please contact us at atlas(a)ripe.net. Thank you for supporting RIPE Atlas. Best regards, RIPE Atlas Team ********** You can change your notification settings on your probe page (go to "My Atlas" and then "Probes" when logged into the RIPE Atlas website). ----- End forwarded message ----- -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

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