January 2016 - ripe-atlas - mailman.ripe.net

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

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

01 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

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

List of my measurements via API
by Luke Overend 09 Feb '16

09 Feb '16

Hi all, I have searched the docs and tried everything I can think of but I cannot get a list of my measurements via the API. Can anyone provide me details on how to do this? If it is not currently possible how do I go about requesting the feature? Thanks Luke Overend -------------------------------------- CloudFlare - AS13335 Network Engineer luke(a)cloudflare.com +442038136383 +447795328022 http://www.peeringdb.com/view.php?asn=13335

2 1

API (v1) querying probes--does stats_name field count and possibility of negative selection
by Wenqin SHAO 28 Jan '16

28 Jan '16

Dear list, I encountered some unexpected results when selecting probes with status_name filed. An example is given below: https://atlas.ripe.net/api/v1/probe/?country_code=BG&tags=system-v3,datacen… <https://atlas.ripe.net/api/v1/probe/?country_code=BG&tags=system-v3,datacen…> 8 results were returned containing probes that are abandoned, as well disconnected and connected. To nail down the problematic field, I tried following queries: https://atlas.ripe.net/api/v1/probe/?status_name=Connected https://atlas.ripe.net/api/v1/probe/?status_name=Abandoned https://atlas.ripe.net/api/v1/probe/?status_name=Disconnected https://atlas.ripe.net/api/v1/probe/?status_name=Haha Exactly same number of probes, 16889, are return with each of these quests, which makes me wonder whether the status_name filed is actually taken into consideration? One other issue, is to negatively select probes according to some fields, especially tags filed, for example, probes do not contain home tag. I’d like to know if such selection logic is supported by v1 API? If yes, how to compose the query? If not, would it be considered in v2 API? A bunch of thanks in advance. Regards, Wenqin Telecom ParisTech

1 0

No Ethernet activity on new probe
by Marat Khalili 28 Jan '16

28 Jan '16

Dear All, I have received my probe yesterday morning (V3, like shown on https://atlas.ripe.net/docs/probe-v3/ ), connected and registered it. Unfortunately, not only no measurements or IP address information appeared in my profile after waiting several hours, but there's no Ethernet activity from probe at all, even in the packet trace. Things I tried: * 3 different switches (Fast and Gigabit types); in all cases a notebook running either Windows or Ubuntu when connected into the same socket acquires IP address just fine and can browse the Internet. * 3 different LAN cables; in all cases switches detect 100 Mbps physical wire but nothing more. * 2 different DHCP servers as well as wireshark on direct connection. * 3 different power sources (1A phone charger, notebook 2xUSB, PC USB). * Removing and re-inserting the USB flash key that came with the device, dd'ing its contents to a different USB flash and inserting it instead (dd finished successfully). Every time after the boot sequence ends first light glows steadily and adjacent one blinks slowly, like it is supposed to be according to https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-pro… . Looks like the interface just isn't up in the device OS. Is there anything else I can check? Should I request another probe? (it took more than month to receive first one by post) -- With Best Regards, Marat Khalili

3 6

500 Probe limit
by Marco Slater 27 Jan '16

27 Jan '16

Hello, I’ve been doing some tests on anycasted networks, and I’ve been hitting an error which doesn’t allow me to assign more then 500 probes to a measurement, is there a way to have this unlocked? I presume it is a default protection to not cause issues to hosts being probed? Thank you. :) - Marco

3 2

HTTP measurements at willing targets / protocol suggestion
by Gil Bahat 27 Jan '16

27 Jan '16

Hi, We are interested (like many others, I guess) in the ability to perform HTTP measurements at our own non-anchored network. Understanding the potential for abuse, I would like to suggest the following authentication protocol, which is based on best practices exhibited by other services with such potential (abuse or privacy implications). 1. Confirm control of the domain registration: * This is usually done by mailing the technical contact for the relevant WHOIS entry with a confirmation email containing a unique hash, thus validating ownership. 2. Confirm control of the DNS servers: * This is usually done by editing the root TXT record with a unique hash or publishing a CNAME with unique hash. 3. Confirm control of the Web servers: * This is usually done by placing a uniquely-hashed file in the webserver root directory, a unique hash in the meta-tags for the index html file or a unique value in a file such as robots.txt. I believe this protocol is sufficient to ensure that a web site owner agrees to the implications of allowing free HTTP measurements against their servers and that no unwilling server will ever be probed. At most during the protocol, the only resource that can be hit is a static file or robots.txt specifically, which has very little capability to overwhelm a web server, especially if negative responses are cached for a considerable amount of time / validation is done via a few nodes and propagated across the network. thoughts/ideas welcome. Regards, Gil Bahat, DevOps Engineer, Magisto Ltd.

3 3