- ripe-atlas - mailman.ripe.net

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

Problems with f.root-servers.net in Russia?
by Marat Khalili 18 Oct '16

18 Oct '16

Sorry for slight offtopic, but does anybody know what is up with Russian instance of F root server? I observe periods of very high packet loss since 11th of October. I used to measure my own internet connectivity pinging it, but seems like by internet works better than that of the root server. Here's a measurement with 50 Russian probes, 34 of them show "Unreachable" right now: https://atlas.ripe.net/measurements/6886549/#!probes -- -- With Best Regards, Marat Khalili

2 1

Out of date system probe tags
by Chris Amin 17 Oct '16

17 Oct '16

Dear all, Some of you have noticed that certain system tags (see below) remained applied to probes when they should have been removed. This is because the process that adds and removes these tags was temporarily disabled following the service issues that we experienced earlier in the month. This process has now been re-enabled after verifying that it was not a cause of the service downtime, and these tags have been applied correctly. The affected tags were: * Flaky connection * Firewall problem suspected * DNS problem suspected * No flash drive * Readonly flash drive * Hardware problem suspected Kind regards, Chris Amin RIPE NCC

1 0

Connect/disconnect timestamps on probe page disappeared
by Marat Khalili 13 Oct '16

13 Oct '16

Connect/disconnect timestamps on a probe page like https://atlas.ripe.net/probes/26656/#!tab-network disappeared this morning; durations still shown. Probably some problem with server side scripts? -- -- With Best Regards, Marat Khalili

2 1

firmware download test?
by Yang Yu 12 Oct '16

12 Oct '16

Hi, I have 2 probes that are connected but shown as offline even after several power cycles. I performed USB stick troubleshooting procedures by removing the USB stick and saw NO-USB SOS message. But after inserting the USB stick there wasn't any new SOS messages. Plugged the USB stick to computer and saw corrupted file system. Formatted the stick and inserted it back, still no SOS messages. What kind of filesystem layout is expected on the stick? From what I read the probe should automatically partition/format the stick. Maybe the stick is bad. I do see a good amount of packet loss between the probe's network and the registration server. How robust is the firmware download process (e.g does it abort on TCP RST)? Is there any way to manually load the firmware? Thanks. Yang

3 4

New on RIPE Labs: What Can You Do with One Million RIPE Atlas Credits?
by Mirjam Kuehne 12 Oct '16

12 Oct '16

Dear colleagues, Ever wondered what to do with all those RIPE Atlas credits you earned? Find out on RIPE Labs how you can best spend your credits to check your services' connectivity and troubleshoot potential issues. https://labs.ripe.net/Members/becha/what-can-you-do-with-one-million-ripe-a… Kind regards, Mirjam Kuehne RIPE NCC

1 0

Re: [atlas] ripe atlas probe v1 cat sylvester (Colin BT)
by Colin Johnston 10 Oct '16

10 Oct '16

smaller pic now to so hopefully auto approved :) Managed to raise over 2500 pounds for Byte Night NW (Action for Children) https://www.facebook.com/ByteNight <https://www.facebook.com/ByteNight> contact myself if want to donate Here is Sylvester on Bus to event, sleeping out and on Bus back home. yours Colin Johnston

1 0

Service downtime
by Robert Kisteleki 06 Oct '16

06 Oct '16

Hello, We seem to experience a database backend problem, rendering the whole service unavailable. We're busy fixing it and investigating the cause. Ill report on progress as soon as I have more information. Regards, Robert

1 1