- ripe-atlas - mailman.ripe.net

packet loss seen by probes to labs.ripe.net?
by Wilfried Woeber, UniVie/ACOnet 06 Nov '11

06 Nov '11

Dear Atlas Team, it looks like many (or even most/all?) of the probes seem to "seen" an increasing rate of packet loss to destination labs.ripe.net (on IPv4). The problem(?) seems to have started around Week 41 and gets worse since. Could the Atlas Team have a look at that? Thanks, Wilfried.

6 10

[atlas]Feature request: tag downtime
by Bengt Gördén 03 Nov '11

03 Nov '11

Hi, Would it be possible to make some tagging functionality on the web page due to reasons as downtime etc.? For me it would be nice due to maintenance or similar. It would also be a courtesy to the upstream network in the future event that the statistics would be public (or at least semi public). /bengan

3 3

j.root-servers.net ICMP?
by Marco Davids 03 Nov '11

03 Nov '11

Hi, Can anyone elaborate on why my Atlas probe is still trying to ping j.root-servers.net, while this seems futile since a few weeks?

4 4

follow-up on private discussion regarding management of access to probe measurement data
by Wilfried Woeber, UniVie/ACOnet 02 Nov '11

02 Nov '11

Hi Vesna, Team, here is my reminder regarding the suggested "better" granularity to manage the access to measurement data per probe. As I see it right now (please feel free to correct me!): - right now there is an "individual" guardianship per probe(s), this guardianship includes configuration access. - regarding access to the measurement data, the guardian only has two option to manage the access privileges - private and public, or simply put: white or black. Now, given that different persons are managing different probes, if I want to grant access for them, or apply for access to the data of probes under their control, the only way to accommodate this is to declare the probe(s) involved "public". That is not necessarily what we want. Thus I am asking for a sort of "intermediate" or "group" access category. I can see a couple of ways to help with this, for example by providing a way to add other user identities to be authorized for (non-config, i.e. read-only) access. An alternate approach could be to allow creation of Groups, into which some probes could be put and which user identities could be added to for access to the probes in the group. Of course any other approach would be equally fine with me, I just tried to come up with a least one idea instead of only asking for added functionality :-) Btw, my feeling is that such a facility would be even more useful in support for the upcoming UDM stuff! Thanks for reading as far, Wilfried.

1 0

3d downtime reported - why?
by Daniel AJ Sokolov (lists) 02 Nov '11

02 Nov '11

Hello, I have noticed that my probe data on the atlas.ripe.net-website reports at downtime of over 3 days: 2011-10-25 04:17:20 UTC to 2011-10-28 08:04:53 UTC. In fact, my connection was not down - maybe a few minutes (that seems to happen regularly), but everythin longer we would have noticed. We use this internet connection most of the day. My probe ID is not unter 500 but over 1000. Is this an error in the database, a problem with the reporting system or any other known bug? Did anyone else experience something like this? Or is there some issue I can resolve locally? Thank you Daniel AJ -- My twitter feed: @newstik http://twitter.com/newstik

4 4

[atlas]Mail list archives
by Ahmed Abu-Abed 21 Oct '11

21 Oct '11

Hello, I just subscribed to the Atlas mail list and I am looking for the mail list archives, can anyone point me to it ? Cheers, -Ahmed

5 8

(no subject)
by Олеся О. 17 Oct '11

17 Oct '11

1 0

Probes, static network configuration and upcoming firmware
by Robert Kisteleki 10 Oct '11

10 Oct '11

Dear Atlas hosts, We're about to release a new firmware version that supports more built-in measurements as well as prepares the probes for the User Defined Measurements feature. We have recently discovered that there's a compatibility issue with the upcoming firmware and (non-DHCP) static network configuration. In order to avoid problems that would come up in this case, we have temporarily disabled the static network configuration panel. We are in the process of releasing a corrected firmware, and enable static configuration for this version automatically. For the probes that already have static configuration up and running: there's nothing you need to do, we'll make sure that during the upgrade these probes keep their static network configuration. We apologise for the inconvenience this may cause. Regards, Robert

1 0

Re: [atlas] The letter from the student of Samara State Aerospace University
by Егоров Павел 05 Oct '11

05 Oct '11

On 28-30 November 2011 the ENOG 2/RIPE NCC Regional Meeting will take place. Registration is free and I think you'll get all required information about Atlas there. -- Pavel Yegorov

