- ripe-atlas - mailman.ripe.net

Inconsistencies in anchor API and measurements
by Malte Appel 18 Nov '21

18 Nov '21

Hi everyone, sorry in advance for the long mail. tl;dr: Anchor API and UI give inconsistent results. Some anchor mesh measurements could be fixed, some might target non-anchors. Not sure what to do about it. I am currently working a lot with RIPE Atlas and recently wanted to use the anchors and their mesh measurements in particular. I wanted to answer two simple queries: 1. Get a list of all active anchors 2. Get a list of all active anchor mesh and probe measurements (traceroute, for my particular use case) However, while trying to answer these queries, I stumbled upon quite some inconsistencies, depending on which interface / API is used. As far as I can tell there are four ways in which one could technically answer query 1: 1. Look at the website: https://atlas.ripe.net/anchors/list/ -> 840 results 2. Query the /anchors API with attribute is_disabled = false: https://atlas.ripe.net/api/v2/anchors/?is_disabled=false -> 844 results 3. Query the /probes API with attributes is_anchor = true and status = 1 (Connected): https://atlas.ripe.net/api/v2/probes/?is_anchor=True&status=1 -> 729 results 4. Query the /probes API with attributes tags = system-anchor and status = 1 (Connected): https://atlas.ripe.net/api/v2/probes/?tags=system-anchor&status=1 -> 729 results Methods 3 and 4 are actually consistent! The main discrepancy is between the /anchors and /probes API: 116 anchors that are listed on the webpage and/or /anchors API as ‘active’ are inactive (97 abandoned; 19 disconnected at time of writing) according to their respective /probes entry. I understand that disconnects might be temporary, but some anchors seem to be inactive for years (at least according to their status) and are still listed as active. I have attached a text file with some notes that go deeper into the differences, but might be hard to read. For query 2, I faced a similar situation: 1. Look at the website: https://atlas.ripe.net/anchors/list/full/ Anchoring Mesh IPv4: 840 Anchoring Mesh IPv6: 739 Anchoring Probes IPv4: 840 Anchoring Probes IPv6: 705 Total: 3124 2. Query the /anchor-measurements API Anchoring Mesh IPv4: 849 Anchoring Mesh IPv6: 743 Anchoring Probes IPv4: 902 Anchoring Probes IPv6: 753 Total: 3247 3. Query the /measurements API with attributes status = 2 (Ongoing), type = traceroute and corresponding attributes: Anchoring Mesh IPv4: af = 4; tags=anchoring,mesh Anchoring Mesh IPv6: af = 6; tags=anchoring,mesh Anchoring Probes IPv4: af = 4; tags=anchoring,probes Anchoring Probes IPv6: af = 6; tags=anchoring,probes For example: https://atlas.ripe.net/api/v2/measurements/?status=2&type=traceroute&af=6&t… Anchoring Mesh IPv4: 1026 Anchoring Mesh IPv6: 902 Anchoring Probes IPv4: 668 Anchoring Probes IPv6: 619 Total: 3215 These results are even more mixed: - Tags can be inconsistent: Some measurements have none, some have the ‘probes’ or ’mesh’ tag, but miss the ’anchoring’ tag. - Some anchors have multiple measurements (especially probes measurements), of which most actually are run by the same set of probes, i.e., they are duplicates. - Which measurements are contained in which of the three result sets is very mixed, maybe I should draw a Venn diagram :) Finally, I looked at the consistency of the IP addresses of the /anchors API (ip_v4 and ip_v6), the /probes API (address_v4, address_v6), the DNS result for the FQDN of the anchors, and the target IP of the mesh/probes measurements. I noticed some problems, since our lab (IIJ) also operates an anchor (probe 6425 [0]) and we updated the IP address some time ago, but are actually not reached by the mesh measurement, because the measurement still targets the old IP. I attached a CSV that includes the raw data (of measurements with some form of problem), but basically there are 93 measurements from connected anchors that fail, and out of which 68 (from 29 anchors) could work, if the measurement would target the correct IP. These measurements have matching anchor/probe IPs and DNS records, so I do not know why the measurement target is stale. There are some additional measurements that could work, but it is unclear what the intended ‘correct’ IP is. On that note, there are 48 measurements that ‘work‘, i.e., they get a response from the target, but it is not clear if the target is the intended receiver: - 8 target abandoned anchors - 18 have different probe and anchor IPs and target one of them - 21 have the same probe and anchor IP but target something else Again, I am sorry for this long mail. I understand that RIPE Atlas is a huge project that has grown over time so it might be hard to keep some things synchronized, and some other things might not be easily decidable (e.g., when to mark an anchor is inactive). However, I think especially the IP address of an anchor in the /anchors and /probes APIs, in the DNS entry, and the target of the mesh/probes measurements need to be consistent. Currently some mesh measurements might target an entirely different machine. I wanted to bring some attention to this, but not sure what else I can do as a user. I don‘t want to complain too much :) For now I will just use all data sources as input and apply some sanity checks. Best, Malte P.S.: Some feedback on how we can bring the measurement of our anchor to target our anchor would be nice though. [0] https://atlas.ripe.net/probes/6425

2 2

RIPE measurement Credits required
by Mccherry, Paul (Student) 02 Nov '21

02 Nov '21

Dear All I have applied and been granted to install an Anchor at my University to generate credits to make measurements, this is taking some time to prepare the equipment etc. In the meantime I need to carry out some measurement tests for a paper I am working on. Would anybody be able to kindly send me some RIPE credits which I will hopefully pay back once I have the anchor up and running ? Regards Paul McCherry Phd Student From: ripe-atlas-request(a)ripe.net<mailto:ripe-atlas-request@ripe.net> Sent: 25 October 2021 23:07 To: ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 6 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. RIPE Atlas Virtual Anchor Application (TNaumann(a)telekom.de) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Oct 2021 22:06:40 +0000 From: <TNaumann(a)telekom.de> To: <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Virtual Anchor Application Message-ID: <FR2P281MB0775F27CBE4C9FAC283EC010A6839(a)FR2P281MB0775.DEUP281.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="iso-8859-1" Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Gro?e Ver?nderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

10 15

Re: [atlas] [External] ripe-atlas Digest, Vol 122, Issue 8
by Mccherry, Paul (Student) 27 Oct '21

