- ripe-atlas - mailman.ripe.net

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

New on RIPE Labs: Orange Blacklisting: A Case for Measuring Censorship
by Mirjam Kuehne 19 Oct '16

19 Oct '16

Dear colleagues, Please find a short a article on measuring censorship on RIPE Labs: https://labs.ripe.net/Members/stephane_bortzmeyer/orange-blacklisting-a-cas… Kind regards, Mirjam Kuehne RIPE NCC

1 0

probe offline - troubleshooting requested
by Andre Heinrichs 18 Oct '16

18 Oct '16

Last night my probe (#29384) was declared offline after the daily Internet disconnection my FritzBox executes to keep the provider from disconnecting me after 24 hours online. According to the SOS history the probe gets DNS requests out but somehow fails to connect completely. I tried rebooting every network component i could locally get my hands on but that didn't seem to help much. The LEDs on the probe don't actually fit any of the descriptions from the FAQ: They are On, Off, fast(er) blink (at least if compared to shortly after booting (Network Test?), On, On. I'm guessing it means the network somehow managed to fail. Although I don't notice anything missing from what I did on the network this morning. 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 TIA, Andre, currently not in reach of the probe

2 1

Shall we continue non-public measurements in RIPE Atlas?
by Mirjam Kuehne 18 Oct '16

18 Oct '16

Dear colleagues, "Non-public measurements" is a feature of RIPE Atlas that allows users to use the infrastructure to measure things while not sharing those results with the public. Is that still a useful feature? Should it exist in the future? For more details, see this new post on RIPE Labs: https://labs.ripe.net/Members/kistel/non-public-measurements-in-ripe-atlas Please also take the polls at the end of the article. Kind regards, Mirjam Kuehne RIPE NCC

1 0

Temporary Reduction of Available History on RIPE Atlas and RIPEstat
by Romeo Zwart 18 Oct '16

18 Oct '16

Dear colleagues, Today, Tuesday, 18 October 2016, between 09:00 and 10:00 UTC, the back-end storage cluster for RIPE Atlas and RIPEstat will be switched to a backup environment. This is part of planned maintenance work. The backup facility has a more limited amount of storage space, which means that RIPEstat and RIPE Atlas, including specific applications like DNSMON and DomainMon, will not serve data older than one year. We expect this to have no impact on ongoing RIPE Atlas measurements, scheduling new measurements, or the retrieval of more recent data from RIPE Atlas, RIPEstat or DNSMON. We apologise for any inconvenience. Kind regards, Romeo Zwart

1 0