- ripe-atlas - mailman.ripe.net

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

UI: "Reuse from existing measurement" probe selection
by Lukas Tribus 17 Jul '26

17 Jul '26

Hello, when I'm using the "Reuse from existing measurement" probe selection method, only a single probe (the last probe looks like) from the existing measurement is used, not as expected all the probes from the existing measurement. The low expected daily cost is a good indicator for this as well, a part from actually starting a measurement and confirming that it only contains a single probe. I tried with a new and empty Google Chrome profile just to exclude any interaction with Firefox, browser caches, or the FF extensions I use, and the behavior is clearly reproducible. The UI also suggest that using a *subset* of the probes selected in a previous measurement is possible, however I have not found a way to actually select probes. The arrow pointing down is not doing anything for me (just endlessly loading nothing). This could absolutely be an embarrassing PBKAC issue, considering that I just spent an undisclosed amount of time the other day to diagnose why my anchor selection didn't work for the HTTP requests I was trying to run (of course it's not that you can only run HTTP requests from anchors, it's that you can only run HTTP requests *against* anchors as a target...). Thanks, Lukas

2 3

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

15 Jul '26

Hello Atlas friends, We have just pushed an update to the UI. Among the highlights: - Anchor management refresh: We have redesigned the "My Anchors" dashboard card and rebuilt the anchor change request forms. You can find more details in the Anchor Management documentation: https://atlas.ripe.net/docs/howtos/anchors/anchor-management - Rebuilt probe registration: The hardware and software probe registration forms have both been rebuilt from the ground up, replacing the legacy versions, and there is now a dedicated software probe install page to walk you through setup. - Probe details improvements: Your probe overview will now tell you when a probe is on hold due to a farming violation, and a software probe's current SSH key is now shown on its Manage tab. You can see the full list of what has changed in the release notes: https://atlas.ripe.net/docs/releases/website_index/2026-07-15 As always, we welcome your feedback and would love to know what you think. Kind regards, Stephen Atlas UI

1 0