1 0

Re: [atlas] The letter from the student of Samara State Aerospace University
by Artem Onoprienko 03 Oct '11

03 Oct '11

I haven't received the answer, so I duplicate this letter I am interested in project RIPE ATLAS http://meeting.afrinic.net/afrinic-13/images/stories/af13_presentation/AF-1… Sukhov Andrey Mihailovich is the supervisor of my diploma project (his mail: amskh(a)yandex.ru) He has recommended to me to write to you that letter. I want to understand how ripe atlas probe works 23 september 2011, 13:58 from "Wilfried Woeber, UniVie/ACOnet" <Woeber(a)CC.UniVie.ac.at>: > Artem Onoprienko wrote: > [...] > > But I found no technical documentation about RIPE’s construction, > > and it’s electrical components. > > I would be grateful if you would give a link to documentation about > > hardware and software construction of the Ripe TestBox. > > I am slightly confused - is this referring to the (traditional) TTM Boxes > or the newer Atlas thumb-probes? > > > It will be great help for me. > > With best regards Artem Onoprienko > > And last but not least, what are the subscribers of this list expected to > do with this request? > > Regards, > Wilfried. >

1 0

The letter from the student Samara State Aerospace University
by Artem Onoprienko 23 Sep '11

23 Sep '11

Hello, I’m a student of Samara State Aerospace University. My name is Artem Onoprienko. I study at electronis engineering faculty with specialization in network technologies. I'm going to write a thesis project. I would like to be engaged in monitoring mechanisms of the Internet, and both hardware, and software part. In my work I would like to consider the possibility of additional quality criteria according to the IETF RFC 2544, and the work being done in the Samara State Aerospace University ( http://arxiv.org/abs/0907.3710 This work was presented at the conference in Lisbon. In this work, to measure the bandwidth using network testing packages of various sizes) As a first step I would like to see the ability to add these features to the RIPE Test Box. But I found no technical documentation about RIPE’s construction, and it’s electrical components. I would be grateful if you would give a link to documentation about hardware and software construction of the Ripe TestBox. It will be great help for me. With best regards Artem Onoprienko

2 1

Atlas infrastructure upgrades
by Robert Kisteleki 12 Sep '11

12 Sep '11

Dear Atlas users, During the course of this week, we'll be busy with a major upgrade to virtually all components of the Atlas infrastructure. This affects the UI, the backend database, and the probe controllers as well. Please don't be alarmed when your probe disconnects, or if you cannot reach the web interface. We apologize the inconvenience this may cause. Regards, Robert

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Roman Mamedov 08 Sep '11

08 Sep '11

On Wed, 7 Sep 2011 12:35:42 +1000 "Robert" <robert(a)robert.id.au> wrote: > What do other participants think about having email alerts when a probe goes > offline or online? Wasn't something like this implemented just recently? --------------------------------------------------------------------------------------------------------- From: Robert Kisteleki <robert(a)ripe.net> To: ripe-atlas(a)ripe.net Subject: [atlas]Atlas current news Date: Thu, 14 Jul 2011 14:46:26 +0200 Sender: ripe-atlas-admin(a)ripe.net User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0 Organization: RIPE NCC Dear Atlas users, We've added two new features to RIPE Atlas recently: 1. Automatic notification about down probes: if your probe has been down for some time, you'll get a one-time automatic notification. This happens after five consecutive days of downtime. 2. Static network configuration: after the testing round with volunteers, we decided to make this feature publicly available, thus released the 4.030 firmware version. You can read more about this feature at https://atlas.ripe.net/doc/static-config Regards, Robert Kisteleki, for the RIPE Atlas Team -- With respect, Roman

6 5

R: Email or SMS alert when probe goes offline/online
by Simone Nulchis 07 Sep '11

07 Sep '11

Hi all, >What do other participants think about having email alerts when a probe goes offline or online? I think it could be a nice feature; in my opinion it should be implemented in "my probe" section of Ripe ATLAS under "Probe's Settings" a specific section that permits to enable such feature and customize the threshold and contact addresses. Simone Nulchis Lucense SCpA

1 0

New Face(s) in the Measurements and Tools Area
by Daniel Karrenberg 07 Sep '11

07 Sep '11

