- ripe-atlas - mailman.ripe.net

Feature request: API call in results page
by Hugo Salgado 03 Mar '17

03 Mar '17

Hi RIPE Atlas people. I wonder if it could be possible to add an option on the "measurements" webpage of a previous stopped or running measurement, to be able to see the API call that created it. Just like the "Measurement API Compatible Specification" section, when you create one. It could be available just to the user who created it... and even with API keys obscured. That will be very handy to be able to replay and exact measurement, or to have the list of probes in a ready-to-use format. Thanks a lot! Hugo Salgado

2 1

USB stick?
by Danny Horne 02 Mar '17

02 Mar '17

Hi all, I've seen in another thread mention of a USB stick. I've got an Atlas probe coming and haven't seen mention of a USB stick anywhere else, just the need for an Ethernet connection and USB power adapter. Have I missed something? Thanks for looking Regards Danny

2 1

modifications to Atlas front-end servers
by Romeo Zwart 02 Mar '17

02 Mar '17

dear Pier, Bjørn and all, We are in the process of migrating the atlas front-end machinery from apache to nginx. Despite our extensive preparations, this change has not been completely transparent, as you have noticed, and has caused some problems with the certificate chains. The problems with the CERTs have now been fixed. Apologies for this inconvenience to everyone. Please let us know if you would spot any other anomalies in the behaviour of the Atlas service. Kind regards, Romeo Zwart

1 0

SSL issue with atlas.ripe.net
by Pier Carlo Chiodi - Active Network S.p.A. 02 Mar '17

02 Mar '17

Hello, I'm facing an issue while using Atlas API. Some connections (not all) to https://atlas.ripe.net fail because of what seems to be an invalid certs chain. It looks like that an intermediate cert is missing. SSLLabs too reports something similar: https://www.ssllabs.com/ssltest/analyze.html?d=atlas.ripe.net&s=193.0.6.158 $ openssl s_client -connect atlas.ripe.net:443 -servername atlas.ripe.net CONNECTED(00000003) depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net verify error:num=27:certificate not trusted verify return:1 depth=0 C = NL, ST = Noord-Holland, L = Amsterdam, O = RIPE NCC, CN = atlas.ripe.net verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/C=NL/ST=Noord-Holland/L=Amsterdam/O=RIPE NCC/CN=atlas.ripe.net issuer=/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA --- ... Verify return code: 21 (unable to verify the first certificate) -- Pier Carlo Chiodi - Active Network S.p.A. via della Chimica, 18 - 01100 Viterbo Tel: +39 0761 17691 08 - Fax: +39 06 23328079

2 1

changing probes of a given measurement
by JORDI PALET MARTINEZ 01 Mar '17

01 Mar '17

Hi, Is it possible to change some of the probes of a given measurement? The issue is that I’ve a set of 10 probes for a specific measurement and it seems that 1 of them is no longer connected. Last time I’d this situation, I created a new measurement with the same probes except the failed one, but I wonder if it is possible to “modify” the actual measurement instead of creating a new one? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

2 1

Probe lights
by Alistair Mackenzie 27 Feb '17

27 Feb '17

Hi, I'm not sure if I'm missing something but there doesn't seem to be a guide on what the lights mean nor even how to read the SOS messages coming from the probe. I've tried resetting the USB drive and I can write to it with my laptop so I don't suspect this is the problem. Is there any information on how to diagnose this probe? Thanks, Alistair

2 1

CHAOS DNS queries
by Kyle Schomp 23 Feb '17

23 Feb '17

Hi all, For chaos txt queries, the only qnames that ripe atlas currently allows are: "hostname.bind", "id.server", "version.bind", "version.server". This seems like an unnecessary limitation to me as I've used chaos txt many times in the past for various dynamic records. I'm wondering what other peoples thoughts are on this restriction. Is this a problem for anyone else? Perhaps if there is enough community interest, the ripe atlas devs might decide to remove the restriction. Thanks! -kyle

1 0

250 RIPE Atlas Anchors now online!
by Michela Galante 23 Feb '17

23 Feb '17

Dear colleagues, Thanks to nineteen new RIPE Atlas Anchors being activated over the last three months, we have now reached an important milestone: 250 anchors online! Congratulations to anchor 250 hosted by Mogul Service and Support LLC in Ulaanbaatar, Mongolia and to APNIC for sponsoring it! These are the other anchors that have become active since our last announcement in November: - nl-ede-as12859, hosted by BIT in Ede, Netherlands - de-tua-as21413, hosted by envia TEL GmbH in Taucha, Germany - de-ham-as12731, hosted by IPHH Internet Port Hamburg GmbH in Hamburg, Germany (replaces older hardware) - py-slo-as27733, hosted by IXpy (sponsored by LACNIC) in San Lorenzo, Paraguay - uk-did-as786, hosted by Jisc in Didcot, United Kingdom - Two anchors hosted by Rabobank: nl-bst-as8211 in Best and nl-bxt-as8211 in Boxtel, Netherlands - nz-wlg-as9834, hosted by Trade Me in Wellington, New Zealand - lt-vno-as21412, hosted by CGATES in Vilnius, Lithuania - de-ber-as25291, hosted by SysEleven GmbH in Berlin, Germany (replaces older hardware) - us-bcb-as1312, hosted by Virginia Tech Transportation Institute in Blacksburg, United States - Two anchors hosted by Elisa Obj: fi-hel-as6667 in Helsinki and fi-tmp-as719 in Tampere, Finland - lu-ezt-as2602, hosted by Fondation RESTENA in Esch-sur-Alzette, Luxembourg (replaces older hardware) - de-kae-as8560, hosted by 1&1 Internet SE in Karlsruhe, Germany - fr-par-as5377, hosted by Marlink Enterprise AS in Paris, France - fr-tls-as39405, hosted by FULLSAVE in Toulouse, France - nl-ams-as286, hosted by KPN Eurorings B.V. in Amsterdam, Netherlands - mm-rgn-as132167, hosted by Ooredoo Myanmar (sponsored by APNIC) in Yangon, Myanmar (IPv4-only anchor) - fr-ilm-as57119, hosted by NAITWAYS in Issy, France - us-lxa-as8560, hosted by 1&1 Internet Inc. in Lenexa, United States You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas Anchors online: https://atlas.ripe.net/anchors/list/ Interested in hosting a RIPE Atlas Anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ There are several organisations that want to host a RIPE Atlas Anchor but don’t have the necessary funding. Find out more about the RIPE NCC campaign to sponsor 15 RIPE Atlas Anchors https://labs.ripe.net/Members/alun_davies/campaign-to-sponsor-15-ripe-atlas… We would also like to remind you about our ongoing cooperation with APNIC, LACNIC, AFRINIC and ISOC: thanks to their help we are getting more geographical diversity to the measurement data. If your organisation is in their region contact us at <atlas(a)ripe.net> and we will get you in touch with them! And don’t forget to let us know by contacting us at <atlas(a)ripe.net> if you’re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC

