- ripe-atlas - mailman.ripe.net

Software probe keeps going to disconnected
by vom513 19 Jun '24

19 Jun '24

Hello all, I have 2 software probes. One is on a datacenter VPS and the other at home (runs on Proxmox). The one at home keeps going to disconnected. The probe is Debian 12. Probe version is 5080-1. This machine has v6 as well - so I was thinking maybe something with temp/privacy addresses getting reaped but no, I only have one good old EUI-64 address on there. (Knock on wood) - no other VMs on my Proxmox machine have any issues like this. The only thing that looks remotely related (and this happened a bit before Nagios sent out an alert) is this: Jun 17 12:34:41 atlas-probe ATLAS[123749]: /usr/local/atlas/bin/ATLAS: 99: kill: No such process Jun 17 12:34:41 atlas-probe ATLAS[123749]: no ssh client matching . cleanup state files. for next restart Jun 17 12:34:41 atlas-probe ATLAS[123749]: RESULT 9006 done 1718642081 bc2411ca94c6 no reginit.vol start registration Jun 17 12:34:41 atlas-probe ATLAS[123749]: /var/atlas-probe/status/reginit.vol does not exist try new reg Jun 17 12:34:45 atlas-probe ATLAS[123749]: Ping works Jun 17 12:34:45 atlas-probe ATLAS[123749]: /usr/local/atlas/bin/ATLAS: 92: kill: No such process Jun 17 12:34:45 atlas-probe ATLAS[123749]: start reg Jun 17 12:34:45 atlas-probe ATLAS[144349]: ATLAS registration starting Jun 17 12:34:45 atlas-probe ATLAS[144349]: REREG_TIMER 1718416507 expired now is 1718642085 Jun 17 12:34:45 atlas-probe ATLAS[144349]: REREG_TIMER_EXPIRED go re register REREG_TIMER 1 , now is 1718642085 Jun 17 12:34:45 atlas-probe ATLAS[144349]: REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 Jun 17 12:34:45 atlas-probe ATLAS[144349]: ssh -p 443 atlas(a)reg03.atlas.ripe.net INIT Jun 17 12:34:48 atlas-probe ATLAS[144349]: Got good controller info Jun 17 12:34:48 atlas-probe ATLAS[144349]: check cached controller info from previous registration Jun 17 12:34:48 atlas-probe ATLAS[144349]: NO cached controller info. NO REMOTE port info Jun 17 12:34:48 atlas-probe ATLAS[144349]: Do a controller INIT Jun 17 12:34:48 atlas-probe ATLAS[144349]: Controller init -p 443 atlas(a)ctr01.atlas-prod.aws.ripe.net INIT I believe I should see an persistent ssh outbound ? The only ESTAB is me ssh’ing in, and a 443 to RIPE: root@atlas-probe:/home/vom# ss -planto | grep ESTAB ESTAB 0 0 192.168.69.111:22 192.168.64.21:65409 users:(("sshd",pid=145083,fd=4),("sshd",pid=145059,fd=4)) timer:(keepalive,115min,0) ESTAB 0 0 [2603:6011:6300:1f02:be24:11ff:feca:94c6]:37176 [2a13:27c0:1c:d01:cc61:f3a3:920d:cd88]:443 users:(("ssh",pid=144380,fd=3)) timer:(keepalive,103min,0) Let me know what else I can look at. I assume there is some debug I can crank up ? Just going to reboot this for now to get it happy and get Nagios to shut up. Thanks.

2 2

[ anchor] Quota on the usage of an anchor in measurement.
by Huseyn Gambarov 19 Jun '24

19 Jun '24

Hello. In my research, I am conducting multiple RTT measurements against different targets. During the measurement process, a single anchor stops getting scheduled for a requested measurement after some number of times or returns -1 as a result. I want to ask if there is a limit on how many times a single anchor can participate in a measurement. And what is its cooldown period if such a limit exists? With regards, Huseyn Gambarov Research Assistant PhD Student in Computer Science Case Western Reserve University

2 1

Atlas UI updated
by Stephen Suess 10 Jun '24

10 Jun '24

Hi Atlas Users, Along with the aforementioned removal of old measurement detail page links, we have just released an update to the UI that includes: - NEW: Pref for using local time (vs UTC) everywhere - NEW: Added local toggle to QuickLook for using probes close to user location - CHANGE: Add traceroute table to msm overview map marker popups - CHANGE: Make clearer the difference between no report (yet) vs no reply (from target) - CHANGE: Map now resizes on larger screens in measurement overview If you want to see the full list of what has changed, you can check the release notes here: https://atlas.ripe.net/docs/releases/website/2024-06-10.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

