April 2018 - ripe-atlas - mailman.ripe.net

New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution
by Mirjam Kuehne 08 Feb '19

08 Feb '19

Dear colleagues, The good news: RIPE Atlas is growing both in terms of geographical diversity and ASN coverage. What's more, RIPE Atlas is evolving, with a new generation of probe hardware having already passed the test phase and a pilot programme underway to assess the viability of VM anchors. The not so good news: With RIPE Atlas so much in demand, and with our current provider having ceased manufacturing the probe hardware, we've had to dramatically reduce the number of probes we're distributing. Please find more details on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-probes-delays-in-distr… Kind regards, Mirjam Kühne RIPE NCC

5 5

Error: Only anchors may be targeted.
by Mozafary Mohammad 28 Jun '18

28 Jun '18

Hello I've got "Only anchors may be targeted." on HTTP measurement creation.Any body can advise what the problem is? Thanks

8 9

Detecting open resolvers with atlas
by Eduardo Duarte 15 Jun '18

15 Jun '18

Hello all, I was wondering if anyone as done any work using Atlas probes to detect open resolvers on the network? I try to find in the RIPE Labs articles works around this problematic but didn't find anything. Thank you, -- Eduardo Duarte Direção de Infraestruturas e Sistemas l Systems and Infrastructure Director *DNS.PT* Rua Latino Coelho, n.º 13, 5.º piso | 1050-132 Lisboa | Portugal Tel: (+351) 211 308 200 Fax: (+351) 211 312 720 dns.pt <http://www.dns.pt> | dnssec.pt <http://www.dnssec.pt> | 3em1.pt <https://www.3em1.pt> | facebook.com/dns.pt <https://www.facebook.com/dns.pt> | pt.linkedin.com/in/dnspt <http://pt.linkedin.com/in/dnspt> Aviso de Confidencialidade/Disclaimer: Este e-mail foi escrito de acordo com o novo acordo ortográfico. Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail and delete it immediately. [ Antes de imprimir esta mensagem pense no ambiente. Before printing this message, think about environment ]

2 1

Minor change in the API Participation Requests endpoint
by Agustin Formoso 03 May '18

03 May '18

Dear Atlas users, We're planning to roll-out a minor change in the API Participation Requests endpoint. We'll be changing the response that gets sent out when a Participation Request is submitted. Although minor, the change may break your code if you are making use of the response. Current response example: [35878] Future response example after roll-out: { 'request_ids': [35878] } We plan to put this change into production two weeks from now. For those who don't know what Participation Requests are, they allow you to add or remove probes from a pre-existing measurement. You can find more information in https://atlas.ripe.net/docs/api/v2/manual/participation_requests.html Regards — Agustín Formoso RIPE NCC

1 1

RIPE Atlas probe status issues
by Chris Amin 26 Apr '18

26 Apr '18

Dear RIPE Atlas users, There were various issues relating to the recorded status of RIPE Atlas probes over the weekend. This was brought to our attention by internal monitoring and information provided by users on the mailing list. Throughout this period most probes did actually remain connected to controllers, and measurement results were collected as normal. The side effects included: * the number of probes reported as connected by the system was lower than it should have been * the status (connected/disconnected) of many probes was incorrect * new measurements took longer than usual to start * fewer probes than usual were available for new measurements, leading in some cases to “no suitable” probes messages when trying to schedule new measurements * various system tags were incorrectly applied, including many probes being marked as having USB problems when this was not the case * temporary discrepancies with crediting/debiting of RIPE Atlas credits for the connected time of probes The issues were caused by a bug fix deployment at Friday 9AM UTC where a package was accidentally downgraded causing a regression to an old bug in the task handling of the central system. This bug caused a backlog of messages to build, slowing down or stopping the registering of various status messages in the system. Problems built up gradually as the backlog increased, until the root cause was identified on Sunday morning. The issue was then fixed and the system stabilized completely by about 10AM UTC. We have identified procedural and technical solutions that will stop this problem happening again, and are looking at ways to improve our monitoring of these kinds of issues. We apologise for any inconvenience or confusion caused by this event and would like to thank all of you who took the time to notify us of what you were seeing. Kind regards, Chris Amin RIPE NCC

