September 2016 - ripe-atlas - mailman.ripe.net

Plan to Implement RIPE Atlas WiFi Measurements
by Robert Kisteleki 09 Oct '17

09 Oct '17

Dear colleagues, We wanted to update the community and let you know that we plan to start work on the proposed experiment with WiFi measurements in mid-2016. As we communicated in a recent RIPE Labs article, we will work with GÉANT as a test partner to learn more about the operational effects of introducing WiFi measurements to the RIPE Atlas system, in addition to the benefits we believe this could provide for the entire RIPE Atlas community. Please see the article for more details if you are interested: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measure… We will continue to update you once we’ve begun work on this plan, and we welcome your comments in the meantime. Regards, Robert Kisteleki RIPE NCC

3 3

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 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

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

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

SSL error on OpenIPMap
by Anurag Bhatia 04 Oct '16

04 Oct '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello everyone. Is it just me or anyone else getting SSL error on OpenIPMap? I can see that SSL cert of atlas.ripe.net is valid but when we open OpenIP Map, it calls one specific map image from fastly on HTTP resulting in "mixed content" making Chrome to throw SSL error. This is the URL of that image:http://stamen-tiles-c.a.ssl.fastly.net/toner-lite/3/5/5.png It does seems to be available on https already and so probably someone at RIPE need to update URL to call https in URL and avoid the false positive it's giving. Thanks. - -- Anurag Bhatiaanuragbhatia.com -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.5.2 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJX7qbdCRDAbdUkJF5Y4gAAP7oP/R+c7QMQEIt7c0/fLnKx IrvoSxS0RlivGHQBcQY4DcQvXNU0SsBdjUTG3hOJP/OyCERG9Uar8xRFXKAB LHrUGPa9rGdxHtJFJYL0fgKc0o0aELBkaot3unJPBRwGtp5Acyfx3Yv9CUF+ fqxq27tRnRtXklqVfYw5aWC20CC4EHEme3vv0+QsdasJ0s1mi1zehI1c60yI RQqZ35MaB9flyMyxU1L2CaKHh0BnZs0ssSxGsr/s2cfqhfu5KPzagi/obsEs 6mhwtkTPD1Y/649QAzs2E3vpZ83tn8fkExU54hHznpBy4QmNIAx7pnlwtOrX 8ou7Rn1Yt7V5NiSHGkr31sPJfMfHXErZ6NAl/Z7uPcs9+ofAkAEBh5H7pINr BFwZzX6DsqNiq1Q+F9sU385D5144Y4YE/vDIDXYXhSgbHv9NeqIph7Ceitt9 Ap4wx7eOh/8ONLddUdqf4/M0m9ORsFc4fRAhFkLCzLdUlXpDqAGGgxSFIcg4 NiInbdyZCO1Ula7TQCPR0qtTDJQ75w93wj5STM2uZjlVd5K6QUB4bmz8S/QX oEMLOSmjcWybQH+dBSJ25VVynCu7sRkSUyhyE2wwrb2adDw8pS0QMG5cyjhZ DX+XP9KGoFi6xYFCQypXO+bkSsh84OBKrxo+fFfznFTYFkDZ6yae/ZKSfC/o urP4 =coGp -----END PGP SIGNATURE-----

2 2

Inconsistent system tags
by Johannes Matheis 30 Sep '16

30 Sep '16

Hello, I got IPv6 connectivity for my probe 4365 a few days ago (2016-09-26) when I first noticed the system tag "IPv6 Doesn't Work". As the system tags aren't updated more often than every four hours I started some successful IPv6 measurements on that probe and settled back for four days. Now the probe is still flagged as IPv6 not working. In the meantime I noticed the tag "v2" but the general information tab tells me the system architecture is probev1… Actually I don't know if it's a v1 or v2, but it's still an old Lantronix one, so it's not completely wrong :-) Is there a possibility to re-trigger the assignment of the system tags for this probe or some other solution? Thanks! jomat

2 1

Initiating a TCP, UDP, and ICMP traceroutes from the same probe at the same time
by Zakaria Al-Qudah 30 Sep '16

30 Sep '16