1 0

Atlas anchor Error message in the Bootlog
by Stanish Stanishev 22 Feb '17

22 Feb '17

Hello, I've installed the software on our Atlas anchor, however I noticed the following error message in the Boot Log: Error adding default gateway 213.91.165.187 for eth0. (213.91.165.187 is the IP addr assigned as def GW, eth0 is connected to the router and it is Up) Has anyone faced this issue ? I've sent an email to atlas(a)ripe.net for troubleshooting assistance but nobody has replied so far. Thanks Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

Querying popular domains with RIPE Atlas
by Chris Amin 21 Feb '17

21 Feb '17

Dear colleagues, As you are probably aware, DNSMON* and RIPE Atlas built-in** measurements are often used when analysing outages and other issues with important DNS services, particularly the root zone servers. These measurements do not provide a direct indication of the impact on actual end-user experience because they involve directly querying authoritative name servers, thereby ignoring the effects of having multiple authoritative name servers as well as caching local recursive resolvers. To improve upon our DNS monitoring, we will initiate two built-in DNS measurements from all RIPE Atlas probes that use the probes' default resolvers instead of authoritative name servers. The first measurement will query for random top-level domains with the intention of avoiding caches and therefore hitting at least one root name server. The second measurement will query for popular domain names, with the intention of hitting caches where appropriate and getting an idea of the true impact on users. As a starting point for the second measurement, we will use a recent snapshot of the global top 50 visited sites according to the Alexa top sites list***, which combines unique visitors and individual page views in its calculations. Probes will cycle through these domains, querying for a different A record every 10 minutes. Since DNS queries containing these domains will be made from every connected RIPE Atlas probe, we would like to ask for feedback on whether querying the DNS for any of these domains could pose legal or political problems for probe hosts in certain parts of the world. I have also included the next 25 most popular domains below, which will be used to fill any gaps caused by removing items from the main list. Kind regards, Chris Amin RIPE NCC * https://atlas.ripe.net/dnsmon/ ** https://atlas.ripe.net/docs/built-in/ *** https://en.wikipedia.org/w/index.php?title=List_of_most_popular_websites&ol… Provisional 50 domains to query =============================== google.com. youtube.com. facebook.com. baidu.com. wikipedia.org. yahoo.com. google.co.in. amazon.com. qq.com. google.co.jp. live.com. taobao.com. vk.com. twitter.com. instagram.com. hao123.com. sohu.com. sina.com.cn. reddit.com. google.de. linkedin.com. tmall.com. yahoo.co.jp. weibo.com. google.fr. 360.cn. google.co.uk. google.ru. google.com.br. yandex.ru. ebay.com. bing.com. msn.com. google.it. soso.com. t.co. wordpress.com. google.es. microsoft.com. tumblr.com. aliexpress.com. blogspot.com. netflix.com. amazon.co.jp. ok.ru. google.com.hk. stackoverflow.com. google.ca. google.com.mx. imgur.com. Next 25 most popular domains, excluding pornography =================================================== apple.com. Naver.com. mail.ru. imdb.com. popads.net. onclickads.net. office.com. google.co.kr. github.com. pinterest.com. paypal.com. tianya.cn. google.com.tw. google.com.tr. google.com.au. diply.com. amazon.de. google.co.id. microsoftonline.com. onclckds.com. twitch.tv. adobe.com. amazon.co.uk. wikia.com. cnzz.com.

3 3

Reminder: Ten Days Left to Apply for "DNS Measurements Hackathon"
by Vesna Manojlovic 16 Feb '17

16 Feb '17

Dear colleagues, The fifth RIPE NCC hackathon will take place on Thursday and Friday, 20-21 April 2017, in Amsterdam. Apply online: https://atlas.ripe.net/hackathon/dns-measurements/#!application-form *The application deadline is 26 February 2017* Find out more in this RIPE Labs article: https://labs.ripe.net/Members/alun_davies/dns-measurements-hackathon-2017 Regards, Vesna Manojlovic RIPE NCC Community Builder

1 0

New on RIPE Labs: Update on RIPE Atlas Probe Lifetimes
by Mirjam Kuehne 15 Feb '17

15 Feb '17

Dear colleagues, Please find an update on the status of RIPE Atlas probe connection times on RIPE Labs: https://labs.ripe.net/Members/wilhelm/update-on-atlas-probe-lifetimes Kind regards, Mirjam Kuhne RIPE NCC