Removing links to legacy measurement detail pages
by Stephen Suess 07 Jun '24

07 Jun '24

Dear Atlas Users, Now that we have been up and running with the new measurement detail pages for a few weeks, we plan to remove the banner and links to the legacy pages next week. Please let us know if you still have any need for the old detail pages and why, and we will do our best to address any concerns. Kind regards, Stephen Atlas UI

1 0

RIPE Atlas infrastructure maintenance on 11 June 2024
by Robert Kisteleki 07 Jun '24

07 Jun '24

Dear RIPE Atlas users, On 11 June 2024, between 8:30-11:30 (CEST) we will carry out maintenance of the central RIPE Atlas infrastructure. The UI, APIs, access to stored results and metadata, as well as measurement scheduling will be unavailable. During this time results will still be still collected and stored. We apologise for the inconvenience this may cause. Regards, Robert Kisteleki, for the RIPE Atlas team

1 0

How to be more helpful...
by Mike 01 Jun '24

01 Jun '24

OK, here's my "problem." For starters I think the Atlas project is a great thing for the Internet, and I thank my local ISP, Comcast (USA), for encouraging me to sign up. But here's the thing for me. I have so many millions of points accumulated. When I see a message on this message list about someone asking for, say 20 million points, by the time I see that message, the requester has already received, typically, more than twice the number of points requested. (and I will say right now, private requests for points will be ignored) So my question becomes... I participate in this amazing project with a measurement device. But I also want to participate in the project by helping others, I guess I am asking, is there a way I can contribute points without having to check the list every hour or so?

2 1

Atlas UI updated
by Stephen Suess 28 May '24

28 May '24

Hi Atlas fans, We got a lot of useful feedback at RIPE88, and have just released some changes to production. Here are some of the highlights: - NEW: Pref for setting Mine tab as default for lists when logged in (instead of Public) - CHANGE: Improved sorting of minRTTs, no reply, n/a - CHANGE: Measurement form now using modal popups for probe selection to clarify interaction - CHANGE: When adding probes in the measurement form, it will now ask you if you want to keep the default probes or remove them - CHANGE: Rework map legend enable/disable logic when clicking on labels - CHANGE: RD bit set true by default for new DNS measurements If you want to see the full list of what has changed, you can check the release notes here: https://atlas.ripe.net/docs/releases/website/2024-05-28.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

TraceMON pages broken?
by Malte Tashiro 28 May '24

28 May '24

Hi, it seems like the TraceMON widget is currently broken. The tracemon-dist.js [0] file appears to be missing, which is required by the main traceroute-widget-main.js [1] file. Tried with Chromium and Firefox and both the old [2] and new [3] way. Would be happy about a fix :) Best, Malte [0] https://www-static.ripe.net/static/rnd-ui/atlas/static/measurements/widgets… [1] https://www-static.ripe.net/static/rnd-ui/atlas/static/measurements/widgets… [2] https://atlas.ripe.net/measurements/9333344/#tracemon [3] https://atlas.ripe.net/tracemon/9333344

2 1

Delays?
by Ernst J. Oud 14 May '24

14 May '24

I experience delays on creating measurements. Even after 2 minutes, a measurement is not running, eventually it will but it used to take a couple of seconds. My streaming api calls now time out… Is this known? Will it approve or do I need to change my scripts so that they wait longer? Regards, Ernst J. Oud

3 2

API advice to pull data from multiple measurements
by techtebatoye＠gmail.com 14 May '24

14 May '24

Hi, I would like to pull data from DNSMON probe measurements to build a real-time view. Considering the combination of IPv4/IPv6, UDP/TCP, multiple nameservers per TLD, it quickly adds up to 150+ measurements. I started with the streaming API, sending register messages for the measurements of interest, but quite quickly I am getting errors with "slow_down" response. I could not find the rate limit values in the documentation of the streaming API. Using the HTTP API would also mean hundreds of API calls, one per measurement. What is the recommended way to regularly pull data from many measurements, to avoid rate limiting or generating too much load on the API ? Regards

2 1

New Atlas UI launched
by Stephen Suess 13 May '24

