- ripe-atlas - mailman.ripe.net

RIPE Atlas Infra IP Rages
by Milad Afshari 20 Aug '24

20 Aug '24

Dear Atlas Team, I hope this message finds you well. Could you please provide the exact IP range(s) used by the RIPE Atlas infrastructure? This information is crucial for our ongoing network configuration. Thank you for your assistance. Best regards, Milad

6 7

Atlas UI update 2024-08-19
by Stephen Suess 19 Aug '24

19 Aug '24

Hello Atlas community, We have just released an update to the UI that includes (among other things): - NEW: Advanced search for probes and measurement listing pages - CHANGE: Header components with new icons to match ripe.net - CHANGE: Anchors cache updated on demand (instead of 24 hours) - CHANGE: Improved debounce, reduced error messaging on measurement form 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-08-19.html As always, we hope you find these changes useful and we welcome your feedback. Kind regards, Stephen Atlas UI

1 0

Strange behavior on UI
by Victor TALVAZ 09 Aug '24

09 Aug '24

Hi, I'm not sure but there is something incorrect on the UI; In Network tab => Connection History in the website, I have the feeling that the column Disconnected for/Connected for has been inverted. For instance, I was connected for 20hours, and now the UI displays that I was Disconnected for 20hours. Dunno if you see the same issue. Regards, Victor

2 5

[atlas]Recent UI changes
by Stephen Suess 08 Aug '24

08 Aug '24

Hello Atlas Users, We have released several updates to the UI over the past month. Here are some of the highlights: - Measurement overview tab: improved summary info for various measurement types and (in the case of dns) most observed answers filtering - Measurement results tab: multiple, non-modal, resizable traceroute popups, toggles for filtering of no reply and no report items, and better error messaging when there are multiple sub queries If you wish to consult an exhaustive list of changes, you can see everything at https://atlas.ripe.net/docs/releases/website.html We hope you find these changes useful and welcome any feedback or suggestions you have. Kind regards, Stephen Atlas UI

2 5

Re: v1 probe loses connection after a while (and webui needs more love)
by Sulev-Madis Silber 07 Aug '24

07 Aug '24

i meant there were recent updates to ripe atlas i noticed the recent power outage is separate issue but i noticed problems appearing at same time. as it is always powered, i'm suspecting it now had to reconnect or maybe it also reflashes new updates on boot, so now it's different. but i don't know what's happening here. hence the question!

3 4

Cannot download periodic measurements
by Shihan Lin 07 Aug '24

07 Aug '24

Hi all, I recently tried to download some public periodic measurements that I launched in May, but I find I cannot download the full result by API or by web interface. One is example is measurement 72054485, which is launched on May 20th. I transformed the start time and end time to timestamp, which is 1716250200 (2024-05-21 00:10) and 1716336540 (2024-05-22 00:09), and when I used the following API to download the results, it responds me with empty file. https://atlas.ripe.net/api/v2/measurements/72054485/results?start=171625020… I cannot download it either when I use the web interface. Any idea about how to solve it? Thank you! Best, Shihan

2 3

doctoral/postdoctoral scholarships at HPI, Germany
by Vaibhav Bajpai 06 Aug '24

06 Aug '24

Dear colleagues, Here (below) is an opportunity to apply for a doctoral/postdoctoral scholarship at the Hasso Plattner Institute in Potsdam, Germany. Deadline: 15.8.2024 At our chair, we do systems research, and publish papers at the intersection of Internet measurements, security and privacy - that are directly relevant for the network operations community. Folks interested in working at our chair can indicate so in the application. Kind regards, — Vaibhav ------------------------ Prof. Dr. Vaibhav Bajpai, www.vaibhavbajpai.com ----------- Hasso Plattner Institute in Potsdam, Germany "Data Science and Engineering" https://hpi.de/en/research/cooperations-partners/research-schools.html The Hasso Plattner Institute (HPI) at the University of Potsdam is one of Germany’s top-ranked computer science institutes. Its PhD school "Data Science and Engineering" currenty supports 20 PhD students. Annually, we seek to add talented young researchers and offer 10 full Ph.D. and Postdoc Scholarships for a support of up to four years in our Potsdam location, on the border of Berlin. Students and Postdocs enjoy a great research environment, close mentorship by professors and postdocs, interaction with many peers, enormous computing power with HPI’s Data Lab, and significant travel funding. HPI faculty and their research groups ensure high quality research and will supervise you. Applications must be submitted at https://hpi.de/en/research/cooperations-partners/research-schools/scholarsh… by August 15, 2024. Please include the following documents: - Curriculum vitae and copies of certificates/transcripts - Brief research proposal, ideally mentioning the suitable HPI research groups you would like to work with - Work samples/copies of relevant scientific work (e.g., master's thesis or scientific papers) - Letter(s) of recommendation and any other supporting documents More information about the program and the application process is at https://hpi.de/en/research/cooperations-partners/research-schools/scholarsh… -----------

