October 2024 - ripe-atlas - mailman.ripe.net

Wrong IPv6 detected for my probe
by Matteo Bonora 23 Oct '24

23 Oct '24

Hello everyone, maybe it's me that I have an unusual configuration, but I was wondering if any of you are experiencing the same behavior... For IPv6 I use in my local network an ULA prefix, to maintain an abstraction layer between my network and the IPv6 prefixes assigned by my ISPs. Each ULA address of any of my devices gets translated via NPTv6 by my router to a global address compatible with my ISP assigned prefix. My probe as well has an ULA address and a public/global address that gets correctly detected by Atlas servers via IP Echo Service, but is the wrong IP that gets elected as the reference address within the Probe Address Discovery section. The correct one should come from IP Echo Service, but the ULA seems to be the preferred one. [image: 2024-10-23_00h07_14.png] Any ideas? Is there a way to force the selection of the IP Echo one? Thanks Matteo

3 2

Re: Changes to RIPE Atlas API keys
by Ponikierski, Grzegorz 22 Oct '24

22 Oct '24

Hi! > * 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. It’s October 2024. Is this plan still valid? I admit that I have a bunch of tools which use URL form which I would have to update to use "Authorization" header. Regards, Grzegorz From: Robert Kisteleki <robert(a)ripe.net> Organisation: RIPE NCC Date: Tuesday, 19 September 2023 at 12:11 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Changes to RIPE Atlas API keys 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 -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at…<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

2 3

webui dashboard is hard to use on mobile
by Sulev-Madis Silber 21 Oct '24

21 Oct '24

there has been some updates iirc but same issue remains got my busted v1/v2 -> v5 shipped and went to preconfigure it at dashboard, in phone, on android firefox, it's extremely hard to scroll dashboard without it dragging all the elements all over place it's also hard to open and close them, keep clicking 10 times around the open/close element and finally got it to react could maybe someone verify it, and fix maybe. perhaps lock it down somewhere? you must use some touch device for this as issue is in hold and drag really annoying each (rare) time i go there

3 2

HTTPS resource record.
by dikshie 18 Oct '24

18 Oct '24

Hi, Any plan to support HTTPS resource record in DNS measurement? example: ------------------- ;; ANSWER SECTION: www.ripe.net. 60 IN CNAME www.ripe.net.cdn.cloudflare.net. www.ripe.net.cdn.cloudflare.net. 300 IN HTTPS 1 . alpn="h3,h2" ipv4hint=104.18.4.245,104.18.5.245 ipv6hint=2606:4700::6812:4f5,2606:4700::6812:5f5 --------------------- Best Regards, -- -dikshie-

2 1

Re: Change git to repository (Randy Bush)
by ripe＠nurfuerspam.de 14 Oct '24

14 Oct '24

> and how does one "using the UI to replace the key?" On your probe's management page (e.g., https://atlas.ripe.net/ probes/1000006/), at the bottom of the page under the "General" tab, there is the option to add a new key. On a 5080 software probe, unless paths were changed during the build, one should find the public ssh key under /var/atlas-probe/etc/probe_key.pub (at least that's where it is on my Debian 12 system).

2 1

Change git to repository
by Jimmy Huybrechts 14 Oct '24

14 Oct '24

Hi, Currently my software probe on Debian 12 is using the git repository as there was no official deb when mine was deployed. Now I wish to change it out for the official repo, how can this be done? Or should I register the repository one as a new probe? -- Jimmy

4 6

Software Probe version 5100
by Michel Stam 07 Oct '24

07 Oct '24

Dear colleagues, We’d like to inform you that a new version of the software probe has been released, version 5100. Please find the changes below: All platforms As of this version, the ripe-atlas-probe-measurements repository on GitHub is deprecated. Its code has been merged into the ripe-atlas-software-probe repository Package can now be built with arbitrary shell shebangs. Note that only OpenWRT ash and bash are officially supported Bug fixed where permissions are wrong when systemd is disabled (reported by César de Tassis Filho <ctassisf(a)gmail.com>) A new code signing key has been introduced. It only signs Debian packages currently, but will sign the RHEL packages in an upcoming release as well. The current RHEL key will then be deprecated. This release already supports code signed using the new key Software probes Streamlined deployment on RHEL CI/CD systemd unit ownership moved to probe and anchor packages Debian 11/12 x86_64 support added Support for OpenWRT software probes and the hardware probes v3, 4 and 5 will be added in a future release. If you run RHEL or Debian, we encourage you to upgrade to the latest version: https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Linux-… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/RHEL8-… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/RHEL9-… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Debian… https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/Debian… Best regards, Michel Stam, RIPE Atlas development team

2 3

Some built-ins are not working anymore
by Ernst J. Oud 07 Oct '24

07 Oct '24

I guess due to the new controller infra, the built-ins measurements for: ctr-ewr01.atlas.ripe.net ctr-fnc01.atlas.ripe.net ctr-sin02.atlas.ripe.net are invalid now? They don’t produce data since October 1st it seems. Will the new controllers be included as built-ins? Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

2 1

About the recent connection problems
by Robert Kisteleki 02 Oct '24

02 Oct '24

Dear colleagues, As many of you have noticed, we have been experiencing some technical issues with RIPE Atlas over the past few weeks. I would like to explain some of these in this email. Earlier this year, we began the process of migrating our infrastructure from our on-premise and co-located data centres to a cloud-based solution. Significant work has gone into rewriting code for multiple components and to renew the underlying infrastructure, to containerise and adapt it for the new cloud environment. In the process of this, we have encountered unforeseen bugs and bottlenecks. The RIPE Atlas team has been working to fix these issues as we find them. We are largely done with the migration of the controlling infrastructure so we hope to have a more stable system in the coming days. We are deploying new code and fixes fairly often to prevent these issues from arising, but it is possible that you might experience unexpected disconnects, but hopefully on a smaller scale than the past weeks. In the coming weeks, we will also begin the migration of the website (the user interface and the API). To clarify some questions that we heard on the list: - We will be looking for a solution to compensate credits for the missing connection times. - In the vast majority of cases, we don’t expect data loss when probes are not connected. The measurement results are delayed until the probes can reconnect and submit the results. - We apologise for the many connection and disconnection emails you might have received when your probe is disconnected. Please note that you can change your email notification preferences on your probe status page. I understand that many of you will want a more detailed explanation. We will be publishing an article on RIPE Labs, and we plan to present our work at the MAT Working Group session at RIPE 89. Regards, Robert Kisteleki RIPE NCC

1 1