27 Oct '21

Many thanks Nick, I will pay them back as soon as possible. Regards Paul Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: ripe-atlas <ripe-atlas-bounces(a)ripe.net> on behalf of ripe-atlas-request(a)ripe.net <ripe-atlas-request(a)ripe.net> Sent: Wednesday, October 27, 2021 9:20:42 PM To: ripe-atlas(a)ripe.net <ripe-atlas(a)ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 8 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. Re: RIPE measurement Credits required (Nick Hilliard) 2. Re: RIPE measurement Credits required (Carsten Schiefner) 3. Re: RIPE measurement Credits required (Dario Ciccarone) ---------------------------------------------------------------------- Message: 1 Date: Wed, 27 Oct 2021 21:06:27 +0100 From: Nick Hilliard <nick(a)foobar.org> To: "Mccherry, Paul (Student)" <p.mccherry(a)lancaster.ac.uk> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] RIPE measurement Credits required Message-ID: <d1cb2c10-5361-cc7e-37b8-67c3183be7eb(a)foobar.org> Content-Type: text/plain; charset=windows-1252; format=flowed Mccherry, Paul (Student) wrote on 27/10/2021 21:02: > I have applied and been granted to install an Anchor at my University to > generate credits to make measurements, this is taking some time to > prepare the equipment etc. ?In the meantime I need to carry out some > measurement tests for a paper I am working on. Would anybody be able to > kindly send me some RIPE credits which I will hopefully pay back once I > have the anchor up and running ? just sent you 50m. Nick ------------------------------ Message: 2 Date: Wed, 27 Oct 2021 22:09:56 +0200 From: Carsten Schiefner <carsten(a)schiefner.de> To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] RIPE measurement Credits required Message-ID: <44a5f3d1-6be8-4c59-8c4b-9ce706c4578e.maildroid@localhost> Content-Type: text/plain; charset=utf-8 Your user id? -- Von meiner H?ngematte aus gesendet. -----Original Message----- From: "Mccherry, Paul (Student)" <p.mccherry(a)lancaster.ac.uk> To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Sent: Mi., 27 Okt. 2021 22:02 Subject: [atlas] RIPE measurement Credits required Dear All I have applied and been granted to install an Anchor at my University to generate credits to make measurements, this is taking some time to prepare the equipment etc. In the meantime I need to carry out some measurement tests for a paper I am working on. Would anybody be able to kindly send me some RIPE credits which I will hopefully pay back once I have the anchor up and running ? Regards Paul McCherry Phd Student From: ripe-atlas-request(a)ripe.net<mailto:ripe-atlas-request@ripe.net> Sent: 25 October 2021 23:07 To: ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> Subject: [External] ripe-atlas Digest, Vol 122, Issue 6 This email originated outside the University. Check before clicking links or attachments. Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.rip… or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. RIPE Atlas Virtual Anchor Application (TNaumann(a)telekom.de) ---------------------------------------------------------------------- Message: 1 Date: Mon, 25 Oct 2021 22:06:40 +0000 From: <TNaumann(a)telekom.de> To: <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Virtual Anchor Application Message-ID: <FR2P281MB0775F27CBE4C9FAC283EC010A6839(a)FR2P281MB0775.DEUP281.PROD.OUTLOOK.COM> Content-Type: text/plain; charset="iso-8859-1" Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…<https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…><https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.teleko…> Gro?e Ver?nderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

1 0

RIPE Atlas Virtual Anchor Application
by TNaumann＠telekom.de 26 Oct '21

26 Oct '21

Dear Ripe Atlas Team, Could we have any estimation about our application for the first virtual anchor in New York? We would like to have a physical and virtual probe at the same time and recycle/reuse the physical later this Year somewhere else in U.S. [cid:image001.png@01D7C9FD.22665680] Kind Regards Thomas Naumann Deutsche Telekom Technik GmbH Network Infrastructure (T-NWI) Thomas Naumann Ginnheimer Stadtweg 88, 60431 Frankfurt am Main +49 69 20060 4042 (Phone) +49 170 3374602 (Mobil) E-Mail: TNaumann(a)telekom.de<mailto:TNaumann@telekom.de> www.telekom.de<http://www.telekom.de/> Erleben, was verbindet. Die gesetzlichen Pflichtangaben finden Sie unter: www.telekom.de/pflichtangaben-dttechnik<http://www.telekom.de/pflichtangaben-dttechnik> Große Veränderungen fangen klein an - Ressourcen schonen und nicht jede E-Mail drucken.

1 0

New on RIPE Labs: Latency Into Your Network - As Seen From RIPE Atlas
by Alun Davies 14 Oct '21

14 Oct '21

Dear colleagues, New prototype visualisations - put together by Emile Aben and Agustin Formoso using the ObservableHQ platform - allow you to visualise network deployment. Drawing on latency data available from RIPE Atlas, each visualisation aims at helping reveal insights about structural latency into given networks. Read more and try it out on RIPE Labs: https://labs.ripe.net/author/emileaben/latency-into-your-network-as-seen-fr… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Training material
by Hank Nussbacher 12 Oct '21

12 Oct '21

I know of: https://www.ripe.net/support/training/material/measurements-and-tools-train… which from slide 79-176 is dedicated to explaining RIPE Atlas. Problem is that it is from July 2019. Is there a later more up to date RIPE Atlas PPT? Thanks, Hank

2 1

ripe atlas Probe 32256 is disconnected firm ware upgrade com326.193.612
by kiran.gunana＠colruytgroup.com 12 Oct '21

12 Oct '21

Dear Ripe Community, Noticed our probe's firmware got upgraded and from there on our measurements stopped working. 2021-10-10 03:31:00 UTC Probe firmware upgraded Your probe #32256 upgraded its firmware from version 5020 to version 5030 Any clue on how we can fix this, current measurements does not work and tried creating new measurements which also does not work. Old Measurement : Ping measurement to www.hln.be: ID23382497 Last successfull measurment was at 2021-10-10 02:46 New Measurement : Ping measurement to www.f5.com from probe 32256 : ID32499756 Recevied following email from ripe: Your probe 32256 has been disconnected from the RIPE Atlas infrastructure since 2021-10-10 02:39:46 UTC. You may be able to learn more about the possible cause from the "Status" tab on your probe's information page: https://atlas.ripe.net/probes/32256/#!tab-status Current status says connected and no measurement works. Kind Regards, Kiran Gunana Dit bericht is onderworpen aan de voorwaarden beschikbaar op onze website Ce message est soumis aux conditions disponibles sur notre site web This message is subject to the terms and conditions available on our website