13 May '24

Hello Atlas community, We are very happy to announce that after months of development and testing, we are today launching major changes to the Atlas UI: - NEW: Simplified navigation - NEW: About pages for Atlas moved to www.ripe.net/ripe-atlas - NEW: Dashboard - All Users: Quick Start, News Flash, QuickLook Measurement, Credits, My Measurements, Messages, API Keys, Quotas - Probe Hosts: My Probes - Anchor Hosts: My Anchors - RIPE NCC Members: Monthly Credits Claim - Ambassadors: Probe Management, Events - NEW: System status indicator on dashboard and table in Statistics - NEW: Measurement detail pages - Overview, Results, Details and Manage tabs - Ability to add or remove probes from a measurement - Participation requests - Improved map overview with summary insights - Standalone pages for TraceMON and LatencyMON - NEW: Preferences page - NEW: Feedback page You can find the full list of changes in the release notes: https://atlas.ripe.net/docs/releases/website/2024-05-13.html We hope you find these changes useful and we welcome your feedback. We will be demoing and discussing these in detail at the upcoming RIPE meeting as well. Kind regards, Stephen Atlas UI

1 0

Summary of the discussions about previous proposals
by Robert Kisteleki 13 May '24

13 May '24

Dear all, In response to community feedback, as well as to the observed behaviour of RIPE Atlas, earlier we put out some proposals about some aspects of future behaviour of RIPE Atlas. We’d like to summarise what we’ve heard so far (written responses as well as verbal discussions we participated in), and the path we plan to take based on these. Probe farming: There were many voices who agreed with some form of limiting this behaviour. We were also asked to reach out to users who are using many probes this way now. We did and the short summary is that most (but not all) answers give reasonable justification. Conclusion: we’ll add the relatively simple proposed rules (in short: limit the number of software probes from the same IP/prefix). Later on we can consider softer approaches, e.g. reducing the number of credits given to hosts with excess probes or using probe similarity metrics. Measurement aggregators: We proposed to embrace this existing phenomenon, ask these users to in the future give the system an indication about the distinct clients they serve, and perhaps step up as sponsors in such cases. We received many responses to this proposal. For the most part, current aggregators who responded stated that they have no significant issues with providing such client information – in an anonymised way of course. At the same time some of them stated that adding a “mandatory sponsorship” would discourage them from using RIPE Atlas in the future. Some argued that by having enough credits to do so, they were in fact contributing positively to the network already, and in fact some of them are or were sponsors. Conclusion: we’ll add the features needed to implement such aggregations, and work on incentives for these users to become RIPE Atlas sponsors. We’ll also add the need for proper attribution to the service, similar to what the commercial use policy describes. We may also look at additional requirements to ensure proper funding for our membership services. Data retention principles: This proposal was a high level one and we received limited feedback. One discussion raised how “financially sustainable” is defined; perhaps the best summary of this is the recent RIPE Labs article published by our CTO Felipe: https://labs.ripe.net/author/felipe_victolla_silveira/reducing-the-ripe-ncc… Conclusion: we are implementing our data storage and access features along the principles we laid out. For transparency, we’ll also include summaries of proposals we put out earlier (see: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/) for which we haven’t provided a written conclusion. Remove per-hop “late” packets from traceroute [LATE-PACKETS]: we only heard support for this, therefore it’s in our plans now. Measure well-known CDNs [CDN-HTTP]: Multiple responses argued that by selecting a “short list” of CDNs that are included by default, there’s an implicit statement and/or bias in the system towards bigger providers, contributing to some aspects of centralisation. Others pointed out that this approach reflects the reality of generic users, since the majority of the content they consume is provided by said CDNs. In addition, there were some voices supporting this proposal because of the value it provides to (smaller) CDNs or because it incentivises probe hosts to join or to keep their probes connected. Based on these discussions we’ll not go ahead with a full set of CDN measurements; however we’ll try a smaller scale experiment to discover the potential benefits to all users. Generic HTTP measurements [GENERIC-HTTP]: the discussions centered around some reiterations of the previous arguments (i.e. the safety of both the probe host and the providers’ sides) and if/how the proposed opt-in activity of the probe host would help this. Given these arguments, and that only a few voices expressed their explicit support for this, we’ll put this activity on hold; we can revisit this if/when the community wishes so. Add support for STARTTLS measurements [STARTTLS]: there were lengthy discussions about how certain SMTP servers may react to such incoming measurements. The general agreement was that this measurement type can be useful, with the confirmation that these checks will explicitly stop after STARTTLS (i.e. they will not have the ability to even try initiating sending mails or such). Remove support for non-public measurements [ONLY-PUBLIC]: the discussion raised both arguments for and against changing the system’s behaviour. Some people also raised the possibility of making private measurements more costly (in terms of credits). We’d also like to note the reference to the data retention principles (private measurement results are not available to all users, therefore we’ll only store them for a limited time). All in all, for the time being we do not plan to make behavioural changes about this feature. Regards, Robert Kisteleki RIPE NCC