1 0

Lot of disconnects for Probe #27262
by Victor TALVAZ 05 Aug '24

05 Aug '24

Hi, Since some days i suffer for highly disconnects, connections to RIPE Atlas are disconnected every 10 minutes, or 50 but nothing more. I tried to change USB stick, and tried to put it on another switch/router. Seems the same. I have tools to monitor my FTTH line from another place, and it looks stable on both IPv4/IPv6. I see the disconnects but there is no alert sent in SOS History and the Probe doesn't reboot. I wonder what more I can do to see the issue ? Can it be an issue on Atlas side ? Maybe somebody from the RIPE see more infos that what I see. PS: I can see dates on connect/disconnect that change sometimes, it's really weird. Thanks for your help, Victor Talvaz

1 2

Re: v1 probe loses connection after a while (and webui needs more love)
by Sulev-Madis Silber 04 Aug '24

04 Aug '24

and, it also seems to try on v6, gets reply but doesn't seem to get connection up for some reason

1 0

v1 probe loses connection after a while (and webui needs more love)
by Sulev-Madis Silber 04 Aug '24

04 Aug '24

i have a old probe here. it's v1 or maybe it was v2. anyway... there were recent updates to system and i had to take everything off power for a few hours. after i put i back and it really is always on here, despite being home. the probe didn't reconnect. i don't have it on pdu. i have never needed it to cycle it before in previous 11 years. taking power off fixed it. now it's down again while on power and network. i went to looked what my atlas vlan does and found probe having both v4 and v6. and looks like it periodically tries to reconnect to ssh, gets reply and then... what happens next? it reports fw issue and trying to reconnect. but what kind of issue suddenly appeared when i have done none of fw changes. it's connection is via fbsd box i have full control over. can somebody check wtf is it and maybe fix it if needed. or maybe it just is too old? it works tho. i'm amazed how long it has been running. before next power cycle, can somebody diagnose it. it seems to connect out well? but just v4 i see. v4 is natted there while v6 is native and routed directly. probe id is 4415 p.s.: new webui tiles are really easy to accidentally mess up with finger on phone screen. never know when you scroll page and when you drag and drop. it's annoying

1 0

Probe #7030 may have specified the wrong location
by Marek Küthe 04 Aug '24

04 Aug '24

Hello, I noticed the probe #7030 [1] during the measurement #76522525 [2]. It has China as its location. However, the probe itself probably belongs to AS23961 [3]. You can see their locations on their website [4]. However, the probe does not appear to be in China, but in Hong Kong. Hong Kong is listed as an extra country/region in the RIPE NCC Atlas and I think this should be used accordingly so as not to falsify results. Could someone adjust the location? Regards Marek Küthe [1] https://atlas.ripe.net/probes/7030 [2] https://atlas.ripe.net/measurements/76522525 [3] https://bgp.tools/as/23961 [4] https://www.misaka.io/services/mc2 -- Marek Küthe m.k(a)mk16.de er/ihm he/him

1 0

REST API: Optional Fields for DNS Measurements
by Richter, Robert 03 Aug '24

03 Aug '24

Dear fellow RIPE Atlases, I am looking for the full definition of all optional field of the RIPE Atlas REST API for creating measurements. Especially the one for creating a DNS measurement. I only find the one defining the required attributes for a DNS measurement. But is there also a list constituting the optional fields? Best regards, Robert

2 1

RIPE Atlas data backend maintenance on 29 July 2024
by Francesco Iannuzzelli 29 Jul '24

29 Jul '24

