August 2026 - ripe-atlas - mailman.ripe.net

Request for RIPE Atlas credits for latency research
by Ernst 31 Aug '26

31 Aug '26

Hello, I am running a small non-commercial latency study comparing OVHcloud AS16276 and Hetzner AS24940 connectivity to the public Bitfinex endpoint api-pub.bitfinex.com. I would like to run a 24-hour RIPE Atlas ping and traceroute measurement from a small set of probes in OVH LIM1 and Hetzner NBG1. My RIPE Atlas account currently has 0 credits. A small credit donation would be greatly appreciated. Around 10,000 credits would already be more than sufficient for this study. Thank you, Ernst

2 2

[atlas+e76c0ca5@ripe.net: Your probe 20605??? has disconnected]
by Gert Doering 25 Aug '26

25 Aug '26

Hi, so that's what you get when you order "preferred e-mail format: plain text" in the portal? gert ----- Forwarded message from RIPE Atlas <atlas+e76c0ca5(a)ripe.net> ----- Date: Mon, 24 Aug 2026 02:50:00 -0000 From: RIPE Atlas <atlas+e76c0ca5(a)ripe.net> To: Gert Doering <gert(a)space.net> Subject: Your probe 20605??? has disconnected <html><head></head><body> <img style="display:none" src="https://r.bulk-email.ripe.net/tr/op/r4IRERQxPRfJWHar4Upz6thEB9Toy9hTxYo5c3j…" /> Probe 20605 is disconnected T-Online end site Gert Doering, Your probe 20605 has been disconnected from the RIPE Atlas infrastructure since 2026-08-24 02:15:29 UTC. You may be able to learn more about the possible cause from the "Overview" tab on your probe's page: https://atlas.ripe.net/probes/20605/ Probes are tagged with suspected problems every four hours, so if there is nothing listed and your probe has just gone offline, please check back in a few hours, as more information may be available. If you need further assistance or have any questions, please contact us at atlas(a)ripe.net. Best regards, The RIPE Atlas Team </body></html> ----- 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

3 3

Request for 10k credits
by Trevor Keith 17 Aug '26

17 Aug '26

I’m doing a few one-off RIPE Atlas API tests to debug a reachability issue for my AS and need around 10k credits to do so. If anyone has a small amount to spare, I’d really appreciate a transfer to my Atlas account: tk(a)tkeith.com

6 6

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