1 0

ASN in probe application page vs. probe ASN status / dynamic ?
by vom513 10 May '24

10 May '24

Sorry for the title gore, hard to summarize this in one line. I was wondering why does the application page ask for ASN, if once the probe is running and connected the ASN is automatically determined ? I just had to flip my home internet to our backup provider and after a bit my home probe changed it’s ASNs as hoped/expected. If this is dynamic - why even ask on the application page ? Thanks. PS: Talking about a software probe here in case that makes a difference.

1 0

Meaning and the future of the project
by Petr Kutalek 08 May '24

08 May '24

Hello, I have been involved in this project for over 12 years. For the last few weeks I have been wondering what the point of this is. OK, I have given out credits to students for research, though sometimes they do not even say thank you. The firmware on the probes has not changed for years, the front-end except for cosmetic changes also does not go through shocking developments (still the same bugs), new features are not implemented, just discussed (e-mail notifications) etc. So I would actually just like to ask: - How many people are working full time on this project at RIPE? - What is the priority for RIPE? - What is the future? Any realistic plans? Thank you, Petr

4 3

random, but unique ASN probe selection
by Marco Moock 08 May '24

08 May '24

Hello! Is there a way to select random probes for measurements that only one per ASN is being chosen? I'd like to test reachability from different AS and don't like to select multiple probes in the same AS. -- kind regards Marco

2 1

Request RIPE Atlas Credit Donation for Internet Routing Research
by Shihan Lin 04 May '24

04 May '24

Dear RIPE Community, My name is Shihan Lin, a PhD student in the Department of Computer Science at Duke University. My colleagues and I are working on an Internet research project led by Prof. Xiaowei Yang, and we are using RIPE Atlas probes in our research project. However, we face a credit shortage in our account, so we are writing to humbly request your consideration of a potential credit donation to support our ongoing research efforts. Our research project aims to improve cloud routing. We first need to measure the existing cloud routing performance, so we need to send traceroutes and pings from probes around the world to VMs in multiple regions of three commercial cloud providers. With traceroute results, we can detect clouds’ Points of Presence (PoPs) used by probes to reach the VMs. By discovering the PoPs of a cloud, we can discover alternative paths by selecting different PoPs to enter the cloud and thus improve the routing latency. We finished a part of such measurements and discovered some better alternative paths. However, we need another round of measurement to verify our findings. Specifically, we need to send repeated pings from probes to alternative PoPs to validate that such PoPs consistently offer lower latency. According to our calculation, we need about 50M credits for our remaining measurement. Thus we are wondering whether we could ask for some donations from the RIPE community. We greatly appreciate any assistance you can offer. If it is possible, you can donate it to my RIPE Atlas account LSHZY137 at gmail.com. Thank you very much for your help and great generosity! Our research will be submitted to a networking conference (SIGCOMM, NSDI, or IMC) to share the knowledge with the public. Many Thanks, Shihan Lin

3 3

Possible software probe "farming" on AS47583
by Ben Cartwright-Cox 02 May '24

02 May '24