Dear RIPE Atlas users, On 29 July 2024, between 9:00-18:00 (CEST), we will carry out planned maintenance on the data storage backend of RIPE Atlas. During this time, RIPE Atlas will be available but will serve stale data until work will be completed. Results for existing measurements will still be collected and stored. Measurement scheduling will be available but new measurements will be executed after the maintenance window. Results streaming will continue unaffected. We apologise for the inconvenience this may cause. Best regards, Francesco RIPE Atlas Team

1 1

[atlas]Installing Software Probe
by Milad Afshari 22 Jul '24

22 Jul '24

Dear RIPE Atlas Team, I encountered the following error while trying to download the RIPE Atlas software probe from the RIPE NCC GitHub repository: fatal: remote error: upload-pack: not our ref d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f fatal: Fetched in submodule path 'probe-busybox', but it did not contain d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f. Direct fetching of that commit failed. Can you please assist me with this issue? Kind regards, Milad Afshari

3 4

[atlas]API Not Working
by MARC BOSCH MARTINEZ 21 Jul '24

21 Jul '24

Hi all! Is anyone having problems issuing SSL measurements from the API? Seems that issuing them via the website works fine, but I've been having issues lately with the ones that I created using the API, leading to measurements in which all or most probes state "No Report Available". Best, Marc

2 1

[atlas]results page empty
by Marco Moock 16 Jul '24

16 Jul '24

Hello! https://atlas.ripe.net/measurements/75882685/results If I try to access the results, the page is empty. I tried Pale Moon and MS Edge. In Tor Browser, I can access it. Is something faulty at my side or is that a general problem? -- kind regards Marco

3 2

[atlas]Can not target google.com with periodic measurement
by Malte Tashiro 15 Jul '24

15 Jul '24

Hi, there seems to be something wrong (?) with the measurement creation process, or maybe some rules have changed? I'm trying to schedule a toy measurement to google.com, however, as soon as I set the timing to periodic, I get the error message: "We do not allow more than 25 concurrent measurements to the same target: google.com" I am not running any measurements at the moment. This behavior is independent of the measurement type (ping, traceroute, SSL) and the number of probes (error appears with one probe requested). It seems to solely be a problem of the timing. So far this message only appears for google.com and 8.8.8.8, other targets work. If I schedule the measurement in the future, I can actually submit it, but get a "Scheduling denied" measurement, for example: https://atlas.ripe.net/measurements/75418006/details I don't know if this is related, but it seems like somebody is hammering Atlas with a large number of geolocation measurements (500 probes per measurement) and DNS lookups (1 probe) at the moment. In the last hour 5582 measurements were scheduled, which is 1.5 measurements per second! Best, Malte

5 7

New status field in probes API, probe archive API
by Johan ter Beest 13 Jul '24

13 Jul '24

Dear Atlas hosts, A while ago we introduced the option for hosts to write off their probes in case they were sure it was never going to be connected again. For instance if it was broken or lost in the mail, a software probe you only used for testing. etc. This written off status was recorded in the database and we show it on the current probe page but it was not reflected in the probe API or on the probe archive API. Starting today, this will change. There is now a new status ID: 4 in the probe API and after we create the probe archive for today, this will also be visible there. Sometime today we will update the status field on the previously written off probes. This will add roughly 5500 probes to this status and will lower the number of abandoned probes with the same amount. Please let us know if you notice any unexpected behaviour. We hope that this change will make the status of probes more clear to both hosts and users. Happy measuring! Johan ter Beest RIPE Atlas Team

3 4

Request RIPE Atlas Credit Donation
by Nishant Acharya 12 Jul '24

12 Jul '24

Hello All, I am Nishant, a PhD student at the University of California, Davis—apologies for spamming the mailing list. I am working on a measurement research project that requires longitudinal analysis of Internet exchange points which requires an active traceroute campaign that we plan to do via RIPE Atlas. I have some credits to start the measurement but, I would require around 50 million more credits to complete the measurements. Therefore, I am reaching out for help. It would be great if some of you could offer me some RIPE Atlas credits. My account at RIPE NCC is on this email: nacharya(a)ucdavis.edu Sincerely, Nishant Acharya

3 3

[atlas]New Probes | Angola Cables
by Inacio Jose 09 Jul '24

09 Jul '24

