- 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