- ripe-atlas - mailman.ripe.net

Probes fluctuation
by Rami Al-Dalky 30 Apr '19

30 Apr '19

Hello, I am running a number of one-off measurements and all what I request is 200 probes. However, I see a fluctuation in the number of participating probes (sometimes I get 198 and sometimes as low as 175). Any idea what is the issue? Thanks a lot, Rami

4 3

All our atlas probes have reverted to DHCP
by Sebastian Wiesinger 24 Apr '19

24 Apr '19

Hi, all of our four atlas probes have reverted from their fixed network configuration to DHCP which is a shame because there is no DHCP at their present locations. Also this not the first time it happend. Can someone explain why this happens and how to prevent this? This wastes a lot of time and effort every time it happens. Regards Sebastian

2 1

Re: [atlas] contacing probe owner.
by Geert Jan de Groot 20 Apr '19

20 Apr '19

> Quite the opposite IMHO, understanding that the anticipated means of > communication will be email and that the email address of a probe's host > will be generic, eg. <ripe-atlas-probe-[number](a)atlas.ripe.net>, > redirecting all incoming emails to a final address. The redirection > would be configured via the portal then. Using an address as described above would allow enumeration attacks. If it would use a hash instead it would be safer. The hash for probe XXX would be obtainable via the portal, where you would need to look up probe's details anyway. Geert Jan

2 1

Measurement result issues for some RIPE Atlas anchors
by Philip Homburg 18 Apr '19

18 Apr '19

In April, we started investigating a strange traceroute result reported by one of the RIPE Atlas anchors. The conclusion of our investigation is that the probe upgrade process for the v3 anchor firmware has been leaving old measurement daemons running as well as starting new ones. This means that a gradually increasing number of measurements from the affected anchors have been performed multiple times more or less simultaneously. Because those processes were writing to the same file, this resulted in a lot of garbled results. Purely by chance, the weird result that triggered the investigation had the first part of one result and the last part of another result in a way that generated syntactically correct JSON. The net result is that for the last few months, measurements done by anchors may have resulted in multiple results at roughly the same time or no results because the results were rejected as invalid. For those who wish to check whether results for specific measurements were affected, the following links will direct you to lists of probe IDs for the affected anchors: https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-virtual&fi… (VM anchors) https://atlas.ripe.net/api/v2/probes/?is_anchor=true&tags=system-v3-pc-engi… (v3 hardware anchors) We are working to resolve the issue and will keep you updated as and when we have more to report. We apologise for any inconvenience this might cause. Philip

1 0

DNS-over-TLS and DNS-over-HTTPS measurement
by Petr Špaček 10 Apr '19

10 Apr '19

Hello, could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements? I had impression that DNS-over-TLS is already supported but now I cannot find it in the UI so I'm probably wrong. Thank you for information! -- Petr Špaček @ CZ.NIC

3 3

Scheduled RIPE Atlas maintenance 2019-04-10 09:00 UTC
by Chris Amin 10 Apr '19

10 Apr '19

Dear RIPE Atlas users, We are planning on making a behind-the-scenes change to the RIPE Atlas database tomorrow in order to make the system more robust. Measurements scheduled during this time may be either rejected or delayed. Probes will continue to carry out measurements as usual so there won't be a gap in scheduled measurement results. The window for the maintenance is 2019-04-10 09:00 UTC until 12:00 UTC. We hope that it will be quicker than this and will keep you updated. Kind regards, Chris Amin RIPE NCC

1 1

DNS measurements broken today?
by Stephane Bortzmeyer 05 Apr '19

05 Apr '19

