September 2021 - ripe-atlas - mailman.ripe.net

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Is there a procedure to move a software probe to a new device
by Peter Garner (iPad) 01 Feb '22

01 Feb '22

Noob question. I set up my software probe on a Debian 10 box which has quite a few small servers on it. However, I intend to move it onto a Raspberry Pi, so I was wondering if there's a specific procedure to follow to preserve existing settings? Only the internal IP address will change; the external remains the same.

6 7

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