1 0

Streaming API, endTime parameter is ignored
by Roberto Nunziato 10 Feb '17

10 Feb '17

Hello everybody, I am an Italian student and I am working with the RIPE Atlas Streaming API. I am trying to replay events that have happened in the past, so I am using the optional parameter endTime in the code below. Now, the stream starts at the specified time but it never ends. Am I doing anything wrong? Is this a bug? var socket = io(“https://atlas-stream.ripe.net <https://atlas-stream.ripe.net/>:443” , {path: “/stream/socket.io <http://socket.io/>”}); startTime = 1486256400 //05-02-17 h: 01:00GMT endTime = 1486258200 //05-02-17 h: 01:30GMT socket.emit(“atlas_subscribe”, {stream_type: “result”, startTime: startTime, endTime: endTime, msm: 1962548}); Best, Roberto Nunziato

2 3

New on RIPE Labs: Campaign to Sponsor 15 RIPE Atlas Anchors
by Mirjam Kuehne 31 Jan '17

31 Jan '17

Dear colleagues, The RIPE NCC is pleased to announce that we will be sponsoring 15 new RIPE Atlas anchors in 2017. This article provides details about the campaign and introduces the criteria that will be used to decide which applicants will receive sponsorship: https://labs.ripe.net/Members/alun_davies/campaign-to-sponsor-15-ripe-atlas… Kind regards, Mirjam Kuhne RIPE NCC

1 0

Reporting incorrect locations
by Marty Strong 30 Jan '17

30 Jan '17

Hi RIPE Atlas folks, Is there somewhere we can go to report a suspected incorrect location of an Atlas probe? This probe: https://atlas.ripe.net/probes/16578/ Is marked as in China, but is clearly in Australia. I couldn’t see anywhere I should report this. Marty

2 3

high v6 user-base, less atlas probes
by Bajpai, Vaibhav 28 Jan '17

28 Jan '17

Hello, -- sorry for cross-posting Here is a list of top 20 countries that have a large v6 user-base [*] but are underrepresented by RIPE Atlas due to less number of deployed dual-stacked probes. Consider hosting a dual-stacked probe in these regions to help remove the region-based bias that v6 studies using RIPE Atlas may otherwise have: Full paper available here: http://goo.gl/hWGveA (§4) +----+------------+-----------| | CC | v6 Users | v6 Probes | |-----+----+------------+-----------| | 01 | BE | 56.48 % | 2.82 % | | 02 | LU | 35.23 % | 0.61 % | | 03 | GR | 33.66 % | 1.39 % | | 04 | CH | 33.48 % | 3.82 % | | 05 | PT | 29.01 % | 0.74 % | | 06 | IN | 22.25 % | 0.09 % | | 07 | US | 33.00 % | 13.21 % | | 08 | DE | 40.07 % | 21.25 % | | 09 | EC | 18.76 % | 0.04 % | | 10 | JP | 19.69 % | 1.35 % | | 11 | GB | 24.63 % | 7.00 % | | 12 | EE | 16.55 % | 0.26 % | | 13 | CA | 17.83 % | 1.91 % | | 14 | FI | 16.68 % | 1.39 % | | 15 | MY | 14.90 % | 0.13 % | | 16 | IE | 13.22 % | 0.87 % | | 17 | NO | 14.02 % | 1.83 % | | 18 | BR | 12.56 % | 0.83 % | | 19 | AU | 12.76 % | 1.09 % | |-----+----+------------+-----------| [*] The estimation of number of IPv6 users is taken from APNIC dataset: http://labs.apnic.net/dists/v6dcc.html -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany --------------------------

1 0

RIPE Atlas Interface Hackathon, 21-22 May, Copenhagen
by Vesna Manojlovic 23 Jan '17

23 Jan '17

Dear colleagues, Calling all front-end developers, UI designers, network operators and other enthusiastic coders! The next RIPE Atlas hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=li… *The application deadline is 23 March* Please note that we are unfortunately unable to provide travel or accommodation funding. We look forward to seeing you there! Regards, Vesna and the RIPE Atlas Team

1 4

RIPE Atlas v1 APIs have been decommissioned
by Robert Kisteleki 20 Jan '17

20 Jan '17

Dear All, As we've been announcing it for a while now (see https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-September/003017.ht… and https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-January/003128.html) the v1 APIs were to be decommissioned by the end of last year / early this year. This step actually happened on Wednesday this week (18 January, around 14h CET). This means that queries to these APIs give 404s (for GETs) and 405s (for other methods, which we may change to 404 instead). This is also the cause for the issues Stéphane was experiencing. Full documentation on the v2 APIs and other features are available at https://atlas.ripe.net/docs/ Apologies for not sending this mail already on Wednesday. Regards, Robert Kisteleki RIPE NCC

1 0

traceroute measurement with abnormally small RTT
by Wenqin SHAO 19 Jan '17

19 Jan '17

Dear list, I recently found a ‘weird’ traceroute measurement record in the sense that: with paris id set, it has different IP addresses for a given hop; after it reached the destination, it tried one more hop; the final hop reported abnormally small RTT. I’d appreciate your views on how this happened. Here is how to identify the measurement in question: (the concerned record is as well provided at the end the mail) from ripe.atlas.cousteau import AtlasResultsRequest filters = dict(msm_id=5010, probe_ids=[10460], start=1482177890, stop=1482177900) _, results = AtlasResultsRequest(**filters).create() It’s a IPv4 traceroute measurement toward DNS b root, 192.228.79.201. What you’ll see is: starting from hop 14, the 3 measurements for the same hop come from different IP address: hop 14: 184.105.80.202, 72.52.92.122 hop 15: 72.52.92.122, 216.218.223.28 hop 16: 216.218.223.28, 130.152.181.189 hop 17: 130.152.181.189, 206.117.5.22 hop 18: 206.117.5.22, 192.228.79.201 hop 19: 192.228.79.201 My first doubt is with Paris traceroute is it still possible that response IP can change due to LB mechanism on the returning path? At hop 18, the traceroute actually already reached the destination, but it continued to perform the hop 19, why? At hop 19, there is one measurement from 192.228.79.201 reporting abnormally small RTT of 0.449ms. How come? Can that happen to other measurements as well, under what circumstances? The above listed neighbouring hops always share one IP address, which makes it seem like a data formatting issue. Is there a known bug? Thanks in advance for your attention. Best regards, wenqin Here below the measurement in question: ==== [ { "lts":-1, "size":40, "from":"176.227.133.141", "dst_name":"192.228.79.201", "fw":4740, "proto":"UDP", "af":4, "msm_name":"Traceroute", "prb_id":10460, "result":[ { "result":[ { "rtt":0.533, "ttl":255, "from":"192.168.1.1", "size":28 }, { "rtt":0.418, "ttl":255, "from":"192.168.1.1", "size":28 }, { "rtt":0.405, "ttl":255, "from":"192.168.1.1", "size":28 } ], "hop":1 }, { "result":[ { "x":"*" }, { "x":"*" }, { "x":"*" } ], "hop":2 }, { "result":[ { "rtt":677.27, "ttl":253, "from":"10.130.162.13", "size":28 }, { "rtt":660.216, "ttl":253, "from":"10.130.162.13", "size":28 }, { "rtt":709.112, "ttl":253, "from":"10.130.162.13", "size":28 } ], "hop":3 }, { "result":[ { "rtt":666.445, "ttl":252, "from":"10.130.162.250", "size":28 }, { "rtt":995.219, "ttl":252, "from":"10.130.162.250", "size":28 }, { "rtt":668.192, "ttl":252, "from":"10.130.162.250", "size":28 } ], "hop":4 }, { "result":[ { "rtt":681.02, "ttl":250, "from":"10.130.162.82", "size":28 }, { "rtt":652.502, "ttl":250, "from":"10.130.162.82", "size":28 }, { "rtt":673.857, "ttl":250, "from":"10.130.162.82", "size":28 } ], "hop":5 }, { "result":[ { "rtt":685.088, "ttl":250, "from":"88.202.127.129", "size":28 }, { "rtt":665.164, "ttl":250, "from":"88.202.127.129", "size":28 }, { "rtt":657.344, "ttl":250, "from":"88.202.127.129", "size":28 } ], "hop":6 }, { "result":[ { "rtt":669.097, "ttl":249, "from":"88.202.127.121", "size":28 }, { "rtt":743.974, "ttl":249, "from":"88.202.127.121", "size":28 }, { "rtt":637.311, "ttl":249, "from":"88.202.127.121", "size":28 } ], "hop":7 }, { "result":[ { "ttl":243, "rtt":692.425, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 }, { "ttl":243, "rtt":659.768, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 }, { "ttl":243, "rtt":698.084, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 } ], "hop":8 }, { "result":[ { "ttl":247, "rtt":684.096, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 }, { "ttl":247, "rtt":685.871, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 }, { "ttl":247, "rtt":736.12, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 } ], "hop":9 }, { "result":[ { "rtt":675.198, "ttl":246, "from":"10.130.1.201", "size":28 }, { "rtt":671.127, "ttl":246, "from":"10.130.1.201", "size":28 }, { "rtt":683.236, "ttl":246, "from":"10.130.1.201", "size":28 } ], "hop":10 }, { "result":[ { "rtt":736.688, "ttl":54, "from":"37.49.236.10", "size":28 }, { "rtt":697.844, "ttl":54, "from":"37.49.236.10", "size":28 }, { "rtt":818.184, "ttl":54, "from":"37.49.236.10", "size":28 } ], "hop":11 }, { "result":[ { "rtt":992.33, "ttl":53, "from":"184.105.213.173", "size":28 }, { "rtt":920.759, "ttl":53, "from":"184.105.213.173", "size":28 }, { "rtt":966.019, "ttl":53, "from":"184.105.213.173", "size":28 } ], "hop":12 }, { "result":[ { "x":"*" }, { "rtt":428.86, "ttl":52, "from":"184.105.80.202", "size":28 }, { "rtt":372.607, "ttl":52, "from":"184.105.80.202", "size":28 } ], "hop":13 }, { "result":[ { "rtt":448.726, "ttl":52, "from":"184.105.80.202", "size":28 }, { "rtt":427.897, "ttl":51, "from":"72.52.92.122", "size":28 }, { "rtt":550.12, "ttl":51, "from":"72.52.92.122", "size":28 } ], "hop":14 }, { "result":[ { "rtt":422.308, "ttl":51, "from":"72.52.92.122", "size":28 }, { "rtt":447.841, "ttl":241, "from":"216.218.223.28", "size":68 }, { "rtt":339.084, "ttl":241, "from":"216.218.223.28", "size":68 } ], "hop":15 }, { "result":[ { "rtt":470.177, "ttl":241, "from":"216.218.223.28", "size":68 }, { "rtt":338.323, "ttl":241, "from":"130.152.181.189", "size":68 }, { "rtt":482.44, "ttl":241, "from":"130.152.181.189", "size":68 } ], "hop":16 }, { "result":[ { "rtt":359.104, "ttl":241, "from":"130.152.181.189", "size":68 }, { "rtt":630.604, "ttl":48, "from":"206.117.5.22", "size":68 }, { "rtt":195.704, "ttl":48, "from":"206.117.5.22", "size":68 } ], "hop":17 }, { "result":[ { "rtt":759.236, "ttl":48, "from":"206.117.5.22", "size":68 }, { "rtt":369.954, "ttl":48, "from":"192.228.79.201", "size":68 }, { "rtt":431.369, "ttl":48, "from":"192.228.79.201", "size":68 } ], "hop":18 }, { "result":[ { "rtt":397.795, "ttl":48, "from":"192.228.79.201", "size":68 }, { "x":"*" }, { "ttl":48, "rtt":0.449, "ittl":2, "from":"192.228.79.201", "size":68 } ], "hop":19 } ], "timestamp":1482177892, "src_addr":"192.168.1.115", "paris_id":15, "endtime":1482177928, "type":"traceroute", "dst_addr":"192.228.79.201", "msm_id":5010 } ]

2 1

Atlas API down?
by Stephane Bortzmeyer 18 Jan '17

18 Jan '17

RIPEAtlas.RequestSubmissionError: Status 405, reason "{"error":{"status":405,"code":104,"detail":"Method \"POST\" not allowed.","title":"Method Not Allowed"}}" Just when I wanted to investigate pool.ntp.org failure :-(