2 1

New RIPE Atlas Sponsorship opportunities
by Lia Hestina 11 Oct '21

11 Oct '21

Dear colleagues, Today we launch our new RIPE Atlas sponsorship model, offering more benefits and exposure to our future sponsors. Thanks to the contributions we've received so far, we've been able to keep distributing hardware probes free of charge all over the world, with each new probe helping make RIPE Atlas a more useful tool for measuring and monitoring the state of the Internet. Read our story on RIPE Labs: https://labs.ripe.net/author/lia_hestina/help-build-a-bigger-better-ripe-at… We're now asking you to help us expand the RIPE Atlas network further still. Even the smallest contribution from you will keep our vibrant community going so we can carry on making the Internet a more stable place for all. Check what our new sponsorship opportunities have to offer: https://atlas.ripe.net/get-involved/become-a-sponsor/ Kind regards, Lia Hestina On behalf of the RIPE Atlas team _________ RIPE NCC

2 2

Scheduled work on RIPE Atlas
by Viktor Naumov 28 Sep '21

28 Sep '21

Dear RIPE Atlas users, We have planned maintenance on the main RIPE Atlas backend database Tuesday, 28 September starting at 08:00 UTC, 10:00 Amsterdam local time. We expect some unavailability of the service for a short while. During this time the website (UI and APIs) may not be responding (properly). This also means that requests for new measurements will be denied or delayed. Data from existing measurements will still be collected normally, though access to them can be impacted. Our apologies for the inconvenience. Best Regards, Viktor Naumov

1 1

Disparity between reported results from probes and actual situation?
by Ishan Jain 25 Sep '21

25 Sep '21

Hi there, There are some sites that are being blocked by ISPs here in India. The two cases I checked are, 1. mega.nz 2. t.me In some cases, It's the Consumer ISP that's blocking access to these domains and in other cases it's the upstream providers like Tata(AS17908) that are blocking access to these sites. To figure out how many probes were effected, I ran 2 TLS tests. The results of those tests are here, 1. https://atlas.ripe.net/measurements/32358061/ 2. https://atlas.ripe.net/measurements/32358052/ As you'll see that almost every probe received correct TLS Certificate with mega.nz and excluding 4-5 probes, All the other probes received correct certificates for t.me. These measurements include 2 probes that I run in AS9829 and AS45609. Somehow, Both of my probes reported that they received the correct/valid certificate in both of these measurement when it doesn't appear to be true. I am presented with connection closed error when accessing these sites over HTTP and a connection reset error when accessing these sites over HTTPS over both WANs used by the two probes. Have I misunderstood TLS tests? I am not sure what is happening here and I really appreciate any insight I can get on these results. I have also included the relevant section from the logs of 1 of my probes. atlas_run: looking for 'evsslgetcert -4 -p 443 -h mega.nz -A "32358061" 66.203.127.18' eooqd: found cmd 'evsslgetcert' for 'evsslgetcert -4 -p 443 -h mega.nz -A "32358061" 66.203.127.18' eooqd: atlas_run: argv[0] = 'evsslgetcert' eooqd: atlas_run: argv[1] = '-4' eooqd: atlas_run: argv[2] = '-p' eooqd: atlas_run: argv[3] = '443' eooqd: atlas_run: argv[4] = '-h' eooqd: atlas_run: argv[5] = 'mega.nz' eooqd: atlas_run: argv[6] = '-A' eooqd: atlas_run: argv[7] = '32358061' eooqd: atlas_run: argv[8] = '66.203.127.18' eooqd: atlas_run: argv[9] = '-O' eooqd: atlas_run: argv[10] = '/var/atlas-probe/data/new/ooq.2' eooqd: init returned 0x738200 for 'evsslgetcert -4 -p 443 -h mega.nz -A "32358061" 66.203.127.18' eooqd: check_resolv_conf2: no change (time 1632496526) msgbuf_read: buf_read failed ooqd: command is done for cmdstate 0x738200 sslgetcert_delete: state 0x738200, index 0, busy 0 total size in dir: 5982 httppost: before getaddrinfo httppost: before connect httppost: sending request posting file '/var/atlas-probe/data/out/ooq/2' httppost: getting result httppost: getting reply headers httppost: got line 'Server: nginx' httppost: got line 'Date: Fri, 24 Sep 2021 15:56:32 GMT' httppost: got line 'Content-Type: text/plain' httppost: got line 'Transfer-Encoding: chunked' httppost: got line 'Connection: close' httppost: writing output httppost: chunked 1, content_length -1 httppost: got chunk line '3' httppost: chunk data 'OK Regards Ishan Jain

2 1

Controller kicking out probe with no clear reason?
by Ishan Jain 24 Sep '21

24 Sep '21

