- ripe-atlas - mailman.ripe.net

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

Fwd: [ncc-announce] [News] 2FA Mandatory on RIPE NCC Access accounts
by Robert Kisteleki 26 Mar '24

26 Mar '24

Dear RIPE Atlas users, In case you're not following the official RIPE NCC communication channels: this is a heads up regarding 2FA use in RIPE Access, the single sign-on mechanism behind various RIPE NCC services including RIPE Atlas. Action needed from you: please make sure you enable 2FA on your account. Regards, Robert Kisteleki RIPE NCC -------- Forwarded Message -------- Subject: [ncc-announce] [News] 2FA Mandatory on RIPE NCC Access accounts Date: Tue, 26 Mar 2024 12:12:12 +0100 From: Felipe Victolla Silveira <fvictolla(a)ripe.net> To: ncc-announce(a)ripe.net Dear colleagues, This week, two-factor authentication (2FA) will become mandatory on RIPE NCC Access accounts. If you have not already done so, enable 2FA on your account. For accounts that do not have two-factor authentication, when you try to log in from Wednesday 27 March, you will be prompted to check your inbox and follow the instructions in the email sent to you by the RIPE NCC. Once you have enabled 2FA, you can log in as you usually would. We will continue to improve the security and usability of RIPE NCC Access accounts over the next few months. Next week, I will also publish a RIPE Labs article explaining our roadmap and main improvements planned in more detail. We welcome your feedback and suggestions on which features are the most important for you on the RIPE NCC Services Working Group (ncc-services-wg(a)ripe.net) mailing list. If you have any issues setting up 2FA on your account, please email ncc(a)ripe.net. Kind regards, Felipe Victolla Silveira Chief Technology Officer -- Click here to unsubscribe or change your email settings: https://lists.ripe.net/mailman/options/ncc-announce

1 0

2FA
by Ernst J. Oud 25 Mar '24

25 Mar '24

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

2 1

Question about TLS test
by marcelo bagnulo braun 08 Mar '24

08 Mar '24

Hi, I understand (from a previous post in this ml) that the TLS test available in the Atlas probes uses OpenSSL. Could anyone tell me the exact command used by the probe when executing the test? I was assuming it uses something like: openssl s_client -connect <target>:port Is this correct? Does it includes further options? Thanks, marcelo

2 1

Call for presentation LACNIC’s Internet Measurements WG
by Elisa 08 Mar '24

08 Mar '24

Hi all, I would like to use this mailing list to send a quick reminder about this initiative that is seeking presentations on Internet Measurements (including, but not limited to, Atlas). The Internet Measurements Working Group (IMWG) at LACNIC41 (10 May). Seeking remote/in-person presentations. Submission deadline 12 April. Instructions: https://listas.nog.lat/archives/list/imwg@listas.nog.lat/thread/KEOIK7VC7GQ… Kind regards, Elisa R&D - LACNIC

1 0

Tomhais STARTTLS: Cad a tharla?
by Niall O'Reilly 06 Mar '24

06 Mar '24

Back in December 2022, there was a proposal to support STARTTLS measurements. (https://www.ripe.net/ripe/mail/archives/ripe-atlas/2022-December/005234.html) I wonder, whether this proposal was implemented ? I've just tried using the measurement definition form (https://atlas.ripe.net/measurements/form/), where the only TLS-related option seems to need the target to be ready to receive a client hello. /Niall

2 1

IP & MAC
by Randy Bush 05 Mar '24

05 Mar '24

i have a remote probe. on the web gui, how can i see what its lan address (it is behind a soho nat) and mac are? i thought i knew how to do this, but the moon must be in klutz. thanks. randy

3 3

Retiring old ("legacy") UI pages and deprecated API calls
by Robert Kisteleki 05 Feb '24

05 Feb '24

Dear all, As part of the RIPE Atlas user interface renewal last year, we released a new measurement scheduling form and new probe and measurement lists. Since these changes the old pages were still accessible via changed URLs. By now the use of these pages all but disappeared, and we'll remove these from the UI in the coming weeks. On a similar note, we'll also remove support for the API calls that took the form /api/v2/measurements/<TYPE>/ [*]. These have been deprecated for a long time, and since the last active user moved way most queries ending up here either come from the legacy pages or from hacking attempts. [*] in fact this has effectively been an alias for /api/v2/measurements/?type=<TYPE> so no functionality is lost and it is trivial to change code that otherwise used these calls Please reach out to us if you believe the legacy pages provided some functionality you think you'll miss so we can help you. Regards, Robert

1 1

4 probes on different networks suddenly down?
by Ernst J. Oud 30 Jan '24

30 Jan '24

Hi, At noon today 4 of my probes disconnected. 1005229 61071 55795 1005072 These are on different ISP’s and one of these is in Oracle’s cloud. So this is not a problem on my side. Restarted the 61071 since that one is nearby and easily restarted since it is a hardware probe, but that does not work. Flashing red LED. What is going on? Regards, Ernst J. Oud

3 5

Atlas weather report: bad day
by Stephane Bortzmeyer 25 Jan '24

25 Jan '24

As reported by <https://atlas.ripe.net/>, indeed, measurements timeout today.

1 0

destination_ip_responded field in traceroute measurements
by Malte Tashiro 24 Jan '24

24 Jan '24

Hi, to my delight I discovered that there is now a "destination_ip_responded" field contained in traceroute measurement results. I often want to know this and had to handle it myself until now so I'm very happy that this seems to be a built-in field now. I only wonder if this is a feature to stay (since it's not in the documentation yet), and if it is server side, i.e., always available independent of the probe firmware? Best, Malte

