- ripe-atlas - mailman.ripe.net

Anchoring measurements from 7106 appear to be affected by a local proxy
by William Kanieski 28 Aug '25

28 Aug '25

Hi, all. I am a computer networks PhD student analyzing RIPE anchoring measurements for research purposes. While I was looking at traceroutes originating from specific anchors, I noticed that all traceroutes from Anchor #7106 only contained one hop, with no silent hops present. Upon further inspection, these singleton hops were actually the destination IP addresses themselves, and they had extremely short (<1ms) RTTs from 7106 even when they were supposed to be located on the other side of the globe. On the other hand, ping and traceroute measurements directed *toward* 7106 all seemed normal, with regular hop counts and RTTs that seemed to agree with reported geographical distance. I strongly suspect that 7106 is connected to a local proxy that is responding to outgoing ping and traceroute traffic on behalf of its intended destinations. As such, I wanted to bring some attention to this anchor so that other researchers might be aware of its status before trying to use it to conduct measurements. Regards, William Kanieski

3 3

Any problems with the registration servers?
by Tore Anderson 25 Aug '25

25 Aug '25

I have recently have had three probes «die» on me in ways the hardware actually seems fine, but the problem is with connectivity with the Atlas infrastructure. I am therefore starting to wonder if my probes were all OK after all, and that the problems are with the Atlas registration servers or infrastructure in general. Here's the timeline: First problem was with V1 probe #138 back in January. It reported through SOS messages that it could not connect on HTTPS, error code «firewall issues suspected» or something like that. However, observing the network traffic in/out of the probe revealed that the probe did successfully establish a TCP three-way handshake with reg01/reg02.atlas.ripe.net, only to immediately close the connection with a FIN packet, without actually sending any payload. There was no firewall blocking any traffic. RIPE NCC support essentially shrugged and said V1 probes aren't really supported nowadays, so I gave up and recycled the probe. Second problem was with another V1 probe (#433), in May. That one was left disconnected for an extended period of time, transitioning to "abandoned" status. As it did not reconnect after I fixed the network, I proceeded to write it off and re-connect it, then re-registered it with my personal account. It too connected fine with the network, and the event log showed a «Registration» event every time I power-cycled the probe, but it never went further and the status was stuck at «No Controller Connection». The written off status never cleared. RIPE NCC support could confirm that the written off status should have cleared after reconnection, but otherwise weren't able to help, so this probe went in the bin as well. Third problem is with a V3 probe (#10667), ongoing as I write this. It was working perfectly fine up until last week, when I moved it from a data centre to my home network. The probe had static IP configuration in the data centre, and with no way of configuring it to back to using DHCP, I thought I'd just re-install firmware by booting it up without the USB in and plugging it back in after a while. It connected fine and reported «NO-USB» SOS messages, and after plugging in the USB stick «Registration» events with the hardware details of the USB stick appeared (curiously enough, most of these events report an IP of 172.17.0.1). At that point the process gets stuck, the «Registration» events with the USB stick details keep repeating approx. every 65 minutes, and there's a warning banner at the top of the page «Flash Drive Filesystem Corrupted». So I have re-tried this with several different USB sticks, all from reputable brands, and all passing whole-device read/write tests to identify bad blocks when connected to my laptop. I have also tried replacing the power supply – nothing helps, it always ends up in the same «Registration» loop. During the process, a partition table with three 1 GiB large partitions is created on the USB stick, containing data/filesystems that my Linux laptop does not recognise as anything familiar. I could be persuaded that the two V1 probes did indeed have hardware problems. However the V3 probe clearly does not, at least not with its USB stick, and since its failure mode is rather similar to how #433 failed (process getting stuck after «Registration» events), I am starting to wonder if at least #433 was fine all along. Anyway, i am curious to hear if it is just me being very unlucky with my probes this year or if anyone else have had similar problems recently? Another issue, probably unrelated but I thought I'd mention it anyway, is that when I try to change the ownership of the V3 probe to my personal account, the web page just displays a red pop-up with the unhelpful message «An error occurred», and the ownership change does not happen. Tore

1 0

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