- ripe-atlas - mailman.ripe.net

Minor nit in first monthly probe report after registration
by ripe＠nurfuerspam.de 01 Jul '24

01 Jul '24

Resent, hopefully without HTML formatting this time (sorry for earlier) Hi, A minor nit with regards to the availability time in the monthly probe report for the month the probe was registered in: The total availability indicated is bogus as the whole month is taken as the calculation interval as its basis, rather than only the time since probe registration. Calculation interval : 2024-06-01 00:00:00 - 2024-07-01 00:00:00 Total Connected Time : 0d 14:40 Total Disconnected Time : 29d 09:19 Total Availability : 2.04% +------------------+---------------------+---------------+-----------------------+ | Disconnected for | Connected at (UTC) | Connected for | Disconnected at (UTC) | +------------------+---------------------+---------------+-----------------------+ | - | 2024-06-30 08:52:15 | 0d 00:36 | 2024-06-30 09:29:07 | | 0d 00:04 | 2024-06-30 09:33:30 | 0d 03:20 | 2024-06-30 12:54:07 | | 0d 00:01 | 2024-06-30 12:55:49 | 0d 00:04 | 2024-06-30 13:00:17 | | 0d 00:04 | 2024-06-30 13:04:44 | 0d 01:35 | 2024-06-30 14:39:54 | | 0d 00:01 | 2024-06-30 14:40:55 | 0d 00:32 | 2024-06-30 15:13:10 | | 0d 00:10 | 2024-06-30 15:23:30 | 0d 00:02 | 2024-06-30 15:26:26 | | 0d 00:05 | 2024-06-30 15:32:13 | 0d 08:27 | Still connected | +------------------+---------------------+---------------+-----------------------+ I guess just an optical issue rather than a problem, maybe a bit misleading. The UI seems to take the fractional aspect into account, which seems more relevant. Connection Information Probe's birthday: 2024-06-30 Time Connected Percent Last Week 21h 11m 97.87% Last Month 21h 11m 97.87% All Time 21h 11m 97.87% Kind regards, R.

2 1

Minor nit in first monthly probe report after registration
by ripe＠nurfuerspam.de 01 Jul '24

01 Jul '24

1 0

[NTP measurements] Minimum offset if negative
by Stephane Bortzmeyer 28 Jun '24

28 Jun '24

Measurement #74488034 says on <https://atlas.ripe.net/measurements/74488034>: "Min Offset: -1 173,799". Since offsets can be positive or negative, I suggest it is not a good idea to take the minimum without first removing the sign. Here, the real minimum offset was -0.000345 (the closest from the server) and the maximum -1.173799 (the farthest from the server). (There is also a strange formatting on the Web, and a lack of units.)

3 5

[NTP measurements] Work with some servers but not all
by Stephane Bortzmeyer 27 Jun '24

27 Jun '24

I'm playing with NTP measurements and I observe that RIPE Atlas probes can talk to some public NTP servers but not all. See for instance measurements #74488034 (it works) and #74487872 (it fails). Testing with other NTP clients succeed with these two servers (ntp.nic.fr and ntp.netnod.se). I do not understand the reason for this difference. The servers which do work: ntp.nic.fr time.cloudflare.com time.google.com 0.pool.ntp.org ntp-p1.obspm.fr The servers which fail with RIPE Atlas probes but work otherwise: ntp.netnod.se time.nist.gov

1 0

[HTTP measurements] Units of timing?
by Stephane Bortzmeyer 27 Jun '24

27 Jun '24

