- ripe-atlas - mailman.ripe.net

Re: v3 probe stuck with BADMD-APP
by Marek Zarychta 25 Nov '25

25 Nov '25

Hello, I have had recently the same problem like Radu described. The probe wasn't connecting with this message since 2025-11-07 09:45:52, so I have taken this probe to different ASN, but it didn't help. Today, after configuring the DNS servers in the original ASN to respond to queries coming from the probe’s temporary network, the probe was finally able to reconnect. It looks like the issue with DNS setting was a problem here. The probe was initially set to use static IP and IPv6 addresses. After changing a few weeks ago to dynamic ones it's still stuck with old DNS server settings. It's really hard to fix the USB issue with the probe using static addresses. The only working way was taking it to the network with working DHCP and/or IPv6 auto-configuration including RDNSS, plugging it without USB, waiting several minutes, plugging USB stick, waiting till it reboots, disconnecting from the network, and connecting back to the network for which static addresses were configured. Of course, if there were DHCP or RDNSS working in the original network, the troubleshooting would be far easier. Anyway, I have two requests for the RIPE Atlas operations team: - please ensure that DNS settings automatically switch to dynamic when changing a probe’s addressing mode from static to dynamic, - please allow users to change a probe’s addressing mode from static to dynamic even when the probe is currently offline. Cheers -- Marek Zarychta

2 1

Atlas UI update 2025-11-24
by Stephen Suess 24 Nov '25

24 Nov '25