2 3

built-in measurement id 12023
by Xiao Song 23 Jan '24

23 Jan '24

Hi all, Hope this email finds you well. The document says that this built-in measurement #12023 requires all available probes to send http requests to the target every 900s, but actually it seems like all probes send requests once a day. I was wondering if there exists inconsistency between the document and the actual measurements? Any suggestions would be appreciated. Thank you! Best, Xiao

2 1

mesures prices
by POULET Benoit 19 Jan '24

19 Jan '24

Hello, we tried to build some monitoring with the Atlas ripe network but we were blocked because of the measure's prices. Our goal is to ping an IP address every 5 minutes, with 3 packets from 3 countries in EU. The UI of Atlas give theses cost : ######################################### One-off mesure : Costs PER PROBE 6 credits for each result of a single probe 6 credits per day per probe FOR ALL PROBES 18 credits for 3 probes in total ######################################### 5 min interval mesure : Costs PER PROBE 3 credits for each result of a single probe 864 credits per day per probe FOR ALL PROBES 2592 credits for 3 probes in total per day ######################################### We have 3 Atlas probes, connected 24/24, 7/7, theses probes provide us 34 944 credits / day. With theses credits we do : * 6 One-off mesures, done every 5 mins * 13 Regular mesures, 5 min interval We were surprised at how few measures we could afford we 3 Atlas probes. Are we missing something ? Perhaps we are miss understanding what is Atlas for. Regards.

1 0

Fwd: Your credits are decreasing dramatically!
by Lukas Tribus 12 Jan '24

12 Jan '24

Hello, the "Your credits are decreasing dramatically!" emails have always been a mystery to me. I always get them a few days after a "troubleshooting session" with a number of one-off measurements. Here's the latest one; on January 6th, between 14:00 and 16:00 UTC I made a number of one-off Atlas measurements. The youngest (latest) Requested Stop Time which matches Systems Stop Time is: 2024-01-06T14:35:02Z I did not request any other measurements, and I have no "continuous" measurements running currently. And yet, on January 10th 00:48 UTC I get an warning: > Our records show that you've consumed 40500 RIPE Atlas credits in the last 48 hours, or approximately 14.06 credits/minute. On January 11th, 01:56 UTC I get the same exact warning again: > Our records show that you've consumed 40500 RIPE Atlas credits in the last 48 hours, or approximately 14.06 credits/minute. The data in those emails is just wrong, I did not use any credits for at least 72 hours (first email) and at least 96 hours (second email). It looks like already stopped one-off measurements are used for predictions not only of the future but for the past 48 hours as well? This is not a first, I got many of those erroneous messages in the past. Thanks, Lukas ---------- Forwarded message --------- From: RIPE Atlas <no-reply(a)ripe.net> Date: Thu, 11 Jan 2024 at 02:56 Subject: Your credits are decreasing dramatically! To: Lukas Tribus <lukas(a)ltri.eu> Dear RIPE Atlas probe host, Our records show that you've consumed 40500 RIPE Atlas credits in the last 48 hours, or approximately 14.06 credits/minute. We're pleased that you find the user-defined measurements useful and encourage you to keep conducting them! However, we'd like to give you a heads up that you have 2d 16h 6m before you will run out of credits at this rate. We recommend you stop some of your current measurements before this happens. If you do run out of credits, we will have to automatically stop running some of your measurements so that you do not reach a negative balance. If you would like to continue running a large number of user-defined measurements, you might want to consider applying for another probe or sponsoring a block of probes in order to earn more credits. Learn more about sponsoring probes at https://atlas.ripe.net/get-involved/become-a-sponsor/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team