Dear RIPE, Kindly help us adding these new probes to my account (Angola Cables). 1. Probe ID:64207 2. Probe ID:65186 Regards, Atenciosamente / Best Regards [cid:0a27b96e-d1a9-4669-83f3-aaee42ad1508.jpg] [cid:barra1transaprente(1)_52615b8f-bb3f-4ceb-92b4-beb18ad7e375.png] Inacio Jose Analista I | Analyst I mob: +244927686227 inacio.jose(a)angolacables.co.ao [cid:barra2transparentenova_ef83f4cd-cee1-4937-bd3b-9911b5eb9df3.png] [cid:LOGO_AC-01_8efd9d25-4916-4057-9ad2-070a690665c2.png] [cid:QRbfe18fad-af5c-4a2a-8d42-f31c5794acbb.png] https://www.angolacables.com<https://www.angolacables.com/> | AS 37468 [cid:ICONES-05_e6989344-99c6-4ded-91b2-748e677220a3.png] <https://www.facebook.com/AngolaCables/> [cid:ICONES-04_5f25e789-1a24-4f5a-8aad-26c0930ba4f5.png] <https://www.linkedin.com/company/angola-cables/mycompany/> [cid:ICONES-03_e5b5ac42-6918-4aec-a29f-caac77f4e32c.png] <http://twitter.com/angola_cables> [cid:ICONES_Prancheta1_02073217-a9bc-45f0-8970-5790a23a3b0a.png] <https://www.instagram.com/angolacables/?hl=pt> [cid:ICONES-02_1c4e151a-ff45-4b93-9f4d-9d5d4ae45f04.png] <https://www.youtube.com/channel/UC5ePxWOmrAT-HYxBPr4dNfg> . <https://services.angolacables.co.ao/meet-angola-cables-at-capacity-middle-e…>[cid:assinatura-saplancamento_71020ae9-fdc6-4150-8cb1-4ee8d5ad16d3.jpg]<https://nivel-one.com/> Antes de imprimir esta mensagem, pense no meio ambiente. | Please consider the environment before printing this email. NOTA DE CONFIDENCIALIDADE: Esta mensagem (e eventuais ficheiros anexos) é confidencial e deverá ser lida apenas por aqueles a quem ela é dirigida. Se não é o destinatário da mesma, por favor, apague a mensagem do seu computador e destrua quaisquer cópias. É proibida a sua divulgação ou cópia sem a autorização da Angola Cables. DISCLAIMER NOTICE: This message (and any files attached) is confidential and should only be read by those to whom it is addressed. If you are not the intended recipient, please contact Angola Cables or delete the message from your computer and destroy any copies. Any distribution or copying without our prior permission is prohibited.

2 1

Bug reports about Atlas
by Stephane Bortzmeyer 05 Jul '24

05 Jul '24

It seems that writing to atlas(a)ripe.net does not go to the Atlas team, but to a generic RIPE-NCC helpdesk, which knows noting about Atlas and sends back funny, but unrelated answers. What is the preferred way to report bugs about Atlas?

2 1

Missing user tags
by Stephane Bortzmeyer 04 Jul '24

04 Jul '24