Hello Atlas community, We have just released an update to the Atlas frontend, with new features, changes and fixes. Here are some of them: NEW: Member resources dashboard card and use case - We have a new feature for members, both as a dashboard card and a use case (https://atlas.ripe.net/use-cases/member-resources) Members will be able to see Atlas probes and anchors within their LIRs' prefixes, see measurements that are targeting those prefixes, and link to these objects. NEW: Probe detail results: traceroute comparison component - We have been working on a component for comparing traceroutes over time, and the first place we are rolling it out for testing is on the results tab of the probe detail page (for example: https://atlas.ripe.net/probes/1/results) When you click on a point and show traceroutes, this component will pull 12 hours of traceroutes on either side of that point and show a timeline of significant changes for comparison. NEW: Probe detail results: download data (csv/json) - On the same probe results tab, you now have a menu in the graph allowing you to download the data in csv or json format. NEW: Probe detail overview: show recently stopped measurements - You will now see a button in the probe detail overview not only for measurements currently running on the probe, but also for recently stopped measurements. In addition to the new items above, there are numerous changes and fixes present. For the full list, please see the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-11-24 We would love to know what you think. Please let us know if you have any questions, comments, or encounter any issues with this update or elsewhere in Atlas. Kind regards, Stephen Atlas UI

1 0

v2 probe repair?
by Phillip Remaker 24 Nov '25

24 Nov '25

Hello! I have an 11+ year old v2 probe Seems to be in a reboot loop. Starts up, all LEDs go blank, and it repeats. Any diagnostics I can do? Any repairs? https://atlas.ripe.net/probes/4111/#tab-network

4 7

v3 probe stuck with BADMD-APP
by Radu Anghel 11 Nov '25

11 Nov '25

hi, one of the v3 probes i spread around the universe that is 12+ years old just had another USB stick die after a power failure. i have tried reviving it by replacing the stick (tried at least 3 different ones), but for some reason it does not work as when i previously replaced it. i also tried different partitioning on the 16/32gb sticks: one single partition fat32/ntfs/ext4, no partitions at all. the probe does not format the new stick or do anything with it except reporting it to the controller, i see "registrations" in the event log with info about the USB that is plugged in. after that it just keeps repeating the BADMD-APP SOS DNS query. no blinky light on the stick to show activity. tried leaving it for more than 8h with the new stick, tried plugging in the stick 10+ minutes after probe booted, tried booting with the fresh stick plugged in. no changes in behaviour. also replaced the power source/cable, that did not help either. is there anything else i can try to revive it? thanks!

3 2

A system tag for DNS resolution of "other types"?
by Stephane Bortzmeyer 11 Nov '25

11 Nov '25

I see a probe (31874) which can resolve A and AAAA (and has system tags for that) but always SERVFAIL for TXT records. % blaeu-resolve --probes 31874 --type TXT ietf.org [ERROR: SERVFAIL] : 1 occurrences Test #136741617 done at 2025-11-08T16:31:22Z % blaeu-resolve --probes 31874 --type A ietf.org [104.16.44.99 104.16.45.99] : 1 occurrences Test #136741646 done at 2025-11-08T16:31:36Z (You can check with other domains such as ripe.net.) Suggestion: a system tag "Resolves TXT".

2 1

Yeh, my v5 probe birthday
by Colin Johnston 10 Nov '25

10 Nov '25

Sent from my iPhone

1 0

IXP Country jedi seems to be down
by Vasileios Giotsas 07 Nov '25

07 Nov '25

Hi all, It seems that the data endpoints for the IXP Country jedi website are down. The website itself (https://jedi.ripe.net<https://jedi.ripe.net/latest/AT/geopath/index.html>) is loading, but none of the graphs are loading, e.g. the https://jedi.ripe.net/latest/AT/geopath/geopath.v4.json is returning 404 (and all other json data paths) so the plots aren't loading. Just thought to bring it to your attention because these data are very useful. Best, Vasilis Giotsas

3 2

Obsolete builtin measurements
by Ernst J. Oud 07 Nov '25

07 Nov '25

2 2

BIG Atlas UI update for 2025-11-06
by Stephen Suess 06 Nov '25

06 Nov '25

Hello Atlas friends, We have just released a pretty big update to the Atlas frontend, with lots of new features. Here are some of them: Probe Connectivity use case - Visualise Internet connectivity by analyzing RIPE Atlas probe connection states over time. This tool helps identify potential outages and connectivity issues across different networks and regions. Here is an example link showing a power outage in Chile earlier in the year: https://atlas.ripe.net/use-cases/probe-connectivity/?method=country&start=1… Khipu: export image and data - There is now an export button in the toolbar allowing you to export Khipu visualisations as pngs, and menu items for exporting your filtered or full measurement data source in either json or csv formats Khipu: multi term path filter - You can now use multiple terms in the path filter to further refine your path selection Khipu: country filter improvements - You can now filter by continent, search for a country, or invert your country selection Clone a measurement (from detail and listing pages) - You can now clone existing measurements (that are stopped and not system tagged) by clicking on a clone icon in the measurements listing page or next to the heading on any valid measurement detail page. This will open a new measurement form with all settings filled in except for timing. Measurement Form: duplicate definition - Within the measurement form itself, you can now duplicate a measurement definition to help copy similar configurations. Recheck DNS option (in measurement form and measurement detail manage tab) - This setting (on by default for periodic measurements that don't resolve on probe and are targeting a domain) will recheck the domain resolution every 24 hours and update the measurement. For the full list of what is new, has changed or been fixed, please see the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-11-06 We welcome your feedback, please let us know if you have any questions, comments, or encounter any issues in the new update. Kind regards, Stephen Atlas UI

1 0

khipu view "enhancements"
by Hendrik Visage 31 Oct '25

31 Oct '25

Good day, reference https://atlas.ripe.net/khipu/134895113/ip I’d love to have the following to make it useful for my case: - Ignore “unsuccessful” not reaching the target In these case I do expect some connectivity issues, and those I’d like to look in, but I want to focus on the main issue in this case is RTT anomalies and routing issues so do want to ignire those. - focus on specific intermediate/IXP hops Ie. want to select some hops and have the radials around them only

2 3

soft probe sending out UDP frames
by Hans Mayer 30 Oct '25

30 Oct '25

Dear All, month ago I installed a soft probe. I have running ripe-atlas-common 5110, ripe-atlas-probe 5110, ripe-atlas-repo 1.5-3 on Debian 12 bookworm. These days I realised something where I need some explaination. When I look at the types of measurements then I would expect a certain amount of services that can go out. Like ping, traceroute, dns, tls, http and ntp. Now I saw that the probe sends out to about 89 different IP addresses ( IPv4 as well IPv6 ) UDP frames. I looked for a period of about a day. Each destination is probed with a specific port number. And this again and again all over the time. So each combination of destination IP and destination port is unique. The ports are high ports above 32k and as far as I can see there is never a reply. (Probably not necessary for UDP) There are a little bit more than 60 frames per hour. That's about 1 UDP frame per minute. Not to say, if I switch off the ripe-atlas.service this phenomena doesn't happen. Is there any explanation for this behaviour ? I can only imagine that these destinations are monitoring servers from ripe and my soft probe says: "hello, I am still alive ! ". ( I didn't dig into the UDP frame itself) Kind regards Hans -- The destination IP's are well distributed around the world.

2 2

Software Probe version 5120 released
by Trix Taiclet 29 Oct '25

29 Oct '25

Dear colleagues, We have released a new version of the RIPE Atlas Software Probe, version 5120. This 5120 release contains the following main changes: * Add support for Debian 13 (#129) * Add support for Enterprise Linux 10 (#129) * Measurement code * Add local timestamp to HTTP POST header * Add local clock value to SOS message * Set Atlas-specific ref-id in NTP packets (authored by Joachim Kross #132) * `NTP_4G` instead of `4294967296.0` (authored by Marco Davids #131) * Fix NTP offset calculations (reported by Marco Davids and Giovane Moura #130) * Other * Improve OpenWrt support with documentation fixes and and reduced dependencies (hostname) * Add missing dependencies to Debian package files (libcap2-bin, ca-certificates) * Improve repo package building (rules.mk/.spec file) for clarity and Git tag support * Fix typo in GitHub org url for RHEL ripe-atlas-repo specfile * Fix casing of OpenWrt (authored by Goetz Goerisch #128) * Internal CI changes * Signed commit (bdf1b93) using production GPG key The full release notes are available on the docs: https://atlas.ripe.net/docs/releases/firmware_index/5120 Please note that this release only applies to software probes, an update will be released for hardware probes once OpenWrt consolidation work is complete. You can find more information and instructions on the GitHub repository: https://github.com/RIPE-NCC/ripe-atlas-software-probe/ https://github.com/RIPE-NCC/ripe-atlas-software-probe/releases/tag/5120 Please let us know if you find any issues with this release. Regards, Trix Taiclet & Marios Mavropoulos RIPE NCC

1 0

Probe Reactivation?
by Cornelius Keck 29 Oct '25

29 Oct '25

My first-generation probe (1198) has been down for 2 or so years. Managed to get it going again inasmuch it pings the outside world. Current status at https://atlas.ripe.net/probes/1198/overview shows it to be abandoned, though it does SOS-ping. What could be done to change its state to active? Thx! -Cornelius

4 4

Fwd: Updated RIPE Atlas Terms & Conditions
by Karolina Bochenek 19 Oct '25

19 Oct '25

Dear Sulev-Madis, all, We amended the terms and conditions in line with applicable legal GDPR requirements and intellectual property law. Under GDPR, personal data cannot be processed without a legal basis, which in the case of RIPE Atlas, would be the individual’s consent. Also, a trade name may not be used without permission from its legitimate owner. To clarify, if consent or permission is granted, RIPE Atlas probe hosts may use personal data or trade names. Regions and cities that do not reveal the identification of individuals are also not personal data and can be used. Best regards, Karolina Bochenek RIPE NCC

8 15

tracemon from old measurement
by Randy Bush 09 Oct '25

09 Oct '25

for a preso, i want a tracemon from an old measurement, 70370611. i am logged in. i go to https://atlas.ripe.net/measurements/70370611/overview i see no tracemon or even khipu option. what am i not understanding this time? randy

4 7

Erroneous data in measurement 7000
by Filip Dobrev 07 Oct '25

07 Oct '25

Dear RIPE Team, I am a Master's student at TU Delft, currently working on a tool that uses RIPE data to reliably detect network outages. While analyzing the measurements, I noticed what appears to be incorrect data being reported. In particular, when counting the number of disconnected probes per country, I observed that many countries show a major outage on 23 April 2025, where nearly all probes were marked as disconnected for about an hour and a half before recovering. For example, in Spain (ES): 2024-09-10 12:58:10 UTC – 16:37:15 UTC (Duration: 3:39:05, Peak offline probes: 154) Happened across many(40+) countries 2024-09-17 10:37:04 UTC – 12:50:56 UTC (Duration: 2:13:52, Peak offline probes: 129) Happened across many(40+) countries 2025-04-23 09:39:27 UTC – 11:11:59 UTC (Duration: 1:32:32, Peak offline probes: 210) Happened across many(90+) countries The timing and duration of the April 23 outage are consistent across many countries. I’ve compiled more examples and raw data in this editable online notepad https://shrib.com/#Asa3ZLP3Xe. It seems that a large portion of probes were marked as disconnected, even though the raw measurement data indicates they were still actively sending and receiving information. It is important to note that such errors can be observed at other times for short periods of less than a minute - 20-05-2025, again across many countries. I would greatly appreciate your clarification on a few points: 1. What could explain this discrepancy? Is it a measurement issue or something related to RIPE’s internal systems? 1. Are all measurements potentially affected by this? For example, measurement 10310, during an outage in NMK on May 18, some probes showed no responses for a 30-minute window(possibly still timing out). Similarly, during the outage in Portugal on April 28, several probes had no data for multiple hours. 1. How trustworthy are the results from the measurements? 1. How long does it typically take for RIPE to detect and reflect a disconnected probe (or other events) in the API? 1. Different requests to root measurements take the same time, even though one is requesting 30 minutes and another is requesting 4 minutes of data. Is the overhead on Ripe's side the reason for this? Looking forward to your response! Best regards, Filip Dobrev

4 3

Fwd: Updated RIPE Atlas Terms & Conditions
by Ernst J. Oud 03 Oct '25

03 Oct '25

3 3

Atlas UI updates 2025-09-26
by Stephen Suess 26 Sep '25

26 Sep '25

Hello Atlas friends, We have just released an update to the UI that includes (among other items): - NEW: Measurement form: auto-top-up settings - NEW: Measurement details manage tab: auto-top-up settings and manual top-up (when possible) - CHANGES: Khipu (beta): Horizontal layout mode, much improved RTT mode with anomaly notes, country filter dropdown, country view lookup/scoring, IP labels in IP view For the full list of what has changed, please see the release notes here: https://atlas.ripe.net/docs/releases/website_index/2025-09-26 Please let us know what you think! Kind regards, Stephen Atlas UI

1 0

FreeBSD/MacOS probe
by Jared Mauch 22 Sep '25

22 Sep '25

I’m looking for people to test out my attempted FreeBSD/MacOS changes to shift a few calls to POSIX compliant and other tweaks to make it build on other operating systems. You can try to build from this git repo: https://github.com/jaredmauch/ripe-atlas-software-probe I would request comments go here: https://github.com/RIPE-NCC/ripe-atlas-software-probe/pull/135 Or possibly in this issue which originated from someone else, but the recent note from Randy had me look at the codebase. https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/123 Hopefully this is useful and might be able to be merged back in, but I know this may cause some troubles due to the busy box parent as well. - Jared

7 29

Debian trixie support for s/w probes?
by Andrew Elwell 16 Sep '25

16 Sep '25

Hi folks, Is there a plan to support debian stable 'soon' for the software probes? I know I could build from the git repo, but I'm lazy and would rather apt-get install it, but https://ftp.ripe.net/ripe/atlas/software-probe/debian/dists/ only has bullseye & bookworm. Hat tip to all involved tho, #1009903 seems to be chugging along happily (well, except that the hypervisor's due for an update & reboot shortly) Andrew

3 2

Atlas UI, Khipu and docs updates
by Stephen Suess 15 Sep '25

15 Sep '25

Hi All, Since the last update on 2 September, we have updated the Atlas UI 3 times (including today). Among the highlights: - Khipu visualisation -- Country view -- DNS multi target view -- Smart popup placement -- Improved path filter -- Docs: https://atlas.ripe.net/docs/tools-and-code/khipu - DomainMON improved error messaging - LatencyMON url param fixes - Legal accordion new sections - Clarify member benefits in the Use Cases menu You can see all the recent changes here: https://atlas.ripe.net/docs/releases/website_index/ And as always we welcome any and all feedback and suggestions. Kind regards, Stephen RIPE Atlas UI

1 0

Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
by Lukas Tribus 15 Sep '25

15 Sep '25

Hello, currently notifications are configurable for the event when a probe is disconnected; however when a probes remains connected but stops working (loosing or no having either system-ipv4-works and system-ipv6-works tags), we are blind. I have written a monitor script to query the API for this, to get this notification but I'm wondering if it would be possible to implement this at RIPE. The system-<AF>-works tags are already there. Software bugs and I guess HW issues can trigger hung probes that remain connected. It's hard to find out, unless one is specifically looking for it or specifically expecting the result of a single probe in a measurement. Lukas

15 29

tracemon false join
by Randy Bush 13 Sep '25

13 Sep '25

looking at TraceMON (for 128292864), it appears as if the traces for a bunch of sources converge at a common node before failing. but they do not. they fail at different points as one can see if one looks at the result details or at khipu. what am i misunderstanding here? this is very misleading to a novice. i see one madly clicking at the apparent point of failure desperately wanting its ip address. of course, i would never make that mistake :) randy

1 0

traffic graph
by Hans Mayer 05 Sep '25

05 Sep '25

Dear All, Based on the conversation about traffic here some days ago I took a look into my statistics. I looked at the dashboard from RIPE Atlas and I looked at netflow from the router for my probe. Both from the last 24 hours. This is the dashboard and this comes from netflow it is summarised for IPv4 in and out and IPv6 in and out. Not to be confused netflow shows bits and the dashboard bytes. There is another difference, netflow has 10 minutes intervals and it seem the dashboard has 3 minutes. But independent of that, the graphs should have some similarities. I am not worried about that because the traffic is below any perception. But is there any explanation ? It becomes funny when I switch to "Last Week" All the traffic is below the 0 KB line. Maybe it should be 10 KB and the "1" is not visible for some reason. Kind regards Hans

2 1

Suggestion to change "next" field in the result of a probes REST API query
by Shane Kerr 05 Sep '25

05 Sep '25

Hello, The REST API query to get probes is documented here: https://atlas.ripe.net/docs/apis/rest-api-reference/probes If you do a lookup which would return too many results, it sets the "next" field in the return, like this: -------------------------------------------------------------------- { "count": 55125, "next": "https://atlas.ripe.net/api/v2/probes/?page=2", "previous": null, ... -------------------------------------------------------------------- The idea is the REST API client will then make a call to the "next" URL and get the next batch of data; this is basic paging. There is no kind of transaction or anything, so the status of the probes can change between each call. This is fine since the status of the probes changes independently and you cannot count on their status really. One problem is that using "page" for this means it is possible to get the same probe twice. For example, if you are looking for "Connected" probes, and returning the probes in order of probe ID, and a probe that you have already returned becomes "Connected", then the answers will all shift up by one, and you will see the last probe twice. This can be avoided by instead of using "page" for the "next" field using whatever the sorting is for the returned values in the query. I think by default this is probe ID, so the "next" field could be: -------------------------------------------------------------------- { "count": 55125, "next": "https://atlas.ripe.net/api/v2/probes/?id__gt=101", "previous": null, ... -------------------------------------------------------------------- I suspect this would be faster on the back-end too. I ended up doing this logic on the client side and it works fine, although that is for a specific sorting order. It would be more complicated to do this for all orderings on the server side. Cheers, -- Shane

2 1

Possibility to specify a POST payload?
by Lars Eggert 04 Sep '25

04 Sep '25

Hi, (Please let me know if there is a better way to make feature requests.) It would be great if it was possible to specify a payload for an HTTP POST when putting together an experiment. Thanks, Lars

5 8

Non-Profit Arts Organization Seeking Credit Donations
by ADCIBC Tech Support 03 Sep '25

03 Sep '25

Hello All, My name is Ari Broad and I am the IT Director for a non-profit arts organization called The American Dance Competition, Inc. (www.adcibc.com) We have expanded our organization internationally and I need to do performance checks on the website in various countries abroad to ensure the site is working for international users as we recently found out our site is blocked in Mainland China, so I am doing my due diligence with other countries where we are touring. I have created a python script that will do this checking process for us (versus doing it manually through online tools which is time-consuming) that utilizes RIPE-Atlas, but it will not work because I have 0 credits on my account. I see that you have to contribute to the probes in order to get credits, I would love to contribute for science, but I do not have a desktop I could host this on. I reached out to RIPE-Atlas help and they suggested I reach out to this mailing list to ask for credit donations. *Here is a list of the tests I am attempting to run:*In these countries: JP,ES,DE,SE,DK,CH,GB,IT,CA,FR,NL,PL Run measurements on 3 ASNs per country. That's *36 site performance measurements. * I am not sure what the credit currency exchange is like, but if we could get enough credits to run these tests that'd be great. *But truly any amount of credits will help!* *If you have any amount of credits you would like to donate to us for our international site performance checks please send them to the recipient: adcibc.tech(a)gmail.com <adcibc.tech(a)gmail.com> * Thank you in advance for any donations we may receive. Best, *Ari Broad, M.S.* *(she/her)* IT Director ADC|IBC www.adcibc.com

4 3

Re: Notification on removal of system-ipv4-works && system-ipv6-works tags while connected
by Antony Gollan 03 Sep '25

03 Sep '25

Hello all, We use Brevo to send these emails primarily because it ensures deliverability and allows people to easily unsubscribe. This is important because big email providers have recently increased their penalties for potential spam, so we track bounces and unsubscribes to make sure the RIPE NCC stays within acceptable limits. It is not possible for us to turn off the tracking pixel in Brevo on our end, but we use it only to view the status of delivery, opens and unsubscribes. We are aware this tracking is not 100% accurate, but it gives us a general view of whether emails are reaching their recipients, which helps us to stay below the spam threshold. If you’d rather get a plaintext version of these emails from Brevo, some email clients provide an option to switch to the plaintext view. This will also block the tracking pixel. Regards, Antony Gollan Communications Team Manager RIPE NCC

2 1

Massive uptick in number of flows to/from probe
by Jenisch Ewald 03 Sep '25

03 Sep '25

Hi, Maybe coincidence with the update of the UI rolled out today, but we've seen a massive uptick in the number of flows going out from our probe up to a range of 120k flows/sec starting around 15:00 local time (CEST) Anybody else experiencing the same thing? Any ideas as to what's going on here? Thanks in advance for any clue, -ewald eingeschränkt/restricted

5 6

Atlas UI update 2025-09-02
by Stephen Suess 02 Sep '25

02 Sep '25

Hello Atlas friends, We just released a rather significant update to the UI that includes the following new features (in addition to other changes and fixes): - NEW: Khipu visualisation (beta) - NEW: Use Cases: Path Analysis (Khipu - beta) and Reachability Testing (QuickLook - beta) - NEW: Probe detail pages results tab: Timed out measurements display - NEW: Measurements advanced search: number of probes - NEW: Measurement detail pages: show destination IPs if target is domain and resolved on probe 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-09-02 As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

New RIPE Atlas Traceroute Visualisation Tool
by Stephen Suess 29 Aug '25

29 Aug '25

Hello Atlas friends, Recently we have been working on a new traceroute visualisation tool, and although we are still in early development, we wanted to release this version to the community to solicit feedback and opinions about it. This will help us focus on the items that are most important to the community as we work to finish it. You can test out this new visualisation on our beta-ui site <https://beta-ui.atlas.ripe.net/>, from any traceroute measurement detail page. Just look for the "TRACEVIS" link at the top of the page and click to access it. There is a labs article that describes the tool in some detail: https://labs.ripe.net/author/stephen_suess_1/new-prototype-ripe-atlas-trace… As always, we hope you find these features useful and we encourage your feedback. Kind regards, Stephen RIPE Atlas UI

3 6

Comparison of HW and SW Probes
by Richter, Robert 28 Aug '25

28 Aug '25

Hello everybody! Currently, I am investigating the possibilities of measurements using RIPE Atlas. Is there information about differences in the measurement results of HW and SW probes? My advisor said that I should rather not use SW probes, but I am not sure what the actual difference is, especially as SW probes often run on better hardware, compared to the HW probes. Could you point me to some resources on that topic? Best regards, Robert

8 7

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