- ripe-atlas - mailman.ripe.net

Software Probe version 5130 released
by Trix Taiclet 14 Aug '26

14 Aug '26

Dear colleagues, We're happy to announce the release of the RIPE Atlas Software Probe, version 5130. This 5130 release contains the following main changes: - Fix NTP measurement offset (GH-130), a regression from the 5120 fix: it reported half the round-trip time instead of the clock offset - Move to new registration servers with ed25519 keys - Modernise the Debian apt repository (ripe-atlas-repo 1.6-1): deb822 .sources format and a Signed-By-scoped signing key, fixing the apt warnings on Debian 13 - Add the openwrt-hwprobe architecture as a common base for the next-generation hardware probe firmware - Measurement code - Add a minimum gap between NTP requests, 4000 ms by default (GH-114) - Send the NTP RIPE reference-id in network byte order, correcting it on big-endian architectures - Use the MAC address from the default-route interface - Use environment-specific SOS servers for SOS calls - Support both iproute2 and net-tools (reported by Paul Menzel, GH-147, GH-148) - Other - Change default SSH key pair algorithm to ed25519 - Pre-fill the probe's public key in the post-install registration URL - Fix RHEL and Debian packaging (dependencies, maintainer scripts, apt changelog) - Add libssl3t64 for Debian 13 (authored by Dreista, GH-139) - Fix the OpenWrt package build on 24.10 and 25.12 (GH-146) - Hardware probe fixes: boot from saved network configuration, reginit upgrade, update checksums - Fix typo in HTTP_POST_PORT configuration entry (authored by Firefishy/Grant, GH-141) - Wrap over-long help text in evtdig (authored by commodo/Alexandru Ardelean, GH-149) - Internal cleanups and CI changes Please note that NTP offsets reported by 5120 are incorrect. The reported round-trip time is unaffected. This is also the last release supporting Debian 11, given that its LTS will end on 31 August 2026. This release only applies to software probes. An update will be released for hardware probes once OpenWrt consolidation work is complete. The full release notes are available in the documentation: https://atlas.ripe.net/docs/releases/firmware_index/5130 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/5130 Please let us know if you find any issues with this release. Kind regards, Trix Taiclet Embedded Systems Engineer @ RIPE Atlas RIPE NCC

2 3

RIPE Atlas UI updates for 2026-08-10
by Stephen Suess 10 Aug '26

10 Aug '26

Hi Atlas friends, We just pushed out an update to the UI that includes numerous fixes and changes. Among them changes to the way we present anchors vs probes on various maps, troubleshooting steps for abandoned probes, and a fix to LatencyMon not showing aggregated data in narrow time ranges. You can see the full list of what has changed in the release notes here: https://atlas.ripe.net/docs/releases/website_index/2026-08-10 Please let us know if you have any feedback or encounter any issues. Kind regards, Stephen Atlas UI

1 0

Probe 52209
by Daryl Morse 06 Aug '26

06 Aug '26

Hello, I've been experiencing a strange problem related to my probe for several years. My internet service is GPON, offering 940 Mbps up and down. The service is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is connected to the LAN side of my router. For the past 3 years or so, there have been approximately 1000 log messages per day which look like the following: Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 The destination address belongs to my probe. For a while I wondered what caused the "5" in the fe80:5::* link-local address, but apparently, FreeBSD, on which pfSense is based, inserts it to denote that the link-local address is associated with the WAN interface. You can see that the messages are periodic, occurring every 4 seconds. The addresses are not random. They repeat. I presume that the multiple addresses indicate multiple measurements associated with my probe. I connected Wireshark to the WAN interface and verified the packets are present, but without the "5". The problem is not that pfSense is logging these messages. It's behaving properly. I'm wondering why the messages have a link-local source address. The only explanation is that the ISP router is converting routable GUA addresses to non-routable link-local addresses, otherwise, the packets could not have been routed to my probe. Since these packets are arriving at my router, this conversion must be happening in the ISP router at the other end of the fibre. I'm wondering if there is any way to get a log of the measurements being run against my probe. If I could see that the messages in my log correspond to measurements against my probe, I could provide that information to my ISP to diagnose the cause. I'm interested to hear if anyone thinks this analysis is correct or if there is another explanation. Regards.

6 9

Probe 16968 unable to recover
by Daan van Gorkum 05 Aug '26

05 Aug '26

Hi all, My probe 16968 went offline late July. On the atlas site it's complaining about bad firmware CRC, then bad USB and now no USB flash drive. I've tried a couple of USB sticks, also tested the original one (that seems to pass badblocks just fine). Can this probe be recovered or unfortunately end of the road? Thanks! Regards, Daan

1 0

Request for credits: DNS resolution measurement across Brazilian ASNs
by Yuri 05 Aug '26

05 Aug '26