3 3

Open positions at HPI, Potsdam
by Vaibhav Bajpai 05 Jan '24

05 Jan '24

Dear colleagues, I am looking for Postdocs and PhD students to bootstrap a research group on data-intensive Internet computing at the Hasso Plattner Institute. These are full-time positions in the Berlin metropolitan area. We do systems research, and publish papers at the intersection of Internet measurements, security and privacy. For instance, we actively use RIPE atlas in our measurement projects. The work place is in Potsdam, Germany. Interested candidates, please feel welcome to send me your application directly via E-mail (vaibhav.bajpai(a)hpi.de) Kind regards, -- Vaibhav ------------------------ Prof. Dr. Vaibhav Bajpai, www.vaibhavbajpai.com

1 0

Thanks!
by Ernst J. Oud 04 Jan '24

04 Jan '24

Hi, I know I was a bit harsh commenting about the degraded performance of Atlas the last couple of days. Therefore herewith also kudos now that the problems appears to be solved. I guess a number of people have worked hard on the issue. Appreciated! Ernst J. Oud

4 3

"Thinking About Internet History"
by Stephane Bortzmeyer 02 Jan '24

02 Jan '24

Among the things to preserve for future studies of Internet infrastructure and connectivity, this interesting article mentions Atlas measurements. https://content.cooperate.com/post/internet_history/

1 0

RIPE Atlas Quarterly Planning Q1 2024
by Adonis Stergiopoulos 20 Dec '23

20 Dec '23

Dear colleagues, We have published our next quarterly plans for RIPE Atlas on our website: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue discussing the five proposals for changing the RIPE Atlas behaviour and working on renewing the big data backend. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Adonis Stergiopoulos Senior Marketing & Communications Officer RIPE NCC

1 0

auto probe renewal
by POULET Benoit 13 Dec '23

13 Dec '23

Hello, When I start a never-ending ping measurement with several probes like 20. What happened if several probes are going off-line ? Will Atlas remove the probes who are dead, and assign new to the measurement ? Or will the measurement die slowly ? I tried to find the answer in the documentation, without success. Thanks.

3 4

Anchor reprovision
by Andrew Asciutto 05 Dec '23

05 Dec '23

Atlas mailing list, Back in September I noticed my Ripe Atlas software probe corrupted itself after an unscheduled DC power outage. I reinstalled the Ripe Atlas anchor software, and left all network settings the same as last time but it doesn't look like it connected back up to RIPE. Any ideas? Anyone with a similar experience? Thanks, Andrew Asciutto Network Engineer https://www.as1003.net <https://www.as1003.net>

3 3

The role of aggregators in RIPE Atlas
by Robert Kisteleki 01 Dec '23

01 Dec '23

Dear all, We've just published a proposal about recognising the role of "aggregators" in RIPE Atlas: https://labs.ripe.net/author/kistel/the-role-of-aggregators-in-ripe-atlas/ We would be very happy to see discussions about this here on the mailing list, on the RIPE NCC Forum, or live at RIPE87. Regards, Robert Kisteleki RIPE NCC

3 2

BADMD-APP error for v3 probe #25855
by Hans Kuhn 23 Nov '23

23 Nov '23

Hi, I'm trying to resurrect a v3 probe that had a status of "Bad Firmware". I did the usual: Unplug the probe from its power source Remove the USB stick from the probe Plug in the probe WITHOUT the USB stick Wait for ten minutes Insert the USB stick I've tried 3 different 8G USB drives and they all give the same result, which is the BADMD-APP-5080 and BADMD-KERNEL-1110 error in the SOS log. Is there anything that I can do to resurrect this probe? I'm not afraid to TFTP... Thanks! Hans

4 6

RIPE NCC measurement data retention
by Robert Kisteleki 22 Nov '23

22 Nov '23

Dear all, We've just published a proposal about establishing principles around how the RIPE NCC retains and publishes Internet measurement data, specifically in RIS and RIPE Atlas: https://labs.ripe.net/author/kistel/ripe-ncc-measurement-data-retention-pri… We would be very happy to see discussions about this here on the mailing list, on the RIPE NCC Forum, or live at RIPE87. Regards, Robert Kisteleki RIPE NCC

1 0

Disconnect notification
by Ernst J. Oud 21 Nov '23

21 Nov '23