1 0

Surplus RIPE Atlas credits
by Michael Oghia 13 Jan '17

13 Jan '17

Hi everyone, I host a probe but do not create measurements. As such, I have a large surplus of unused credits. Is anyone in need of credits and would like for me to transfer them? Best, -Michael __________________ Michael J. Oghia iGmena <http://igmena.org/> communications manager Independent #netgov consultant & editor Belgrade, Serbia Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia>

7 13

Maximum daily spending boundaries?
by Sebastian Castro 12 Jan '17

12 Jan '17

Hi: While scheduling a few one-off measurements, I'm constantly hitting the "Maximum daily spending" limit, however I don't have any ongoing measurements and just a handful of one-off measurements going at a expense of ~5000 credits each. When is the daily spending is reset? Midnight in some time zone? Something different? This case seems to be a race condition or something like that, as few measurements attempts actually go through, while the rest is rejected. A consistent behavior seems to be "from here no other measurement will succeed" Cheers! -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

2 1

Maximum (unknown) spending limit?
by Sebastian Castro 11 Jan '17

11 Jan '17

Happy New Year RIPE Atlas Users: Executing some measurements today, it started rejecting them with the message: Executing this measurement request would violate your maximum daily spending limit of {max} credits. Please stop some of your currently running measurements and try again. It's startling the {max} credits, like a template that didn't get replaced when processing the message, not the message itself as it's documented. A little 2017 bug perhaps? Cheers! -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

