- ripe-atlas - mailman.ripe.net

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

Questions with regard to the measurement status and running time
by Jerome Mao 20 Oct '23

20 Oct '23

Hi RIPE Atlas Team and Community, I would like to know more about the status of measurements - I have scheduled a one-off ping measurement which utilized 15 anchors. I polled the measurement status and results from my local desktop to the restful API through cousteau Python lib. The results were returned to me in less than a minute, but it took around 13 minutes for the measurement to transition from "ongoing" to "stopped." On the other side, the time delta between the "requested start time" and "requested stop time" on the RIPE Atlas portal is 9 minutes. My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available? 2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal? 3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state? Thanks! Best, Jerome

3 3

HE "Supertraceroute" exposes ATLAS traceroute functionality to the public
by me＠natha.info 19 Oct '23

19 Oct '23

Hi all, As mentioned by Lukas, NLNOG Ring is also used in the "supertraceroute" project from HE. The NLNOG Board just published a statement regarding this on the NLNOG mailing list: http://mailman.nlnog.net/pipermail/nlnog/2023-October/003099.html Kind regards, Nathalie Trenaman (also on the NLNOG Board)

2 1

HE "Supertraceroute" exposes ATLAS traceroute functionality to the public
by Lukas Tribus 19 Oct '23

19 Oct '23

Hello, FYI HE's new "supertraceroute" exposes ATLAS traceroute functionality to the public: https://bgp.he.net/traceroute/ Other sources are (NLNOG) RING nodes and other projects. Interesting approach, not sure if I should be happy about this, but I guess HE is paying for it with Atlas credits. Lukas

2 1

NTP empty results ('result': [{'x': '*'}])
by Giovane C. M. Moura 12 Oct '23

12 Oct '23

Hi folks, I am getting some NTP results in the following format: 'result': [{'x': '*'}], Does anyone know waht is this supposed to mean? is it like the measurement did not run? See blob below: {'fw': 5080, 'mver': '2.6.2', 'lts': 20, 'dst_name': '186.155.28.147', 'dst_addr': '186.155.28.147', 'src_addr': '10.10.31.19', 'proto': 'UDP', 'af': 4, 'result': [{'x': '*'}], 'msm_id': 47867316, 'prb_id': 33745, 'timestamp': 1671799154, 'msm_name': 'Ntp', 'from': '85.238.41.3', 'type': 'ntp', 'group_id': 47867316, 'stored_timestamp': 1671799249}] thanks, /giovane

2 1

New measurement form is now live (and default)
by Stephen Suess 12 Oct '23

12 Oct '23

Hello Atlas Community, We have just pushed the release version of the new measurement form (that was formerly in beta) to production. It is now the default (and lives at the same url as the old form) and the old one has been renamed legacy and will remain available for a few weeks in the menu and linked from the new form. Please check it out and let us know if you find any issues. We really appreciate the feedback given by the community during the beta, it helped us evolve and improve the form significantly. You can find the new form at https://atlas.ripe.net/measurements/form/ Thanks! Stephen RIPE Atlas UI

1 0

Changes to RIPE Atlas API keys
by Robert Kisteleki 04 Oct '23

04 Oct '23

Dear RIPE Atlas users, We'd like to update you on some upcoming changes regarding API keys in RIPE Atlas. TL;DR nothing changes regarding how you can use your API keys in the short term - as long as you're actually using them. However, we'll change how unused or forgotten keys are handled as well as remove the less secure in-URL use of them. At the moment RIPE Atlas users can query their existing API keys via the UI and API, including the possibility to retrieve old keys. In order to improve the security of how we handle these, we'll introduce the following changes in October 2023: * The listing (retrieval) of keys will only reveal parts of the keys (enough to identify them) in the API as well as in the UI. * We'll add the ability to "regenerate" an API key, which will replace the secret UUID of the key while keeping exactly the same permissions. * Unused API keys will automatically be frozen after 1 year of not being used. Active keys (i.e. the ones that have been used at least once) will not be frozen. You still have the ability to save your keys until these changes are done and, as written above, you will be able to regenerate them later. We'll notify this list when the changes are about to be done. In addition, in order to further increase the security of our system, in the long run we'll make changes about how these API keys are communicated to the API: * At the moment the API accepts these either in HTTP headers ("Authorization" header) or in the URL (?key=xyz), although the Authorization header version has been documented as the preferred version for some time. * We'll deprecate and remove the ability to use the URL form in about a year (around October 2024). * We plan to send further reminders about this change over time, as well as reaching out to heavy users of the to-be-removed format. Regards, Robert Kisteleki RIPE Atlas team

1 1

RIPE Atlas Quarterly Planning Q4 2023
by Robert Kisteleki 04 Oct '23

04 Oct '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, Robert Kisteleki Principal Engineer RIPE NCC

1 0

Changes to RIPE Atlas API auth status codes on 2 Oct
by Chris Amin 02 Oct '23

02 Oct '23