Hi there, I run a probe with ID, 1001577. I had to restart it few days back and now it's just not connecting to the controller. It cycles through the list of controllers, Finds 1 controller it can connect to but that controller kicks it out. I haven't been able to figure out why this is happening. I have tried clearing out all the data related to that probe, restarting it and updating the probe key on the dashboard but nothing seems to be working. The probe dashboard is receiving stats data, Current IP address and all the other information but it's marked offline. I have attached the logs below. ssh -i /var/atlas-probe/etc/probe_key -p 443 atlas(a)193.0.19.247 INIT Got good controller info check cached controller info from previous registeration NO cached controller info. NO REMOTE port info Do a controller INIT Controller init -p 443 atlas(a)ctr-fsn01.atlas.ripe.net INIT initiating KEEP connection to -R 53662 -p 443 ctr-fsn01.atlas.ripe.net { "name": "lo", "bytes_recv": 0, "pkt_recv": 0, "errors_recv": 0, "dropped_recv": 0, "fifo_recv": 0, "framing_recv": 0, "compressed_recv": 0, "multicast_recv": 0, "bytes_sent": 0, "pkt_sent": 0, "errors_sent": 0, "dropped_sent": 0, "fifo_sent": 0, "collisions_sent": 0, "carr_lost_sent": 0, "compressed_sent": 0 }, { "name": "eth0", "bytes_recv": 12352, "pkt_recv": 52, "errors_recv": 0, "dropped_recv": 0, "fifo_recv": 0, "framing_recv": 0, "compressed_recv": 0, "multicast_recv": 1, "bytes_sent": 12456, "pkt_sent": 76, "errors_sent": 0, "dropped_sent": 0, "fifo_sent": 0, "collisions_sent": 0, "carr_lost_sent": 0, "compressed_sent": 0 }condmv: not moving, destination '/var/atlas-probe/data/out/v6addr.txt' exists condmv: not moving, destination '/var/atlas-probe/data/out/simpleping' exists /usr/local/bin/atlas: 95: kill: No such process no ssh client matching . cleanup state files. for next restart Controller kicked us out. KEEP result is nonzero kill the session and forced reregister /usr/local/bin/atlas: 88: kill: No such process RESULT 9003 done 1632454514 8ead83275bd8 REREGISTER Controller kicked us out from KEEP Can someone here tell me what do I need to do fix this? I have another probe that's connected to atlas(a)reg03.atlas.ripe.net and it's working perfectly. Is ctr-fsn01.atlas.ripe.net operating normally? Regards Ishan Jain

2 1

All-Probe Traceroute + detect RFC1918 addresses
by Jeroen Massar 18 Sep '21

18 Sep '21

Hi Folks, Has anybody ever run a all-probe traceroute and then to detect any RFC1918 addresses in there? (though many probes will have locally some RFC1918) We got CAIDAs spoofer project, but that primarily afaik checks that by doing connections, not by checking ICMP returns. I just saw towards 213.244.71.2 : 11 Bundle-Ether42.br03.mrs01.pccwbtn.net (63.223.38.78) 29.068 ms 29.301 ms 29.129 ms 12 Bundle-Ether41.br03.mrs01.pccwbtn.net (63.223.38.74) 31.462 ms 31.410 ms 31.459 ms 13 10.74.42.10 (10.74.42.10) 77.574 ms 63.222.97.82 (63.222.97.82) 73.651 ms 63.222.97.90 (63.222.97.90) 73.514 ms 14 10.74.42.129 (10.74.42.129) 82.789 ms * 10.74.19.29 (10.74.19.29) 78.695 ms 15 * * 10.74.25.22 (10.74.25.22) 78.914 ms 16 * * 10.74.25.22 (10.74.25.22) 78.875 ms 17 * * * Which means the whole path till that IP was not doing any kind of RPF.... thus spoofing anything else would be possible too. At least one could kick PCCW in this case... but likely there are others. And as we are in 2021... a hall of shame might be appropriate... Of course, one should also do that for IPv6; though I expect outside the stray ULA address (thank you apple; though they are fixing that ULA issue with homepods apparently) very little of it, though "meten is weten" (measuring is knowing). Greets, Jeroen

6 20

New release on the RIPE Atlas back-end
by Viktor Naumov 13 Sep '21

13 Sep '21

Dear RIPE Atlas users, We'd like to inform you that we have just deployed a new release of our back-end system based on an upgraded version of a back-end framework we're using. We don't expect major issues but please let us know if you encounter something odd that may be related to this work by sending email to atlas(a)ripe.net <mailto:atlas@ripe.net> and we'll look into the issue. Regards, Viktor Naumov

1 0

A minor issue yesterday evening - today morning
by Robert Kisteleki 07 Sep '21

07 Sep '21

Dear All, You may have noticed a small hickup in RIPE Atlas measurement scheduling: between yesterday around 22:30 and today 10:30 (CEST) the measurements participants have not been properly recorded in our metadata store. This had virtually no impact on your measurements, but we're aware that some of you have eagle eyes for such details so we wanted to inform you regardless. Interesting background info for the curious: after more than 10 years of bookkeeping we basically exhausted the 32 bit ID space in our main database for confirming probe participation in the measurements... so we needed to upgrade the relevant fields and processes around it ahead of schedule. (The original plan was to do this for in all locations before EOY, perhaps even in the coming weeks.) Regards, Robert Kisteleki RIPE NCC

1 0

snmp
by Folkert van Heusden 01 Sep '21

01 Sep '21

Hi, Is it possible to do snmp queries? I have a device on the internet. From some ip-adresses snmpwalk returns the whole list (about 6 entries), from some ip-addresses 1 + timeout and from most only a timeout. I would like to figure out what the pattern is. Can ripe atlas assist in that? I checked the user-interface but only found dns, ntp, etc. regards

1 0

Website Login Redirection: Error 404
by Christian Schrötter 28 Aug '21

28 Aug '21

Hi, seems like there's a tiny (but annoying) bug at the new Atlas website. Steps to reproduce: * Logout at RIPE! * Open a private probes page: https://atlas.ripe.net/probes/35732/ * "You do not have permission to access this page. […]" -> click at the hyperlink "LOGGING IN" within the text. Now you're at [1]. Enter your username/password and continue. After that you'll be redirected to [2] – beautiful HTTP error 404 from Nginx. ;-) -- With kind regards, Christian Schrötter [1]: https://access.ripe.net/?originalUrl=https://atlas.ripe.net/login/?next= [2]: https://atlas.ripe.net/login/?next=

2 3

DNS resolution
by Thomas Schäfer 20 Aug '21

20 Aug '21

Dear atlas team, I have a simple question. After crating a measurement how often the name of the target is resolved? E.g. I want to ping a target with a stable dyndns name, but with changing ip addresses. It seems to me that most probes don't refresh the ip address once the measurement has started, even it is just a daily ping. Regards, Thomas

3 2

New on RIPE Labs: Exploring RIPE Atlas Traceroutes from 2012 to 2019
by Antony Gollan 09 Aug '21

09 Aug '21

Dear colleagues, In a new article on RIPE Labs, Nevil Brownlee presents an analysis of RIPE Atlas traceroutes for days in 2012, 2015, 2017 and 2019 with full network graphs for each successive half-hour, and develops an algorithm for finding node or edge outages of an hour or more: https://labs.ripe.net/author/nevil/exploring-ripe-atlas-traceroutes-from-20… Kind regards, Antony Gollan Communications Team Leader RIPE NCC

