- ripe-atlas - mailman.ripe.net

[atlas]Simple way to open API access?
by Richard L. Barnes 24 Mar '11

24 Mar '11

Hey all, Suggestion for a simple way to provide some basic automated access to ATLAS data: It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. Just a thought, --Richard [1] For example <http://atlas.ripe.net/atlas/publicprobesgrid.json>

3 3

[atlas]New Atlas Features
by Andreas Strikos 07 Mar '11

07 Mar '11

Dear Hosts, We've now enabled two features that were requested by hosts earlier: 1. The "Probe DNS" function allows you to ask for a DNS entry for you probe. Operational details: * The exact DNS name of your probe depends on your settings (simple or obfuscated), and can be looked up on the "Probe Conf" section of the probe status page. * The zone file is re-generated every 15 minutes. * The resulting address is the one we observe when the probe to connects to our infrastructure, so if you're using NAT then it's the public address of the NAT device. Currently it's either IPv4 or IPv6, but not both. We'll add the "other address" too in the future. 2. The probe uptime section has more details. It now contains: * Relative uptime for the last week and month, and for the full lifetime. * The source IP address of the individual connections. * The amount of up- and downtime (in days/hours/minutes), for each connection. Regards, Andreas

2 1

[atlas]too many disconnects?
by Wilfried Woeber, UniVie/ACOnet 07 Mar '11

07 Mar '11

[my apologies to the Team for the duplicate, I 1st picked the wrong address] Q to the Team and to the Probe Hosts: My feeling is that the probes do register too many "disconnects". I just had a look at the two under my control and the numbers of transitions are - 466: 25 events between 2010-12-21 07:14:30 UTC and 2011-03-01 10:24:11 UTC 414: 25 events between 2010-11-22 12:31:02 UTC and 2011-02-20 20:18:24 UTC While there may be a local reason for some of the down-periods, I doubt that I had so many outages on my ends. Is anyone else seeing a similar pattern? Regarding presentation, again, could we please have an additional item of "Total Downtime" (next to the "Total Uptime"), and the duration of the downs in the 25 lines with the time stamps? This would make it much more straight- forward to spot patterns.... Minor cosmetics, relevant when reporting stuff, could the probe's number be displayed somewhere in the Probe Conf panel (e.g. in the line with the Firmware Version)? Thanks for your consideration, have a nice weekend Wilfried

3 2

[atlas]Atlas website upgrades
by Andreas Strikos 02 Mar '11

02 Mar '11

Hi, Today, in sync with the new Ripe NCC website we are upgrading Ripe Atlas website. You might encounter strange behaviors on some pages but we believe until the end of the day they will be fixed. Except from the template, there are some other changes in UI like a new tab for public probes and a bigger settings button. Also, from now on there will be an announcement page where you can read the latest information about Atlas. Regards, Andreas

4 3

[atlas]Down/Up fail
by Richard L. Barnes 16 Feb '11

16 Feb '11

Hey guys, I've just been re-engineering my home network to give probe 394 more stable access. It seems that the ATLAS web site still reports it as "down" even though it's clearly reporting information to the central system (since the RRD graphs are updated). Huh? --Richard

2 2

[atlas]Strange behaviour of probe
by Patrick Vande Walle 31 Jan '11

31 Jan '11

Hello Robert, According to the graphs on atlas.ripe.net, my probe (#45) seems to have been offline for nearly 24 hours. During that period, the DSL connection was up nevertheless. Are there more detailed logs on the probe controller that could explain what happened ? Thanks, Patrick Vande Walle

2 1

[atlas]Some new UI features
by Robert Kisteleki 13 Jan '11

13 Jan '11

Hello, We've added some changes to the UI yesterday. From now on upon registering a new probe, or changing its attributes (from the probe status page) the host can set the following additional information: * Router type: optional, describes the router/NAT model you have, mainly in a home installation. This information could be useful for us to correlate weird probe behavior across similar router models. * Allowed bandwidth: it's not used yet, but you can imagine the future purpose for it :) * DNS options: this has been asked by some of you before. By default it's off. If you set it to "simple" then your probe will have a probe-xxxx.probes.atlas.ripe.net DNS entry. If you set it to "obfuscated" then your probe will have a <something random looking>.probes.atlas.ripe.net DNS entry. We'll activate this feature soon. * Public: you can make your probe visible to everyone, which means that all Atlas users will see the probe in their probe list (with role "Viewer"), and they will be able to see the measurement details on the probe status page. Consider this an experimental feature -- we have to see if it's useful or not. You'll need to reload the page (with the browser "reload") in order to see these changes. Regards, Robert

7 8

[atlas]Probe comparisons
by Michael Behringer (mbehring) 13 Jan '11

13 Jan '11

Team, The new feature of making probes generally visible is EXCELLENT. It allows nice comparisons between different probes. For example, I just compared my Orange DSL probe to a Free probe (both France). The results are VERY interesting! (Would be interested to chat with the owner of this Free probe off line, BTW - can you ping me please?). Now of course this leads immediately to a new feature request! :-) (the curse of being popular!) It would be nice to be able to compare a number of probes side by side. In the simplest case, min/avg/max values (graphs are nice but not essential). Now of course the next feature request :-) that'll come out of this is to see the full traceroute from each probe, to be able to understand where the difference in RTT is coming from. On the positive side, the beer supply to the developers at the next RIPE meeting should be plenty! :-) Thanks for all your work! Michael

1 0

[atlas]Not my probes ?
by Andrzej Wolski 12 Jan '11

12 Jan '11

Hi everyone, after coming back from holidays I've looked at the graphs of my probe ( 00:20:4A:C8:24:17 ) and found that I have rights to view about 16 other probes from all over the place. Bug or a feature ? ;-) -- Andrzej Wolski aka Taihen mailto/xmpp: taihen(a)taihen.org

2 1

[atlas]trying to collect basic info about the architecture
by Wilfried Woeber, UniVie/ACOnet 05 Jan '11

05 Jan '11

Dear ATLAS-Team, I am aware of the fact that my poking and attempt to collect information may be premature, as the whole thing is still very much in development... Still, I think it would be useful for many of us to have some sort of "snapshot" regarding the behaviour of the probes and the framework they live in. The initial basic questions on my end would be: What does the term "connect", to one of the controllers, really mean in terms of TCP/IP Lingo? Like: does the thing open a TCP hose to the controller? Is communication based on UDP and/or on TCP? Is the probe capable of bufffering data for a while if connectivity to the Net is still there, but not to the controller(s)? Is there any means to (locally, on the same subnet, or even remotely) trigger or "reboot" a probe, other than disconnecting power (which means physical access required)? I am also wondering how much of this stuff is available already and where to collect it - the 'labs pool may be more appropriate than this list? Thanks to everyone who was and is involved in this fascinating project, with season's greatings and a happy (2010)++ to everyone, Wilfried. PS: for a future version of the probes or as an optional gadget: how about making the thing capable of feeding it off 2 different power plugs, e.g. a primary and a UPS? :-)

4 4