Gentlepeople, I am very happy to announce that we have a new community builder for measuremnts and tools: Vesna Manjolovic. Many of you will know Vesna already as a trainer and through her very enthousiastic work on our IPv6 promotion and IPv6 related measurements. Vesna has been with the RIPE NCC for more than 10 years; it gives me great pleasure to promote her to a position that makes optimal use of her capabilities and ambitions. Vesna's first priorities will be to establish relationships with current and potential sponsors of RIPE Atlas and to help develop a plan for the evoloution of RIPE TTM. RIPE Atlas sponsors and RIPE TTM customers will hear from her soon. The decision to hire internally not only affirms that initiative and effort are rewarded at the RIPE NCC; it also provides the budgetary room to engage another person to help with the community building for measurements: Ann Barcomb will therefore join Vesna in October. >From that time both Vesna and Ann will start to work on additional goals such as building a strong community around RIPEstat. Please join me in welcoming Vesna and help her to achieve her goals, which are also our common goals. Daniel

4 3

Re: [atlas] Email or SMS alert when probe goes offline/online
by Bert Wijnen 07 Sep '11

07 Sep '11

On 9/7/11 4:35 AM, Robert wrote: > What do other participants think about having email alerts when a probe goes offline or online? > > I’d like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. > > This means that the alert could serve a dual purpose: > > ·Increased network uptime > > ·Greater availability of the RIPE Atlas Probe (and thus increased data gathering). > > Anyway, this is something that I’d like to see – email alerts at a minimum. > Email alerts for sure. And pretty quick after the probe is detected to be offline. SMS might be nice, but I certainly would like to have a way to turn it off at times. Bert > Robert >

2 1

Re: [atlas] Email or SMS alert when probe goes offline/online
by Dennis Kögel 07 Sep '11

07 Sep '11

Am 07.09.2011 um 05:53 schrieb Robert: > What do other participants think about having email alerts when a probe goes offline or online? Doing this monitoring-style is not a job for the NCC, IMHO, as this certainly involves way more work that one might think at first. This is a case for your local monitoring solution, which does that job much better. That being said, it might make sense to e-mail hosts if a probe has been down for a *long* time (something like "one e-mail per week of downtime"), just to catch dead hosts and unnoticed configuration fails. - D.

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Daniel AJ Sokolov 07 Sep '11

07 Sep '11

On 07.09.2011 00:53 wrote Robert: > What do other participants think about having email alerts when a probe > goes offline or online? I generally like the idea. There should be a threshold though - for example the e-mail could be triggered once the probe is offline for 5 minutes. BR Daniel AJ

1 0

Email or SMS alert when probe goes offline/online
by Robert 07 Sep '11

07 Sep '11

What do other participants think about having email alerts when a probe goes offline or online? I'd like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. This means that the alert could serve a dual purpose: . Increased network uptime . Greater availability of the RIPE Atlas Probe (and thus increased data gathering). Anyway, this is something that I'd like to see - email alerts at a minimum. Robert

1 0

Re: [atlas] Email or SMS alert when probe goes offline/online
by Richard L. Barnes 07 Sep '11

07 Sep '11

This might not actually be desirable until the probes stop crashing so often :) It might be more useful to have alarms that trigger on things like sudden or sustained increases in latency or loss, configurable by the probe host. --Richard On Sep 6, 2011, at 10:35 PM, Robert wrote: > What do other participants think about having email alerts when a probe goes offline or online? > > I’d like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. > > This means that the alert could serve a dual purpose: > > · Increased network uptime > · Greater availability of the RIPE Atlas Probe (and thus increased data gathering). > > Anyway, this is something that I’d like to see – email alerts at a minimum. > > > Robert >

1 0

Email or SMS alert when probe goes offline/online
by Robert 07 Sep '11

07 Sep '11

What do other participants think about having email alerts when a probe goes offline or online? I'd like this is at will alert me to any network issue as soon as it happens allowing for that issue to be investigated and rectified. This means that the alert could serve a dual purpose: . Increased network uptime . Greater availability of the RIPE Atlas Probe (and thus increased data gathering). Anyway, this is something that I'd like to see - email alerts at a minimum. Robert

1 0

[atlas]Apache again....
by Viktor Naoumov 30 Aug '11

30 Aug '11