1 0

Upgrade existing Anchor to newer hardware
by Cathal Mooney 05 Aug '21

05 Aug '21

Hi, I am working for the Wikimedia Foundation, and we have several Atlas Anchor's deployed at various locations. Some time ago the Anchor we had in our location in Dallas, US (p6093.probes.atlas.ripe.net) failed due to a hardware failure. We are now attempting to replace the Anchor with new hardware which we have installed. The old device was a v2 Anchor (Soekris), however, and the new device is v3 (PC Engines APU.2E2). Given the newer hardware I expect we will need a different USB image to boot from? Our hope would be to re-use the previous IP addressing and other details so that does not need to change. What might be the best way to approach this? Many thanks, Cathal.

2 2

Representative probe sets in eyeball networks by country
by Bart van der Sloot 21 Jul '21

21 Jul '21

Hi RIPE Atlas community, Can anyone recommend/provide predefined probe sets which provide a fair representation of the eyeball networks in a country, e.g. “10 probes in each of the Top 5 eyeball networks in France” – and preferably probes that are “in” these eyeball networks (and/or close to their interconnection routers – where they peer or connect to their Transit providers, decreasing the dependency on last mile access and in-home networks) and probes that have a high uptime? Thanks in advance for your reactions! Kind regards, Bart van der Sloot Managing Director Leaseweb Network Leaseweb Network B.V. +31 20 316 0237 +31 6 5249 8035 b.vandersloot(a)network.leaseweb.com www.leaseweb.com Hessenbergweg 95, 1101 CX Amsterdam, the Netherlands © Leaseweb Network B.V. and FiberRing, Hessenbergweg 95, 1101 CX Amsterdam, is filed with the Chamber of Commerce under registration nr. 30188570, in the Netherlands. This email including any attachments contains confidential information from us. If you have received this email message in error or unauthorized by us, please immediately notify us by replying, keep the message strictly confidential and immediately delete the email message including all attachments. Leaseweb and FiberRing are the registered trademark under which Leaseweb Network B.V. as separate and independent Leaseweb sales company provides services in a particular geographic area, subject to the FiberRing B2B Sales Terms and Conditions. Please see www.fiberring.com for more information.

1 0

anchor disk recovery
by Matthieu Herrb 20 Jul '21

20 Jul '21

Hi, after a power outage, our anchor got its grub.cfg file corrupted. I managed to use a .rpmsave boot.cfg that was present on the disk and boot into the recovery kernel. >From here the anchor is alive again on the management interface at https://atlas.ripe.net/probes/7000/ but I guess it's still in a unstable state. What is the procedure to actually repair the installation ? Should I re-install it from the USB image, or is there something else I can do remotely ? x -- Matthieu Herrb

1 0

Latest data point shown is from 2021-07-16 10:43 UTC
by Thomas Schäfer 19 Jul '21

19 Jul '21

Hi, I run two independent software probes. Looking at the graphs "Built-ins" I get the orange text: "Latest data point shown is from 2021-07-16 10:43 UTC" It only happens on the software probes. My hw probe seems to run without that problem. All three probes are online "Your probe is currently connected" Regards, Thomas

2 1

Removing virtual RIPE Atlas probe
by Milad Afshari 18 Jul '21

18 Jul '21

Hello everyone, I hope you are doing well, I am curious to know if there is any way to remove a virtual RIPE Atlas probe from my panel? Sincerely yours; Milad Afshari

2 1

Unable to create measurements in RIPE Atlas
by Salvador Bertenbreiter 12 Jul '21

12 Jul '21

Hi guys, I hope you're doing well. I am preparing an article about latency in LATAM and I would like to use RIPE Atlas to gather some data, unfortunately, I'm not being able to create my first measurement, I completed the three first steps: 1) Ping x.x.x.x 2) Selected 10 probes in Peru 3) Choose the time interval But when I click on the Create My Measurement(s) button nothing happens, I don't even receive an error message about a missing or wrong field. Any idea what could be happening? Are you able to create measurements without issues? Thank you Best regards, -- Salvador Bertenbreiter (+51) 947 145 352

1 0

Getting RRSIG records when do bit is set
by pravicha 07 Jul '21

07 Jul '21

Hello, When I set the do bit in dig, I get back RRSIG records associated with the Query Type, but I don’t get the RRSIGs when I create a measurement with do bit set in Ripe Atlas. Can I replicate the same behavior in RIPE atlas? Thanks

2 8

Is there a way to find the resolver used by the probe?
by pravicha 06 Jul '21

06 Jul '21

Hello, I’ve been trying to get dns measurements for a couple of domains over different regions using atlas probes. Is there a way to find the resolver’s IP used by the probes when use_probe_resolver is set to true? Thanks

3 3

Resolves AAAA Correctly, Doesn't Resolve A - best way to resolve this?
by Peter T Garner 28 Jun '21

28 Jun '21

I've been having a few problems setting up my software probe, but this has now almost stabilised. It's been quite an education in DNS setup! My problem now is that my probe General Information is reporting "Resolves AAAA Correctly, Doesn't Resolve A, IPv4 Stable 1d, IPv4 Works, Software IPv4 RFC1918, IPv4 Capable" but I can't seem to fix the "Doesn't Resolve A" problem: is there anything specific that I can try from the command line to diagnose this? FWIW, all other traceroutes, pings, digs etc on the box seem to be working.

1 0

IPv6-renew
by Marco Davids (IETF) 22 Jun '21

22 Jun '21

Hi, Whenever my network get's a different IPv6-prefix from my provider (which happens every now and then), the probe is flagged down in the dashboard. The reason seems to be that RIPE Atlas probes are unable to renew their (SLAAC?) IPv6-addresses when needed. Only solution is a powercycle. Is this a flaw, or is it by design? -- Marco

6 5

Re: [atlas] IPv6-renew
by Nick Hilliard (INEX) 21 Jun '21

21 Jun '21

Ole Troan wrote on 21/06/2021 11:11: > To be correct; it's an operational issue. SLAAC works as designed with IPv6 renumbering. slaac - being stateless 'n all - was not designed with flash renumbering in mind because flash renumbering needs some degree of state synchronisation on all devices on the path between the provisioning system issuing the prefix and the end device. So in this sense it is a protocol issue, albeit an issue that was outside the design scope of the protocol. > Imagine if the mobile operator swapped your mobile phone number midstream. mobile phone numbers are stateful. You don't need to change phone number every time you're handed off to a different cell. Nick