It seems all DNS measurements (not just mine, checked on <https://atlas.ripe.net/measurements/?page=1#tab-dns> return only an empty array today... % curl -s https://atlas.ripe.net/api/v2/measurements/20566896/results/ []%

1 0

Responsive Probe Fluctuations
by Marcel Flores 05 Apr '19

05 Apr '19

Hi All, Noticed a funny little swing in probe responsiveness. It seems to have returned to normal, but was curious if anyone else had seen it. We do one-off measurement where we select all probes, usually the responsiveness rates look something like: 12743 Requested / 10147 Actually Participated (Taken from 18 March) But on 19 March we started seeing rates more like: 12914 Requested / 7852 Actually Participated Which continued until about 28 March, when it returned to about the previous levels: 12916 Requested / 9943 Actually Participated Something funny happen with the dispatching? Did anybody else see? -- *Marcel Flores, PhD* | Sr. Research Scientist research.verizondigitalmedia.com | AS15133 <https://www.peeringdb.com/asn/15133> p: +1 310.593.6880 e: marcel.flores(a)verizondigitalmedia.com 13031 W Jefferson Blvd. Building 900, Los Angeles, CA 90094

2 2

Probe not coming online anymore after firmware upgrade
by Annika Wickert 25 Mar '19

25 Mar '19

Hi everyone, I bought a new USB Stick for this probe as the old one was tagged as readonly etc.. https://atlas.ripe.net/probes/23913/ <https://atlas.ripe.net/probes/23913/> In the panel it says: 2019-03-21 14:50:02 UTC Probe firmware upgraded Your probe #23913 <https://atlas.ripe.net/probes/23913/> upgraded its firmware from version 3.3.8 to version 4960 But for some reason it is not coming online at all :(. Any idea what could be the issue? I also see no network traffic at all originating from the probe. Best, Annika

5 5

Fwd: credit request
by Michael Rabinovich 22 Mar '19

22 Mar '19

(I previously subscribed to this list using the same mail alias as used for my RIPE Atlas account, and the mail below was held up for moderation since it came from a non-matching email address. I now changed my subscription and am re-sending that email. I apologize in advance if the moderator releases the original mail and you see a duplicate. — Michael) > Begin forwarded message: > > From: Michael Rabinovich <michael.rabinovich(a)case.edu> > Subject: credit request > Date: March 21, 2019 at 2:45:45 PM EDT > To: ripe-atlas(a)ripe.net > > Folks, > > I teach computer science at Case Western Reserve University. I have a group of students working on a research project to characterize certain aspects of DNS and HTTP interactions on the Web. To get a representative measurement, we need to resolve hostnames from top-1M websites from a large number of widely dispersed probes. So we need a large amount of credits and I was wondering if I could ask folks for help. My back of the envelop calculations suggest we are short of ~200M credits. I realize it’s a large amount, but we would take any help we can get and will conduct as credible measurement as we can with the credits we assemble! Please note that my RIPE Atlas account is associated with mail alias misha(a)case.edu <mailto:misha@case.edu> (not the default email address I am sending from), so please use “misha(a)case.edu <mailto:misha@case.edu>” for credit transfer if you can help. > > Many thanks in advance! > Regards, > Michael Rabinovich > > >

4 4

Request RIPE Atlas Credit for Research
by 陆超逸 07 Mar '19

07 Mar '19

Dear all, Greetings! I'm a PhD student at Tsinghua University, China. Recently a large-scale measurement via RIPE Atlas is needed for my research. However, as a new user I don't have any credit to proceed, and unfortunately the time doesn't allow me to earn them by myself. So I'm here to ask for help. Is it possible for anyone generous enough to offer me some RIPE Atlas credits (like, a million)? My account at RIPE NCC is lcy17(a)mails.tsinghua.edu.cn. Many thanks for your help! Sincerely, Chaoyi Lu

26 27

Re: [atlas] ripe-atlas Digest, Vol 91, Issue 4
by Markus heptner 06 Mar '19

06 Mar '19

500.000 sent :) Markus

1 0

Graphing packet loss
by Steve Hill 01 Mar '19

01 Mar '19

I've got some ping measurements set up and am trying to find a good way to visualise outages. The Latencymon tool obviously shows red shaded sections on the graphs for an outage, but they vanish when zoomed out a long way. A graph of average packet loss seems the obvious way of doing it, but it doesn't look like there's any way to get this from the Atlas website, sort of downloading the data and building my own tool to analyse it. Am I missing something obvious? :) -- - Steve

1 0