Back to apache... 'Listen 8080' was a bad solution because it opens apache to the world. Instead we should do now: Listen 127.0.0.1:8080 #Listen localhost:8080 Having Listen localhost:8080 <VirtualHost *:8080> prevents apache from starting with the following message: zelenka-dev:/etc/apache2# /etc/init.d/apache2 restart Restarting web server: apache2 ... waiting (98)Address already in use: make_sock: could not bind to address 127.0.0.1:8080 no listening sockets available, shutting down Unable to open logs Action 'start' failed. The Apache error log may have more information. failed! looks like it because zelenka-dev:/etc/apache2# host localhost localhost has address 127.0.0.1 localhost has IPv6 address ::1 but not sure yet.... didn't have time to figure out what do you think? /vty

1 0

[atlas]UI for "My Probes" in IE7 broken (again)?
by Wilfried Woeber, UniVie/ACOnet 11 Jul '11

11 Jul '11

It looks like th UI for the "My Probes" section is broken again for IE7. All the other sections of the site seem to work. Wilfried.

2 2

[atlas]Probe with static IPv6 can 'lock up' if unreachable on IPv6
by Kenneth Aalberg 11 Jul '11

11 Jul '11

Greetings. As advised by other members of the list, I've moved my probe from behind a router that provided IPv6 tunneling and to the pure IPv4 network. However, when reconfiguring the probe, the static IPv6 address I added to it seems to not 'let go'. It now gets an IPv4 address as it should, but it shows as down in the probe list. The configuration page also claims it still has the static IPv6 address configured. I mentioned earlier about fallback to IPv4, but I'd also like to extend the question towards whether there is any functionality that lets the probe try 'last ditch efforts' to connect in cases where its configuration just doesn't work? (As in, give up on static addresses and try DHCP even if it has been assigned a static address) Best regards, Kenneth Aalberg

1 0

[atlas]Falling back to IPv4 if IPv6 connectivity is lost?
by Kenneth Aalberg 11 Jul '11

11 Jul '11

Greetings, Probers. (Yes, that was the first name that came to mind. :P ) I've joined the probecloud, and it is working fine. However, I am on an IPv6 tunnel behind a NAT that doesn't let me configure protocol 41 to be forwarded to one specific host (my linux router). Thus, the AYIYA tunnel is in a NAT table as a normal connection, and will sometimes be cycled out if it is the oldest connection and a new one is attempted, regardless of whether the NAT entry has seen traffic recently or not. The probe receives an IPv6 address, and uses this correctly. However, if the tunnel should go down, the probe will also be marked as down, even if it is actually still alive and can communicate through IPv4. Is there any kind of fallback option to try IPv4 connections before declaring a probe host down? Or would it make more sense for me to disable IPv6 on the probe to ensure it accurately represents the actual state of my connectivity? Best regards, Kenneth Aalberg Probe 737.

3 4

[atlas]Probe rebooting every minute
by Roman Mamedov 09 Jul '11

09 Jul '11

Hello, Probe ID 73, it seems to reboot itself after about 1-2 minutes of operation, even though according to tcpdump on the gateway it can successfully communicate with the control DNS, NTP, server, can ping stuff and does receive ping replies. What could be the problem? -- With respect, Roman

1 0

[atlas]'Location' sorting for the Public Probes
by Carsten Schiefner 04 Jul '11

04 Jul '11

Hi there, not sure sure whether that's been raised already - but the strictly alphabetical ordering of the probes when 'Location' sorting is activated, doesn't make any reals sense to me; cf. the attached screen shot. Maybe a somewhat greater "intelligence" could be deployed here? I'd suggest the DNS approach: from right to left. :-) Cheers, Carsten -- Homer Simpson meint: http://www.youtube.com/watch?v=Fk0To_o6NxE

2 1

[atlas]Jak zostać ekspertem?
by Dorota Masionek 02 Jul '11

02 Jul '11