1 0

Is there a definitive guide to firewall rules?
by Peter Garner (iPad) 21 Jun '21

21 Jun '21

Noob question. I set up a software probe a couple of days ago on a Linux box that uses Universal FireWall (UFW). I've no problem with the required internal ports and the probe seems to be working as intended but would like to know if there's a definitive list of ports and protocols that I can apply to get the maximum benefit to the data?

2 1

My probe (10047) is dead
by Ondrej.Flidr 18 Jun '21

18 Jun '21

Hi Ripe, it looks like my probe is dead. Connection on site is working but probe doesn't seems to be connected. There is flashing orange led on USB dongle. What should I do now? How can I debug it? Best regards, Ondrej Flidr

5 4

DNS probes: spurious SERVFAIL
by Lukas Tribus 30 May '21

30 May '21

Dear list, while troubleshooting DNS issues on the Google network yesterday [1] we found that RIPE Atlas probes did not recover after Google fixed the issue, we kept seeing SERVFAIL answers on the RIPE Atlas probes. We now know that those ATLAS results are bogus. For example google.us against 8.8.4.4 https://atlas.ripe.net/measurements/30456676/#probes google.us against 1.1.1.1 https://atlas.ripe.net/measurements/30464549/#probes zoom.us against 8.8.8.8 https://atlas.ripe.net/measurements/30464774/#probes zoom.us against 1.1.1.1 https://atlas.ripe.net/measurements/30464777/#probes amazon.com on quad9 https://atlas.ripe.net/measurements/30479180/#probes amazon.com on quad1 https://atlas.ripe.net/measurements/30479179/#probes Even amazon.com on quad9 and quad1 has numerous SERVFAIL. To reproduce, just try to resolve zoom.us or google.us against 8.8.8.8 or 1.1.1.1 on your probe. Any recommendations on how we could troubleshoot this? [1] https://puck.nether.net/pipermail/outages/2021-May/013648.html

3 4

New on RIPE Labs: Deploying a RIPE Atlas Probe Software via PPP
by Alun Davies 17 May '21

17 May '21

Dear colleagues, Want to install a RIPE Atlas software probe, but not sure how to keep it isolated from your private network? In this new guest post on RIPE Labs, Aris Tzermias demonstrates how to do this using a dedicated PPP connection with your Internet Service Provider. https://labs.ripe.net/author/aris-tzermias/deploying-a-ripe-atlas-probe-sof… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

New on RIPE Labs: Surrounded by the Clouds - A Comprehensive Cloud Reachability Study
by Alun Davies 12 May '21

12 May '21

Dear colleagues, Lorenzo Corneo and colleagues recently conducted a comprehensive cloud reachability study to evaluate the suitability of modern cloud environments for latency-sensitive applications. Read about the results of the study now on RIPE Labs: https://labs.ripe.net/author/lorenzo-corneo/surrounded-by-the-clouds-a-comp… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0

Result delivery issues - 2021-05-11
by Robert Kisteleki 11 May '21

11 May '21

Dear All, The RIPE Atlas result storage backend started experiencing issues today at around 3am (CEST). The team is working on resolving the issue; we'll provide an update when more information is available. The result streaming feature is not affected, it is still delivering results in real-time. Regards, Robert Kisteleki

2 2

Scheduler adding extra probes for some measurements
by Chris Amin 07 May '21

07 May '21

Dear colleagues, We have fixed a bug in the RIPE Atlas scheduler which caused extra probes to be added to some ongoing measurements. This bug affected many users who submitted "removal" requests using the REST API from 2021-03-23, and in some cases caused a large increase in the consumption of credits due to the extra generated measurement results. This bug has now been fixed, and the affected accounts have been credited with approximately 125% of the erroneous overpayment. My apologies for any inconvenience caused. Please let me know if you have any further questions or issues. Kind regards, Chris Amin RIPE NCC

1 0

Rapidly decreasing credits
by ms 07 May '21

07 May '21

Hi, Recently, looks like since beginning of April, my credits started dropping exponentially. I'm only running a ping measurement at the moment. Any changes to the credit system I missed? Cheers, ms

2 1

research support: credits/limits for DSCP marking measurements
by Stephen Strowes 07 May '21

07 May '21

Hi, One more RIPE Atlas research support request: this time on DSCP marking/bleaching from as many vantage points as possible. This one feeds into the IETF tsvwg, and is pretty applicable to operators in the RIPE community also. In short: they have one target host, and they want to test 3 DSCP codepoints with traceroutes from as many probes as possible. This is not an ongoing study. They'll run a pretty typical traceroute config from as many probes as possible once for each DSCP they're interested in, and they'd like to do it as rapidly as possible. This is simplest as three one-off measurements. Could you: - bump their credit allowance if necessary - bump the number of probes allowed per measurement to some high number; as close to "all probes" as possible? The account they're using is ana(a)erg.abdn.ac.uk <mailto:ana@erg.abdn.ac.uk> Cheers, S. -------- Forwarded Message -------- Subject: Re: Can you help perform a large-scale ATLAS measurement campaign? Date: Tue, 4 May 2021 19:48:40 +0100 From: ana(a)netstat.org.uk To: Stephen Strowes <sds(a)ripe.net> Hi Stephen, > Would you like to run (e.g.) thousands of probes to the target with > all DSCP values as rapidly as possible, or would you run multiple > measurements with 1,000 probes each over a longer period? > Thousands of probes as rapidly as possible, but each DSCP is a separate measurement (so 3 separate measurements). I don’t expect to repeat them over a longer period. > > Either way, the credit cost will likely be the same, but the Atlas > folks may need to modify other limits to accommodate the measurements. > Your current account settings should be visible at > https://atlas.ripe.net/atlas/user/ > The only limit that worries me there is: Maximum number of probes per measurement:1,000 It doesn’t look like these measurements will hit the other limits. > Also: Is this email address the one to add credits to? > The account uses email address ana(a)erg.abdn.ac.uk <mailto:ana@erg.abdn.ac.uk>, rather than this one. Thanks again! Ana