Hi Folks, I am planning an experiment where I need each probe to perform TCP, UDP, and ICMP traceroutes at the same time. I could not see how I can do it using the Ripe Atlas website. Is there any way to do it? Best regards, Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

Making public probes’ IP addresses public in web interface
by Andreas Strikos 30 Sep '16

30 Sep '16

Hello, We made a change a few weeks ago to the RIPE Atlas web interface to align it more closely with the API. As a result, you can now see the IP addresses for public probes, regardless of whether you are a logged in user or not. This information is displayed on the public probes’ detailed information pages, under the “Network” tab. Previously, public probes' IP addresses were not shown, even for logged in users. Nothing has changed in the API or the web interface for probes that are not shared publicly. We understand that some of you were surprised by this change and we apologise for not communicating it earlier. However, I want to make it clear that the IP addresses of public probes have always been available via the API, whether you are a logged in user or not. We decided to include it via the web interface so that our users could access the same information regardless of which interface they decide to use. RIPE Atlas is meant to be a public platform that openly provides data to everyone interested. In this spirit, we encourage everyone to make their probes public. However, if you decide that you *don’t* want to share your probe publicly, you can change this setting by going to your probe’s detailed information page (go to "My Atlas" and click on your probe’s ID), clicking on the “Edit” button under the “General Information” tab, and deselecting the “Shared Publicly” box. Please note that personal information such as MAC addresses and email addresses will never be shown, regardless of whether you decide to share your probe publicly or not. You can learn more about what information is made public in RIPE Atlas in this RIPE Labs article: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-p… Please let us know if you have any questions or concerns. Regards, Andreas Strikos RIPE NCC

1 0

Fifteen new RIPE Atlas anchors - including the first IPv4-only anchor
by Michela Galante 19 Sep '16

19 Sep '16

Dear colleagues, Fifteen new RIPE Atlas anchors have been activated since our last announcement in June, bringing the total number to 216: - us-abn-as54054, hosted by Deteque LLC in Ashburn, United States - us-sgu-as46309, hosted by Gartner Inc in Saint George, United States - lu-kay-as35733, hosted by EURid VZW in Kayl, Luxembourg - de-ham-as35258, hosted by akquinet Outsourcing in Hamburg, Germany - ua-iev-as24725, hosted by Hostmaster LLC in Kiev, Ukraine - ca-wnp-as18451, hosted by les.net in Winnipeg, Canada - de-dus-as12676, hosted by HKN GmbH in Düsseldorf, Germany - uk-lon-as34587, hosted by bet365 in London, United Kingdom - us-lax-as15133, hosted by Verizon Digital Media in Los Angeles, United States - us-lwc-as2495, hosted by KanREN Inc in Lawrence, United States - lb-bey-as12812, hosted by the American University of Beirut in Beirut, Lebanon (IPv4-only anchor) - pg-pom-as17828, hosted by Telikom PNG (sponsored by APNIC) in Port Moresby, Papua New Guinea - ch-zrh-as9092, hosted by Open Systems in Zurich, Switzerland - nl-ams-as34106, hosted by TMG/Telegraaf in Amsterdam, Netherlands - dk-hje-as39642, hosted by WNB ApS in Højer, Denmark 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/ As a follow-up to some discussion on this list, we wanted to reiterate that we made the decision to support IPv4-only anchors because the goal of RIPE Atlas is to measure as much of the Internet as possible, and right now, that includes IPv4-only networks. We also believe that measuring networks before and after they enable IPv6 provides useful data. IPv4-only anchors are clearly marked as such, and we will implement checks to ensure these anchors become IPv6-capable as soon as their ASNs begin announcing IPv6. In the meantime, the RIPE NCC will continue to actively promote IPv6 deployment through our training courses, IPv6 Act Now website, IPv6 Roadshows and other programs, and our IPv6 Program Manager will follow up with any hosts requesting an IPv4-only anchor to help them in any way possible. We believe that supporting IPv4-only anchors will provide a more comprehensive understanding of the Internet and that the entire Internet community will benefit from more measurement data. You can learn more in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ipv4-only-ripe-atlas-an… 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