We all know that user tags are imperfect and there is not a lot we can do (except pinging from time to time the hosts, like ICANN does with "Keep your social data up-to-date for your domain", with mixed success). One of the problems is that people tag correctly (I hope so) but do not always tag when it would be useful. For instance, the tag "nat" is sometimes given to probes without NAT (see for instance probes 1000929, 1005290, 1008281 or 50663) but the opposite is much more common. When requesting a measurement withOUT tag "nat", 3/4 of the selected probes have a RFC 1918 IP address (see measurement #74862711) and are certainly NATted. It seems that for many hosts, "nat" is the default.

3 2

Re: [atlas] Atlas probes in non-production networks
by Ponikierski, Grzegorz 02 Jul '24

02 Jul '24

Since we talk about usage of public service, I think that there is nothing to hide. Let me answer all questions. Problem refers to these PCCW AS3491 probes: 7007 7010 7032 7079 7080 7172 7198 1002754 1002771 1002785 1002844 1003737 1005609 They are are virtual anchor and software probes. PCCW has more probes but according to my data they are fine. Problem is observed for IPv6 routing. You can check built-in IPv6 traceroutes towards F root server. You can see that everything is routed into link between PCCW and HE AS6939 in Kuala Lumpur, MY. If you check PCCW routing towards F root server using their looking glass (so their production network) everything will look normal and won’t be routed via HE. As for now, these probes don’t have any tags or description that will allow you distinguish them from other, normal probes. Regards, Grzegorz From: ripe-atlas <ripe-atlas-bounces(a)ripe.net> on behalf of "Ponikierski, Grzegorz via ripe-atlas" <ripe-atlas(a)ripe.net> Reply to: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Tuesday, 2 July 2024 at 11:38 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Atlas probes in non-production networks Hi all! I discovered a disturbing practice how RIPE Atlas probes are used by at least one major provider which significantly impacts measurement results and interpretation of these results. I want to share it with you to open discuss about how to deal with such cases. I was doing traceroutes for one of Tier 1 provider which is very well covered by RIPE Atlas probes. I was surprised, that for some probes I got RTTs 100x worse than expected. After verification I discovered that routing for these probes is absurd and contact the provider to explain it. It turned out, that these probes are deployed in this part of their network that provide for some kind of internal service which is not provided for customers of this provider. In other words, these probes don't measure production network, but they measure some kind of hidden experimental network not available for the public. In my private opinion, this practice is against the whole idea of RIPE Atlas, and it is a form of appropriation of the platform for solely private purpose disregarding interest of the RIPE Atlas community. As far I understand, RIPE Atlas supposed to be used to measure public Internet and it was not prepared to be used as internal/private measurement platform. RIPE Atlas probes are not tagged and separated into groups that can be used appropriately for public and internal/private measurements. Therefore, descripted practice creates another uncomfortable situation for RIPE Atlas user because there is no way to tell which probe is deployed in public/production part of the network and which one in the experimental/non-production one. I guess that most of us want to measure production networks and if there is somebody that want to play with experimental stuff then it should be clearly marked as experimental. Please share your thoughts and ideas how to deal with it. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940

1 0

Atlas probes in non-production networks
by Ponikierski, Grzegorz 02 Jul '24

02 Jul '24

Hi all! I discovered a disturbing practice how RIPE Atlas probes are used by at least one major provider which significantly impacts measurement results and interpretation of these results. I want to share it with you to open discuss about how to deal with such cases. I was doing traceroutes for one of Tier 1 provider which is very well covered by RIPE Atlas probes. I was surprised, that for some probes I got RTTs 100x worse than expected. After verification I discovered that routing for these probes is absurd and contact the provider to explain it. It turned out, that these probes are deployed in this part of their network that provide for some kind of internal service which is not provided for customers of this provider. In other words, these probes don't measure production network, but they measure some kind of hidden experimental network not available for the public. In my private opinion, this practice is against the whole idea of RIPE Atlas, and it is a form of appropriation of the platform for solely private purpose disregarding interest of the RIPE Atlas community. As far I understand, RIPE Atlas supposed to be used to measure public Internet and it was not prepared to be used as internal/private measurement platform. RIPE Atlas probes are not tagged and separated into groups that can be used appropriately for public and internal/private measurements. Therefore, descripted practice creates another uncomfortable situation for RIPE Atlas user because there is no way to tell which probe is deployed in public/production part of the network and which one in the experimental/non-production one. I guess that most of us want to measure production networks and if there is somebody that want to play with experimental stuff then it should be clearly marked as experimental. Please share your thoughts and ideas how to deal with it. Regards, Grzegorz Ponikierski Senior Network Engineer Akamai Technologies AS20940

5 4

FW: Ripe Atlas Speeds.
by Josseth Villacis 02 Jul '24

02 Jul '24

From: Josseth Villacis <Josseth.Villacis(a)detecon.com> Date: Monday, July 1, 2024 at 1:10 PM To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> Subject: Ripe Atlas Speeds. Dear<mailto:ripe-atlas@ripe.net> Ripe Atlas community, We are Detecon an telecommunication consulting company and we would like to know what is the availability of data you have, and what is the cost of having that information ? Also, we would like to know for our network analysis from your data if: Is there a way to determine if a speed test is performed on a mobile network operator’s network in India? Specifically, do MNOs and fixed network operators use the same ASN (Autonomous System Number)? Reference: [MNO List with ASN](https://github.com/nitindermohan/multifaceted-starlink-performance/blo… If MNOs and fixed network operators do use the same ASN, is there an alternative method to distinguish fixed speeds from those on a wireless network? For example, see [Distinguishing Between Fixed and Mobile IP Addresses](https://www.linkedin.com/pulse/distinguishing-between-fixed-mobi….

1 0

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 19 Jun '24

19 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