3 3

Error for getting measurement results from an api
by Sanaa GHANDI 30 Apr '21

30 Apr '21

Hello, I would like to use the Ripe api : /api/v2/measurements/{msm_id}/participation-requests/{source_id}/. for getting measurement results, but I keep getting the following error (in the picture). Here is the website of the different apis: https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Type_0_1_2_3_4… Is it due to my key? Knowing that I have already used it to create measurements and get measurement results and in other apis from Ripe. Concerning the example below, I have checked the measurement ID and that the probe in the source ID figures among the participant probes. I don't quiet see the source of the problem, do you have any ideas about this? Thank you, Cheers, Sanaa

1 0

Satellite based "last mile" and Atlas probes
by Eric Kuhnke 27 Apr '21

27 Apr '21

Hello all, I am running what I believe to be the only probe on a Starlink satellite connection right now: https://atlas.ripe.net/probes/1001821/ Is anyone aware of a list of probe ID numbers which are definitively known to be on some form of satellite-based access technology? I am thinking of, for instance, sites on consumer grade geostationary VSATs, more serious VSATs, or in island nations which are not known to have any submarine cables. The reason why I am searching for such a list is that I intend to consume some of my accumulated credits to run periodic one-off measurements of latency, traceroutes and other things to quantify improvements in satellite based latency and other performance metrics over time. And to quantify what it looks like when an ISP previously dependent on geostationary (min 495ms latency) gains access to either terrestrial/submarine fiber, or a lower latency low earth orbit based service. The best information I can find right now is to manually pick probes which never show below geostationary latency to a first hop in any traceroute, and are located on the probes map in certain island locations. It's a bit more time consuming to manually search for probes in continental locations which are on a VSAT (for instance if anyone knows of a probe on a VSAT terminal in a remote part of Wyoming, USA, let me know...).

14 37

RIPE Atlas CLI tools docker image
by Anurag Bhatia 26 Apr '21

26 Apr '21

Hello everyone, A little while ago I put RIPE Atlas CLI tools docker image based on alpine. - https://hub.docker.com/r/anuragbhatia/ripe-atlas-tools It stores the API keys at ~/.config on the host (and that is mounted inside the container). Dockerfile can be found here <https://github.com/anuragbhatia/ripe-atlas-tools/blob/master/Dockerfile> and one can use it to build image locally if intended to. *Example usage: * docker run --rm -v ~/.config:/root/.config -it anuragbhatia/ripe-atlas-tools ripe-atlas measure traceroute --from-country IN --target he.net One can set an alias in the local shell to make it appear almost like a locally installed setup. E.g on fish: anurag@Anurags-MacBook-Pro ~> alias ripe-atlas='docker run --rm -v ~/.config:/root/.config -it anuragbhatia/ripe-atlas-tools ripe-atlas' anurag@Anurags-MacBook-Pro ~> funcsave ripe-atlas anurag@Anurags-MacBook-Pro ~> Thus the reduces syntax is alias becomes: ripe-atlas measure traceroute --from-country IN --target he.net Please do share if anyone has any feedback. -- Anurag Bhatia anuragbhatia.com

1 0

Filtering measurements
by Sanaa GHANDI 23 Apr '21

23 Apr '21

Hello, I hope you are all doing well. I have a few questions concerning the measurements selection, and I am interested only on the anchoring mesh measurements. In fact, for optimisation issues, I would like to be able to select only measurements of interest: For example, I want to get the results coming from sources: X and Y, and targeting the anchor 6771. Now I can get the measures targeting the anchor 6771 using this code from Altas Cousteau ################################################################## from ripe.atlas.cousteau import MeasurementRequest filters = {'tags': ['anchoring','mesh',6771] } measurements = MeasurementRequest(**filters) #################################################################### But I have no idea of how to make a filter on the sources as well, since all we can access through the measurements are the number of anchors requested and not their ids. Do you know a way to get access to the sources of a measurement via Atlas Cousteau or another Ripe Tool ? Thank you -- Sanaa

4 4

Custom box and bag
by Slite 22 Apr '21

22 Apr '21

Hello, Have a nice day. Does your company needs any Custom packaging box/bags for your products? We are Chinese supplier who can produce customized packaging/bag with custom logo. Dear,we have cartons,cardboard box,plastic box,metal tin box,paper bag,plastic bag,non-woven bag ... to pack your products. Then tell me which one you want,I will give you best price with good service. Any of your reply will be appreciated. Looking forward to your reply. Best regards, Slite Contact Email: slite(a)slcpackage.com What's app: 0086 15314679598SLC-PACKAGE CO. LTDwww.slcpackage.com www.slcpackages.comContact Person: Slite Cao Address:1406, No 11,Dongyue Huayuan,Nancheng,Xinluo,Longyan,Fujian,China If you no longer wish to receive mail from us, you can <http://tracking.littleindustrial.info/tracking/unsubscribe?d=hV-G-DkT38mtq2…> Unsubscribe

1 0

Request for credits for research
by Mohan, Nitinder 20 Apr '21

20 Apr '21