Hi everybody, While doing some measurement work earlier this weekend I discovered that there are a large amount of probes on AS47583 that look like they are being set up to farm credits. With a suspiciously high amount of purely software probes on the same IP prefix and sequential IPv6 addresses. $ curl -s 'https://stat-ui.stat.ripe.net/data/atlas-probes/data.json?resource=47583' | jq .data.probes[] -c | grep Connected | jq '.address_v4 + " " + .address_v6' | sort "153.92.14.66 2a02:4780:6:c0de::e" "153.92.14.67 2a02:4780:6:c0de::f" "153.92.14.68 2a02:4780:6:c0de::11" "153.92.14.69 2a02:4780:6:c0de::12" "153.92.14.70 2a02:4780:6:c0de::13" "153.92.14.71 2a02:4780:6:c0de::14" "153.92.14.72 2a02:4780:6:c0de::15" "153.92.14.73 2a02:4780:6:c0de::16" "153.92.14.74 2a02:4780:6:c0de::17" "153.92.14.75 2a02:4780:6:c0de::18" "153.92.14.76 2a02:4780:6:c0de::19" "153.92.14.77 2a02:4780:6:c0de::1b" "156.67.223.15 2a02:4780:3:1::2a" "156.67.223.16 2a02:4780:3:1::2b" "156.67.223.29 2a02:4780:3:1::35" "156.67.223.30 2a02:4780:3:1::36" "156.67.223.31 2a02:4780:3:1::37" "156.67.223.36 2a02:4780:3:1::38" "156.67.223.37 2a02:4780:3:1::39" "156.67.223.38 2a02:4780:3:1::3a" "156.67.223.39 2a02:4780:3:1::3b" "156.67.223.40 2a02:4780:3:1::3c" "156.67.223.41 2a02:4780:3:1::3d" "156.67.223.42 2a02:4780:3:1::49" "156.67.75.19 2a02:4780:b:c0de::16" "156.67.75.20 2a02:4780:b:c0de::17" "156.67.75.21 2a02:4780:b:c0de::18" "156.67.75.22 2a02:4780:b:c0de::19" "156.67.75.23 2a02:4780:b:c0de::1a" "156.67.75.24 2a02:4780:b:c0de::1b" "156.67.75.25 2a02:4780:b:c0de::1c" "156.67.75.26 2a02:4780:b:c0de::1d" "156.67.75.27 2a02:4780:b:c0de::1e" "156.67.75.28 2a02:4780:b:c0de::1f" "156.67.75.29 2a02:4780:b:c0de::20" "156.67.75.30 2a02:4780:b:c0de::21" "156.67.75.31 2a02:4780:b:c0de::22" "156.67.75.32 2a02:4780:b:c0de::23" "156.67.75.33 2a02:4780:b:c0de::24" "185.201.11.3 2a02:4780:1::3" "185.224.136.17 2a02:4780:8::12" "185.224.136.18 2a02:4780:8::13" "185.224.136.19 2a02:4780:8::16" "185.224.136.22 2a02:4780:8::1a" "194.5.158.13 2a02:4780:8:b::11" "194.5.158.15 2a02:4780:8:b::12" "194.5.158.16 2a02:4780:8:b::13" "194.5.158.18 2a02:4780:8:b::15" "194.5.158.223 2a02:4780:8:b::f" "194.5.158.226 2a02:4780:8:b::10" "194.5.158.228 2a02:4780:8:b::16" "194.5.158.238 2a02:4780:8:b::14" "212.1.215.106 2a02:4780:1:12::3" "212.1.215.107 2a02:4780:1:12::4" "212.1.215.108 2a02:4780:1:12::5" "212.1.215.109 2a02:4780:1:12::6" "212.1.215.110 2a02:4780:1:12::7" "212.1.215.111 2a02:4780:1:12::8" "212.1.215.112 2a02:4780:1:12::9" "212.1.215.113 2a02:4780:1:12::a" "212.1.215.114 2a02:4780:1:12::b" "212.1.215.115 2a02:4780:1:12::c" "212.1.215.116 2a02:4780:1:12::d" "217.21.86.65 2a02:4780:11:c0de::d" "217.21.86.66 2a02:4780:11:c0de::e" "217.21.86.67 2a02:4780:11:c0de::f" "217.21.86.68 2a02:4780:11:c0de::10" "217.21.86.69 2a02:4780:11:c0de::11" "217.21.86.70 2a02:4780:11:c0de::12" "217.21.86.71 2a02:4780:11:c0de::13" "217.21.86.72 2a02:4780:11:c0de::14" "217.21.86.73 2a02:4780:11:c0de::15" "217.21.86.74 2a02:4780:11:c0de::16" "217.21.86.75 2a02:4780:11:c0de::17" "217.21.86.76 2a02:4780:11:c0de::18" "217.21.86.77 2a02:4780:11:c0de::19" "217.21.86.78 2a02:4780:11:c0de::1a" "217.21.86.79 2a02:4780:11:c0de::1b" "2.57.90.18 2a02:4780:a:c0de::3" "2.57.90.38 2a02:4780:a:c0de::2" "2.57.90.41 2a02:4780:a:c0de::4" "2.57.90.42 2a02:4780:a:c0de::5" "2.57.90.43 2a02:4780:a:c0de::6" "2.57.90.44 2a02:4780:a:c0de::7" "2.57.90.45 2a02:4780:a:c0de::8" "2.57.90.46 2a02:4780:a:c0de::9" "2.57.90.47 2a02:4780:a:c0de::a" "2.57.90.48 2a02:4780:a:c0de::b" "2.57.90.49 2a02:4780:a:c0de::c" "2.57.90.50 2a02:4780:a:c0de::d" "45.128.160.100 2a02:4780:9:c0de::2be" "45.128.160.101 2a02:4780:9:c0de::1ae" "45.128.160.102 2a02:4780:9:c0de::3f" "45.128.160.104 2a02:4780:9:c0de::10a" "45.128.160.108 2a02:4780:9:c0de::3c2" "45.128.160.111 2a02:4780:9:c0de::11f" "45.128.160.112 2a02:4780:9:c0de::38f" "45.128.160.116 2a02:4780:9:c0de::12" "45.128.160.119 2a02:4780:9:c0de::c6" "45.128.160.121 2a02:4780:9:c0de::116" "45.128.160.124 2a02:4780:9:c0de::94" "45.143.83.65 2a02:4780:13:c0de::b" "45.143.83.66 2a02:4780:13:c0de::c" "45.143.83.67 2a02:4780:13:c0de::d" "45.143.83.68 2a02:4780:13:c0de::e" "45.143.83.69 2a02:4780:13:c0de::f" "45.143.83.70 2a02:4780:13:c0de::10" "45.143.83.71 2a02:4780:13:c0de::11" "45.143.83.72 2a02:4780:13:c0de::12" "45.143.83.73 2a02:4780:13:c0de::13" "45.143.83.74 2a02:4780:13:c0de::14" "45.143.83.75 2a02:4780:13:c0de::15" "45.143.83.76 2a02:4780:13:c0de::16" "45.143.83.77 2a02:4780:13:c0de::17" "45.143.83.78 2a02:4780:13:c0de::18" "45.143.83.79 2a02:4780:13:c0de::19" "89.116.146.65 2a02:4780:27:c0de::b" "89.116.146.66 2a02:4780:27:c0de::c" "89.116.146.67 2a02:4780:27:c0de::d" "89.116.146.68 2a02:4780:27:c0de::e" "89.116.146.69 2a02:4780:27:c0de::f" "89.116.146.70 2a02:4780:27:c0de::10" "89.116.146.71 2a02:4780:27:c0de::11" "89.116.146.72 2a02:4780:27:c0de::12" "89.116.146.73 2a02:4780:27:c0de::13" "89.116.146.74 2a02:4780:27:c0de::14" "89.116.146.75 2a02:4780:27:c0de::15" "89.116.146.76 2a02:4780:27:c0de::16" "89.116.146.77 2a02:4780:27:c0de::17" "89.116.146.78 2a02:4780:27:c0de::18" "89.116.146.79 2a02:4780:27:c0de::19" Now while I myself don't particularly care about credit farming on RIPE Atlas (After all RIPE Atlas credit is kind of like Monopoly money), I do care about things becoming biased towards these software probes. For example, when I had selected for a selection of probes in Brazil I ended up with several of these software probes giving me the exact same results. this is not very useful and this has the potential to bias academic measurements, had I not looked at the probe list results this would not have been immediately obvious. Is there an immediate way to report these probes other than this mailing list? I don't know of one and so I'm here :) Cheers Ben

