- ripe-atlas - mailman.ripe.net

[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