May 2017 - ripe-atlas - mailman.ripe.net

Error: Only anchors may be targeted.
by Mozafary Mohammad 28 Jun '18

28 Jun '18

Hello I've got "Only anchors may be targeted." on HTTP measurement creation.Any body can advise what the problem is? Thanks

8 9

Plan to Implement RIPE Atlas WiFi Measurements
by Robert Kisteleki 09 Oct '17

09 Oct '17

Dear colleagues, We wanted to update the community and let you know that we plan to start work on the proposed experiment with WiFi measurements in mid-2016. As we communicated in a recent RIPE Labs article, we will work with GÉANT as a test partner to learn more about the operational effects of introducing WiFi measurements to the RIPE Atlas system, in addition to the benefits we believe this could provide for the entire RIPE Atlas community. Please see the article for more details if you are interested: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measure… We will continue to update you once we’ve begun work on this plan, and we welcome your comments in the meantime. Regards, Robert Kisteleki RIPE NCC

3 3

Your probe is currently disconnected
by Conrad Kostecki 15 Aug '17

15 Aug '17

Hi! I've applied for an Atlas probe v3 and got one via postage. So, I've connected the probe to my network. I can see in my DNSMasq logs, that the probe gets successfully an IP address. It can be pinged without any problems. But that's all. Even after 24 hours it's still reported not connected. I can see multiple LEDs: 1 (power): on 2: off 3: slow blink 4: fast blink 5 (button): on I can't find that in the FAQ, the LEDs should light different. The FAQ also did mention to try first without USB and insert USB later. Or try to replace the USB. Both cases did not help. If I connect my ThinkPad instead the probe with the same network connection (cable and port), it can access the internet just fine without any problems.. I've no clou, what could be wrong. Any ideas? Thanks! Conrad Viele Grüße Conrad Kostecki

7 9

Surplus RIPE Atlas credit offer
by Dan Jones 31 May '17

31 May '17

I have a large pool of unused credits if anyone needs any transferred to their account. I likely won't be using them so they should go to a good cause. Dan Jones

1 0

Three improvement suggestions
by Michael Oghia 31 May '17

31 May '17

