- ripe-atlas - mailman.ripe.net

[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

[atlas]Probe actually down?
by Richard L. Barnes 05 Jan '11

05 Jan '11

Probe #394 is reported as being down in the web GUI, but I can ping6 to it without a problem. I'm not near the probe right now, so I can't look at it or its traffic. Are there known cases where probes are alive but not reporting to their controllers? --Richard

4 4

[atlas]Geo-location
by Hartmut Richard Glaser 29 Dec '10

29 Dec '10

After the registration of the probes, how can I correct the geo-location? Thanks Hartmut

4 3

[atlas]Geo-location
by Hartmut Richard Glaser 29 Dec '10

29 Dec '10

After the registration of the probes, how can I correct the geo-location? Thanks Hartmut

1 0

[atlas]DHCP behaviour of the probe on startup
by Wilfried Woeber, UniVie/ACOnet 22 Dec '10

22 Dec '10

Hi folks, while debugging some non-probe-related issues here at my ADSL'd net @home, I was told by the provider's techie, that the probe tries to grab *two* addresses at startup. He was monitoring the ARP table in the router, saw a DHCP request and the address assigned by the DHCP Server, and immediately asfterwards, the probe sent a request for an additional address, which was granted by the server. Trying to verify that, I later found out that I can ping the probe only on the second address. [1] Has anyone seen such a behaviour? Unfortunately, I don't have access to the router (cisco 800 series) as it is fully managed by the ISP, and for my other probe we had the IP-Address hard-wired into the DHCP server for the MAC address. Thanks, Wilfried. [1] this is particularly nasty for home networks with a very small number of addresses available (a bock of 8 in may case) and a long timeout...

2 1