- ripe-atlas - mailman.ripe.net

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