- ripe-atlas - mailman.ripe.net

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