- ripe-atlas - mailman.ripe.net

Discrepancy between built-in test and my own test
by Ernst J. Oud 22 Aug '25

22 Aug '25

Hi, I have a probe (probe ID 1005229) running on a VM in the Oracle Cloud. On that probe I have a ping test (measurement ID 85299016) to Google. Thus, an Atlas controller instructs my probe to do a latency test every 5 minutes. The result of that test is fairly consistent at around 7 ms. However, there is also a built-in measurement running on all Atlas probes to Google, every probe automatically performs this measurement every 10 minutes. The results of that test is fairly consistent at around 1 ms. Why is there such a difference between these two equal measurements? Both to Google, both from the same probe. Any clues? Regards, Ernst J. Oud

2 3

re-adopting
by Randy Bush 20 Aug '25

20 Aug '25

Probe 25918 may have come back to life some months after i abandomed it. how can i re-adopt it? thanks. randy

5 7

Re: Need RIPE Atlas Credits for measurements
by Carsten Schiefner 14 Aug '25

14 Aug '25

2 3

Need RIPE Atlas Credits for measurements
by Rohan Bose 14 Aug '25

14 Aug '25

Hello RIPE Atlas community, I am Rohan Bose, PhD student at the Technical University of Munich. My research efforts are focused towards understanding LEO satellite network behavior and performance. Our earlier work has investigated general Starlink network performance with the help of RIPE Atlas platform and contributed our understanding to the community: https://labs.ripe.net/author/nitinder-mohan/a-multifaceted-look-at-starlink… For more details I urge you to go through our publication: https://dl.acm.org/doi/10.1145/3589334.3645328. More recently, I aim to uncover CDN performance characteristics for Starlink users across the world. The objective is to investigate latencies to CDN servers for different CDN providers and CDN server selections for Starlink users in different regions. CDN server selections can be highly dependent on the DNS resolver selection. Hence, I also want to have a look at the DNS responses for CDN hosted domains when targeting different public resolvers. Furthermore, a comparison with current terrestrial network deployment is also crucial in understanding the impact that LEO satellite networks have on remote areas. In order to run such a large-scale measurement on Atlas, I am in need of credits. I would appreciate if community folks would be willing to donate some extra RIPE Atlas credits and support the measurement work, I have outlined here. My Atlas account id is linked with this email: rohan.bose(a)tum.de<mailto:rohan.bose@tum.de>. Thanks much! I would appreciate any help coming from the community. Best regards, Rohan Bose

5 4

Atlas software probe - dual-stack - hanging onto old v4
by vom513 13 Aug '25

13 Aug '25

Hello all, I have a probe I run here at home. I have both (we only have 2) incumbent ISP services here. I used to have this on ISP 1 and now it’s on ISP 2. Looks like the probe registered via v6 ? However it’s still hanging onto the old (and currently wrong) v4 IP/ASN. https://imgur.com/a/GP2Zw9G Is there a way I can force the probe to update this on the v4 side too ? Just wait it out (what is this “patience” virtue you speak of ?! :) ) Thanks.

1 0

WHY2025 - RIPE Community Village
by Trix Taiclet 06 Aug '25

06 Aug '25

Dear colleagues, a few employees from the RIPE NCC will be present at WHY2025 [0], a hacker camp in the Netherlands happening in a couple of days. There will be a "RIPE Community Village” [1], including a tent with a few cool things. Pass by to see ;) I will be present at WHY2025, though not in an official capacity, but I'm more than happy to chat about RIPE Atlas, in particular probes. -- Trix Taiclet Embedded Systems Engineer @ RIPE Atlas RIPE NCC [0]: https://why2025.org/ [1]: https://wiki.why2025.org/Village:RIPE_Community

1 0

Request for RIPE Atlas Credits for Research on Domain Blocking in Latin America
by Kirill Betberry 28 Jul '25

28 Jul '25

Hello, Atlas community! My name is Kyrylo, and I’m currently exploring how different ISPs across Latin America implement domain-level blocking, particularly in the context of content filtering and censorship. To get a more comprehensive and unbiased view, I’d like to use RIPE Atlas measurements from a geographically diverse set of probes. I’m especially interested in comparing how domain reachability varies across providers and countries in the region. This is a personal project designed to learn more about global network behavior. I would appreciate it if anyone in the community is willing to donate some extra RIPE Atlas credits to support this effort. Any help would be greatly appreciated! My RIPE Atlas account is registered with this email: kyrylo(a)betberry.io Thank you in advance for your support and for making such a great tool available to the community. -- Thanks! Kyrylo

