March 2016 - ripe-atlas - mailman.ripe.net

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

RIPE Atlas Interface Hackathon, 21-22 May, Copenhagen
by Vesna Manojlovic 23 Jan '17

23 Jan '17

Dear colleagues, Calling all front-end developers, UI designers, network operators and other enthusiastic coders! The next RIPE Atlas hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas. 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/Interface/?pk_campaign=hackathon&pk_kwd=li… *The application deadline is 23 March* Please note that we are unfortunately unable to provide travel or accommodation funding. We look forward to seeing you there! Regards, Vesna and the RIPE Atlas Team

1 4

Probe marked as offline, but it's online...
by Christian Schrötter 10 Nov '16

10 Nov '16

Hello Atlas users! I've connected my probe to a new network environment, to test everything before the big migration starts. It came up again immediately and displayed it's new network details at the WebUI. For the first time there was an IPv6-ULA prefix visible. The router (OpenWrt 15.05) supports full IPv6 via tunnel, but it's not advertised to the probe's VLAN and blocked by firewall rules. Everything seems to work, good! I've switched it off/on for several times, went back to the old router/modem and powered it on again. After some hours I've checked the WebUI again: My probe is offline! :-( I've tested it again on the new router: Offline! Once again on the old setup: Offline! Untouched default router/modem from my ISP: Offline! Current LED status: (from 1-5; power to button) > on > off > slow blink > on > on SOS-DNS-history from Wireshark: (switch port mirrored to my analysis interface) > Standard query 0x0002 AAAA U.*************.sos.atlas.ripe.net > Standard query response 0x0002 AAAA 2001:67c:2e8:11::c100:1337 > Standard query 0x0003 A U.*************.sos.atlas.ripe.net > Standard query response 0x0003 A 193.0.19.55 The probe is online and communicates with many servers. Looks like the built-in tests are running fine. There is NTP, DNS, ICMP, UDP and HTTP traffic. But it's still offline at the WebUI. I've double and triple checked everything on my side. Any ideas what's going wrong? -- With kind regards, Christian Schrötter

2 4

Fwd: Probe 2317 is down (home fibre)
by Colin Johnston 25 Jul '16

25 Jul '16

seems fine to me ? dont have connectivity to ripe site though from BT network range in uk what is telia upto ? Colins-iMac:~ colinj$ traceroute www.ripe.net traceroute to www.ripe.net (193.0.6.139), 64 hops max, 52 byte packets 1 bthomehub (192.168.1.254) 1.913 ms 1.078 ms 1.078 ms 2 * * * 3 * * * 4 31.55.185.196 (31.55.185.196) 16.187 ms 15.477 ms 15.443 ms 5 195.99.127.142 (195.99.127.142) 15.557 ms 195.99.127.130 (195.99.127.130) 16.274 ms 195.99.127.128 (195.99.127.128) 16.602 ms 6 vhsaccess2-pos1-0.faraday.fixed.bt.net (195.99.127.9) 16.979 ms 16.611 ms 195.99.127.25 (195.99.127.25) 17.097 ms 7 166-49-211-240.eu.bt.net (166.49.211.240) 16.413 ms 166-49-211-236.eu.bt.net (166.49.211.236) 16.225 ms 166-49-211-238.eu.bt.net (166.49.211.238) 15.821 ms 8 213.248.82.249 (213.248.82.249) 16.880 ms 15.785 ms 15.470 ms 9 ldn-bb2-link.telia.net (62.115.137.194) 16.633 ms 213.248.82.249 (213.248.82.249) 15.631 ms 15.400 ms 10 ldn-bb3-link.telia.net (80.91.248.90) 15.776 ms ldn-bb2-link.telia.net (213.155.136.62) 16.815 ms adm-bb4-link.telia.net (62.115.142.221) 22.936 ms 11 adm-b2-link.telia.net (62.115.141.51) 25.759 ms adm-b2-link.telia.net (80.91.253.182) 22.263 ms adm-b2-link.telia.net (62.115.141.17) 21.979 ms 12 adm-b2-link.telia.net (80.91.253.182) 22.481 ms adm-b2-link.telia.net (62.115.141.9) 22.344 ms adm-b2-link.telia.net (62.115.141.63) 27.606 ms Colin > Begin forwarded message: > > From: RIPE Atlas (no reply) <no-reply(a)ripe.net> > Subject: Probe 2317 is down (home fibre) > Date: 21 June 2015 20:30:07 BST > To: colinj(a)mx5.org.uk > > Dear Dear colin johnston, > > Your probe 2317 has been disconnected since 2015-06-21 18:49:16 UTC. > > This is an automatically generated email from RIPE Atlas. It was sent to you because you asked to be notified if your probe becomes disconnected for more than 30 minutes. > > If you want to change this, or disable this notification altogether, please go to https://atlas.ripe.net/probes/2317/, and click the "edit" button under "Notifications". > > Kind regards, > > RIPE Atlas Team > atlas(a)ripe.net

5 7

USB drive
by Michael Ionescu 13 May '16

13 May '16

Hi all, I have a probe that's been down for several days now. I did contact RIPE about it, but support has been superficial. I also didn't yet find the level of technical detail I need in the information on the website and in this list's archives. The 8GB drive, when reformatted on a windows box with FAT32 as per support instructions, surprisingly only comes out with a 1GB partition. Inspecting the drive under linux, I find multiple partitions, with only the first containing an a fat32 filesystem: Platte /dev/sdc: 7927 MByte, 7927234560 Byte 244 Köpfe, 62 Sektoren/Spur, 1023 Zylinder, zusammen 15482880 Sektoren Einheiten = Sektoren von 1 × 512 = 512 Bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Festplattenidentifikation: 0xc3072e18 Gerät boot. Anfang Ende Blöcke Id System /dev/sdc1 2048 2099199 1048576 b W95 FAT32 /dev/sdc2 2099200 4196351 1048576 83 Linux /dev/sdc3 4196352 6293503 1048576 83 Linux On first glance, the others contain ext2 filesystems # fsck -N /dev/sdc? fsck von util-linux 2.20.1 [/sbin/fsck.vfat (1) -- /dev/sdc1] fsck.vfat /dev/sdc1 [/sbin/fsck.ext2 (2) -- /dev/sdc2] fsck.ext2 /dev/sdc2 [/sbin/fsck.ext2 (3) -- /dev/sdc3] fsck.ext2 /dev/sdc3 but on further inspections do not contain a valid magic number in their superblocks, so they are effectively unformatted. I would therefore suspect that they are not being used by the probe. Now the question: What is the correct layout supposed to look like (primary/secondary, size, ID, FS-type)? I would like to get my probe back up and running. Bonus question: What can I expect to find in point of files/data on the drive, that would tell me whether the probe was working correctly until I cut power and removed the drive? Thanks, Michael

3 6

An article/FAQ entry about probe troubleshooting
by Ondřej Caletka 02 May '16

02 May '16

Hi all, it seems that failing probes are getting more and more to be an issue, possibly due to USB flash drive failure. I think it would be nice if there was an article / FAQ entry with some official troubleshooting procedures, so we could just send a link to anybody complaining about non functional probe. Is there something like this on the roadmap? Perhaps we as the community could make something up: - how to check whether the port probe is connected to has proper IP and DNS parameters and is allowed to establish a SSH session to TCP port 443 in the Internet (beware of DPI firewalls that allow HTTPS but not SSH over 443) - how to check the LED status and the SOS list at the probe page (the current LED explanation in the FAQ is too techy and even power users like me still don't understand all presented states :) ) - how to diagnose USB flash drive failure, how to force reformatting the flash drive and how to replace it with a new one What do you think? Cheers, Ondřej Caletka CESNET

9 11

Failing 4GB USB on v3 probes?
by Phillip Remaker 11 Apr '16

11 Apr '16

So far, I have had two of the SanDisk Cruzer 4GB drives (SDCZ33) fail, and I think I have two other ML-3020 (v3) devices with the same fate. Case #1, the drive fell into read only one. Case #2, the drive identifies to the USB, but read of block 0 (capacity) fails. The first time I called SanDisk and jumped through their hundred hoops to replace it.They were reluctant since I couldn't produce a receipt. This time, I just grabbed an old 8GB USB and dropped it in. Looks like it only uses 3GB. Does Atlas plan to pursue warranty claim, or is this an acceptable failure level for the probes?

2 1

Scheduling a test for all probes?
by Jared Mauch 06 Apr '16

06 Apr '16

Is there a way to schedule a one-off test on all the probes to be run “at a leisurely pace”, eg: looking up a specific DNS QNAME? (I’ll call it a lazy query/scheduling). - Jared

3 2

probe tagged as "system: Firewall problem suspected"
by sarah.wassermann＠student.ulg.ac.be 02 Apr '16

02 Apr '16

Hi, I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. Anybody knows how to fix this? (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( Thanks! Sarah

4 8

Implementing structured error reports ("Problem Details for HTTP APIs")?
by Stephane Bortzmeyer 01 Apr '16

01 Apr '16

Hello, IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem Details for HTTP APIs" which standardize structured error reports (in JSON) to add machine-readable information to HTTP error codes. Would it be a good idea to convert current Atlas reports ({"error":{"status":400,"code":104,"detail":"__all__: Your selected prefix is not covered by our network.","title":"Bad Request"}}) to the new and standard format?

3 4

IPv6 working
by gboonie 30 Mar '16

30 Mar '16

Hi, This seems to be an anchor that has Ipv6 connectivity but probably connected to a network with a incomplete routing table. https://atlas.ripe.net/probes/6149/#!tab-builtins It cannot reach a lot of the internet so I'm wondering what causes the system to flag it as "ipv6 works". Also, I've done a few hundred pings and found that probes get their "ipv6 works" only taken away after it has been failing for a few hours. Could that please be changed to something short like 10 minutes? And if possible, some stability tests so that if connectivity comes and goes that if does not get back it's "works" status. Thanks, Dave

4 4

Re: [atlas] Probe not flagged as "IPv4 works"
by gboonie 24 Mar '16

24 Mar '16

Hi Philip, A powercycle did not help. I did a reboot without USB stick and formated it in my laptop. Then plugged it back and after some minutes it started working again. Some googeling showed that the stick can be replaced by a 4GB stick but the one that it currently has seemed to be only 1GB. What is your view on this? The other strange thing is that the probe did somehow earn credits. That seems to contradict that it was down. On the other hand the "Connection and traffic" graph clearly shows that it is up after been down. Thanks, Dave Op 23-3-2016 om 16:29 schreef Philip Homburg: > On 2016/03/23 16:27 , Dave . wrote: >> Dit you remotely order a reboot?I did get the mail that the probe is >> down now. > Yes, I did. It is now connected again, but doesn't really work. > >> I'll power cycle when I get home and if it does not help, I'll do te >> delayed plug in trick. > That would be nice. > > Philip >

2 1

Probe not flagged as "IPv4 works"
by gboonie 23 Mar '16

23 Mar '16

Hi, I have 3 probes in different networks. This one probe is not selected for tests when I do a test on multiple probes that I select op probe ID or ASN. This is the troubling probe: https://atlas.ripe.net/probes/24645/ It is connected via a 4G LTE router. The router is up and everything else works. I could just reboot the modem and the probe but I'm wondering why it fails to get flagged with "IPv4 works". The "built in" test seem to work fine. What could be the issue? Is there something I could do to debug? Or just reboot and forget about it? Thanks, Dave

2 1

Fwd: New on RIPE Labs: Support for Elliptic Curve Cryptography (ECC) in DNS Resolvers as Seen by RIPE Atlas
by Vesna Manojlovic 21 Mar '16

21 Mar '16

Dear colleagues, Please find this new article on RIPE Labs contributed by Maciej Andzinski: The Elliptic Curve Cryptography (ECC) is becoming increasingly popular in DNSSEC. While it is sometimes considered to be a remedy for the low DNSSEC adoption rate, there is also a lot of controversy around it. One of the main concerns is that DNSSEC-validating resolvers don't always make use of ECC. We used RIPE Atlas to measure the support for ECC in DNS resolvers. https://labs.ripe.net/Members/maciej_andzinski_2/support-for-elliptic-curve… Kind regards, Vesna Manojlovic RIPE NCC

1 0

Eleven new RIPE Atlas anchors have joined the community
by Vesna Manojlovic 18 Mar '16

18 Mar '16

Dear colleagues, 11 new RIPE Atlas anchors have been activated during the last month, bringing the total number to 188: - uk-lba-as33920, hosted by aql in Leeds, United Kingdom - de-ber-as62310, hosted by managedhosting.de GmbH in Berlin, Germany - bt-thi-as38740, hosted by Tashi InfoComm Limited in Thimpbu, Bhutan and sponsored by APNIC - cz-prg-as52130, hosted by Livesport s.r.o. in Prague, Czech Republic - de-dar-as8365, hosted by TU Darmstadt - Secure Mobile Networking Lab/ DFG Collaborative Research Center in Darmstadt, Germany - one more anchor hosted by INX-ZA/Internet Service Providers' Association of South Africa: za-cpt-as37663 in Cape Town, South Africa - ee-tll-as51349, by Estonian Internet Foundation in Tallinn, Estonia - two anchors hosted by Sky UK Limited: uk-lon-as5607 in London and uk-slo-as5607 in Slough, United Kingdom - sixth anchor for Leaseweb Network B.V.: hk-hkg-as133752 in Hong Kong - fi-hel-as3274, hosted by Cygate Oy in Helsinki, Finland. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa, in order to add more geographical diversity to the measurement data. There are more organisations that want to host a RIPE Atlas anchor but don’t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb(a)ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas(a)ripe.net Regards, Vesna Manojlovic Measurements Community Building RIPE NCC

1 0

Webinar "Advanced RIPE Atlas Usage" on Thursday 17 March
by Michela Galante 15 Mar '16

15 Mar '16

Dear colleagues, On Thursday 17 March, 12:30 UTC, we are hosting the webinar on "Advanced RIPE Atlas Usage", aiming to teach network operators how to use RIPE Atlas measurements for network monitoring and troubleshooting. Register now at: https://lirportal.ripe.net/training/register/courseCode/WEB20160011 Web-registration is *only* possible for LIRs (RIPE NCC members). Non-members of RIPE NCC (people who do not have "Reg-ID") can email training(a)ripe.net and be manually registered. More details below. -------------------------- https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-a… This is part of the series of interactive on-line learning sessions, that give you the opportunity to learn and interact with trainers without leaving your desk, as well as for hands-on practice, and to get your questions answered by developers. Learn how to: - Use RIPE Atlas measurements for network monitoring and troubleshooting - Use API calls for measurement creation - Integrate RIPE Atlas with existing monitoring systems Webinars start at 12:30 UTC, and take about one hour. ----------------------------- We look forward to seeing you online. Kind regards, Michela Galante and Vesna Manojlovic RIPE NCC

1 0

Travel funding for RIPE Atlas Interface Hackathon
by Michela Galante 10 Mar '16

10 Mar '16

Dear colleagues, We’re excited to announce that travel funding is now available for the RIPE Atlas Interface Hackathon! As a reminder, the hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas - and we can now help cover the cost of travel and accommodation for a number of successful applicants, thanks to the generous financial support of our sponsor, Comcast. All of the event details and application form are available online: https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=li… *The application deadline is 23 March* We hope to see you there! Michela and the RIPE Atlas Team

1 0

DNS64 system tag using RFC7050
by Pier Carlo Chiodi 09 Mar '16

09 Mar '16

Hello, I would like to recall this short conversation that appeared in ipv6-wg: https://www.ripe.net/ripe/mail/archives/ipv6-wg/2015-November/002747.html I was wondering if it is worth adding a new system tag to probes: something like system-dns64. >From a quick analysis that I made using RFC7050 [1] I noticed that only a handful of probes are behind a DNS64 box, but I think it would be useful to have them tagged, to avoid spending credits to detect them every time. Or perhaps the game is not worth the candle... In that case, you can find my results as of yesterday there on GitHub. Bests, 1] https://gist.github.com/pierky/e5ec5c8f8f926bff3ef3#file-ripe-atlas-rfc7050… -- Pier Carlo Chiodi

1 0

Querying your own measurements
by Sebastian Castro 09 Mar '16

09 Mar '16

Hi: I'm currently testing the API to get a list of my own measurements. The API here reports ----------- Querying for Your Own Measurements In order to limit the results to your measurements only, just add a mine=true argument. For example: /api/v1/measurement/?mine=true Note that this only works if you're logged in, otherwise the result is the same as for any unauthenticated user. ----------- This seems to imply you need to manage a session within your code to get your own measurements, which I think violates the principle of a REST API. If you have the API key that provides you with access, shouldn't be reasonable to run the call as /api/v1/measurement/?mine=true&key=API_KEY and get a list of your own measurements? Thoughts? Am I reading the documentation in the wrong way? Thanks in advance -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

9 17

Small downtime expected
by Robert Kisteleki 02 Mar '16

02 Mar '16

Dear All, Due to operational reasons we will have a short downtime of the main RIPE Atlas website at 11:00 (CET). We expect this to last less than 15 minutes. The system will continue to collect results in the meantime, so no data loss is expected. Regards, Robert Kisteleki

1 0