Hi, One of my ISP’s had an outage today, which made my probe on that connection report the disconnect by email. Fine, but the question popped up why a probe cannot be configured to send an email when it is able to connect again. Could this be implemented in the future perhaps? Regards, Ernst J. Oud

4 4

sharing access
by Randy Bush 20 Nov '23

20 Nov '23

how can i share access to the probe management page(s) with someone? randy

1 1

New coverage and statistics page
by Stephen Suess 16 Nov '23

16 Nov '23

Hi Atlas Friends, As part of our continuing improvements to the Atlas UI, we have just pushed a major reworking of the coverage and statistics page. Among the improvements: - Cleaner, simpler interface - Vastly improved loading time - Single map integrates layer toggles for connected, disconnected and percent coverage - Top ASNs / Prefixes / Countries section are now clickable pie charts allowing you to see items in relation to each other or the entirety - Reworked line charts for users, probes, anchors - As with other Atlas improvements, this is now completely client side (except for the API getting data) You can find the new page at https://atlas.ripe.net/coverage/ Hope you enjoy, please let us know what you think. Thanks! Stephen RIPE Atlas UI

6 9

New Atlas app Beta UI
by Stephen Suess 16 Nov '23

16 Nov '23

Hello Atlas fans, For quite some time we have been working towards a plan to separate Atlas into three distinct components: 1. The Atlas “app” 2. The Atlas promotional pages 3. The Atlas (technical) documentation The idea with this scheme was to make each more useful on their own, and not to get in the way of or confuse the others, because they each serve different purposes. This structure has been applied over several apps and services at RIPE NCC, and has been something that many teams have slowly been working towards over the past few years. The Atlas technical documentation has been in production for quite some time now (and you can check it out at https://atlas.ripe.net/docs/). And the promotional pages are being worked on and will hopefully roll out in the new year. That leaves the app. By Atlas “app”, we mean a simplified interface for interacting with the main functions of Atlas. This includes measurements, probes, anchors, credits as well as some stats. We are starting to build this simplified interface, and there is an early beta that we are releasing that we would very much like your feedback on as we develop it. Here are some of the highlights: 1. A much simplified menu structure that hopefully makes it easy to find what you need 2. A personalised dashboard that will show you cards of information related to you and your role(s). 3. On the dashboard will also be some utilities that we are developing, the first of which is an early quicklook measurement tool. You enter your target and will see a live streamed map of responses as they arrive. 4. For those of you with the Ambassador role, the dashboard contains a card that will allow you to manage the probes you have given out, and message hosts. 4. The app aims to be fully client side at launch. Many of our recent page changes on the production site have been with this in mind, and they are at the forefront of the beta interface 5. Although not yet active, there will soon be a personal preferences page that you can use to configure several aspects of the interface to your liking You can visit the beta at https://beta-ui.atlas.ripe.net/ We are very early days here (and there will definitely be bugs), but we wanted to release this beta to the public to start a conversation about what the Atlas app can and should be. Many things will change on the site over the coming weeks, and we welcome your feedback and suggestions on how to make this better and more useful to you. If possible please provide your feedback in the forum post created specifically for this purpose (https://forum.ripe.net/t/new-ripe-atlas-app-beta-ui-feedback/747) Thanks! Stephen RIPE Atlas UI

1 0

Re: [atlas] Probe with ever changing upstreams/ASs?
by stephane＠mouton.com 12 Nov '23

12 Nov '23

+ripe-atlas Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Thursday, 3 August 2023 at 17:49 To: Carsten Schiefner <carsten(a)schiefner.de> Subject: Re: [atlas] Probe with ever changing upstreams/ASs? Hi! It depends on use case. For me, such probe would be fine for one-off measurements but for continuous measurements I would filter out such probe to avoid noise in data. However, when I looked on freifunk.net map I noticed that this network span across Germany, Switzerland, and Austria so even for one-off measurements usage of such probe is questionable because I never know where remote end of the tunnel is. If I understand correctly it can jump from country to country every day. In other words, such probe would be tricky to handle and user will have to be aware how such probe behave to properly handle data generated by it. Probably new system tag would be needed to mark such exotic probe. Regards, Grzegorz From: Carsten Schiefner <carsten(a)schiefner.de> Date: Thursday, 3 August 2023 at 15:07 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe with ever changing upstreams/ASs? All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C. -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at… [1] -- 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 Links: ------ [1] https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…

1 0

Re: [atlas] Probe with ever changing upstreams/ASs?
by stephane＠mouton.com 12 Nov '23

12 Nov '23

+ripe-atlas Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Thursday, 3 August 2023 at 17:49 To: Carsten Schiefner <carsten(a)schiefner.de> Subject: Re: [atlas] Probe with ever changing upstreams/ASs? Hi! It depends on use case. For me, such probe would be fine for one-off measurements but for continuous measurements I would filter out such probe to avoid noise in data. However, when I looked on freifunk.net map I noticed that this network span across Germany, Switzerland, and Austria so even for one-off measurements usage of such probe is questionable because I never know where remote end of the tunnel is. If I understand correctly it can jump from country to country every day. In other words, such probe would be tricky to handle and user will have to be aware how such probe behave to properly handle data generated by it. Probably new system tag would be needed to mark such exotic probe. Regards, Grzegorz From: Carsten Schiefner <carsten(a)schiefner.de> Date: Thursday, 3 August 2023 at 15:07 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe with ever changing upstreams/ASs? All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C. -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at… [1] -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas Links: ------ [1] https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…

1 0

decommission of virtual probes
by ripe.net＠toppas.net 07 Nov '23

07 Nov '23

Hello folks, dear Atlas team, I would like to discuss the case, where a virtual probe is decommissioned because the place where you ran it will no longer be available. For example, a VPS which you have rented somewhere, but you've decided to cancel that service. Does it make sense to create and keep a backup of the virtual probe, so that you can re-deploy it later (with another AS)? Or is it better to delete the virtual probe and create a new one? Also: is there an official way to decommission a virtual probe permanently? I felt like this could be interesting for other people too, so i decided to discuss this question publicly. BR, Simon

2 1

Re: [atlas] decommission of virtual probes
by ripe.net＠toppas.net 06 Nov '23

06 Nov '23

My bad. non-hardware probes are called "software probes" non-hardware anchors are called "virtual anchors" I mixed that up. I meant software probes. BR, Simon On 06.11.23 21:16, Ernst J. Oud wrote: > Define “virtual probe” please? Do you mean a SW probe? To me a SW probe is as real as a HW probe. > > Or do you mean an abandoned probe? > > Regards, > > Ernst J. Oud > >> On 6 Nov 2023, at 20:53, Simon Brandt via ripe-atlas<ripe-atlas(a)ripe.net> wrote: >> >> Hello folks, dear Atlas team, >> >> I would like to discuss the case, where a virtual probe is decommissioned because the place where you ran it will no longer be available. For example, a VPS which you have rented somewhere, but you've decided to cancel that service. >> >> Does it make sense to create and keep a backup of the virtual probe, so that you can re-deploy it later (with another AS)? Or is it better to delete the virtual probe and create a new one? >> >> Also: is there an official way to decommission a virtual probe permanently? >> >> I felt like this could be interesting for other people too, so i decided to discuss this question publicly. >> >> BR, >> Simon >> >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net >> https://lists.ripe.net/mailman/listinfo/ripe-atlas

1 0

Customs value of Atlas Probe
by Christopher Munz-Michielin 06 Nov '23

06 Nov '23

Hi All, I'm fighting a bit of a battle over the value of the ripe atlas probe for the purposes of taxation (they are insisting it's value is more then $300 CAD and over $50 in taxes is owed to import it) and in order to fight this I need to provide proof of value, however, I obviously don't have a purchase receipt to show them. Is there any form that RIPE provides which shows the value of the Atlas probes for customs/import purposes that I can include with my case? Thanks!

2 2

New measurements listing page
by Stephen Suess 24 Oct '23

24 Oct '23

Hello Atlas friends, As part of our continuing improvements to the Atlas UI, we have just pushed a major update to the measurements listing page. Among the improvements: - Cleaner, simpler interface - Improved filtering and sorting - Views are sharable with all params - Improved paging - Favourite and Hide actions - and quite a bit more You can find the new page at https://atlas.ripe.net/measurements/ or in the menu under "Measurements", and the old page will remain available for a few weeks at https://atlas.ripe.net/measurements/legacy/. Your input and feedback is highly appreciated, you can reply to this message or directly to me or in the forum at https://forum.ripe.net/t/new-ripe-atlas-measurement-listing-page/725 Thanks! Stephen RIPE Atlas UI

1 0

Delays in web interface
by Ernst J. Oud 21 Oct '23

21 Oct '23

Hi, I experience that lots of graphs in the web interface don’t display, sometimes when clicking on the built-ins tab the “loading” never finishes etc. Measurements appear to run fine. Any performance problems in the back end or ripe stat? Regards, Ernst J. Oud

1 1