4 3

Problem deleting measurements
by Loqman Salamatian 25 Jul '25

25 Jul '25

Hi folks, I’ve recently run into an issue when trying to stop some ongoing measurements that I created. I’ve tried two approaches: 1. Using the Cousteau API wrapper: from ripe.atlas.cousteau import AtlasStopRequest stop_request = AtlasStopRequest(msm_id=m_id, key=API_KEY) success, response = stop_request.create() 2. Attempting a raw DELETE via the API I attempted to stop them using the DELETE method via the /measurements/{id}/ endpoint. These two approaches worked for some measurmeents but then I get the following error: {"error":{"detail":"That measurement cannot be stopped","status":400,"title":"Bad Request","code":104}} 3. Using raw PATCH via the API I then tried to use a PATCH request to update the stop_time to a timestamp in the past. Here I get no error but the measurements are not updated. All these measurements appear under my user account and are marked as “Ongoing.” I’m unsure why they can’t be stopped. Could you please advise on: 1. Why these measurements might be undeletable? 2. Whether there’s an alternative way to terminate them? Thanks in advance for your help! Best, Loqman

1 0

measurements cannot be created
by Marco Moock 25 Jul '25

25 Jul '25

Hello! I tried to create a measurement, I get the green banner Measurement(s) created! 119740137 When opening it, I get the error that the data cannot be fetched. Do other people encounter the same? -- kind regards Marco Send unsolicited bulk mail to 1753424511muell(a)stinkedores.dorfdsl.de

1 0

Atlas UI and Docs updates
by Stephen Suess 24 Jul '25

24 Jul '25

Hello Atlas friends, We just released an update to the UI that includes the following new features (in addition to other changes and fixes): - NEW: Probe detail: Resolve geo location dispute - NEW: Measurement Detail: Add link out to new troubleshooting doc when any msm has no replies - NEW: Prefs: set preferred address family (v4/v6) for use in forms and charts when possible For the full list of what has changed, you can check out the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-03-25 We have also just released a new docs system based on vitepress: https://atlas.ripe.net/docs/ As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

7 17

atlas.ripe.net service migration
by Christopher Amin 24 Jul '25

24 Jul '25

Dear colleagues, The scheduled maintenance on atlas.ripe.net was successfully completed earlier today, with a short-lived minor impact on API requests. For details, please see the status page entry: https://status.ripe.net/incidents/jv6wtx5s71rg Regards, Chris Amin RIPE NCC

1 0

really strange hop situation on 1006475
by Marco Moock 23 Jul '25

23 Jul '25

Hello! Probe 1006475 has really interesting results: RESOLVED tr.dorfdsl.de TO 2a01:170:118f:30::100 STARTED QUERY AT 2025/07/23 14:52:56 UTC Fetching Measurement: 119451691 Traceroute from 2405:8d40:48d9:592f:10b8:22ff:fe88:a416 to 2a01:170:118f:30::100 (2a01:170:118f:30::100): 1 fd8d:b030:165f::1 8.901ms 0.79ms 0.762ms 2 tr.dorfdsl.de (2a01:170:118f:30::100) 268.925ms 262.384ms 262.513ms This cannot be true as my system is far away. I also receive that packet, so it is not a simulation etc. This is the situation from the other direction: m@tr:~$ sudo traceroute -I 2405:8d40:48d9:592f:10b8:22ff:fe88:a416 traceroute to 2405:8d40:48d9:592f:10b8:22ff:fe88:a416 (2405:8d40:48d9:592f:10b8:22ff:fe88:a416), 30 hops max, 80 byte packets 1 2a01:170:118f:30::1 (2a01:170:118f:30::1) 1.164 ms 2.235 ms 2.309 ms 2 2a01:170:0:10::1 (2a01:170:0:10::1) 10.751 ms 10.853 ms 10.816 ms 3 * * * 4 * * * 5 * * * 6 ffm-bb1-v6.ip.twelve99.net (2001:2034:1:6b::1) 10.444 ms 11.857 ms 11.418 ms 7 mei-b5-v6.ip.twelve99.net (2001:2034:0:15a::1) 26.477 ms 41.573 ms 41.224 ms 8 sng-b7-v6.ip.twelve99.net (2001:2034:0:14::1) 197.873 ms 197.940 ms 196.175 ms 9 * * * 10 ditona-ic-388046.ip.twelve99-cust.net (2001:2035:0:28f0::2) 194.862 ms 194.751 ms 194.879 ms 11 2405:8d40:2:103b::3 (2405:8d40:2:103b::3) 230.238 ms 230.303 ms 230.253 ms 12 2405:8d40:0:1002::2 (2405:8d40:0:1002::2) 222.359 ms 222.388 ms 222.404 ms 13 2405:8d40:3:1004::3 (2405:8d40:3:1004::3) 256.477 ms 248.020 ms 247.930 ms 14 2405:8d40:103:1013::3 (2405:8d40:103:1013::3) 242.521 ms 244.766 ms 243.801 ms 15 2405:8d40:a38:20b3::4d (2405:8d40:a38:20b3::4d) 243.622 ms 244.194 ms 244.200 ms 16 2405:8d40:48d9:592f:569:347b:29b8:4da3 (2405:8d40:48d9:592f:569:347b:29b8:4da3) 261.501 ms 271.957 ms 275.285 ms 17 2405:8d40:48d9:592f:10b8:22ff:fe88:a416 (2405:8d40:48d9:592f:10b8:22ff:fe88:a416) 255.513 ms 249.852 ms 248.217 ms m@tr:~$ Does anyone have a clue what is going on? Traffic manipulation at the remote ISP? -- Gruß Marco Send unsolicited bulk mail to 1753282214muell(a)stinkedores.dorfdsl.de

