- ripe-atlas - mailman.ripe.net

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

Understanding participating probes and probe requests
by Malte Tashiro 08 Apr '24

08 Apr '24

Hi, I'm currently looking at measurement metadata and am a bit confused about the different ways of getting the number of probes participating in a measurement and the number of probes requested by the user. I'd like to know how to... 1. get the number of probes _currently_ participating in a measurement (for ongoing measurements) 2. the number of probes that participated when the measurement finished (for stopped measurements) 3. the number of probes a user requested over the lifetime of a measurement The default response to /measurements returns a participant_count and a probes_requested value. However, there are also the optional fields current_probes and participation_requests and these do not add up. For example, this [0][1] measurement (not mine) has a participant_count of 0 (showing as "Actually Participating: None") in the web interface, but one probe listed in current_probes, which shows up in the "Latest Results" list and is still performing measurements (at least while writing this). So it seems like the current_probes list is more accurate to get the number of probes _currently_ (or when the measurement finished) participating in a measurement? Similarly, there are 35 probes_requested, which equals the sum of "requested" probes from the participation_requests, however, some request are actually "remove" actions, which should not be included in this count? Any hints on how to interpret these fields? I think the requested probes and participation requests are more a problem for long-running measurements, but the participant count is sometimes weird for one-offs as well. Thanks, Malte [0] https://atlas.ripe.net/measurements/67903255 [1] https://atlas.ripe.net/api/v2/measurements/67903255?optional_fields=current…

2 1

probe online but not doing any measurements [condmv: not moving, destination]
by Lukas Tribus 07 Apr '24

07 Apr '24

Hello, my probe 1007423 is online, however it does not appear to do any measurements (which is a silent failure one only notices when trying to use it's own probe unfortunately). It's running on OpenWRT 23.05.3 (installed atlas-sw-probe package). I'm not sure since when this is happening. After booting I can see that the sos dns request fails (probably when connectivity is not yet ready): evping: bad address 'U14.H484d19378dbf100f.sos.atlas.ripe.net' evping_ops.init failed And every 3 minutes I see: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/v6addr.txt' exists condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/simpleping' exists Any ideas on what could be happening here? Can I safely delete those files? Thank you, Lukas

1 0

Confused by the documentation
by Stephane Bortzmeyer 05 Apr '24

05 Apr '24

I confess I have a lot of problems finding something in the documentation in its current state. For instance, I assume that HTTP requests can have a "method" parameter to switch from GET, HEAD, etc but where is it documented? Not here: https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/types/type_sp… Not here: https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements

3 3

Empty responses for HTTP tests with a non-existing path?
by Stephane Bortzmeyer 05 Apr '24

05 Apr '24

It seems the anchors, when receiving a HTTP request for a non-existing path, instead of a 404, send a broken response: % curl -v http://fr-par-as2486.anchors.atlas.ripe.net/nonono * Trying 2001:67c:217c:4::2:80... * Connected to fr-par-as2486.anchors.atlas.ripe.net (2001:67c:217c:4::2) port 80 (#0) > GET /nonono HTTP/1.1 > Host: fr-par-as2486.anchors.atlas.ripe.net > User-Agent: curl/7.81.0 > Accept: */* > * Empty reply from server * Closing connection 0 curl: (52) Empty reply from server

2 2

RIPE Atlas maintenance on Wed 10 April
by Christopher Amin 05 Apr '24

05 Apr '24

Dear colleagues, On Wednesday 10 April we will carry out maintenance on a storage solution used by critical backend nodes of the Atlas infrastructure. Work start: 2024-04-10 08:00 UTC Work end: 2024-04-10 11:00 UTC What you should expect during the maintenance window: - The LIR Reachability Test will not work; - Newly connected probes may take longer than usual to connect to the RIPE Atlas system. All other parts of the RIPE Atlas service should continue to work as usual. Regards, Chris Amin RIPE NCC

1 0

Fwd: 2FA
by Ernst J. Oud 27 Mar '24

27 Mar '24

L.S. Oh well, I installed the Authenticator Chrome Extension (https://chromewebstore.google.com/detail/authenticator/bhghoamapcdpbohphigo…) on my PC which could scan (nifty!) the QR code exported from Google Authenticator. All is fine now. Can use 2FA via Chrome on my PC. Regards, Ernst > From: "Ernst J. Oud" <ernstoud(a)gmail.com> > Date: 25 March 2024 at 13:39:45 CET > To: Bogdan-Stefan Rotariu <bogdan(a)rotariu.ro> > Subject: Re: [atlas] 2FA > > Bogdan-Stefan, > > I agree with your remark about the fact that 2FA using an Authenticator on the same system used for the login defeats its purpose. > > However, RIPE refers on the 2FA instruction page (https://www.ripe.net/membership/member-support/ripe-ncc-access/two-step-ver…) under the heading “What if I don't have or want to use a smartphone?” to the OATH Toolkit for Linux. > > Thus, if I accept the risk that my PC could be hacked and RIPE clearly also accepts running 2FA on a PC running Linux then I reckon that running a 2FA Authenticator on Windows or even macOS should also be made possible. > > I therefore stand by my question how to enable an Authenticator on a PC if already enabled on another device. More than 95% of users don’t use Linux on their desktop. Then only referring to an arcane Linux CLI tool is a bit limiting. > > I installed that toolkit on WSL2 on my PC and it installed fine but to use it I still need the secret key that was used to enable 2FA. Which I don’t have and is also not available on my profile page. Tried exporting it in Google Authenticator which gives a QR code, pointed WinAuth to the URL where I stored it. Didn’t work. > > Regards, > > Ernst J. Oud > >>> On 25 Mar 2024, at 12:40, Bogdan-Stefan Rotariu <bogdan(a)rotariu.ro> wrote: >>> >> Hello, >> >> The scope of 2FA is to use a secondary device to get the authorisation codes. We saw hacked PC’s that had Authy or any other 2FA Apps, and the attackers used those to obtain the codes and hijacked accounts. >> So using a 2FA App on the same device that you’re using to login and authorise at the same time defeats the purpose of the 2FA. >> >> We are try now to teach our users and employees to stop using desktop apps for 2FA code generators and I encourage you to do the same, even if it adds a second layer (as expected) of effort for you. >> >> Thanks, >> >> -- >> Bogdan-Stefan Rotariu >> >> >> >>> On 25 Mar 2024, at 13:13, Ernst J. Oud <ernstoud(a)gmail.com> wrote: >>> >>> Hi, >>> >>> I enabled 2FA for Atlas website access. Works fine on my iPad and Android phone, using the Google Authenticator. However not always I have these devices with me when I want access via my Windows PC. >>> >>> I installed WinAuth on my PC but it needs the secret key that is generated when 2FA is enabled. Is there a way to get this secret key for this purpose? Tried exporting from Google Authenticator but that only supplies a QR code, not the key. >>> >>> Is there a way to use both a tablet/phone and a PC for authentication? >>> >>> I read that in Q1 2FA will be enforced. I am a bit amazed that there has been no further announcement in this group with some help. The page on 2FA only mentions the Oauth Toolkit for Linux. No help whatsoever for Windows users. >>> >>> Any clues? >>> >>> Regards, >>> >>> Ernst J. Oud >>> -- >>> ripe-atlas mailing list >>> ripe-atlas(a)ripe.net >>> https://lists.ripe.net/mailman/listinfo/ripe-atlas >> >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas

1 1