Dear colleagues, Currently the RIPE Atlas REST API (https://atlas.ripe.net/api/v2/) returns a 403 Forbidden status code in two cases: * When a request requires authentication but the user has not provided any credentials, or has provided incorrect credentials * When a user has authenticated correctly, but they or their API key lacks the permissions needed for a particular request Distinguishing between these two cases is important because in the first case the client can potentially get access by authenticating, and in the second case there is no point in retrying authentication with the same credentials. In order to enable this distinction, and to generally conform to web standards and best practices, on Monday, 2nd October we will change the REST API so that a completely unauthenticated request will receive a response with a 401 Unauthorized status code. The 403 Forbidden status code will still be returned for users and API keys that are authenticated but lack the necessary permissions for the request. As a temporary migration measure, the API will keep the same behaviour (always return 403) if either: * The "Referer" header contains "RIPE Atlas Tools" and a version string <= 3.1.1, or * An "X-Compat" header is set and contains the string "auth-2022" This temporary measure is guaranteed to work for the rest of 2022, after which it will be removed and the API will always make the 401/403 distinction. Kind regards, Chris Amin RIPE Atlas team

2 4

Will probes catch up?
by Ernst J. Oud 21 Sep '23

21 Sep '23

Hi, Some of my probes, all on different providers, (for instance: https://atlas.ripe.net/probes/1005104/#tab-builtins) have not catched up after the recent disruption. Will this happen automatically? They are connected, streaming results are ok., so I guess I don’t need to restart them? Regards, Ernst J. Oud

2 1

Atlas fully down..
by Ernst J. Oud 20 Sep '23

20 Sep '23

Considering the fact that all of Atlas is completely down for more than 24 hrs., I find the silence a bit deafening. No status updates, nothing. Weird. Not up to RIPE standards. Regards, Ernst J. Oud

7 16

One-off measurements stopped after 5-6 minutes without results
by Gerdriaan Mulder 20 Sep '23

20 Sep '23

Hi list, A few hours ago (around 15:00Z), I launched some one-off measurements[1][2][3] on the platform for a select number of probes (based on ASN and region). The target in all three cases was 2a02:1807:1020:700::1 (no hostname, purely the address). Although the number of requested and participating probes varied a bit, it seems none of the measurements yielded any results. At the time I didn't look at recent posts on this mailing list, nor was I aware of this ongoing incident[4] on the Atlas backend. It seems like that incident might be the cause of the (current) unavailability of these results. It would be great if anyone can confirm that (viewing results of) user-defined measurements are affected as well. Aside, I suppose the following messages on "My RIPE Atlas Dashboard" are also caused by the mentioned incident[4]? --->8--- 2023-09-18 16:40 UTC Your probe #11nnn was automatically untagged as "system: Resolves AAAA Correctly" 2023-09-18 16:40 UTC Your probe #11nnn was automatically untagged as "system: Resolves A Correctly" 2023-09-18 16:20 UTC Your probe #11nnn was automatically untagged as "system: IPv6 Works" 2023-09-18 16:20 UTC Your probe #11nnn was automatically untagged as "system: IPv4 Works" ---8<--- Perhaps the incident page[4] can include a few lines of the current (estimated) impact, as well. Best regards, Gerdriaan Mulder [1] https://atlas.ripe.net/frames/measurements/60161706/ (default IPv6 traceroute) [2] https://atlas.ripe.net/frames/measurements/60162230/ (IPv6 traceroute, paris=0) [3] https://atlas.ripe.net/frames/measurements/60162753/ (default IPv6 ping) [4] https://status.ripe.net/incidents/wfd7qywz3v68

3 4

Issues with Atlas back-end
by Ernst J. Oud 19 Sep '23

19 Sep '23

Hi, From September 18th there is an issue with the Atlas back-end, already 9 hours delay. Built-ins show data until around 14:00 UTC. It is now midnight. I am confused, the status page (https://status.ripe.net/) at the bottom says: “Resolved - The backend team could restore the service level and with that issues in RIPEstat stopped as well. Sep 18, 15:11 UTC” It clearly is not resolved. On the top of that status page it says: “Investigating - We are experiencing issues with the RIPE Atlas backend and currently are investigating this issue. Sep 18, 2023 - 14:07 UTC” So what is the status? Regards, Ernst J. Oud

2 1

New Atlas Measurement Creation Form (BETA)
by Stephen Suess 18 Sep '23

18 Sep '23

Hello Atlas fans, As part of our ongoing User Interface renewal activity we've been working on a redesign of the measurement creation form. Today, we're excited to announce the release of this new form in beta, and we would love your feedback and suggestions as we continue to develop it. Notable improvements include: - A simplified and cleaner user interface. - Client-side functionality, eliminating the need for external libraries, websites, or APIs (except for cost calculations and final submit). - Enhanced performance. - Mobile-friendly design. - Clearer probe selection information. - Presentation of API specification with and without the cURL command. You can find the new form at https://atlas.ripe.net/mform or in the menu under "Measurements -> Create Measurement (BETA)". 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-measurement-form-beta/678 Thanks! Stephen RIPE Atlas UI

1 0