1 0

Offset of NTP measurement
by Marco Davids (SIDN) 23 Jul '25

23 Jul '25

I noticed a discrepancy between the output of my own tool and RIPE Atlas. My tool reports the offset as a negative value, while RIPE Atlas shows a positive one. For example: https://atlas.ripe.net/measurements/115803954/results Any thoughts? -- Marco

7 10

Possible Corner Case Bug in RIPE Atlas NTP Measurement
by Marco Davids 22 Jul '25

22 Jul '25

Dear RIPE Atlas team, I believe we may have discovered a corner case bug in the way RIPE Atlas handles NTP measurements. The issue surfaced during experiments with my NTP simulator — a small tool that mimics an NTP server and allows for controlled manipulation of its behavior. In one particular scenario, the simulator randomly varies the poll value in each response. While this doesn’t occur frequently in real-world implementations, it is technically valid behavior. It appears, however, that either the probes or the measurement system itself do not expect the poll value to change across responses. When initiating a measurement with the default setting of 3 packets, and each response has a different poll value, the result is that the measurement ends up reporting nothing. I first described this on the RIPE Atlas mailing list: https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/33KNP7KPX… A detailed analysis can be found here: https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/message/OSRNUJ2Y… The NTP simulator is publicly reachable at: ntp1.testdns.nl I'd appreciate it if you could take a look. Thank you in advance for your time and consideration! Kind regards, -- Marco Davids SIDN Labs

1 0

Re: Atlas probes not reporting NTP results on ntp0.testdns.nl ?
by Marco Davids 22 Jul '25

22 Jul '25

Hi Joachim, Thanks again for your work and the promising findings! I’ve updated the settings of the NTP simulator (now running at ntp1.testdns.nl) to keep the poll value fixed, and I’ve created a new measurement with 50 probes, each sending 10 packets per interval: https://atlas.ripe.net/measurements/118724341 And indeed — things already look a lot better! So... did we just find a bug? Best, -- Marco -------- Original Message -------- *Subject: *[atlas] Re: Atlas probes not reporting NTP results on ntp0.testdns.nl ? *From: *Joachim Kroß *To: *"Marco Davids (SIDN)" , ripe-atlas(a)ripe.net *Date: *Thu, 17 Jul 2025 15:30:35 +0200 > When multiple packets are sent per sample (default is to send three), > those are currently sent back to back. I.e., unless there is packet > loss, the second and third request are sent as soon as the response to > the previous request has been received. As consequence, the values of > the majority of fields in the responses are typically the same, e.g., > ref-id, poll, precision, stratum, version, mode, even ref-ts. As such, > they are at the top level of the JSON object. And the "result" structure > only has the fields that vary between the packets, i.e., the timestamps > related to the actual packet transmissions (and derived values). > > With the explicitly misbehaving server, however, some of the fields that > would typically not change between back-to-back responses, or rather > rarely only, _do_ change from one response to the next. E.g., the poll > and precision fields. In those cases, there still is an entry at the top > level of the JSON object, I guess perhaps derived from the first packet. > But then, the result structure would additionally have entries for those > types of fields where the value differs from the one at the top level.

1 1

Atlas probes not reporting NTP results on ntp0.testdns.nl ?
by Marco Davids (SIDN) 18 Jul '25

18 Jul '25