Chcesz zwi�kszy� swoje kompetencje? Chcesz dosta� w prezencie netbooka lub czytnik ksi��ek elektronicznych? Zapraszamy na nasze szkolenia! Szanujemy Twoj� prywatno�� i w zwi�zku z tym prosimy o wyra�enie zgody na przes�anie informacji dotycz�cej szkole� z tematyki: MS Excel - zaawansowane rozwi�zania w arkuszach kalkulacyjnych MS PowerPoint - zaawansowane prezentacje multimedialne MS Word - tworzenie profesjonalnych dokument�w Odpowiedz wpisuj�c TAK w temacie wiadomo�ci, je�li chcesz otrzyma� od nas informacje handlowe. Je�li jednak nie wyra�asz zgody, prosz� odpowedz wpisuj�c NIE w temacie - adres zostanie zablokowany. Niniejsza wiadomo�� nie jest informacj� handlow�, a jedynie zapytaniem o zgod� na przesy�anie oferty handlowej drog� elektroniczn� zgodnie z art. 10 ustawy z dnia 18 lipca 2002r. o �wiadczeniu us�ug drog� elektroniczn� (Dz.U. z 2002r. Nr 144, poz 1204 z p�n. zm.). Wiadomo�� nadano na podstawie adres�w e-mail og�lnodost�pnych w Internecie, zgodnie z art. 25 ust. 2, pkt. 2 ustawy o ochronie danych osobowych. Copyright ASAP24. Mail przeznaczony dla ripe-atlas(a)ripe.net

1 0

[atlas]Atlas probe is "never seen"
by Martin Topholm 02 Jul '11

02 Jul '11

Hi all, I connected the Atlas probe thursday and is is conducting measurements as seen with tcpdump and from the logs on the Atlas site. However the site says the probe is "never seen". How long will it take for the site to register with the probe? Should I reset the probe? Probe ID 776 (near Helsinge, Denmark) -- Best regards, Martin Topholm

2 1

[atlas]Kasia już się zdecydowała.
by Anna Ewelina Wilczy�ska 16 May '11

16 May '11

Dzieñ dobry. Reprezentujê firmê ASAP24 - wdra¿amy wiedzê. Na naszych szkoleniach uczestnicy otrzymuj¹ narzêdzia, pomagaj¹ce im w codziennej pracy jak Netbooki lub Czytniki E-booków Organizujemy szkolenia stacjonarne i wewnêtrzne m.in. z tematów: MS PowerPoint - zaawansowane prezentacje multimedialne MS Word - tworzenie profesjonalnych dokumentów MS Excel - automatyzacja pracy dziêki wykorzystaniu VBA MS Excel - zaawansowane rozwi¹zania w arkuszach kalkulacyjnych Proszê o wyra¿enie zgody na przesy³anie ofert szkoleniowych. Bêd¹ one trafia³y na Pañstwa skrzynkê nie czêciej ni¿ raz w tygodniu. Je¿eli wyra¿aj¹ Pañstwo zgodê na przes³anie oferty, proszê przes³aæ wiadomoc TAK w temacie, lub zrezygnowaæ przesy³aj¹c wiadmoæ NIE. W razie pytañ prosimy o bezporedni kontakt: Z powa¿aniem Anna Ewelina Wilczyñska kom: 783 225 777 www.ASAP24.pl ---------------------------------- Zapytanie wys³ano zgodnie z Ustaw¹ z dnia 18 lipca 2002 r. o wiadczeniu us³ug drog¹ elektroniczn¹ (Dz.U. z 2002r, nr 144 poz. 1204 ustawy z dnia 18 lipca 2002 r.) oraz dyrektyw¹ UOKiK: "Dopuszczalne jest przes³anie na adres e-mail pytania czy adresat zgadza siê na otrzymywanie drog¹ elektroniczn¹ informacji handlowej". Copyright ASAP24. Mail przeznaczony dla: ripe-atlas(a)ripe.net

1 0

Re: [atlas]Feature request (fo consideration): broadcast rate measurement?
by Jesper Skriver 11 Apr '11

11 Apr '11

Hi As I see it the atlas project is about getting a global view. So in my book the last thing we want is stats about the local LAN segment the probe is connected to. Further more for privacy and security reasons the probes should in my mind gather as little information about the directly attached network as possible. /Jesper "Wilfried Woeber, UniVie/ACOnet" <Woeber(a)CC.UniVie.ac.at> wrote: >Xmas WishList 2011 :-) > >Looking at the yellow LED of the probes, I presume that their Ethernet IF >operates in promiscuous mode. Even if not... > >I'd like to see some (easily configurable) measurement available, at least >the rate of broadcast-packets on the probe's net. > >On a more elaborate basis, maybe according to simple paramters like a >protocol/port combination. > >Would this make sense to implement and be of interest to others? > >Thanks for consideration, >Wilfried. > >PS: yes, I do know about Netflow, WireShark and similar, but the beauty of > the ATLAS Probe Approach is imho in the ready-nade UI :-) >

