- ripe-atlas - mailman.ripe.net

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

28 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