- ripe-atlas - mailman.ripe.net

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