- ripe-atlas - mailman.ripe.net

New on RIPE Labs: RIPE Atlas Probes as IoT Devices
by Mirjam Kuehne 20 Oct '17

20 Oct '17

Dear colleagues, As a follow-up to the presentation Robert Kisteleki gave during the IoT Roundtable Meeting in September [1], we have published a RIPE Labs article describing RIPE Atlas probes as IoT devices and some initial design decisions that we thought were important for such an infrastructure: https://labs.ripe.net/Members/kistel/ripe-atlas-probes-as-iot-devices Kind regards, Mirjam Kuhne RIPE NCC [1] https://www.ripe.net/participate/meetings/roundtable/september-2017/ripe-io…

1 0

status is confusing
by Dave 18 Oct '17

18 Oct '17

Hi, The status page of one of my probes says: I’ve been bitten a few times by misinterpreting this. Could these 2 things be put on separate lines? This does suggest the probe is up but only when you missed the red colour and didn’t get the meaning of the icon. Also, when you read the mail it may be hours later than when it was sent. So keep in mind that a receiver’s probe could be back online in the meantime. Often a mail will be checked on the mobile. The status on a small screen must be clear too. I’ll restart the probe and modem and it will work again but I would have done that on day 1 if the message was more clear. Thanks, Dave

1 0

New on RIPE Labs: Insights from RIPE Atlas Probe Disconnections
by Mirjam Kuehne 17 Oct '17

17 Oct '17

Dear colleagues, There are all kinds of reasons why RIPE Atlas probes might become disconnected. So, even though we'd like all probes to be connected all the time, disconnects can also tell us a useful story. Please find this new article by Emile Aben on RIPE Labs exploring what insights we can gain from RIPE Atlas probe disconnections: https://labs.ripe.net/Members/emileaben/insights-from-ripe-atlas-probe-disc… Kind regards, Mirjam Kuhne RIPE NCC

1 0

What is the meaning of 127.0.0.1 as probe resolver?
by Baptiste Jonglez 16 Oct '17

16 Oct '17

Hi, While looking at the result of built-in DNS measurements that use the probe resolvers, I noticed that a significant fraction of probes have "127.0.0.1" as a resolver. And the results are strange: performance is really bad, for instance measurement 30002 gives a median resolution time of 300 ms for these probes! What could be the meaning of this? It almost looks like a recursive resolver with no cache at all is running on the probes themselves. I was looking at this measurement: https://atlas.ripe.net/measurements/30002/ And here are some example probes that exhibit this "127.0.0.1" symptom: 6001, 6087, 6162, 6235, 6308. Any reasonable explanation is welcome! Thanks, Baptiste

2 2

Problem in status checks?
by Stephane Bortzmeyer 14 Oct '17

14 Oct '17