12 17

ICMP error codes in measurement results
by Marco Moock 25 Apr '24

25 Apr '24

Hello! https://atlas.ripe.net/measurements/70248021#probes That should display route to dest rejected (ICMPv6 Type 1 Code 6), but only shows Last hop's response(s): `6, 6, 6`. Is it intended to implement that? -- kind regards Marco Send unsolicited bulk mail to 1713939075muell(a)cartoonies.org

3 2

Another research credit request
by Peter Thomassen 24 Apr '24

24 Apr '24

Dear friends of ATLAS, We're conducting a research project [1] involving ATLAS measurements with multiple PQC signing implementations (Falcon, XMSS, Dilithium, Sphincs+) to see how many clients choke, in various scenarios, depending on the response packet properties that come with such responses. The idea is to help inform how good or bad the situation is, and which aspects need further research. We'd like to do a very comprehensive measurement, and expect our measurements to use around 25M credits total. (We currently have 3M.) If anyone is willing to donate the missing amount to this project, that would be very much appreciated! My RIPE account is peter(a)desec.io. Thank you very much for considering and your generosity! Best, Peter [1]: https://nlnet.nl/project/PQ-DNSSEC-Testbench/ -- https://desec.io/

7 6

Banner stacked in latest results of measurement
by Marco Moock 24 Apr '24