Dear RIPE community, I hope you are all safe and sound. I am a Postdoctoral fellow at the Technical University of Munich, Germany. We are currently working on an ongoing research project which aims to analyze the availability and reachability of cloud data centers globally. The first work of our work will appear in ACM HotNets 2020 titled "Pruning Edge Research with Latency Shears" (http://conferences.sigcomm.org/hotnets/2020/program.html). We are currently preparing the camera-ready version of the paper and will share it with the community by hosting it (and the associated dataset) publicly soon. We are currently planing to submit the second leg of our work to a conference with submission deadline a month. In order to complete all set of measurements for required analysis, we are scheduling very large-scale measurements over the platform which has burned through almost all our credits and left us in need. I have always found the RIPE Atlas community to be helpful and generous towards research and I am hoping that you could support our research by donating us some of your spare credits. Your help will be highly appreciated. My RIPE account is nitinder.mohan(a)helsinki.fi Thanks and Regards Nitinder Mohan Postdoctoral Fellow Technical University of Munich, Germany <http://www.cs.helsinki.fi/u/nmohan/>https://www.nitindermohan.com/

15 18

Feature request for Validated Timestamps
by Will 15 Apr '21

15 Apr '21

I was starting to work on a mapping measurement project where I wanted to delegate measurements to remote machines. There are a number of schemes that have been used where a not fully trusted node can come away from a measurement with a record that can be used to verify that it actually made the measurement. Many of these make use of a time stamp signed by the "server" as a way to prevent replaying old measurements. Things that have been done with this feature also include tlsnotary[1], which works with web servers where the "server random" bytes of the tls handshake includes the server timestamp (the default for openssl). The implementation of ssl currently used by probes does not appear to include the timestamp in the server hello. Another approach would be to add a "roughtime" service on probes Interested to hear if there would be willingness to have probe software support something in this direction. [1] https://tlsnotary.org/ --Will

5 9

Spurious "would violate your maximum daily spending limit"
by Stephane Bortzmeyer 07 Apr '21

07 Apr '21

I receive a: {"error":{"detail":"There was a problem with your request","status":400,"title":"Bad Request","code":102,"errors":[{"source":{"pointer":""},"detail":"Executing this measurement request would violate your maximum daily spending limit of 1000000.0 credits. Please stop some of your currently running measurements and try again."} from the API. The request is: {'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of use-application-dns.net./A from AS #3215', 'af': 4, 'type': 'dns', 'query_argument': 'use-application-dns.net.', 'query_class': 'IN', 'query_type': 'A', 'set_rd_bit': True, 'protocol': 'UDP', 'use_probe_resolver': True}], 'probes': [{'requested': 100, 'type': 'asn', 'value': '3215', 'tags': {'include': ['system-ipv4-works', 'system-resolves-a-correctly', 'system-resolves Which is very small. I run this sort of requests frequently. My daily expenditure is small (13,680 credits). Why is it rejected?

3 5

What to do with broken v1 probe?
by Lorenzo Colitti 30 Mar '21

30 Mar '21

Fellow atlas users, After more than 10 years (!) of 99% uptime (see below), my probe v1 appears to have given up the ghost. When connected to power, the lights still come on, but after a few seconds link bounces, and it never sends any packets. Any idea what to do? Should I just apply for a new probe? Are new probes being given out these days? Cheers, Lorenzo ---------- Forwarded message --------- From: RIPE Atlas <no-reply(a)ripe.net> Date: Tue, Nov 24, 2020 at 9:59 PM Subject: Congratulations! Your RIPE Atlas probe 333 is 10 years old! To: Lorenzo Colitti <lorenzo(a)colitti.com> Dear Lorenzo Colitti, It's your probe's birthday today !! To celebrate that fact, we are giving you 9869024 credits to use for scheduling your own measurements. In the last 10 years your probe was connected for 99% of the time. Happy measuring and thank you on behalf of everyone at the RIPE NCC and the other RIPE Atlas users. The RIPE Atlas Team

7 6

Re: [atlas] Probe location obfuscation
by Ponikierski, Grzegorz 26 Mar '21

26 Mar '21

I would add to it additional problem that some hosts obfuscate probe location even more. For example you can find probes which in reality are located in US but are marked as CN or probes which are in reality in Wisconsin but are marked in California. Of course these are extreme cases. I guess most hosts just put a pin with probe location just somewhere around where it's locate as long it's in the same city. I don't remember, as a host of 3 probes, to get any precise recommendations how to mark probe location. Personally I just put a pin in city district where probe is locate. Regards, Grzegorz From: "Mccherry, Paul (Student)" <p.mccherry(a)lancaster.ac.uk> Date: Thursday 2021-03-25 at 11:20 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe location obfuscation Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public<https://urldefense.com/v3/__https:/atlas.ripe.net/about/faq/*are-the-locati…> I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.

10 13

Unused Probes (was: What to do with broken v1 probe?)
by Sylvain Baya 25 Mar '21

25 Mar '21

{change the subject [0]} Dear all, Hope you are doing well! Le lun. 22 mars 2021 10:35, Estelmann, Christian <c.estelmann(a)gmx.net> a écrit : > Is there a possibility to return no longer used probes? Hi Christian, Thanks for your email brother. ...imho, it's a very useful idea! Within one [1] of our NOG's activities we have included the recovery of unused probes ; but maybe we should have tried it the other side...by asking probe's hosters to send it to an other volunteer or to us, if they become unable to keep it online... __ [1]: FR <https://www.cmnog.cm/dokuwiki/IdeasAndProjects:Projects:AtlasCM> I have one which was homed at a now closed location. Someone else could > give it a new home. > ...i suggest that you write to your ccNOG's mailinglist to find the nearest volunteer who could want to host your protected probe ;-) ...hope this could help. Blessed thursday! __ [0]: <https://lists.ripe.net/pipermail/ripe-atlas/2021-March/004638.html> Shalom --sb. > Greeting, > Christian > > Am 21. März 2021 17:14:57 MEZ schrieb Chriztoffer Hansen <ch(a)ntrv.dk>: > >On Sun, 21 Mar 2021 at 08:18, Lorenzo Colitti via ripe-atlas wrote: > >> After more than 10 years (!) of 99% uptime (see below), my probe v1 > >appears to have given up the ghost. [...] > >Cheers, > >Chriztoffer > > -- -- Best Regards ! __ baya.sylvain[AT cmNOG DOT cm]|<www.cmnog.cm/dokuwiki> Subscribe to Mailing List: <lists.cmnog.cm/mailman/listinfo/cmnog/> __ #‎LASAINTEBIBLE‬|#‎Romains15‬:33«Que LE ‪#‎DIEU‬ de ‪#‎Paix‬ soit avec vous tous! ‪#‎Amen‬!» ‪#‎MaPrière‬ est que tu naisses de nouveau. #Chrétiennement‬ «Comme une biche soupire après des courants d’eau, ainsi mon âme soupire après TOI, ô DIEU!»(#Psaumes42:2)

1 0

Probe location obfuscation
by Mccherry, Paul (Student) 25 Mar '21

25 Mar '21

Can anyone confirm the geo-location obfuscation of probes as being up to 1km as per https://atlas.ripe.net/about/faq/#are-the-locations-of-probes-made-public I am a Phd student carrying out research on the RIPE atlas platform and an early result seems to indicate 1 probe has an obfuscation of 10km distance but this may be an anomaly or perhaps something not taken into account as yet.

1 0