Dear list, If anyone knows, or is able to figure out, why most (but not all) Atlas probes don’t report results for NTP measurements to ntp0.testdns.nl, I’d appreciate your insights. Examples: https://atlas.ripe.net/measurements/116922622/ https://atlas.ripe.net/measurements/116946257/ https://atlas.ripe.net/measurements/116830921/ Ping works: https://atlas.ripe.net/measurements/116921717/ Thanks in advance. -- Marco

5 11

Re: Atlas probes not reporting NTP results on ntp0.testdns.nl ?
by Marco Davids (SIDN) 17 Jul '25

17 Jul '25

Hi Joachim, Thank you for looking into this! On Thu, 17 Jul 2025 15:30:35 +0200 Joachim Kroß wrote: > It seems the explicitly misbehaving server has been replaced by a more > sane one (albeit apparently not synchronized) Oh, yes that's correct - sorry for that. I started doing some tests with an NTPv5 enabled Chrony server. The NTP simulator is still available on another server though, albeit IPv6 only (because such VM's are so much cheaper): ntp1.testdns.nl. For those interested; my simple NTP simulator is here: https://github.com/mdavids/ntptools/tree/main/go/fake-ntp-server A version that allows to simulate jitter and clock drift is here: https://github.com/mdavids/ntptools/tree/main/go/fake-ntp-server-2 Just a few simple experiments, mostly the result of a bit of vibe coding. -- Marco

1 0

Asking for credits for a university project
by Serban Orza 16 Jul '25

16 Jul '25

Hello, Atlas community! I am Serban Orza, a second-year Computer Science student at Delft University of Technology. Together with another 4 students, we are working on an open-source project that measures the accuracy and reliability of NTP servers. We already implemented the basics, but we would like to integrate RIPE Atlas to have a global perspective and to avoid the bias of a single measurement point. We would appreciate it a lot if somebody could provide us with some RIPE API credits to perform measurements and analyze the reachability of NTP servers. My account at RIPE NCC is on this email: orza(a)student.tudelft.nl Thank you! Serban

10 14

sw-probe reducing syslog messages
by Hans Mayer 14 Jul '25

14 Jul '25

Dear All, I am running the package ripe-atlas 1.5-3 on Debian 12 bookworm with probe id 1010735. Is there a way to reduce the syslog messages for really necessary events like errors ? Kind regards Hans --

2 1

software probe disconnected: REGINIT exit with error
by Marek Küthe 09 Jul '25

09 Jul '25