24 Apr '24

Hello! When hovering on the ticks/crosses in the success column on the latest results page of a measurement, a banner is being displayed. This banner isn't going away when moving the mouse and a new banner will be place on the old one when hovering another cross/tick and make both unreadable. This happens in Pale Moon and Chromium. Can other confirm this? https://atlas.ripe.net/measurements/70021438/#probes See screenshot. -- kind Marco Send unsolicited bulk mail to 1713940405muell(a)cartoonies.org

1 0

Operational work on RIPE Atlas
by Robert Kisteleki 23 Apr '24

23 Apr '24

Dear all, A heads-up: we are just about to start scheduled maintenance work on RIPE Atlas. During the maintenance we expect scheduling of new measurements will be delayed and searching for measurements will not yield up-to-date information. Regards, Robert

1 0

Request RIPE Atlas Credit for Research
by Rolland 18 Apr '24

18 Apr '24

Hi all, I am sorry to spam this email. My name is Fengyan Han, a master's student at Tsinghua University, China. Recently, my research on RPKI requires conducting a large-scale measurement via RIPE Atlas. I have some credits but still need 50M more credits to carry out my study. unfortunately, time constraints prevent me from earning them myself. Therefore, I am reaching out here to ask for assistance. Is there anyone generous enough to offer me some RIPE Atlas credits (like, 1 million?) My account at RIPE NCC is hfy23(a)mails.tsinghua.edu.cn <>. Many thanks in advance! Regards, Fengyan Han

4 3

New default settings for Atlas measurement form
by Stephen Suess 17 Apr '24

17 Apr '24

Hello Atlas users, After an analysis of usage patterns in measurement creation, we have rolled out a couple of changes to the defaults in the measurement form (https://atlas.ripe.net/measurements/form/) - Under timing, the default is now one-off (instead of periodic as before) - Default probe selection is now 50 random, worldwide probes (instead of 10 as before) We hope you find these useful. Please let us know if you encounter any issues. Thanks! Stephen RIPE Atlas UI

4 7

Reverse traceroute
by Hank Nussbacher 16 Apr '24

16 Apr '24

https://pulse.internetsociety.org/blog/reverse-traceroutes-help-troubleshoo… "Measure at least one reverse path from 39,544 Autonomous System (AS) destinations, which host 92.6% of Internet users. As a comparison, RIPE Atlas vantage points can measure from 4,344 AS destinations, representing 67.1% of the Internet user base." Has anyone tried this and indeed found better visibility via their system? Thanks, Hank

3 2

Wohoo: Your RIPE Atlas Probe (ID: 12724) has reconnected
by Gert Doering 09 Apr '24

09 Apr '24

Hi, wohoo, "I'm back" notifications!! Thanks very much to whoever silently implemented this :-) (this was a provider outage, and the probe was indeed offline and came back, so when I got up I found the "it's back, all is well" note already in my mail). If you're bored and want to optimize this: add an "In-Reply-To:" to the original "it's gone"-mail, so there is threading (in case you only see the original mail when it's already back)... cheers, gert ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- Date: Tue, 09 Apr 2024 05:00:00 -0000 From: RIPE Atlas <no-reply(a)ripe.net> To: gert(a)space.net Subject: Your RIPE Atlas Probe (ID: 12724) has reconnected Dear RIPE Atlas probe host, We're just letting you know that your probe (#12724 ) has re-established its link to our network and we are again receiving data from it. For your own records, it appears that the reconnection took place at . If you have any questions, please contact us at atlas(a)ripe.net. Thank you for supporting RIPE Atlas. Best regards, RIPE Atlas Team ********** You can change your notification settings on your probe page (go to "My Atlas" and then "Probes" when logged into the RIPE Atlas website). ----- End forwarded message ----- -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Ingo Lalla, Karin Schuler Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0