October 2025 - ripe-atlas - mailman.ripe.net

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