Hello, For a few hours now, my two software probes (#1008711 and #1008669) are no longer connected. I have attached the log. I build the software probe myself [1] and use a somewhat hardened systemd unit [2]. Does anyone know what I could do? Greetings Marek Küthe [1] https://codeberg.org/mark22k/dn42-router/src/commit/ae9b7cc8c36a7cb0dd9ce8d… [2] https://codeberg.org/mark22k/dn42-router/src/commit/ae9b7cc8c36a7cb0dd9ce8d… -- Marek Küthe m.k(a)mk16.de er/ihm he/him

2 1

Location quantisation?
by Ray Bellis 08 Jul '25

08 Jul '25

In an effort to find and report probes with incorrect geolocation, I'm rather curious to find out what's special about a lake just west of Wichita (Kansas) that results in it having 11 probes in the middle of it? I suspect some sort of very coarse location quantisation, yet the probes there are not just distributed all over the US, but I also see a probe from Madrid and another from near Ljubljana. cheers, Ray

6 14

Probe areas
by Yohan Prod'homme 07 Jul '25

07 Jul '25

Hello, When you start a measurement, you can specify an area to chose probes from. These areas are like "West", "North-Central", "South-East"... What do they corresponds to? If I use the "West" area, this is the west of what? Of the europe? Because "west of the world" barely makes any sense to me, and I can't find any documentation about these areas. I feel like I'm missing something obvious, so I'd be grateful if someone can enlighten me :) Thanks, Yohan

2 2

Probe down ?
by Colin Johnston 30 Jun '25

30 Jun '25

7 11

traceroute with specific udp target port
by julien.piccaluga 25 Jun '25

25 Jun '25

Hello, I’m developing a Proof of Location project and have a use case requiring a traceroute on a specific UDP port. It appears that traceroute only supports selecting a target port for TCP. Are there any undocumented or lesser-known methods to achieve this with UDP? Regards Julien Piccaluga Mobile: +41 (0) 78 832 36 20 Envoyé avec un e-mail sécurisé [Proton Mail](https://proton.me/mail/home).

1 0

Probe location API
by Ray Bellis 25 Jun '25

25 Jun '25

My RIPE visualiser for the DNS root system has previously been using this endpoint, that now returns an error: https://atlas.ripe.net/api/v2/cartography/locations Is there another I can use in its place with the same output? thanks, Ray

2 4

RIPE Atlas measurements broken since yesterday
by Lucas Rolff 24 Jun '25

24 Jun '25

Hello, It seems like creating new measurements through RIPE Atlas has been broken since yesterday afternoon, while the given measurement is created, it will simply return "Error fetching data", regardless of how long waits. e.g. a traceroute towards 8.8.8.8: https://atlas.ripe.net/measurements/111806687/overview Is RIPE aware of this issue? And any possible ETA when it will work again? - Lucas Rolff

2 2

Request for RIPE Atlas Credits for Geo-Staking Research
by julien.piccaluga 17 Jun '25

17 Jun '25

Hello, I’m currently working on a project related to proof of location for blockchain Proof-of-Stake node decentralization. To support my testing, I would like to run a series of measurements using the RIPE Atlas platform. If anyone has spare credits and would be willing to share, I’d greatly appreciate your support. Thank you in advance for your generosity. Best regards, Julien Piccaluga Mobile: +41 (0) 78 832 36 20 Envoyé avec un e-mail sécurisé [Proton Mail](https://proton.me/mail/home).

2 1

Request for RIPE Atlas Credits for Oceanic Connectivity Project
by Andrew 08 Jun '25

08 Jun '25

Him I’m Andrew and I'm currently working on a project aiming to test and analyze connectivity across the Atlantic and Pacific Oceans. The goal is to measure latency, reliability, and routing performance to better understand intercontinental connectivity and network behavior. To achieve a comprehensive perspective, we're planning extensive measurements using RIPE Atlas probes. However, we're limited by available credits. If anyone could provide RIPE Atlas credits to support this effort, it would be greatly appreciated. My RIPE NCC account email is: andrew(a)izongrp.com Thank you Andrew

4 5

eperd segaults on software probe?
by Alexander Bochmann 07 Jun '25

07 Jun '25

Hi, on this one software probe I run, I've noticed a bunch of segfaults in eperd between May 19 and May 21: > May 19 11:23:51 kernel: eperd[1705]: segfault at 0 ip 00007a7e28e95ace sp 00007ffdaa698030 error 4 in libc.so.6[7a7e28e45000+155000] likely on CPU 1 (core 1, socket 0) > May 19 13:23:50 kernel: eperd[2119167]: segfault at 0 ip 0000793ee0becace sp 00007ffc83ca3bd0 error 4 in libc.so.6[793ee0b9c000+155000] likely on CPU 1 (core 1, socket 0) > May 19 13:53:52 kernel: eperd[2168145]: segfault at 0 ip 000070f2b71ecace sp 00007fff868d06d0 error 4 in libc.so.6[70f2b719c000+155000] likely on CPU 1 (core 1, socket 0) > [..] > May 21 07:53:55 kernel: eperd[3181618]: segfault at 0 ip 00007dfe4bc95ace sp 00007fffeaf5b420 error 4 in libc.so.6[7dfe4bc45000+155000] likely on CPU 1 (core 1, socket 0) > May 21 08:54:03 kernel: eperd[3218383]: segfault at 0 ip 00007dba7970cace sp 00007fff1d145490 error 4 in libc.so.6[7dba796bc000+155000] likely on CPU 1 (core 1, socket 0) > May 21 09:24:04 kernel: eperd[3243867]: segfault at 0 ip 000076d0a8becace sp 00007fff2ffb2b20 error 4 in libc.so.6[76d0a8b9c000+155000] likely on CPU 1 (core 1, socket 0) Software probe version is 5110 on Debian 12. I haven't found anything similar before or after. Coredumps are not enabled on that system, and I don't notice anything unusual in the service logs (except that eperd has been restarted), so that's pretty much the information I have... Has anyone else seen something like that? Alex.

1 0

Best way to download bulk data older than a month?
by Vasileios Giotsas 02 Jun '25

02 Jun '25

I'm trying to download the RIPE Atlas traceroutes for a day that is older than one month. Given that the FTP repository publishes only results from the last month, I need to use the API. So, what I'm doing is to list of measurement IDs for a given data and then for each ID I do a GET for the results of that ID. The code is here: https://github.com/vgiotsas/RIPEAtlas_Queries/blob/main/download_atlas_trac… However, often some downloads time out and when I'm trying to resume it using the Range header it seems that the API doesn't support it and the download starts over until it fails again halfway through the download. Is there a better way to do such bulk downloads? Or at least to resume failed downloads? Thanks!

4 6

Anchor time sources
by Tim Chown 27 May '25

27 May '25

Hi, I assume the anchor nodes take their time via NTP and a general NTP pool? Have there been studies of time drift on anchors? Is there a way to configure a specific set of NTP sources? Thanks, Tim

3 2

Atlas reported uptime vs OS reported uptime
by Alexander Männel 26 May '25

26 May '25

Hi atlas folks, is there a way to get the operating system uptime of a probe? The reason I'm wondering is that I want to differentiate a shut down probe (i.e. power outage, operator reasons) from a disconnected probe (i.e. Internet connectivity lost). Depending on the goal of a measurement these two cases should be considered differently. The one way I think this is currently possible is to look for results that the probe has uploaded from its local buffer after it has regained network connectivity. In case of a disconnected probe, there will be measurement results during the outage but not if the probe was fully turned off. This approach is however a bit hacky and requires you to query the event log and align that with the measurement results. Depending on how often your measurement runs, you might have to query data from the built-ins as well. Of course you can always try to look at probes from the same region/AS and see if they faced outages, but this requires a lot of additional data to be queried and will not be 100% accurate. I understand that this probably is only relevant for a subset of all probes, but also collecting the uptime as tracked by the OS would be a simple fix to easily differenciate between different disconnect reasons. Regards, Alexander Männel -- Alexander Männel TU Dresden, Chair of Distributed and Networked Systems https://tu-dresden.de/cs/netd

1 0

Ripe Probes clock update
by Giovane C. M. Moura 12 May '25

12 May '25

Hi Atlas folks, I was wondering if there is an update on how Atlas probes sync their clocks from the article from 10 years ago[0]. * Anchors: `pool.ntp.org` * v1: fallback mechanism using HTTP * v2 : ntpclient (but which ntp servers?) * v3: opentpd (but which ntp servers)? What about newer probes version? v4? v5? vms? Thanks, /giovane [0] https://labs.ripe.net/author/philip_homburg/ntp-measurements-with-ripe-atla…

2 1

Atlas UI update - New Internet Maps
by Stephen Suess 01 May '25

01 May '25

Hello Atlas Community, We have just released an update to the UI that completely reworks the Internet Maps section: Root Name Server Instances & RTT to well-known destinations Performance: many times faster than previous maps Sharable URLs with all params Clickable legend tags to filter probe markers Probes on maps are searchable by ID, ASN, Country, IP, Prefix Time travel up to 30 days in the past You can find these maps here: https://atlas.ripe.net/maps/ Over the next couple of months we plan to bring many of the performance improvements of these maps to other areas of Atlas as well as refining and adding to the Internet Maps collection. And as always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

2 2

RIPE Atlas API rate limits
by Huseyn Gambarov 30 Apr '25

30 Apr '25

Hello. While looking for the rate limits defined for the RIPE Atlas API, I found the mail sent by Robert Kisteleki two years ago saying: > The measurement API in particular will impose a limit of 150 queries/second (if done over multiple connections) Can you tell me please, if the requests sent to the Streaming API are also considered in this limit? Thank you. Original mail: https://mailman.ripe.net/archives/list/ripe-atlas@ripe.net/thread/7K4JC7ZZN… With regards, Huseyn Gambarov Research Assistant PhD Student in Computer Science Case Western Reserve University

1 0

bulk-email.ripe.net
by Marco Moock 29 Apr '25

29 Apr '25

Hello! Some mails regarding RIPE atlas are being sent via bulk-email.ripe.net. Is there a reason RIPE uses that 3rd party (IPv4-only) service instead of its own infrastructure? -- Gruß Marco

8 12

Newbish DNS question
by Hank Nussbacher 29 Apr '25

29 Apr '25

Perhaps a newbie question: I am doing a DNS measurement and almost all probes return NXDOMAIN (expected), yet one probe returns NOERROR. How can I determine which DNS server it is using to provide a NOERROR? See attached json. Thanks, Hank

4 3

Atlas credits fallen way below zero
by Seth David Schoen 23 Apr '25

23 Apr '25

Hi, I created some rather large measurements a few months ago. I got a notice at some point that I was going to run out of credits and that the measurements would be stopped -- something which has happened to me before. Somehow, it looks like the measurements didn't stop (or maybe did stop and were then resumed), and my account balance has gone very significantly negative before I got around to checking what was going on. I keep getting e-mail notifications warning me that my balance is nearly exhausted, but these notifications (correctly?) state that my balance is already negative, and will run out a negative amount of time into the future. Can I assume this is a backend bug, where some part of the logic for credit exhaustion wrongly assumes that one's balance is currently positive, and then never triggers after it somehow becomes negative? My dashboard page somewhat comically states Daily credit spending currently (approximately) / your limit: 7160665 / 1000000 Daily measurement result flow (approximately) / your limit: 721024 / 100000 I didn't mean to "overdraw" the system or use resources without contributing resources back; I just didn't realize the cost of some particular measurements, and had previously seen that measurements that one's account couldn't afford would in fact be terminated. Can I "declare bankruptcy" and get my balance reset to zero? And can someone take a look at the credit logic to understand how this credit overdraft phenomenon can come about? Thanks!

2 1

Atlas Account Disabled
by cassianoaquino＠me.com 22 Apr '25

22 Apr '25

Hi, I was trying to login to my atlas ripe account and forgot I had multiple authenticators configured and kept trying with the wrong one which gave me an error about the account being disabled to contact "your administrator". Now when I try to login it says "Invalid email address or password". Is there someone who can help me or point me on how to contact "your administrator"? The atlas login email is the same I use here on the mailing list. Thanks in advance!

1 0

how to delete a never used software probe
by Hans Mayer 17 Apr '25

17 Apr '25

Dear All, by a mistake I submitted the wrong SSH key during the installation of a software probe. Therefore I have now in my list of probes a second probe ID which is hidden and was never connected. Querying the Internet tells me Click on your probe and Click the "Write off your probe" function on the probe's detailed information page But when I do so I see an almost empty screen with the probe ID and "This probe was Never Connected" and nothing else. Any help is welcome. Kind regards Hans --

2 2

Decreasing number of probes
by Felix Hoffmann 09 Apr '25

09 Apr '25

Hey, I am currently running multiple scheduled measurements (ids: 85023653, 85023729, 85023782, 85023852). In the wizard, I selected the probes by area with the following settings: WW, 1000 probes. At the beginning of the measurements, mostly all probes reported, but meanwhile the number of probes reporting has decreased constantly. Is there an option to rotate the probes regularly to ensure a certain amount of active probes? Best regards, Felix Hoffmann

5 5

Atlas software probe on FreeBSD
by Marco Moock 09 Apr '25

09 Apr '25

Hello! Are there any people who have the RIPE Atlas software probe daemon running on FreeBSD? I have a virtual machine that could host a probe, although I haven't found any info if the daemon runs there. -- kind regards Marco Send unsolicited bulk mail to 1744132937muell(a)stinkedores.dorfdsl.de

2 1

Monthly probe reports for March 2025 missing?
by ripe＠nurfuerspam.de 07 Apr '25

07 Apr '25

Hi, I don't recall having seen the monthly probe report for March 2025, and also cannot find anything when explicitly looking for them. Did anyone else get the probe report for March 2025? In the past, they usually came in the very early hours of the first day of the month. Thanks! Kind regards, R.

2 2

RIPE Atlas Anchor Certificate Change
by Robert Kisteleki 07 Apr '25

07 Apr '25

Dear colleagues, We will be carrying out planned maintenance on RIPE Atlas anchors to replace the existing Lets Encrypt certificates with self-signed ones. There is no action needed by anchor hosts. The only visible change for users - should they want to visit an anchor URL using their browser - will be the standard notification asking them whether they trust the certificate before proceeding. This change is not expected to have a significant impact on functionality as the HTTPS service on RIPE Atlas anchors is not intended to be accessed by regular users in browsers but from measurements and scripts. Kind regards, Robert Kisteleki

1 0

Software Probe version 5110 released
by Trix Taiclet 02 Apr '25

02 Apr '25

Dear colleagues, We have released a new version of the RIPE Atlas Software Probe, version 5110. This 5110 release contains the following changes: * Added support for Raspberry Pi OS 12 (added Debian 12 arm64 package) * Rewrote GitHub README and BUILD instructions * Display Probe registration instructions during installation for RHEL and Debian * Generate Probe keys after installation without requiring service startup * Using the signing key introduced in 5100 to sign RHEL packages. The current RHEL key is deprecated as of this release. * Fixed compilation error by adding a missing include to telnetd.c (authored by César de Tassis Filho <ctassisf(a)gmail.com>) * Hardened the security of the RIPE Atlas service unit (reported by Marek Küthe <m.k(a)mk16.de>) * Added missing requirement for procps-ng on RHEL9 to RHEL probe package specfile (authored by Robert Scheck <robert-scheck(a)users.noreply.github.com>) * Document runtime options for custom TCP ports (authored by AtlasMUC <AtlasMUC(a)mail.de>) * Fixed typo in GitHub org url for RHEL ripe-atlas-anchor specfile (authored by Pouria Mousavizadeh Tehrani <info(a)spmzt.net>) * Fixed typo in GitHub org url for RHEL ripe-atlas-probe specfile (authored by eeple <m.renusson(a)gmail.com>) This release does not contain any functional changes to the measurement code. You can find more information and instructions on the GitHub repository: https://github.com/RIPE-NCC/ripe-atlas-software-probe/ You might have seen this release before our announcement; we faced an issue with the arm64 repo package, which caused us to delay that specific package and our announcement. Please let us know if you find any issues with this release. Regards, Trix Taiclet & Marios Mavropoulos RIPE NCC

1 0

How to set a probe non-public?
by Robby van de Meulenhof 01 Apr '25

01 Apr '25

Hello, At the moment i have 3 probes. 1 of the 3 probes i would like set non-public. With the new detail page i can't change the Shared Publicy (no checkbox like the old design) I switch to /Legacy Probe Detail/ i can *uncheck Shared Publicy* when i save it a get an error "You cannot make a public probe non-public." I can'tt find how i set a probe to non-public. How i do that? Regards, Robby

2 3

API-Key grants: There were problems with your request
by Bjoern Franke 01 Apr '25

01 Apr '25

Hi, I created a new API key and tried to set some measurements permissions. Yesterday evening and also now I'm only getting "There were problems with your request" and no grants are set. Regards Bjoern

1 0

Missing data in connection and uptime history for probe
by Anton Bobov 21 Mar '25

21 Mar '25

Hello! I am experiencing an issue with incorrect uptime and connection history for my probe (ID: 1006959 https://atlas.ripe.net/probes/1006959/network) I am currently running a software probe on Rocky Linux 8.10, with the probe version 5100. There was a power outage between 2025-03-14 04:25 and 2025-03-14 05:25 (UTC), which seems to have affected the data. I downloaded the connection history for the specified period, and it shows the following entries: seq timestamp (UTC) event stored_timestamp (UTC) ---------------------------------------------------------------------- 1 2025-02-08 23:13:51 disconnect 2025-02-08 23:13:51 2 2025-02-08 23:17:18 connect 2025-02-08 23:17:18 3 2025-03-14 04:25:35 disconnect 2025-03-14 04:25:36 4 2025-03-14 05:25:06 connect 2025-03-14 05:25:06 5 2025-03-14 06:49:19 disconnect 2025-03-14 06:49:19 6 2025-03-14 06:52:46 connect 2025-03-14 06:52:47 7 2025-03-15 22:36:49 disconnect 2025-03-15 22:36:50 8 2025-03-15 22:39:17 connect 2025-03-15 22:39:17 However, entries [2] to [7] are missing from the connection history, and only [1] (last disconnect) and [8] (last connect) are displayed. Additionally, this period is also missing from the uptime history. Could this be a bug, or is there another explanation for this issue? -- Cheers, Anton

2 4

Unable to remove probe's Description
by ripe＠brite.cz 20 Mar '25

20 Mar '25

Hi team, I wanted to remove the Description, before I make new one. When click Edit button, delete the description and click Save, I get "Failed to update probe info". Only if I enter any valid character then it saves fine. I would suggest to allow empty string to be saved as well, since sometimes you just want to remove the description instead of writing a new one. Cheers from Czechia Jiri

1 0

purpose of *untagged* status
by ripe.net＠toppas.net 06 Mar '25

06 Mar '25

Hi everyone, can anyone explain to me the reason of system tags not being set (for long time)? There are system tags for every case, but there's also the case, that no tag is being set. For example: ipv6-works check (three possible cases): 1. tagged: system-ipv6-works 2. tagged: system-ipv6-doesnt-work 3. untagged (none of the above tags is set) I don't see the purpose of the untagged status. Either IPv6 / IPv4 works, or not. What is the completely untagged status supposed to tell me? The same applies to DNS checks. There's a tag for every case, plus the "no-tag status": DNS resolving check: 1. tagged: system-resolves-a-correctly 2. tagged: system-resolves-a-incorrectly 3. tagged: system-doesnt-resolve-a 4. untagged (none of the above tags is set) I would like to know the condition, how the controllers (?) decide this. Or in other terms: if a system tag is removed (untagged) shouldn't this implicate, that the opposite system tag has to be applied immediately? This is not a matter of a short time period, completely untagged probes do exist for long time periods. Thanks & best regards, Simon

3 3