- ripe-atlas - mailman.ripe.net

atlas feature suggestion
by Geert Jan de Groot 20 Jun '17

20 Jun '17

Hi, On the portal: > Notifications > Notify me at my registration address if this probe is down for more than 600 minutes. This doesn't seem to take into account that a probe may be dual-stacked (v4 and v6) and just one of these protocols may fail w/o the other one failing as well (this is a problem with my CPE, but I'm not touching that box until the temperature in the lab has dropped to sensible values) In any case, if v6 dies but v4 still works, the probe doesn't complain. Perhaps this should be flagged separately? How are we doing on testing silent v6-failures in general? Happy eyeballs make a lot of breakage invisible.. Geert Jan

1 0

Improvements to the RIPE Atlas measurement creation form
by Chris Amin 15 Jun '17

15 Jun '17

Dear all, We’ve made some changes to the interface for creating measurements on the RIPE Atlas website (https://atlas.ripe.net/measurements/form/) that will make it both faster and more responsive. Users should also see similar improvements in the user interface for monitoring and configuring domains with DomainMON (https://atlas.ripe.net/domainmon/). The changes were made possible by switching to the public measurement API (https://atlas.ripe.net/docs/api/v2/manual/). Concurrently with this, we also improved the error reporting in the API to make it easier to find out the cause of errors. This API change is backwards compatible and is documented in the API manual (https://atlas.ripe.net/docs/api/v2/manual/overview/error_messages.html). Whilst we do not expect the transition to cause any issues, we kindly ask that users let us know if they experience anything out of the ordinary that might be related to the change. Best regards, Chris Amin RIPE NCC

1 0

Firmware Update for RIPE Atlas V1 and V2 Probes
by Alun Davies 09 Jun '17

09 Jun '17

Dear all, We’re currently in the process of deploying a new firmware update for RIPE Atlas V1 and V2 probes. The update provides a fix for a bug that caused around 15% of RIPE Atlas V1 probes to disconnect. As of the time of writing, the update is at approximately 60% deployment. If you’ve been unable to reconnect your RIPE Atlas V1 probe, you can return it to the following address to be fixed. If you’d like the probe to be returned to you afterwards, please let us know. Alternatively, we’d encourage you to apply for a V3 probe. RIPE NCC P.O. Box 10096 1001EB Amsterdam The Netherlands We’d like to take this opportunity to thank all probe hosts for your ongoing efforts in supporting RIPE Atlas. Cheers, Alun Davies RIPE NCC

1 0

Anchors as target hosts for SLA
by Antonio Prado 06 Jun '17

06 Jun '17

hi, do you think could be a good idea to use Ripe Atlas Anchors as target hosts for measuring respect of SLA terms of an Internet transit? SLA example This Internet transit should meet the following criteria: average round trip delay (echo request, echo reply) toward $NEAREST_ATLAS_ANCHOR should be less than 100ms on a 10k packets stream of pings; packet loss equal or less than 0.02% pros, cons, recommendations? thank you -- antonio

3 3

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