When using "extended_timing" with HTTP measurements, in what units are tt*? I suspect that ttr is in seconds and the other two in milli-seconds but I want to be sure. (The Web interface does not display these values, it seems, but see measurement #74293060 if you want an example.)

2 2

[HTTP measurements] What is the use of query_string?
by Stephane Bortzmeyer 27 Jun '24

27 Jun '24

The documentation says that you can add a "query_string" parameter in a HTTP measurement but the anchor seems to ignore it?

2 3

IPv4 Built-ins fail while IPv6 work
by RIPE 26 Jun '24

26 Jun '24

Hi, My old hardware probe seems to have finally given up. So I installed a soft probe on my openwrt edgerouter-X, using the openwrt opkg packages. That seems to work except for all the IPv4 built-ins. I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and does not provide IPv6. The IPv6 built-ins all show data but the IPv4 ones show ‘No data available for the period’ From the shell I can ping the addresses used by the built-ins, the names also resolve. Any idea what the cause could be ? Or how to find the cause. Probe ID = 1008458 Running OpenWrt 23.05.3, r23809-234f1a2efa Package: atlas-sw-probe Version: 5080-2 Regards, Paul

2 4

Atlas UI updated
by Stephen Suess 25 Jun '24

25 Jun '24

Hello Atlas fans, We have just released an update to the UI that includes: - NEW: download transactions in credit history - NEW: added toggles to allow hiding no reply/no report results in measurements details results - CHANGE: rework sorting in measurements results details (min to max rtt, no reply, no report) - CHANGE: map markers now sort from highest RTT on bottom to lowest RTT on top - CHANGE: added summary detail for RTT to DNS measurement detail overview If you want to see the full list of what has changed, you can check the release notes here: https://atlas.ripe.net/docs/releases/website/2024-06-25.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

multiple probes down since Jun 24th?
by Andreas S. Kerber 25 Jun '24

25 Jun '24

Hi, our probe is reported down since yesterday: https://atlas.ripe.net/probes/7054/ Since I couldn't find a problem on our side and rebooting didn't change the status, I checked other probes (not mine) and they are reported down since the exact downtime as mine. Is there any kind of known problem at the moment? Other probes with the same downtime: https://atlas.ripe.net/probes/7040 https://atlas.ripe.net/probes/7052 https://atlas.ripe.net/probes/7063 https://atlas.ripe.net/probes/7067 https://atlas.ripe.net/probes/7068 -- Andreas Kerber (Senior IT-Engineer/Consultant) ask(a)idkom.de _______________________________________ IDKOM Networks GmbH Dieselstraße 1 * D-87437 Kempten (Allgäu) Tel.: 0831 59090-200 Fax: 0831 59090-90 www.idkom.de Registergericht: Amtsgericht Kempten (HRB 6359) Geschäftsführer: Benjamin Mayer * Klaus Giehl Diese E-Mail und alle mitgesendeten Dateien sind vertraulich und ausschließlich für den Gebrauch durch den Empfänger bestimmt!

6 5

repetitive 2fa authentication on every login
by ripe＠brite.cz 24 Jun '24

24 Jun '24

Hi team, https://atlas.ripe.net/probes/mine requires new login upon every browser open. It even requires 2FA every time. Is it possible to keep the session active for maybe a month, or at least do not ask 2FA every single time? I would think as services like gmail.com, portal.azure.com, account.synology.com, etc., do not require 2fa on every browser close and reopen, it may not be as crucial to perform 2fa every time I need to check if my probes are online? It becomes a bit annoying, especially me using mobile browser. Please consider. Thank you. Jiri

3 2

How long is a year?
by Edward Lewis 20 Jun '24

20 Jun '24

On my probe’s status page, there is an “All Time” “Time Connected” of 8y 343d 15h 30m. How many minutes are in a “y”? Context: in trying to illustrate uptime (number of 9’s) I wanted to show how long it would take to achieve different number of 9’s based on my probe’s history. (It’s only at one ‘9’ - 97%.)

3 4

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

19 Jun '24

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

2 2

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

19 Jun '24

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

2 1

Atlas UI updated
by Stephen Suess 10 Jun '24

10 Jun '24

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

1 0

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

07 Jun '24

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

1 0

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

07 Jun '24

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

1 0

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

01 Jun '24

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

2 1

Atlas UI updated
by Stephen Suess 28 May '24

28 May '24

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

1 0

TraceMON pages broken?
by Malte Tashiro 28 May '24

28 May '24

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

2 1

Delays?
by Ernst J. Oud 14 May '24

14 May '24

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

3 2

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

14 May '24

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

2 1

New Atlas UI launched
by Stephen Suess 13 May '24

13 May '24

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

1 0

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

13 May '24

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

1 0

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

10 May '24

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

1 0

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

08 May '24

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

4 3

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

08 May '24

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

2 1

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

04 May '24

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

3 3

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

02 May '24

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

12 17

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

25 Apr '24

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

3 2

Another research credit request
by Peter Thomassen 24 Apr '24

24 Apr '24

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

7 6

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

24 Apr '24

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

1 0

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

23 Apr '24

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

1 0

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

18 Apr '24

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

4 3

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

17 Apr '24

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

4 7

Reverse traceroute
by Hank Nussbacher 17 Apr '24

17 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