- ripe-atlas - mailman.ripe.net

shared fate for my two probes
by Jay Borkenhagen 08 Feb '19

08 Feb '19

Hi, My two RIPE Atlas probes have been acting strangely over the past several months. Very frequently I receive automatic notices from the RIPE Atlas system that both of my probes have been "disconnected from the RIPE Atlas infrastructure" essentially simultaneously. Here's the history from 2018: probe 11171 2018-02-23 18:08:57 UTC. probe 11203 2018-02-23 18:10:23 UTC. probe 11171 2018-06-21 04:32:15 UTC. probe 11203 2018-06-21 04:30:59 UTC. probe 11171 2018-06-24 05:36:57 UTC. probe 11203 2018-06-24 05:37:04 UTC. probe 11171 2018-07-31 20:25:27 UTC. probe 11203 2018-07-31 20:25:32 UTC. probe 11171 2018-08-18 04:48:20 UTC. probe 11171 2018-09-15 02:31:26 UTC. probe 11203 2018-09-15 02:31:28 UTC. probe 11171 2018-10-15 23:03:50 UTC. probe 11203 2018-10-15 23:04:06 UTC. probe 11171 2018-11-16 14:42:28 UTC. probe 11203 2018-11-16 14:42:33 UTC. (Those last three events are eerily periodic.) Each time when I am finally able to visit inspect the probes (both are reported as "Firmware Version 4940 (1100)"), their LEDs are in the same state: --------------- Looking at the units with the on/off LED to the left: (1) the left-most (on/off) LEDs are on steadily. (2) the next LED is off. the next two LEDs are flashing at different frequencies: (3) the next flashes on approx. 48 times per minute (4) the next flashes on approx. 110 times per minute (5) the centers of the wide "WPS/RESET" LEDs are on steadily. --------------- Once these probes fail they remain offline until I try turning it off and on again. The probes are powered similarly: the RIPE-provided USB cable is plugged into an Apple iPhone USB power adapter, in turn plugged into a standard US 120v / 60 Hz AC receptacle. However, the AC power circuits feeding these receptacles come from two very different sources which should not share fate. Until today both probes have been plugged into ports on the same Cisco switch, but after today's disconnect I moved probe 11203 to a different physical switch that has the same VLANs. None of my other equipment experiences any troubles around the times when these events happen to my RIPE Atlas probes. In the past I have reported these events to atlas(a)ripe.net, but I doubt that the causes cited (e.g. "the problem is with your dns") have been accurate. (I do not blame the atlas(a)ripe.net folks who have responded. Something strange is happening here, and I haven't yet cracked it.) I'm curious whether anyone else sees similar behaviors, or has suggestions for ways to determine what is happening. Thanks! Jay B.

3 5

New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution
by Mirjam Kuehne 08 Feb '19

08 Feb '19

Dear colleagues, The good news: RIPE Atlas is growing both in terms of geographical diversity and ASN coverage. What's more, RIPE Atlas is evolving, with a new generation of probe hardware having already passed the test phase and a pilot programme underway to assess the viability of VM anchors. The not so good news: With RIPE Atlas so much in demand, and with our current provider having ceased manufacturing the probe hardware, we've had to dramatically reduce the number of probes we're distributing. Please find more details on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-probes-delays-in-distr… Kind regards, Mirjam Kühne RIPE NCC

5 5

Re: [atlas] New on RIPE Labs: RIPE Atlas Probes: Delays in Distribution
by Gert Doering 08 Feb '19

08 Feb '19

Hi, On Fri, Feb 08, 2019 at 03:32:38PM +0100, Philip Homburg wrote: > On 2019/02/08 13:45 , Micha Bailey wrote: > > Interesting. This seems like a much higher power device. What are the > > actual power requirements? So far my probe has been powered from the USB > > port on the router, and I???m concerned that this may make the > > installation of future probes more difficult. > > The power requirements are quite reasonable when used as an Atlas probe. > There should be no problem powering a v4 probe from a USB port. My v4 probe is fed from an USB port on an older Mac Mini, with no adverse effects I can see. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

1 0

New RIPE Atlas measurement details page
by Alun Davies 31 Jan '19

31 Jan '19

Dear colleagues, We have made the switch to the new and improved user interface for RIPE Atlas measurement details. To see the new interface right now, simply click on any measurement ID on the RIPE Atlas measurement listing page: https://atlas.ripe.net/measurements/ <https://atlas.ripe.net/measurements/> Please note that, for a limited time, you will still be able to revert back to the old interface via the yellow banner at the top of the measurement details page. For further details on exactly what changes have been made and why, please see the following article on RIPE Labs: https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionalit… <https://labs.ripe.net/Members/jasper_den_hertog/new-design-and-functionalit…> Kind regards, Alun Davies RIPE NCC

2 1

EDNS Client Subnet
by Rami Al-Dalky 31 Jan '19

31 Jan '19

Hello, I was exploring the possibility of using RIPE Atlas probes to do some study on EDNS Client Subnet (ECS), however, the way it is implemented on the probes makes it less interesting. When I tried to create a DNS measurement, I found that the only way to send DNS query with option is to set default_client_subnet to True. However, by setting this option, a DNS query will be sent with 0.0.0.0/0 as client subnet. According to the RFC, a compliant resolver which receives such content SHOULD NOT forward the client IP to the Auth. DNS server (which the same behavior when you set the flag to False). That's make it impossible to study the protocol from Auth. DNS perspective. Is there a reason why ECS is implemented that way? If it for privacy issue, the RFC recommends to sent the client IP with /24 prefix for IPv4 and /56 for IPv6 to preserve the privacy. Thanks in advance! Rami

3 3

Columns in Web UI for measurement results can't be sorted
by Evgeniy S. 31 Jan '19

31 Jan '19

Hi, I can't sort by any column in measurement results for traceroute (worked before by mouse click). [image: Screen Shot 2019-01-31 at 2.14.52 PM.png] There is my measurement results page short link https://goo.gl/iQrxWC -- -- With regards, Eugene Sudyr

1 0

Bug in DNS client subnet measurement
by Philip Homburg 31 Jan '19

31 Jan '19

Hi, We got a bug report that using the DNS client subnet option in a measurement results in a form error. It turns out that probe firmware version 4940 will send a malformed DNS query. Code cleanup related to other changes fixes this issue in the upcoming firmware. We expect to release the new firmware in about one month from now. Philip

1 0

Probe v1 disconnecting every 2 hours
by Hugh Saunders 30 Jan '19

30 Jan '19

Hey All, My probe v1 (id:65[1]) has started disconnecting roughly every 2 hours. I read a previous post[2] that said this may be related to power, so changed the USB power supply to one that provides 1A (the FAQ says the need 500ma) but no improvement. I don't notice connectivity issues every couple of hours with any other devices on the same switch. Any suggestions welcome :) Thanks. [1] https://atlas.ripe.net/probes/65/ [2] https://www.ripe.net/participate/mail/forum/ripe-atlas/PDI1MDc1YjM1LTA5MTct… -- Hugh Saunders

5 5

DNSEC Tag for Probes
by Philippe Mächler 28 Jan '19

28 Jan '19

Hello RIPE Atlas Users I’d like to some measurements about DNSSEC with RIPE Atlas and need a way to check if the probe does DNSSEC validation The docs mention the system-tags e.g resolvs A and resolvs AAAA. Is there something like “system: does DNSSEC validation” if not, is there any other way or is this on the roadmap? 😊 Freundliche Grüsse / best regards Philippe Mächler

1 0

Making a bunch of tests/measurements to a single destination is 'tedious'
by Christopher Morrow 24 Jan '19

24 Jan '19

howdy! So, if I have a dns server somewhere and I want to make a bunch of measurements: "how does NYC see my dns?" (pick N probes near NYC) "How does DEN see my dns?" (pick N probes near DEN) "How does LHR see my dns?" (pick N probes near LHR) "how does ...." ...you get the idea... I'm trying to characterize my service from a 'user' perspective by large Metropolis, well within N km of that metropolis anyway :) but across ~70 or so metros, in v4 and v6 and with authoritative and non-authoritative queries with each test running for 4 days so i can see some daily cycles in traffic patterns/etc. The number of measurements is large in total, breaking up by 3-4 metropolis chunks is super tedious :( Can I request an API key (or some other thing) which can make that sort of request happen for all my measurements in one go? The thing I'm probing is very able to handle a few extra thousand queries per second.. and I'd only be hurting myself i get my estimate wrong :) thanks! -chris

3 4