2 1

JE country code
by Marty Strong 11 Jan '17

11 Jan '17

Hi Atlas list, I sent a probe to Jersey (https://atlas.ripe.net/probes/28215/) but it shows up as GB instead of JE. Seems like perhaps a geodb is wrong :)

6 9

RIPE Atlas APIs
by Robert Kisteleki 03 Jan '17

03 Jan '17

Dear colleagues, We've just published a RIPE Labs article about a reminder for the RIPE Atlas API version changes. You can read it here: https://labs.ripe.net/Members/kistel/ripe-atlas-api-changes Regards, Robert Kisteleki RIPE NCC

2 3

status-checks very slow?
by Stephane Bortzmeyer 03 Jan '17

03 Jan '17

Since yesterday 2200 UTC, status-checks seem very slow (around 15 seconds, which make my monitoring software Icinga timeout). New Year party hangover?

1 1

RIPE Atlas Probes at Hackerspaces
by Vesna Manojlovic 28 Dec '16

28 Dec '16

Dear all, here is an example of the possible communities that are now easier to build around RIPE Atlas probes. With the tagging of similar probes, existing communities can use additional tools for creating and analysing RIPE Atlas measurements, such as "IXP Country Jedi", to create their own interpretation of the available data. The example we used is - hackerspaces: "community-operated physical places, where people share their interest in tinkering with technology, meet and work on their projects, and learn from each other." We are hoping this is going to be an inspiration to the reader, and an invitation to play with the results and improve on the code. Longer story, with pictures, is available on RIPE Labs: https://labs.ripe.net/Members/becha/the-next-42-ripe-atlas-probes-at-hacker… Regards, Vesna

1 0

Http
by mostafa shahdadi 22 Dec '16

22 Dec '16

Sent from my iPad

1 0

New on RIPE Labs: Four Years of RIPE Atlas Anchors
by Mirjam Kuehne 22 Dec '16

22 Dec '16

Dear colleagues, Four years have passed since the RIPE NCC announced its plans to put RIPE Atlas anchors into production. Since the first anchors went online in 2013, we’ve been working hard to both maintain and expand the network. As a result, we currently have 238 anchors deployed across 66 countries! Please find more on RIPE Labs: https://labs.ripe.net/Members/alun_davies/four-years-of-ripe-atlas-anchors Kind regards, Mirjam Kuehne RIPE NCC

1 0

Success Story: Zoom-in on Germany
by Vesna Manojlovic 09 Dec '16

09 Dec '16

Dear community, we wrote an article as an example of how cross-pollination between two or more communities can create success. An overlap between IETF participants, RIPE Atlas users and listeners of a popular German podcast has led to growth in the deployment of RIPE Atlas probes. We are still interested in expanding this platform in areas and networks that need more coverage. For pictures & links, go here: https://labs.ripe.net/Members/becha/ripe-atlas-success-story-zoom-in-on-ger… Text is bellow. Regards, Vesna In July 2016, during the IETF meeting in Berlin, the popular "rfc podcast" had a special episode aired an interview with Daniel Karrenberg talking about the RIPE NCC and RIPE Atlas. Thanks to the podcast listeners, and with the help of promotion on Twitter, the episode prompted many, many, MANY applications for new RIPE Atlas probe hosts. Because of both summer vacations and a temporary shortage of probes, there was a delay in shipping - but when the new batch of probes arrived at our office, we started shipping them to applicants, most of whom were from Germany. Currently, with regard to the number of active probes, Germany is leading with more than 1,000. This is more than the USA, which was in the lead for the previous few years. If you want to zoom in to this success-story, you can take a look at this RIPEstat widget. There you can see that, between 22 September and 7 October, the number of activated probes jumped from 999 to 1,157. Thank you to all the hosts, in Germany and elsewhere, who are helping to build RIPE Atlas - the largest active measurements platform! Actions Although we are happy that there is so much enthusiasm in Germany, we are still interested in increasing diversity of coverage. To this end, we're looking to reach out to: - Regions, countries and areas within countries with fewer probes - Networks (ASNs) with fewer probes - Deploying RIPE Atlas anchors instead If you would like to apply for your own RIPE Atlas probe, there is a special link just for the readers of this RIPE Labs article :) If you already have a probe, and want to get in touch: - Check out the Community pages - Follow us on Twitter - Be active on the mailing list

1 0

Probe 16917 started over
by Jacques Lav!gnotte. 08 Dec '16

08 Dec '16

after changing the usb memory stick. https://atlas.ripe.net/probes/16917/#!tab-general Regards, Jacques -- GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/

1 0

ipad air 2
by mostafa shahdadi 07 Dec '16

07 Dec '16

Sent from my iPad

1 0

ipad air 2
by mostafa shahdadi 07 Dec '16

07 Dec '16

Sent from my iPad

1 0

RIPE Atlas and nagios status-checks
by Robert Kisteleki 07 Dec '16

07 Dec '16

Dear All, The following message may be of interest to you if you're using Nagios (or variations like icinga) to query RIPE Atlas for status-checks. Yesterday morning our operations team made a change to the service configuration such that atlas.ripe.net only answers queries if they have proper Host: headers set. This is arguably a good operational practice, so we'd like to enforce it. However, one of the users running said nagios checks noticed that this causes 403 answers instead of the expected behaviour. We concluded that this is because the check_http plugin doesn't always set the Host: header. According to our statistics in total 12 users are affected, and since we could not foresee this problem, we temporarily reverted our configuration to the old settings. The fix on the client side is easy: one needs to add "-H atlas.ripe.net" parameter (or a similar change depending on forks and versions) to the checks. We'd like to ask our user to apply this change in the next two weeks in order to send well-formatted requests to our service. Thank you, Robert Kisteleki RIPE NCC

1 1

New on RIPE Labs: Countering RIPE Atlas Hardware Issues with Better Firmware
by Mirjam Kuehne 06 Dec '16

06 Dec '16

Dear colleagues, We're working on installing better firmware in order to counter hardware issues with RIPE Atlas. Please find more information on RIPE Labs: https://labs.ripe.net/Members/kistel/ripe-atlas-countering-hardware-issues-… Kind regards, Mirjam Kuehne RIPE NCC

1 0

tp-link probev3 tl-mr3020
by folkert 25 Nov '16

25 Nov '16

Hi, I have one of those tp-link probes, a v3 it looks like. Now when I got it, I was warned to put it on a 1A powersource. Now that is a bit of a problem so I started to measure its power usage to verify if I could maybe run it on a smaller power supply. What I measure is 0.14A upto 0.23A - that should easily be powered by a 0.5A power supply I think. As I'm not an electronics expert I'm now writing this message for confirmation: am I right about the power usage? Or ar there situations where it would be using a lot more power? Thank you, Folkert van Heusden -- ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

3 2

Fifteen new RIPE Atlas anchors have joined the community
by Michela Galante 24 Nov '16

24 Nov '16

Dear colleagues, Fifteen new RIPE Atlas anchors have been activated since our last announcement in September, bringing the total number to 231: - us-bos-as26167, hosted by Markley Group in Boston, United States (IPv4-only anchor) - us-pct-as88, hosted by Princeton University in Princeton, United States (IPv4-only anchor) - tz-dar-as327844, hosted by Tanzania ISP Association in Dar es Salaam, Tanzania and ke-nbo-as37578, hosted by TESPOK in Nairobi, Kenya. These are the first two of five anchors that ISOC will sponsor. - dk-aal-as9158 and dk-cph-as9158, hosted by Telenor Denmark A/S in Aalborg and Copenhagen, Denmark - au-syd-as135150, hosted by bet365 in Sydney, Australia - ca-wnp-as16395, hosted by asn16395 in Winnipeg, Canada - us-ljl-as195, hosted by Center for Applied Internet Data Analysis (CAIDA) at the University of California, San Diego in La Jolla, United States - nz-akl-as38064, hosted by NZ Registry Services in Auckland, New Zealand - us-bos-as111, hosted by the Boston University in Boston, United States - kw-kwi-as42961, hosted by Zain Kuwait in Kuwait City, Kuwait - nl-ede-as12859-client, hosted by HCC in Ede, Netherlands - it-rom-as24796, hosted by NaMeX Consortium in Rome, Italy - us-fcn-as32934, hosted by Facebook in Forest City, United States. You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas anchors online: https://atlas.ripe.net/anchors/list/ Interested in hosting a RIPE Atlas anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa in order to add more geographical diversity to the measurement data. There are several organisations that want to host a RIPE Atlas anchor but don’t have the necessary funding. To learn more about sponsoring an anchor, or for any other questions, please contact us at atlas(a)ripe.net And don’t forget to let us know if you’re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC

1 0

Emails Regarding Probe Connection Issues
by Alun Davies 17 Nov '16

17 Nov '16

Dear members of the RIPE Atlas community, It was recently called to our attention that certain emails we send out to RIPE Atlas probe hosts, concerning probe connection issues, have been somewhat abrupt in their tone. We are working to address the issue. While we devote a great deal of effort to ensuring that any correspondence we send out is both informative in content and appropriate in tone, we greatly appreciate feedback whenever it is felt that such goals have not been met. We would like to take this opportunity to once again thank all RIPE Atlas probe hosts for their ongoing participation. Best regards, Alun Davies (RIPE NCC)

7 7

New on RIPE Labs: Changes to RIPE Atlas API Keys
by Mirjam Kuehne 11 Nov '16

11 Nov '16

Dear colleagues, We’ve made some changes to RIPE Atlas API Keys with the aim of improving the experience of RIPE Atlas users. The changes are designed to boost transparency and efficiency in the way users are able to manage their API Keys. Please find more details on RIPE Labs: https://labs.ripe.net/Members/alun_davies/changes-to-ripe-atlas-api-keys Kind regards, Mirjam Kuehne RIPE NCC

1 0

Probe marked as offline, but it's online...
by Christian Schrötter 10 Nov '16

10 Nov '16

Hello Atlas users! I've connected my probe to a new network environment, to test everything before the big migration starts. It came up again immediately and displayed it's new network details at the WebUI. For the first time there was an IPv6-ULA prefix visible. The router (OpenWrt 15.05) supports full IPv6 via tunnel, but it's not advertised to the probe's VLAN and blocked by firewall rules. Everything seems to work, good! I've switched it off/on for several times, went back to the old router/modem and powered it on again. After some hours I've checked the WebUI again: My probe is offline! :-( I've tested it again on the new router: Offline! Once again on the old setup: Offline! Untouched default router/modem from my ISP: Offline! Current LED status: (from 1-5; power to button) > on > off > slow blink > on > on SOS-DNS-history from Wireshark: (switch port mirrored to my analysis interface) > Standard query 0x0002 AAAA U.*************.sos.atlas.ripe.net > Standard query response 0x0002 AAAA 2001:67c:2e8:11::c100:1337 > Standard query 0x0003 A U.*************.sos.atlas.ripe.net > Standard query response 0x0003 A 193.0.19.55 The probe is online and communicates with many servers. Looks like the built-in tests are running fine. There is NTP, DNS, ICMP, UDP and HTTP traffic. But it's still offline at the WebUI. I've double and triple checked everything on my side. Any ideas what's going wrong? -- With kind regards, Christian Schrötter

2 4

Latencymon widget: It is not possible to retrieve measurement information for this ID
by Marat Khalili 10 Nov '16

10 Nov '16

Latenchmon widget stopped working for me this morning with the message "It is not possible to retrieve measurement information for this ID". Same error displays for sample widget code from documentation <https://atlas.ripe.net/docs/tools-latencymon/#embed>: > |<script > src="https://atlas.ripe.net/resource/latencymon/latencymon-widget-main.js"></script> > <div id="place-here"></div> <script> initLatencymon( '#place-here', > {}, // Tool options, see table below for more info { > measurements:[1791207, 2083078] } // Query options, see table below > for more info ); </script>| Has something changed in API, or are these just temporary problems server-side? -- With Best Regards, Marat Khalili

3 3

Ethical considerations
by Robert Kisteleki 07 Nov '16

07 Nov '16

Dear All, As mentioned in my RIPE Atlas update during the RIPE 73 MAT working group, we'd like to draw RIPE Atlas users’ attention to relevant ethical considerations. We've just published a RIPE Labs article about this: https://labs.ripe.net/Members/kistel/ethics-of-ripe-atlas-measurements/ Regards, Robert Kisteleki RIPE NCC

1 0

Probe not taking UDMs for months but no issue reported
by gboonie 06 Nov '16

06 Nov '16

Hi, My probe 24434 had an issue without me being aware because there was no notification. But even if there was, it was hard to detect. The only reason I found out was because I looked at a long running measurement that did not return data. On the other side, the built in measurements seemed fine. So first though was that something prevented the probe to perform DNS tests to the network's resolvers. I've attached a laptop to the connection but all worked fine. So rebooted the probe and found that the USB storage went to read-only. But why does it only detect this after a reboot? This probably means that the probe probably only checks at startup what the status is of the USB key. The other thing that is odd is that the probe kept earning credits. Here is a graph with the proof that it did stop taking UDMs early august. *My request: Please improve the probe's detection of issues. I do not mind replacing a USB dongle at all but I do find it annoying that the probes can be in this state where it is not down but also not taking any UDMs.* Thanks, Dave Proud owner of 3 probes.

1 0

Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database)
by Ondřej Caletka 03 Nov '16

03 Nov '16

Dne 6.9.2016 v 15:32 Tim Bruijnzeels napsal(a): > Dear colleagues, > > In compliance with data protection rules and the desire to maintain a “clean” database, we plan to remove unreferenced objects from the RIPE Database. We have recently been working on an improved implementation, and we are now ready to re-start the process. > > In order to be eligible for deletion, objects must have no incoming references (or be a person-maintainer or role-maintainer pair) and must have had no incoming references from any aut-num, domain, inet(6)num, route(6), as-set, filter-set, inet-rtr, peering-set, route-set, rtr-set, as-block, key-cert or irt object during the last 90 days. Hello Tim, hello RIPE Atlas team, I just found out that my RIPE Atlas Anchor contact role object CAAO-RIPE has been cleaned from the RIPE database. This object is registered as a RIPE Atlas Anchor contact in the RIPE Atlas systems. Could you perhaps somehow undelete such role object? Would it be possible to prevent such clean up in the future? Best regards, Ondřej Caletka CESNET

3 6

Probe reconnecting problem
by Nils Ohlmeier 03 Nov '16

03 Nov '16

Hello, is there any known problem around probes reconnecting after the uplink connectivity got lost? My probe was offline for several days even though my local network worked fine. I'm assuming that the uplink was dead for some time. And I waited a few days to see if the probe would recover by itself, but eventually gave up and power cycled it. Is there anything I could do to debug such a problem in case it should happen again? Cheers Nils

2 1

Do you have any Probe version 2 [Lantronix XPort] available for distribution?
by ripe＠brite.cz 03 Nov '16

03 Nov '16

Hi team, I will have the opportunity to install a probe on very remote place. Due to limited space in the place of installation, and also very limited reachability in case of USB failure, I would like to install only the previous version of probe, without USB flash drive. Do you have one or two Probes [not based on TP Link router] available? Thank you Jiri

2 1

Fwd: Your RIPE Atlas Probe (ID: 24870) is not connected to our network
by Jonathan Brewer 02 Nov '16

02 Nov '16

Hi Team, It'd be great if you could change the tone of the alert messages below. Admit some fault. Ask for help. The majority of disconnects I've seen have been due to device failure, nothing to do with " everything is set up correctly on your side" and messages like this do nothing to encourage me or the networks I've convinced to host probes to help fix the problems. It really hurts that I've lost so many probes that took so much effort to get installed - and these messages don't help. Thanks, Jon ---------- Forwarded message ---------- From: RIPE Atlas <atlas(a)ripe.net> Date: 30 October 2016 at 20:41 Subject: Your RIPE Atlas Probe (ID: 24870) is not connected to our network To: jon.brewer(a)gmail.com Dear RIPE Atlas probe host, Thank you for participating in RIPE Atlas! This is the second reminder that your probe () is not connected to our infrastructure and has been disconnected since 2016-10-09 05:44 UTC. Could you please check whether everything is set up correctly on your side? You may be able to find more information about the possible cause of the problem here: https://atlas.ripe.net/probes//#!tab-status <https://atlas.ripe.net/probes/24870/#!tab-status> If you believe everything is correctly set up and your probe is still reported as disconnected after 24 hours when you log in at https://atlas.ripe.net, please contact us at atlas(a)ripe.net Best regards, RIPE Atlas Team ********** You are receiving this message because you applied for or were given a RIPE Atlas probe. We will only send messages when your probe becomes disconnected for an extended period of time.

1 0

Probe pickup at meeting?
by Joe Provo 27 Oct '16

27 Oct '16

Hey, Are any $SMALLNUM probes available for pickup tonight/tomorrow? I found I only have one "to be distributed" probe left, and in a couple weeks will be taking holiday in Columbia (in current coverage voids :-). Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG

2 1

Actual measurement interval much larger than planned
by Wenqin SHAO 20 Oct '16

20 Oct '16

Dear list, I encountered some cases where the actual time interval between two neighbouring measurements being much larger than the scheduled value. Have you witnessed similar cases? I appreciate explanations on underlying reasons. Here goes an example: from ripe.atlas.cousteau import AtlasResultsRequest filters = dict(msm_id=1010, probe_ids=[16981], start=1470055258, stop=1470056217) is_success, results = AtlasResultsRequest(**filters).create() if is_success: for mes in results: print mes.get('timestamp', -1) The above code requests some built-in ping measurements (240s interval) made by probe 16981 and prints their timestamps. See below for the execution result: 1470055259 1470055499 1470055978 1470056216 Four measurements are retrieved within the given time range. I noticed that time interval between the 2nd and the 3rd measurement is 479s much larger than the planned value 240s. How come? Many thanks for your attention. Best regards, wenqin

4 9

Re: [atlas] ripe-atlas Digest, Vol 62, Issue 14
by Andre Heinrichs 19 Oct '16

19 Oct '16

On Wed, Oct 19, 2016 at 12:00 PM, <ripe-atlas-request(a)ripe.net> wrote: > Date: Tue, 18 Oct 2016 12:24:25 +0200 > From: Philip Homburg <philip.homburg(a)ripe.net> > To: ripe-atlas(a)ripe.net > Subject: Re: [atlas] probe offline - troubleshooting requested > Message-ID: <3af3a709-9198-06d7-19a1-ae367d03a58e(a)ripe.net> > Content-Type: text/plain; charset=utf-8 > > On 2016/10/18 7:46 , Andre Heinrichs wrote: >> Any ideas what I could try to get the probe reconnected? >> >> Just to be complete: Here are the last lines of the SOS history: >> 62.109.121.35 2016-10-18 05:43:27 A 3h 59m >> 62.109.121.35 2016-10-18 05:43:27 AAAA 3h 59m > > The best thing to try is to reflash the USB stick (i.e. connect the > probe without USB stick, wait for a out 10 minutes and insert the USB > stick). > > Unfortunately, corruption of the filesystem on the USB stick can result > in weird behavior, like your probe is showing. SOS works fine but it > doesn't connect. Just for the record: the probe works again after I did the USB fix Philip described. I'm guessing the status tab only showed the hint about Firewall trouble because that would have been another possible cause for the symptoms. Thanks, Andre

2 1