Error 500 when trying to retrieve status checks: % curl -v 'https://atlas.ripe.net/api/v2/measurements/2060427/status-check?permitted_t…' ... > GET /api/v2/measurements/2060427/status-check?permitted_total_alerts=3 HTTP/1.1 > Host: atlas.ripe.net > User-Agent: curl/7.52.1 > Accept: */* > < HTTP/1.1 500 Internal Server Error < Server: nginx/1.10.2 < Date: Sat, 14 Oct 2017 07:09:10 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 38403 < Connection: keep-alive < Vary: Accept-Encoding, Cookie < X-Frame-Options: SAMEORIGIN < Strict-Transport-Security: max-age=15768000

2 1

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

Probe disconnects
by RIPE 09 Oct '17

09 Oct '17

Hi, I have a probe ( #22583 ) at home connected via my DSL link, for IPv6 connectivity I use a Hurricane Electric ( tunnelbroker.net ) /48 tunnel. I noticed on the monthly report that my probe is showing lots of short ( 1-2 min) disconnects. But it only seems to happen when the connection address in the probe’s network tab is the IPv6 address. In that case the IPv4 Connection address is empty. If it’s showing the IPv4 the probe stays connected for days ( until the DSL link really disconnects). Is there a way to get the probe to ignore the IPv6 for connection status ? Or to mark it as disconnected when both iPv4 and IPv6 are disconnected ? Best regards, Paul van der Zwan

3 2

Charity IT Pulse :) one more sleep till Bytenight Action for Children 2017
by Colin Johnston 05 Oct '17

05 Oct '17

> > Dear all, one more sleep until ByteNight events across the UK on Friday night. > Please donate if you can electronically > > > See mydonate page linked to Byte Night https://mydonate.bt.com/fundraisers/colinjohnston1 <https://mydonate.bt.com/fundraisers/colinjohnston1> > > For more information go to www.bytenight.org.uk <http://www.bytenight.org.uk/> or to donate Text Byte17 and the amount to 70070. > > In just 1 days time, on Friday 6 October, I am spending one night sleeping rough for Byte Night. Byte Night works to support some of the 83,000 young people who are homeless in the UK. One in four young people who are homeless have been diagnosed with mental health issues and one in five will have self-harmed due to their situation at home. £10 could provide an hour’s support with a mental health practitioner for 1 young people to help them get through their issues. Action for Children has supported many young people to a safe and happy future. Unfortunately, so many more still need our help. You can help support young people across the UK by generously donating to my page > > > > Yours > > Colin Johnston > > Colin Johnston <https://myprofile.bt.com/Person.aspx?accountname=IUSER%5C600969844> > IT Support Senior Professional, Core IT Infrastructure > BT Technology Service & Operations <https://intra.bt.com/bt/tso/Pages/index.aspx> | Tel: 01313001324 <tel:01313001324> | MyProfile <https://myprofile.bt.com/Person.aspx?accountname=IUSER%5C600969844> | colin.johnstone(a)bt.com <mailto:colin.johnstone@bt.com> | http://fixit.bt.com/ <http://fixit.bt.com/> > > BT Group plc Registered office: 81 Newgate Street London EC1A 7AJ. Registered in England and Wales no. 4190816 This electronic message contains information from BT Group plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please delete it and notify me immediately by telephone or email.

1 0

ipv6 ping to root name servers failing?
by Tapio Sokura 04 Oct '17

04 Oct '17

Hello, I noticed a few days ago from the built-in probe graphs that ipv6 pings started to fail to the a-root name server instance serving the probe I host. Now also the j-root serving the probe is dropping pings. Some other instances of the same root servers at the moment are still answering pings. If it is intentional that root name servers are starting to drop pings, something should probably be done to the built-in probe measurements/graphs. Does someone know more about this, will all roots be dropping pings in the future or is this just a Verisign thing (a and j operator)? Tapio

2 1

List of Atlas probes subjected to DNS traffic interception (MITM)
by Baptiste Jonglez 29 Sep '17

29 Sep '17

Hi, I am looking for a list of Atlas probes that suffer from DNS traffic interception, to exclude them from my measurements. What I mean by "traffic interception" is that DNS queries from the probe to a third-party DNS server do not reach the server, but are intercepted and answered by a middle-box instead. I started building this list myself, but it's a long and potentially error-prone process. It seems that the "DNS Root Instances" map could be used for that purpose, because DNS traffic interception shows up as if the probe was contacting an "Unknown" root instance. To get the list of probes, I ended up using an URL like the following, showing probes for all possible "unknown" root instance hostnames: https://atlas.ripe.net/results/maps/root-instances/?server=1&question=10300… ... However, there seems to be a limit on the size of the URL so I cannot get all probes, and they are just displayed on the map without any obvious way to get the raw list of probes instead. Is there a way to get the raw list of probes from this map? Or has anybody already done this classification work independently? I also looked for DNS-related tags on probes, but could not find anything useful. Thanks, Baptiste

4 6

New on RIPE Labs: Celebrating 10, 000 Active RIPE Atlas Probes
by Mirjam Kuehne 29 Sep '17

29 Sep '17

Dear colleagues, In August 2017, just short of seven years after RIPE Atlas was launched, the number of connected RIPE Atlas probes hit 10,000. Thank you all for making this happen! Find some more details and an overview of recent developments on RIPE Labs: https://labs.ripe.net/Members/alun_davies/celebrating-10000-active-ripe-atl… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New RIPE Labs article on RIPE Atlas v3 Anchors
by Alun Davies 29 Sep '17

29 Sep '17

Dear colleagues, In this RIPE Labs article the RIPE NCC looks into hardware specifications and logistics for the next generation of RIPE Atlas anchors: https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors Best regards, Alun Davies RIPE NCC

3 3

New on RIPE Labs: Measuring your Web Server Reachability with TCP Ping
by Mirjam Kuehne 27 Sep '17

27 Sep '17

Dear colleagues, HTTP measurements from RIPE Atlas probes are only possible towards RIPE Atlas anchors. However, when it comes to measuring the connectivity and latency of web servers on the network level, an alternative exists, which we call TCP Ping: a traceroute with special options that mimic the TCP handshake that takes place when an HTTP connection is established. In this RIPE Labs article we compare the results of large scale HTTP and TCP Ping measurements: https://labs.ripe.net/Members/wilhelm/measuring-your-web-server-reachabilit… Kind regards, Mirjam Kuhne RIPE NCC

1 0

New on RIPE Labs: PoE-ing a RIPE Atlas Probe
by Mirjam Kuehne 18 Sep '17

18 Sep '17

Dear colleagues, In this new RIPE Labs article Geert Jan de Groot explains how to "PoE" a RIPE Atlas Probe: https://labs.ripe.net/Members/geert_jan_de_groot/poe-ing-the-ripe-atlas-pro… Kind regards, Mirjam Kuhne RIPE NCC

1 0

RIPE Atlas v3 Anchor Hardware
by Alun Davies 12 Sep '17

12 Sep '17

Dear all, The RIPE NCC has chosen a new model for the RIPE Atlas v3 Anchors. The hardware we finally opted for is the PC Engines APU2. As well as being cheaper than the previous generation of anchors, this model meets the majority of requirements we laid out for the next generation of anchors. To be clear, given that there are still a couple of minor logistical details to resolve, we are still keeping applications on hold for the time being. That said, we look set to meet our September deadline to resume shipping of RIPE Atlas anchors. For more information and future updates, please read our article on RIPE Labs: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas… <https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas…> Kind regards, Alun Davies Comms RIPE NCC

4 3

Can Atlas probe handle Truncated response ?
by Davey Song(宋林健) 12 Sep '17

12 Sep '17

Hi folks, I once setup a measurement of DNS UDP to see if the number of timeout increase due to large response. The answer is yes. But I wonder if the timeout is no answer after three times of retries or also includes TCP fallback. Is it true that the probe in DNS UDP measurement will not use TCP to retry even after it receives a truncated response. Best regards, Davey

3 2

IPv6 issues with ATLAS and DNSMON
by Romeo Zwart 12 Sep '17

12 Sep '17

dear all, Due to a human error on our side, there have been problems with IPv6 connectivity to/from many of our servers, including atlas anchors since approximately 9:30 UTC this morning. The problem has been corrected and systems are recovering, but you may still see some problems in RIPE Atlas and DNSMON. We're still investigating the full impact of the problem and will have more information at a later stage. We apologise for any inconvenience. Romeo Zwart

1 1

Infrastructure upgrades
by Robert Kisteleki 06 Sep '17

06 Sep '17

Dear all, Yesterday we began infrastructure (OS) upgrades on our controllers. As a consequence each probe will be disconnected for an hour or two. This can trigger notifications, if you have that configured to a sensitive enough setting. Regards, Robert Kisteleki RIPE NCC

3 4

Is there a problem with ctr-ams07 right now?
by Max Mühlbronner 06 Sep '17

06 Sep '17

Hi, my probe is online (ping) and it shows SOS messages (reboots - This probe probably last rebooted on 2017-07-06 12:23:08) on the probe page. Disconnected since 59 minutes. Is this a general problem, e.g. of the controller or is it just my probe? Does someone see similar problems right now? BR Max M.

3 3

[Training] Launching RIPE NCC::Educa - Online Learning Event
by Sandra Bras 04 Sep '17

04 Sep '17

Dear colleagues, The RIPE NCC has a new way to dive deep into a topic without having to travel or leave your desk. RIPE NCC::Educa are free, online learning events that bring industry experts together to share insight, expertise and best practice with those that want more in-depth knowledge on a particular subject. Our first event focuses on RIPE Atlas on Thursday, 5 October from 8:00 - 13:00 UTC. Reserve your place here: https://www.ripe.net/support/training/ripe-ncc-educa <https://www.ripe.net/support/training/ripe-ncc-educa> You can join us for one session, multiple sessions or the full programme. We’re updating the agenda constantly, so be sure to check here for the latest additions: https://www.ripe.net/support/training/ripe-ncc-educa/agenda <https://www.ripe.net/support/training/ripe-ncc-educa/agenda> For more information on RIPE NCC::Educa, check out our RIPE Labs article: https://labs.ripe.net/Members/sandra_bras/introducing-ripe-ncc-educa <https://labs.ripe.net/Members/sandra_bras/introducing-ripe-ncc-educa> If you have any questions, please get in touch with us: <e-learning(a)ripe.net <mailto:e-learning@ripe.net>> Warm regards, Sandra Brás E-Learning Program Manager RIPE NCC

1 0

Sharing Credits seems broken .....
by Barry Raveendran Greene 24 Aug '17

24 Aug '17

Hi Team, We have a problem with the sharing credits. I’ve got plenty of credits on my account. I’ve granted access to my colleague (Jim Gilbert) and a test group account (atlas-network(a)akamai.com). Just to be clear, it states: Sharing Access - If you don’t want to set limits on the number of credits you share, you can also allow other RIPE Atlas users to use your credits directly for their own measurements. Select the “Share Access” tab on your credits page and enter the RIPE Atlas users you want to give access to. Users who have been given access to others’ credits will be able to choose whose account to charge when they create a new measurement from a drop-down menu. This option can also be set via the measurement API. A running measurement can be stopped by both you and the person with access to your credits. If you decide to stop giving someone else access to your credits, any measurements they have running will start using their own credits instead. This means I should be able to log into atlas-network(a)akamai.com select “bgreene(a)senki.xn--org-9o0a and create/run test. Correct???? This is what I get: What are we missing? Barry

2 2

DNS results visualisation
by Dave . 22 Aug '17

22 Aug '17

Hi, For the traceroute results there is a icon at the right side where you can get the complete traceroute. (View Latest Result) This is beautifully presented. Could we please have a similar icon for DNS results? Thanks, Dave Boonstra

2 2

measurement UI on 12hour clock?
by Rene Wilhelm 22 Aug '17

22 Aug '17

See attached screenshot. I created a couple of measurements which were to start at 16:05 local time, 14:05 UTC. The measurement page https://atlas.ripe.net/measurements however states a start time of 22-08-2017 02:05 UTC which is of course 12 hours in the past and had me worried for a bit I made a mistake filling in the form. Can this be fixed? it is confusing and looks a bit clumsy :) -- Rene

2 1

[rfc-editor@rfc-editor.org: RFC 8193 on Information Model for Large-Scale Measurement Platforms (LMAPs)]
by Stephane Bortzmeyer 22 Aug '17

22 Aug '17

This recent RFC on the data model for Internet measurements platform is of course of interest for RIPE Atlas. Note that their model separates controller and collector, which are one in Atlas.

1 0

New on RIPE Labs: Processing RIPE Atlas Results with jq
by Mirjam Kuehne 21 Aug '17

21 Aug '17

Dear colleagues, Please find this new article by Stephane Bortzmeyer on RIPE Labs: Processing RIPE Atlas Results with jq https://labs.ripe.net/Members/stephane_bortzmeyer/processing-ripe-atlas-res… Kind regards, Mirjam Kuhne RIPE NCC

1 0

Notify time setting does not work
by Marat Khalili 18 Aug '17

18 Aug '17

Probes have very handy feature of sending a notification when the probe is disconnected. I have mine set to 10 minutes, however last two such notifications only arrived 30 minutes after the probe was disconnected. Probe #26656 if that's important. One would think that probe itself was slow to react, but last time I monitored outage from the very beginning and the probe's page correctly showed "Disconnected for: 1 minute" and so on. Neither it is a case of slow email arrival, since according to Received header in the email it was indeed received from worker1.atlas.ripe.net 30+ minutes after disconnection time mentioned in the email body. Can it be that "Notify time" setting just doesn't work and some default value of 30 minutes is used? -- With Best Regards, Marat Khalili

4 7

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

Updated RIPE Atlas measurements listing page
by Massimo Candela 09 Aug '17

09 Aug '17

Dear RIPE Atlas users, With the increasing number of measurements supported by RIPE Atlas, the measurement listing page [1] was slowing down. Today we deployed a new release with improved performance and functionality. The new page contains a re-arrangement of the tabs, allowing the user to more easily access the types of measurement they are interested in. The searching has also been improved, allowing more precise filtering of the measurements. If you experience any issues, try to refresh the cache for the page. And of course, let us know if you have any feedback about this change. Best regards, Massimo Candela Software Engineer - RIPE Atlas project [1] https://atlas.ripe.net/measurements/ <https://atlas.ripe.net/measurements/>

1 0

Test, please ignore
by Robert Kisteleki 08 Aug '17

08 Aug '17

1 0

Update to RIPE Atlas Anchors Article
by Michela Galante 08 Aug '17

08 Aug '17

Dear colleagues, We just published an update to the RIPE Labs article “The Next Generation of RIPE Atlas Anchors”. You can read it here: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas… Best regards, Michela Galante RIPE NCC

2 3

Join RIPE NCC Hackathon Version 6, 4-5. November, Copenhagen, Denmark
by Vesna Manojlovic 08 Aug '17

08 Aug '17

Dear colleagues, The sixth RIPE NCC hackathon will take place on Saturday and Sunday, 4-5 November 2017 in Copenhagen, Denmark. The topic is: IPv6! We're looking for creative thinkers: front-end developers, UI designers, network operators, researchers, hackers and other enthusiastic coders, to help us develop new tools that would enable deployment of IPv6 and visualizations based on IPv6 measurements data. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/version6/#!application-form *The application deadline is 9.9.* (9th September) We look forward to seeing you there! Find out more in this RIPE Labs article: https://labs.ripe.net/Members/becha/join-the-ripe-ncc-hackathon-version-6 Regards, Vesna Manojlovic Community Builder RIPE NCC

1 0

SOS History empty since 2017-07-20
by Christian Schrötter 01 Aug '17

01 Aug '17

Hi, the last entry in my SOS History is from 2017-07-19, see screenshot [1]. My probe is still connected and working, but there should be two items per day at minimum, for each reconnect of my DSL connection after 24 hours. Looks like something is broken at the Atlas system. Could someone confirm this bug? -- Regards, Christian [1]: https://happytec.at/r/Xfaab

2 2

Probe recovery does not work
by Gil Bahat 27 Jul '17

27 Jul '17

Hi, I've finally managed to get a few USB drives to recover at least a few of my probes (I've spread about 3 dozen and only 2 are still online). But the stated recovery procedure does not work for me, with brand new 8GB keys. Is there any good way to see what's really going on with the recovery? the probes register themselves with the right addresses so I know connectivity and DHCP is ok, and yet they never recover. can the dhcp firmware be modified to try more aggressive recovery or better reporting of its state? Regards, Gil

1 0

Wifi measurements?
by Hank Nussbacher 24 Jul '17

24 Jul '17

When I start a new measurement, in addition to the standard measurements like ping and traceroute, I see a "wifi" measurement that appears for about 2 seconds at the end of the list and then auto-disappears. See attached screenshot. Explanations? Thanks, Hank

2 1

New on RIPE Labs: The Next Generation of RIPE Atlas Anchors
by Alun Davies 21 Jul '17

21 Jul '17

Dear Colleagues, The RIPE NCC is in the process of testing hardware for the next generation of RIPE Atlas anchors. Here’s a detailed overview of the process: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas… Best regards, Alun Davies RIPE NCC

5 4

NSID option on the RIPE Atlas SOA measurements of the root servers
by Chris Amin 20 Jul '17

20 Jul '17

Dear colleagues, RIPE Atlas is currently running a series of DNS SOA built-in measurements* towards all of the root servers from all probes. During the recent DNS measurements hackathon** it became apparent that for some use cases it would be useful to have SOA queries from all probes with the NSID EDNS option set, in order to be able to match up responses with the particular responding instances in an anycasted (or load balanced) setup. We would like to ask for feedback on two alternative options for implementing this change. They are: 1) Enable the NSID option for the existing built-in measurements towards the nine root servers which support it. 2) Start a new set of built-in measurements towards the nine root servers which support NSID. The advantages of option (1) are that it will be possible to compare and contrast the two sets of results, and that historical data for the existing built-ins will remain consistent with the current results. A very simple analysis shows that there is no overall increase in query error rates through enabling NSID, but there are bound to be individual marginal cases where queries fail or produce different results with NSID set but succeed without it. The advantages of option (2) are that there will be no increase in result storage usage -- the current IPv4+IPv6 UDP SOA built-ins towards the nine supporting root servers adds up to about 80 results per second (~1.5% of the total results in the system). This could potentially be mitigated by reducing the frequency for these new measurements, but perhaps more important than the slightly increased load is the potential user confusion caused by generating and providing two very similar sets of measurements. Please let us know if you have any preference for which way we go on this, particularly if you have a (current or future) use case for this kind of data. Kind regards, Chris Amin RIPE NCC * https://atlas.ripe.net/docs/built-in/ ** https://labs.ripe.net/Members/becha/results-dns-measurements-hackathon

1 0

Update on the anchoring measurements change
by Johan ter Beest 20 Jul '17

20 Jul '17

Dear all, As described in the labs article here: https://labs.ripe.net/Members/alun_davies/balancing-act we have split the anchoring measurements. We are currently in the process of adding more probes to the new 'probe' anchoring measurements. We expect this to be completed by the end of this week. Please let us know if you notice anything out of the ordinary. Kind regards, Johan ter Beest RIPE Atlas Team

1 0

Link aggregation for anchors?
by Tore Anderson 20 Jul '17

20 Jul '17

Hi, I was wondering if it is possible to connect our anchor in a fault tolerant fashion using 802.3ad link aggregation? This would allow us to perform serialised maintenance on the upstream switches without ever offlining the anchor. Tore

4 6

Trace and Ping measurements fail on Probe 15861
by ripe＠brite.cz 18 Jul '17

18 Jul '17

Hi team, recently I'm not able to run measurements on probe 15861 I am hosting at home. When I create a measurement with only this probe, it ends up in Failed status [measurements 9193416 9193417 9199824 for example]. When there is multiple probes in the measurement, probe 15861 ends up showing "No recent report available" [9193406 9192883]. Otherwise the probe has been online and does not show any anomalies. Any idea? Thank you Jiri

1 0

New RIPE Atlas Measurement Options
by Alun Davies 17 Jul '17

17 Jul '17

Dear all, The RIPE Atlas team have added a number of new measurement options on RIPE Atlas. Here’s an overview of the changes: DNS measurements timeout: allows the user to specify a custom timeout in milliseconds after which probes will stop waiting for a response from the DNS server use_macros: allows the use of special macro strings in the "query_argument" field, to create unique or easily distinguishable queries. The allowed macros are: $p the (integer) ID of the probe carrying out the measurement $r a random 16-digit hexadecimal string $t a Unix timestamp of the time that the probe carries out the DNS query SSLcert measurements hostname: specifies a hostname to send as a Server Name Indication (SNI), which is necessary for web servers which host multiple TLS domains on the same IP address. Ping measurements include_probe_id: include the probe ID as an ASCII string within the payload of ping measurements. Note: this is included in addition to other payload data. The changes are all included in the RIPE Atlas API reference: https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Measurement_Li… <https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Measurement_Li…> If you have any questions whatsoever about the new measurement options, do let us know. As always, we welcome suggestions for new features from RIPE Atlas users. Best regards, Alun Davies RIPE NCC Communications Department

1 0

Caching issues on the latest call
by Johan ter Beest 13 Jul '17

13 Jul '17

Dear all, Today we became aware of some caching issues on the latest API call (https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Latest_GET). In certain corner cases it was possible that an incomplete set of results for a logged-in user was cached for up to 24 hours. This did not apply to non logged-in users as the results are not cached in that case. A fix for this issue has been deployed and going forward the latest call will have a 1 minute cache regardless of whether the user is logged in or not. As caching is always tricky, we kindly ask that users will let us know if they experience anything out of the ordinary that might be related to this change. Kind regards, Johan ter Beest RIPE Atlas Team

1 0

half dead v1 probe ?
by Matthieu Herrb 13 Jul '17

13 Jul '17

Hi, Here at Tetaneutral.net we're hosting a V1 Atlas probe since 2012 or so. A few weeks ago it started beeing marked as unconnected on the ripe atlas page : https://atlas.ripe.net/probes/523/ Since it's a v1 probe, I can only power cycle it to try to reconnect it, which I've done a number of times now, without success. It's still answering to ping requests, both on its v4 and v6 addresses and I can see some traceroute-like trafic going out of it. It's marked as "firewall problems suspected", but we don't do any firewalling on it. On IPv4 it's on a 1:1 NAT, all ports are open and forwarded in both directions, and on V6 it's routed without any filtering. Also we haven't changed anything on our infrastructure around the time it became disconnected. I'm starting to suspect a firmware upgrade problem as the one mentionned by Alun Davis in https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-June/003329.html Any suggestion before I send it back and ask for a new one ? Thanks in advance, -- Matthieu Herrb

3 2

Probe does not request IPv4 address via DHCP
by Stanish Stanishev 11 Jul '17

11 Jul '17

Hello, My probe(ID 16372) has disconnected from the Atlas network and in the Status I see USB flash corrupted. I did the troubleshooting - power off the probe, remove the USB, power on the probe, waited 10 mins, plugged brand new 4G USB. Several times with no success, So I decided to do a traffic capture of the uplink port where the probe is connected to. According to the capture the probe does not send DHCP requests. It sends only IPv6 traffic - Multicast Listener reports and Neighbor solicitation. Hence not getting IP address. I did several restarts - no change. Anybody has seen this issue before ? Any hints how to deal with such issue ? Thanks Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum

3 9

New on RIPE Labs: Anchoring Measurements - Bringing Back the Balance
by Mirjam Kuehne 06 Jul '17

06 Jul '17

Dear colleagues, Please read on RIPE Labs how we're striking a balance between probes and anchors in RIPE Atlas anchoring measurements: https://labs.ripe.net/Members/alun_davies/balancing-act Kind regards, Mirjam Kühne RIPE NCC

1 0

[ripe-atlas-tools] Anyone had success with renderer aggregate_ping?
by Stephane Bortzmeyer 05 Jul '17

05 Jul '17

I cannot make the renderer aggregate_ping work: https://github.com/RIPE-NCC/ripe-atlas-tools/issues/186

1 0

New on RIPE Labs: Next Five Sponsored RIPE Atlas Anchors
by Mirjam Kuehne 04 Jul '17

04 Jul '17

Dear colleagues, The second phase of the RIPE NCC’s campaign to sponsor 15 RIPE Atlas anchors has been completed, with another five anchor hosts selected for sponsorship. We want to tell you about the new anchor hosts and also take a look at some related developments here at the RIPE NCC: https://labs.ripe.net/Members/alun_davies/next-five-sponsored-ripe-atlas-an… Kind regards, Mirjam Kühne RIPE NCC

1 0

Monthly probe report says it was down for the entire month
by James Andrewartha 03 Jul '17

03 Jul '17

Hi, I got my monthly probe report and oddly it says my probe was down for the entire month, rather than the 14d 6h 55m (47.63%) the website says. I've only just been able to reboot the probe (it didn't respond to ping at all), and it has come up with a new IP, but hasn't connected to the controller. Some things have updated with the new IP, eg p29530.probes.atlas.ripe.net but others like the local address are still showing the old IP. Should I try doing the recovery procedure? Thanks, James -------- Forwarded Message -------- Subject: Monthly probe report for CCGS Perth (#29530) Date: Sat, 1 Jul 2017 01:50:21 +0000 From: RIPE Atlas <no-reply(a)ripe.net> Reply-To: RIPE Atlas <no-reply(a)ripe.net> To: linuxadmin(a)ccgs.wa.edu.au Dear James Andrewartha, This is your monthly availability report for probe 29530 (CCGS Perth). Calculation interval : 2017-06-01 00:00:00 - 2017-07-01 00:00:00 Total Connected Time : 0d 00:00 Total Disconnected Time : 30d 00:00 Total Availability : 0.00% This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to receive reports about probe availability. If you would like to change this, or disable this reporting altogether, please go to https://atlas.ripe.net/probes/29530/, click the "Edit" button next to "Notifications", and use the form there to define what you want. Kind regards, RIPE Atlas Team

2 1

Re: [atlas] VM probes (was Re: Feature request for IP record route feature in RIPE Atlas)
by mostafa shahdadi 21 Jun '17

21 Jun '17

Sent from my iPad

1 0

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