3 2

[atlas]strange dns resolver display
by Florian Obser 10 Apr '11

10 Apr '11

Hi, Probe ID: 167 Firmware Version: 4020 DNS Resolver: ,1,9,2,.,1,6,8,.,1,0,0,.,2,5,4 (it should be 192.168.100.254) For what it's worth I had a lot of problems with my dsl connection since April 1st, switching to umts and back to dsl, rebooting the router a lot while the probe was constantly powered up. Thanks, Florian -- I remember yesterday, but the memory is in my head now. Was yesterday real? Or is it only the memory that is real?

1 0

[atlas]time base / synch for the "lst two hours" graphs?
by Wilfried Woeber, UniVie/ACOnet 08 Apr '11

08 Apr '11

I just noticed that the various graphs for the "last 2 hours" display seem to be based on different clocks or update cycles (delta = some 25m). Should these graphs be "synchronised"? >From a UI-perspective it would certainly be a bonus to have them aligned, at least for one probe. All the best, Wilfried.

3 6

[atlas]Feature request (fo consideration): broadcast rate measurement?
by Wilfried Woeber, UniVie/ACOnet 08 Apr '11

08 Apr '11

Xmas WishList 2011 :-) Looking at the yellow LED of the probes, I presume that their Ethernet IF operates in promiscuous mode. Even if not... I'd like to see some (easily configurable) measurement available, at least the rate of broadcast-packets on the probe's net. On a more elaborate basis, maybe according to simple paramters like a protocol/port combination. Would this make sense to implement and be of interest to others? Thanks for consideration, Wilfried. PS: yes, I do know about Netflow, WireShark and similar, but the beauty of the ATLAS Probe Approach is imho in the ready-nade UI :-)

1 0

Fwd: [atlas]"perceived" downtime of probe?
by Andreas Strikos 30 Mar '11

30 Mar '11

Begin forwarded message: > From: Andreas Strikos <astrikos(a)ripe.net> > Date: March 30, 2011 4:21:09 PM GMT+02:00 > To: Woeber(a)CC.UniVie.ac.at > Subject: Re: [atlas]"perceived" downtime of probe? > > Hi Wilfried, > > your probe is fine! > Last history uptime values are not propagated immediately to the central database by design. > That is why there were some "fault" calculations for small time for your probe. > Now that the latest uptime values are there, everything seems fine I believe. > > Regards, > Andreas > > On Mar 30, 2011, at 3:52 PM, Wilfried Woeber, UniVie/ACOnet wrote: > >> Hi Team, >> >> could you please have a look at the data for my 414, >> the "uptime" info claims a downtime of 7d, 16h, 51m, >> disconnected at 2011-03-22 20:50:26 UTC, up again at 2011-03-30 13:41:40 UTC. >> >> (the reason for the very short(!) interruption *today* was the need to move >> the USB cable to a different outlet...) [1] >> >> At the same time there is *no* loss of measurement data for this period!? >> >> Has anyone else seen such a situation recently? >> Wilfried >> >> [1] it would really be "cool" to ship future probes with some sort of >> "Y"-cable which w|should allow moving probes without loss of power, >> and/or to connect one plug to a UPS-fed outlet :-) >> >

1 0

[atlas]"perceived" downtime of probe?
by Wilfried Woeber, UniVie/ACOnet 30 Mar '11

30 Mar '11

Hi Team, could you please have a look at the data for my 414, the "uptime" info claims a downtime of 7d, 16h, 51m, disconnected at 2011-03-22 20:50:26 UTC, up again at 2011-03-30 13:41:40 UTC. (the reason for the very short(!) interruption *today* was the need to move the USB cable to a different outlet...) [1] At the same time there is *no* loss of measurement data for this period!? Has anyone else seen such a situation recently? Wilfried [1] it would really be "cool" to ship future probes with some sort of "Y"-cable which w|should allow moving probes without loss of power, and/or to connect one plug to a UPS-fed outlet :-)

1 0

[atlas]Statically configures probes - call for testers
by Robert Kisteleki 29 Mar '11

29 Mar '11

Hi, In a few days we'll be ready with a firmware that will support statically configured (IPv4) addresses for the probes. We'd like to test this out and get feedback from the interested people before we release it fully. So, if you are running a probe and would like to test the new functionality, please drop me a line. Cheers, Robert

1 0

[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

[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