Dear all, I have three suggestions for how to improve the Atlas program: 1. Set up an automatic transfer system? That way, if someone accrues credits they would like to transfer, we can set it up to do so automatically once we hit 1,000,000 credits (think of it as similar to a bank's auto-pay system). 2. A system where, if someone needs extra credits, they can automatically request them to be deducted (with those who opt-in) from someone like myself with unused / extra credits. 3. Email notifications of when we have accrued 1,000,000 credits (my apologies if this is already a feature). I say this because I don't use my credits, so I don't want them to go to waste. It would be much more efficient if someone who needed them could access them any time (assuming I already gave permission for that (opted-in)). Let me know if anyone needs clarification about my suggestions. Best, -Michael __________________ Michael J. Oghia EuroDIG 2017 focal point (WS 11 <http://eurodigwiki.org/wiki/WS_11_2017>) Independent #netgov consultant & editor Belgrade, Serbia Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia>

7 9

TLS tests with login.live.com
by Stephane Bortzmeyer 29 May '17

29 May '17

TLS tests from the Atlas probes work for me, for every server... *but* login.live.com, for which I always get timeouts (it works with other TLS clients). Measurement #8775150 if someone has an idea...

2 4

Need host with very large ping times
by Marat Khalili 29 May '17

29 May '17

I have an interesting problem: I need some host that doesn't mind being pinged but with several seconds of RTT (that's thousands milliseconds; from Moscow, but it probably doesn't matter). Amazingly, I could not easily find one. I even tried to ping-scan IP ranges of Antarctica, but those hosts that responded did so in fraction of a second. Not much luck with North Korea (mostly down), Taiwan (internet is much better than it used to be) and several other suspect countries. (Though I'm not sure my tests are correct, since firewall processing of such long response times is one of the things I'm trying to find out.) Is it possible to somehow find one using RIPE ATLAS, preferably without ping-scanning whole internet? Would be especially great if it responded to other types of ping beside ICMP. -- With Best Regards, Marat Khalili

6 9

challenges with reproducibility
by Bajpai, Vaibhav 28 May '17

28 May '17

Dear RIPE Atlas / MAT WG -- sorry for cross-posting. A few of us wrote a paper discussing challenges with ‘reproducibility’ of research and certain steps we can take to initiate a cultural change. This paper will appear at the SIGCOMM reproducibility workshop [b]; the paper is now available online [a]. Thought to share it along: [a] http://vaibhavbajpai.com/documents/papers/proceedings/reproducibility-sigco… [b] http://conferences.sigcomm.org/sigcomm/2017/workshop-reproducibility.html -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany --------------------------

1 0

DNS and recursion
by Stephane Bortzmeyer 27 May '17

27 May '17

API v1 had a field recursion_desired when performing DNS measurements. If I remember correctly (but I cannot find the reference right now), it worked only when querying a specific name server, and not when using the probe's own resolver, to avoid cache snooping. API v2 has instead a set_rd_bit. Documentation <https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Measurement_Li…> does not indicate its default value. Anyway, my experience with the API is that the RD (Recursion Desired) bit is always set, whether with 'set_rd_bit': False or with 'set_rd_bit': True, and independant of use_probe_resolver. I can understand this choice for privacy reasons (RFC 7626, section 2.3). But, in that case, the documentation should be fixed. Anything I missed? (Here, a request by a probe, the + after the Query ID - here, 52379 - means the RD bit is set 12:22:23.170304 IP (tos 0x0, ttl 64, id 2287, offset 0, flags [DF], proto UDP (17), length 65) 192.168.2.8.45955 > 212.27.40.240.53: [udp sum ok] 52379+ AAAA? uucp.bortzmeyer.org. (37)

2 2

DNS measurement
by Stanish Stanishev 25 May '17

25 May '17

Hello, I am having troubles running a a DNS measurement against our DNS cache servers. I get Error: Timeout: 5000 every time I run such measurement. Please see measurement ID #8771668 for example. In this measurement I've selected the two anchors (ids 6262 and 6263) hosted by us (Vivacom) as the source and the target is one of our DNS cache servers - 212.39.90.42. There is no firewalls or other preventing our anchors from reaching the 212.39.90.42 and also the DNS cache server running on 212.39.90.42 is configured to serve queries from Anchors' IPs. What am I doing wrong ? Thanks, Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 2

RIPE Atlas V1 Probe Issue
by Alun Davies 18 May '17

18 May '17

Hello all, Due to an unfortunate bug in a recently released probe firmware (version 4760), a number of RIPE Atlas V1 probes are not currently able to connect to the network. The bug leads to excessive memory fragmentation which impacts that V1 probes because they have no MMU and only 8 MByte worth of memory. For reasons that are not yet clear, the issue has only affected well below half of the V1 probes. We are working on a new firmware that will correct this issue, but probes that will not connect will need to be returned to the RIPE NCC in order for the fix to be carried out. Once the new firmware is ready, users can either return their V1 probes to us to be fixed, or request a V3 probe instead. Thank you to Wilfred Woeber for reporting this and requesting an update on the current issue with the V1 probes. Cheers, Alun Davies RIPE NCC

4 4

Introducing blitzortung.org Network for Lightning and Thunderstorms in Real Time
by Jean-Michel Pouré 13 May '17

13 May '17

Dear Friends from RIPE community, This is my first post on the forum. I would like to point out to the community the existence of a free community providing a network device for Lightning and Thunderstorms in Real Time: http://blitzortung.org The device works the same as a RIPE probe, except that it collects information about lightning via radio and delivers the information to a central network of computers for data processing. If you are network specialist hosting very expensive network devices, it might be interesting for you to participate in the effort to build a free community and host a Blitzordnung device in your premisses. All information can be found on http://blitzortung.org and BlitzOrdnung forum : http://en.blitzortung.org/forum.php BlitzOrdnung coverage is good in Europe and North America, but BlitzOrdnung needs more devices in Africa/South America/China and Russia. All help is welcome and may save you a lot of money in lightning protection. Kind regards, Kellogs

1 0

Results of the DNS Measurements hackathon - article now published on RIPE Labs
by Vesna Manojlovic 11 May '17

11 May '17

Dear all, in April we held a fifth hackathon. Altho the topic was DNS, most of the projects were using RIPE Atlas data. Therefore, I invite you to check out the hackathon results, follow the links to the code, and enjoy the photos that attempt to transfer some of the atmosphere.. https://labs.ripe.net/Members/becha/results-dns-measurements-hackathon Please do take part: - use the tools/SW and let us know your experiences with it - modify the code & publish it again on GitHub - join our next hackathon - as a host, sponsor, or participant (date & location & topic to be announced soon!) Let me know in person if you are interested; and otherwise, post your comments or questions on the list, greetings from RIPE74, Vesna

1 0

Many timeout-failures for DNS over TCP
by Davey Song(宋林健) 11 May '17

11 May '17

Hi folks, I setup measurements for DNS queries over both TCP and UDP. I found the timeout and failures of TCP is far more than UDP. For example : DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes DNS over UDP: https://atlas.ripe.net/measurements/8552846/#!probes Is it normal ? I mean is there any special timeout routine/parameters of atlas probes from normal resolver? Best regards, Davey

4 4

TraceMON follow up
by Massimo Candela 10 May '17

10 May '17

As a follow up to my talk at RIPE74 about TraceMON, here a link with some live examples: https://massimo.ripe.net/tracemon/widget/ <https://massimo.ripe.net/tracemon/widget/> Ciao, Massimo

1 0