- 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