Hello, I am the technical operator of a licensed online gaming platform in Brazil and I would like to request RIPE Atlas credits for a DNS measurement. Context: our domain (vixe.bet) was included in a DNS blocking list issued by a Brazilian federal authority and enforced by Anatel, the national telecom regulator, starting 25 July 2026. The inclusion was later determined to be an error — we hold a valid state licence — and on 29 July 2026 the same authority formally instructed Anatel to unblock the domain. What I need to verify is whether that unblocking has actually propagated to the recursive resolvers of the major Brazilian ISPs. Since the blocking is implemented at DNS resolver level by each operator individually, I cannot observe it from outside their networks. Residential proxies do not work for this, as the DNS resolution happens at the proxy gateway rather than on the end device. Proposed measurement: one-off DNS lookups (type A) for our domain, plus one control domain still on the blocking list and one unaffected domain, from probes in BR filtered by ASN — primarily Vivo, Claro, TIM and Oi, plus regional providers where probes are available. Roughly 200 probes, three queries each. By my calculation this costs around 12,000 credits per run. I would like to repeat it a few times over the coming weeks to confirm the result is stable, so I am requesting 50,000 credits. My RIPE Atlas account e-mail is: yurigow(a)gmail.com I am also in the process of setting up a software probe on our own infrastructure, which is in a Brazilian ASN. Thank you very much, Yuri CEO, Playzen Gaming LTDA

3 2

new all-time low in monthy probe report mails
by Gert Doering 02 Aug '26

02 Aug '26

Hi, the monthly reports for the Atlas probes have received a new lower watermark... now I get mails that have a HTML body "with relevant information", and a text body that has basically boilerplate, and and an unsubscribe link (see below). If you send MIME/Multipart, the different parts MUST be identical to be any useful. If you can't ensure that the text/plain part is meaningful, much better to not include it at all. Unfortunately, the readability of the HTML body also reached a new low - it was sort-of-ok-but-annoying in the last months, now it's the usual "optimized for outlook prettyprinting" with a full page of boilerplate and font definitions, and relevant information buried under tons of HTML tags. This is supposed to be a simple table with useful information, not a marketing brochure where "perfect rendering and colours and fonts" is where everyone gets excited about. Which brings me to "why should I want to support this effort at all anymore, if people so obviously do not care what *I* want?"... gert ----- Forwarded message from RIPE Atlas <atlas+3616a83f(a)ripe.net> ----- Date: Sat, 01 Aug 2026 02:06:24 +0000 From: RIPE Atlas <atlas+3616a83f(a)ripe.net> To: Gert Doering <gert(a)space.net> Subject: Monthly probe report for probe #50014 v4 beta probe??? **RIPE NCC** Stationsplein 11, 1012 AB, Amsterdam This email was sent to gert(a)space.net You've received this email because you are registered as a RIPE Atlas probe host. [Unsubscribe](https://r.bulk-email.ripe.net/tr/un/SJYBU8c0ZIM62k2wnWdTQrAVQm… ----- End forwarded message ----- Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Karin Schuler, Sebastian Cler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: Dr. Frank Thiäner D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

4 5

RIPE Atlas UI updates for 2026-07-29
by Stephen Suess 29 Jul '26

29 Jul '26

Hello Atlas users, We have just pushed another update to the UI. Among the highlights: - You can now set notification email format (in Preferences) to text or html. Please note that as we have moved to a new email sending system, for a short while still there may be an email here or there that needs reworking or is in the process of being converted. - We have replaced the charting library used for many Atlas charts with Apache e-charts. - We have fixed numerous other issues related to measurement cloning, historic data display in LatencyMon, and more. You can see the full list of what has changed in the release notes here: https://atlas.ripe.net/docs/releases/website_index/2026-07-29 Please let us know if you have any feedback or encounter any issues. Kind regards, Stephen Atlas UI

2 1

Firmware updates for v3 probes
by Urban Suhadolnik 29 Jul '26

29 Jul '26

Hi, Do older RIPE probes get updates? I have just recently revived this v3 probe. Best, Urban

3 2

Global timeout event root DNS
by Jesse Prins 23 Jul '26

23 Jul '26

Hey all! For the final research project for my bachelor I am researching timeouts involving the Root DNS servers using RIPE atlas measurements. In my research I stumbled upon (in my opinion) a weird event that I can’t find any causes for. On the 23rd of December there was a spike (ranging from 10% - 60% depending on the server) in timeouts involving all root servers except F, G and H which don’t show any spike at all (see https://rootviz.sidnlabs.nl/public-dashboards/f81c02c68d7a4986ba1674fd7eb87…) My main question is if there were any problems with RIPE atlas itself around this time (causing an artifical spike)? and if not: Does anyone know what could have caused such a global spike in timeouts? Thanks in advance. Kind regards, Jesse Prins

2 1

Request for small Atlas credits for personal network measurement study
by 考生-高亚杰 22 Jul '26

22 Jul '26

Hello everyone,              I am a beginner learning internet measurement with ripe-atlas-tools. My RIPE account email is 2820665306(a)qq.com, my current credit balance is zero so I can't run ping and traceroute tests for study. If anyone has spare credits to donate me about 10000cr, I will really appreciate it. All my measurements are only for personal learning, no commercial use at all.              Thanks very much for your help!

3 2