2 1

Hidden measurements
by Marty Strong 25 Apr '18

25 Apr '18

Does anybody else find that measurements you’ve marked as hidden by clicking on the eye next to it disappear as expected, but don’t show up on the hidden tab (https://atlas.ripe.net/measurements/?page=1#tab-hidden)? Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty(a)cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335

2 9

measurements "Forbidden"
by Marc Anthony Warrior 25 Apr '18

25 Apr '18

All of my RIPE Atlas measurement requests (pings in this case) are suddenly failing with a status "title" field value "Forbidden". Why is this happening?

4 6

paris traceroute output
by Radim Hrazdil 23 Apr '18

23 Apr '18

Hello all! I'm struggling to understand how is the number of paris variations reflected in the merasurement output. If I run paris-traceroute on my machine, the output of a single hop looks something like this: 6 P(16, 16) HOSTNAME (IP):0,1,2,3,4,9,10 4.534/6.072/15.130/2.957 ms HOSTNAME (IP):5,6,7,8 7.641/10.282/13.119/1.965 ms What I'm reffering to is this part: (IP):0,1,2,3,4,9,10, which says which probe packets 'visited' this particular router. I don't understand, how is this reflected in the measurement output. I have never encountered situaton in which 'from' fields within one hop would differ. This would suggest that no load balancing has been encountered, but that seems unlikely to me. Thanks for any replies, Radim Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

1 0

dnssec validating system tag?
by Tapio Sokura 23 Apr '18

23 Apr '18

Hello, I was looking at the probe system tags at https://atlas.ripe.net/docs/probe-tags/ when dnssec validating resolvers came to mind. Has there been thoughts about making the probes do dnssec resolver statistics gathering? I.e. how many / which probes are configured with dns resolvers that do / don't do dnssec validation? Tapio

2 1

TLS error when the certificate is expired?
by Stephane Bortzmeyer 23 Apr '18

23 Apr '18

I'm reasonably certain that it has been possible to use 'sslcert' measurements even when the certificate is expired. Today, I try to use 'sslcert' with trigger-happy.eu and it fails: "alert": { "description": 40, "level": 2 }, And no certificate in the JSON output (this is measurement #12166428) 40 is the very general "handshake failure" of TLS. <https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-pa…> Was there a change in Atlas recently? The TLS server does reply: % gnutls-cli trigger-happy.eu Processed 167 CA certificate(s). Resolving 'trigger-happy.eu:443'... Connecting to '51.254.210.94:443'... - Certificate type: X.509 - Got a certificate list of 2 certificates. - Certificate[0] info: - subject `CN=trigger-happy.eu', issuer `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', serial 0x0359a66c5eb5da799afe079f87416f8d9641, RSA key 2048 bits, signed using RSA-SHA256, activated `2018-01-13 10:46:26 UTC', expires `2018-04-13 10:46:26 UTC', key-ID `sha256:8216c7a7f221f3efcf7e7c3eb1760275d6ebf38d153b74992ee7864147b54435' Public Key ID: sha1:668c4506a393d9bb633590b68c05d878734d7ffe sha256:8216c7a7f221f3efcf7e7c3eb1760275d6ebf38d153b74992ee7864147b54435 Public key's random art: +--[ RSA 2048]----+ | +. o++ | | o +*.=.. | | .=o* . . . | | * B o | | . = S . | | = . . | | + E | | . . | | | +-----------------+ - Certificate[1] info: - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST Root CA X3,O=Digital Signature Trust Co.', serial 0x0a0141420000015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', key-ID `sha256:60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18' - Status: The certificate is NOT trusted. The certificate chain uses expired certificate. *** PKI verification of server certificate failed... *** Fatal error: Error in the certificate. *** handshake has failed: Error in the certificate.

2 3