New RIPE Atlas Version 4 Probes
by Mirjam Kuehne 26 Feb '19

26 Feb '19

Dear colleagues, In part as a response to recent questions regarding the distribution of RIPE Atlas probes, we have prepared an article detailing the work we have been doing to get supply back on track: https://labs.ripe.net/Members/alun_davies/new-ripe-atlas-version-4-probes We hope that this article, in which we introduce the new generation of RIPE Atlas probes, will answer at least some of the questions that have arisen lately. We’d like to thank you all once again for your patience! Kind regards, Mirjam Kühne RIPE NCC

1 0

Time difference between results and update of measurement status
by Vasileios Giotsas 25 Feb '19

25 Feb '19

I've seen that the status of a measurement is updated much later than when the measurement results become available. For instance, while the RTTs of a ping measurement are returned the status is still Ongoing for up to 3 minutes. Is there anything (such as sanity checks) that intervenes between the update of the results and and update of the measurement status, which may change the results? Or is it safe to assume that once the results are out the measurement status will eventually change to 'Stopped', just a bit later? Thanks! Vasileios

2 1

Issue with RIPE Atlas HTTP measurements
by Philip Homburg 19 Feb '19

19 Feb '19

We recently discovered an issue with RIPE Atlas HTTP measurements. In trying to fix an issue that caused the HTTP body size to be reported incorrectly, we inadvertently introduced a bug that prevents the measurement from working under certain conditions. This bug affects firmware release 4940 and the upcoming releases 4950 and 4960. The combination that fails is a recurring measurement after the first run with an HTTP server that returns the body as chunks. This means that one-off measurements are fine. Unfortunately, HTTP measurements that are part of anchoring measurements are affected. We will work to fix this issue in the first firmware release after 4960, which can be expected in the next couple of months. We apologise for the ongoing issue and will keep you informed as we work to resolve it. Philip

1 0

Re: [atlas] "Cannot resolve" tag on IPv6-only network?
by ripe＠brite.cz 14 Feb '19

14 Feb '19

https://atlas.ripe.net/about/faq/#i-have-an-ipv6-only-network-will-the-prob… says I have an IPv6-only network. Will the probe work on it? Yes. All probes can be configured statically with an IPv6 address, default router, DNS resolvers, etc. through the web UI. In addition, version 3 probes can be fully configured through router advertisements (support for RFC 6106 was added in firmware release 4680). There is at the moment no support for DHCPv6 (RFC 3315). Version 1 and 2 probes can obtain addresses and default routers through router advertisements, but cannot obtain DNS resolvers that way. For those probes, the DNS resolvers will have to be configured statically through the web UI. ______________________________________________________________ > Od: "Lorenzo Colitti" <lorenzo(a)google.com> > Komu: "Anand Buddhdev" <anandb(a)ripe.net> > Datum: 14.02.2019 12:47 > Předmět: Re: [atlas] "Cannot resolve" tag on IPv6-only network? > > CC: <ripe-atlas(a)ripe.net> >On Sat, Feb 9, 2019 at 7:47 PM Lorenzo Colitti <lorenzo(a)google.com> wrote: > >> IPv6-only networks are certainly supported, but if the probe isn't aware >>> of any DNS resolver, then it's not going to be able to do any of its own >>> DNS lookups, and that's why it's been tagged with the "cannot resolve" >>> tags. >>> >> >> Hmm. The network announces IPv6 DNS servers via RDNSS, and as far as I >> know, they work. Does the probe support RDNSS? >> > >I turned on IPv4 on that subnet and things started working again. That >makes me think that the probe doesn't support RDNSS. Can anyone confirm or >deny? Should I file a bug? > >

2 1

"Cannot resolve" tag on IPv6-only network?
by Lorenzo Colitti 14 Feb '19

14 Feb '19

My probe v1 is on an IPv6-only network with NAT64 and DNS64. In the web UI I see it's tagged with "cannot resolve A" and "cannot resolve AAAA". Are IPv6-only networks supported? Is this because the network doesn't have a DHCP server? Something else?

2 3

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