From gwbnanog at gmail.com Wed Dec 14 05:37:37 2011 From: gwbnanog at gmail.com (Greg B - NANOG) Date: Tue, 13 Dec 2011 23:37:37 -0500 Subject: [atlas] Email or SMS alert when probe goes offline/online Message-ID: Hi, I see there was a thread started back on September 7, 2011 with subject: Email or SMS alert when probe goes offline/online this was prior to me joining the mailing list. I'd like to voice my support for a user-configurable amount of time for the Atlas system to send out an email notification that your probe is down (and returned to service). My probe which I run on my home internet connection was apparently down for 3.5 days before I just happened to login to look at the stats. Considering I was at home for much of these 3.5 days, and my Internet connection was working, I assume the probe crashed because simply power-cycling it "fixed" the problem. I know that if I got an email ~15 minutes after the probe was down, my probes downtime would probably have been closer to about 30 minutes rather than 3.5 days. Thanks. -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Dec 14 15:05:58 2011 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 14 Dec 2011 15:05:58 +0100 Subject: [atlas] Email or SMS alert when probe goes offline/online In-Reply-To: References: Message-ID: <4EE8AD46.7010900@ripe.net> Hi, On 2011.12.14. 5:37, Greg B - NANOG wrote: > Hi, > I see there was a thread started back on September 7, 2011 with > subject: Email or SMS alert when probe goes offline/online > this was prior to me joining the mailing list. > > I'd like to voice my support for a user-configurable amount of time for the > Atlas system to send out an email notification that your probe is down (and > returned to service). Indeed, this is on our list -- but see also below. > My probe which I run on my home internet connection was apparently down for > 3.5 days before I just happened to login to look at the stats. Considering I > was at home for much of these 3.5 days, and my Internet connection was > working, I assume the probe crashed because simply power-cycling it "fixed" > the problem. > > I know that if I got an email ~15 minutes after the probe was down, my > probes downtime would probably have been closer to about 30 minutes rather > than 3.5 days. A little background story: We have identified a particular condition on the probes where the probe refuses to connect back to our infrastructure after a disconnect (which can be caused by a network hickup, anywhere between the probe and our infrastructure, for example). This particular issue happens in low memory situations. The probe still does measurements happily, it just cannot connect to us and send the results in. After a while, the storage on the probe fills up, so as a best effort the probe reboots -- which fixes the low memory situation and then everything is back to normal again. The punch line: the probe's local storage, as with the current configuration, fills up in about 3.5 days... We're rolling out a new firmware (4.280) to address this. So, unless there are other similar conditions, after upgrading you will not see 3.5 day downtimes. Fingers crossed :-) Regards, Robert > Thanks. > > -Greg From gwbnanog at gmail.com Wed Dec 14 18:36:29 2011 From: gwbnanog at gmail.com (Greg B - NANOG) Date: Wed, 14 Dec 2011 12:36:29 -0500 Subject: [atlas] Email or SMS alert when probe goes offline/online In-Reply-To: <4EE8AD46.7010900@ripe.net> References: <4EE8AD46.7010900@ripe.net> Message-ID: Robert, That's great and I do hope the firmware update helps at least some of these situations. Looking at my last 25 connections list I also see downtimes of 4 hours, 6 hours, and two times for 1 hour over the last month. I'm pretty sure my internet connection wasn't actually down for these long periods since I have monitoring of it from another location (my office) which doesn't show these outages. So I do hope a feature is added in the near future to allow the probe host to set a threshold for when to notify of probe down in minutes instead of the default of 5 days. -Greg On Wed, Dec 14, 2011 at 9:05 AM, Robert Kisteleki wrote: > Hi, > > On 2011.12.14. 5:37, Greg B - NANOG wrote: > > Hi, > > I see there was a thread started back on September 7, 2011 with > > subject: Email or SMS alert when probe goes offline/online > > this was prior to me joining the mailing list. > > > > I'd like to voice my support for a user-configurable amount of time for > the > > Atlas system to send out an email notification that your probe is down > (and > > returned to service). > > Indeed, this is on our list -- but see also below. > > > My probe which I run on my home internet connection was apparently down > for > > 3.5 days before I just happened to login to look at the stats. > Considering I > > was at home for much of these 3.5 days, and my Internet connection was > > working, I assume the probe crashed because simply power-cycling it > "fixed" > > the problem. > > > > I know that if I got an email ~15 minutes after the probe was down, my > > probes downtime would probably have been closer to about 30 minutes > rather > > than 3.5 days. > > A little background story: > > We have identified a particular condition on the probes where the probe > refuses to connect back to our infrastructure after a disconnect (which can > be caused by a network hickup, anywhere between the probe and our > infrastructure, for example). This particular issue happens in low memory > situations. The probe still does measurements happily, it just cannot > connect to us and send the results in. > > After a while, the storage on the probe fills up, so as a best effort the > probe reboots -- which fixes the low memory situation and then everything > is > back to normal again. The punch line: the probe's local storage, as with > the > current configuration, fills up in about 3.5 days... > > We're rolling out a new firmware (4.280) to address this. So, unless there > are other similar conditions, after upgrading you will not see 3.5 day > downtimes. Fingers crossed :-) > > Regards, > Robert > > > Thanks. > > > > -Greg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Wed Dec 14 20:44:21 2011 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 14 Dec 2011 20:44:21 +0100 Subject: [atlas] Email or SMS alert when probe goes offline/online In-Reply-To: References: <4EE8AD46.7010900@ripe.net> Message-ID: <28B1F318-69B0-43D0-905F-F7516A64D489@ripe.net> We also need to be quite clear in our communication on what "probe down" means and that data keeps being collected. Daniel On 14.12.2011, at 18:36, Greg B - NANOG wrote: > Robert, > That's great and I do hope the firmware update helps at least some of these situations. > > Looking at my last 25 connections list I also see downtimes of 4 hours, 6 hours, and two times for 1 hour over the last month. I'm pretty sure my internet connection wasn't actually down for these long periods since I have monitoring of it from another location (my office) which doesn't show these outages. So I do hope a feature is added in the near future to allow the probe host to set a threshold for when to notify of probe down in minutes instead of the default of 5 days. > > -Greg > > On Wed, Dec 14, 2011 at 9:05 AM, Robert Kisteleki wrote: > Hi, > > On 2011.12.14. 5:37, Greg B - NANOG wrote: > > Hi, > > I see there was a thread started back on September 7, 2011 with > > subject: Email or SMS alert when probe goes offline/online > > this was prior to me joining the mailing list. > > > > I'd like to voice my support for a user-configurable amount of time for the > > Atlas system to send out an email notification that your probe is down (and > > returned to service). > > Indeed, this is on our list -- but see also below. > > > My probe which I run on my home internet connection was apparently down for > > 3.5 days before I just happened to login to look at the stats. Considering I > > was at home for much of these 3.5 days, and my Internet connection was > > working, I assume the probe crashed because simply power-cycling it "fixed" > > the problem. > > > > I know that if I got an email ~15 minutes after the probe was down, my > > probes downtime would probably have been closer to about 30 minutes rather > > than 3.5 days. > > A little background story: > > We have identified a particular condition on the probes where the probe > refuses to connect back to our infrastructure after a disconnect (which can > be caused by a network hickup, anywhere between the probe and our > infrastructure, for example). This particular issue happens in low memory > situations. The probe still does measurements happily, it just cannot > connect to us and send the results in. > > After a while, the storage on the probe fills up, so as a best effort the > probe reboots -- which fixes the low memory situation and then everything is > back to normal again. The punch line: the probe's local storage, as with the > current configuration, fills up in about 3.5 days... > > We're rolling out a new firmware (4.280) to address this. So, unless there > are other similar conditions, after upgrading you will not see 3.5 day > downtimes. Fingers crossed :-) > > Regards, > Robert > > > Thanks. > > > > -Greg > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Dec 15 12:33:41 2011 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 15 Dec 2011 12:33:41 +0100 Subject: [atlas] New: Atlas resource coverage (and more maps!) beta Message-ID: <4EE9DB15.7090502@ripe.net> Dear Atlas Users, Today we enabled another interesting feature (in beta mode, for now): details about what networks Atlas covers at the moment. This feature lists IPv4/IPv6 prefixes, ASNs and countries. This information will also be used for User Defined Measurements, in order to filter vantage points to specific networks or locations. You can access this at https://atlas.ripe.net/atlas/coverage.html Background information: * the prefixes and ASNs are looked up in RIS, based on the address of the probe * the country code is looked up in OpenStreetMaps based on the probe geolocation We are aware that in some cases the lookup has a surprising result. One example is 6to4: for IPv6 related ASNs the prefix is 2002::/16 but the ASN can be misleading. We'll most likely stop looking up ASNs for 6to4 (and Teredo) prefixes. If you see anomalies *not* related to this, you can let us know at atlas-dev at ripe.net Regards, Robert, for the whole team From rbarnes at bbn.com Thu Dec 15 19:18:58 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Thu, 15 Dec 2011 13:18:58 -0500 Subject: [atlas] New: Atlas resource coverage (and more maps!) beta In-Reply-To: <4EE9DB15.7090502@ripe.net> References: <4EE9DB15.7090502@ripe.net> Message-ID: Might be nice to have some summary statistics, e.g.: According to today's data, Atlas probes are present in... - 1.6% of IPv4 ASNs - 4.2% of IPv6 ASNs - 0.17% of IPv4 prefixes (covering 45% of the address space) - 2.3% of IPv6 prefixes - 91 countries On Dec 15, 2011, at 6:33 AM, Robert Kisteleki wrote: > Dear Atlas Users, > > Today we enabled another interesting feature (in beta mode, for now): > details about what networks Atlas covers at the moment. This feature lists > IPv4/IPv6 prefixes, ASNs and countries. This information will also be used > for User Defined Measurements, in order to filter vantage points to specific > networks or locations. > > You can access this at https://atlas.ripe.net/atlas/coverage.html > > Background information: > * the prefixes and ASNs are looked up in RIS, based on the address of the probe > * the country code is looked up in OpenStreetMaps based on the probe geolocation > > We are aware that in some cases the lookup has a surprising result. One > example is 6to4: for IPv6 related ASNs the prefix is 2002::/16 but the ASN > can be misleading. We'll most likely stop looking up ASNs for 6to4 (and > Teredo) prefixes. If you see anomalies *not* related to this, you can let us > know at atlas-dev at ripe.net > > Regards, > Robert, for the whole team > From davidp at preshweb.co.uk Thu Dec 15 19:54:39 2011 From: davidp at preshweb.co.uk (David Precious) Date: Thu, 15 Dec 2011 18:54:39 +0000 Subject: [atlas] Email or SMS alert when probe goes offline/online In-Reply-To: References: Message-ID: <20111215185439.60c096e1@columbia> On Tue, 13 Dec 2011 23:37:37 -0500 Greg B - NANOG wrote: > I see there was a thread started back on September 7, 2011 with > subject: Email or SMS alert when probe goes offline/online > this was prior to me joining the mailing list. That sounds like a very useful idea. For extra flexibility, it could be ideal to support firing a basic web hook when a probe goes offline/online; that would allow users to trigger whatever form of notifications or actions they may desire. -- David Precious ("bigpresh") http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github From robert at ripe.net Fri Dec 16 09:33:49 2011 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 16 Dec 2011 09:33:49 +0100 Subject: [atlas] New: Atlas resource coverage (and more maps!) beta In-Reply-To: References: <4EE9DB15.7090502@ripe.net> Message-ID: <4EEB026D.3080508@ripe.net> On 2011.12.15. 19:18, Richard L. Barnes wrote: > Might be nice to have some summary statistics, e.g.: According to today's data, Atlas probes are present in... > - 1.6% of IPv4 ASNs > - 4.2% of IPv6 ASNs > - 0.17% of IPv4 prefixes (covering 45% of the address space) > - 2.3% of IPv6 prefixes > - 91 countries Indeed. We're thinking about creating a statistics page that can contain this and some other interesting data. Robert From gwbnanog at gmail.com Tue Dec 20 20:20:28 2011 From: gwbnanog at gmail.com (Greg B - NANOG) Date: Tue, 20 Dec 2011 14:20:28 -0500 Subject: [atlas] Algortithm for probe detecting its offline Message-ID: Hi, I wanted to ask what is the algorithm / methodology used for a probe detecting / reporting it is offline? I ask, because this morning I intentionally rebooted my cable modem on the network the probe is attached to, which brought my internet down for about 1-2 minutes (I was using the internet immediately after the cable modem re-synched), but the probe is reporting that outage as a 29 minute outage rather than a few minutes. Any comments on why there should be such a large variance from my actual experience versus what the probe saw? -Greg -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at romanrm.ru Tue Dec 20 21:08:30 2011 From: rm at romanrm.ru (Roman Mamedov) Date: Wed, 21 Dec 2011 02:08:30 +0600 Subject: [atlas] New measurement target suggestion: 6to4 anycast Message-ID: <20111221020830.54499eb3@natsu> Hello, I'd like to suggest adding to the list of monitored addresses a new one: 192.88.99.1 - 6to4 anycast IPv4 to IPv6 gateway; https://en.wikipedia.org/wiki/6to4 https://tools.ietf.org/html/rfc3068 This could provide interesting data on what percentage of networks have this address blocked/inaccessible (resulting in broken operation of 6to4), and also what is the average latency to the closest 6to4 gateway across various countries/regions. The next step would possibly be the collection of statistics which ASes 'see' whose 6to4 gateways, this can be inferred from the AS of the traceroute hop that is right before the 192.88.99.1 on the trace. -- With respect, Roman ~~~~~~~~~~~~~~~~~~~~~~~~~~~ "Stallman had a printer, with code he could not see. So he began to tinker, and set the software free." -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From philip.homburg at ripe.net Wed Dec 21 00:01:55 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 21 Dec 2011 00:01:55 +0100 Subject: [atlas] Algortithm for probe detecting its offline In-Reply-To: References: Message-ID: <4EF113E3.1010207@ripe.net> On 12/20/11 20:20 , Greg B - NANOG wrote: > I wanted to ask what is the algorithm / methodology used for a probe > detecting / reporting it is offline? > > I ask, because this morning I intentionally rebooted my cable modem on > the network the probe is attached to, which brought my internet down > for about 1-2 minutes (I was using the internet immediately after the > cable modem re-synched), but the probe is reporting that outage as a > 29 minute outage rather than a few minutes. > > Any comments on why there should be such a large variance from my > actual experience versus what the probe saw? > At the moment, we use a rather simplistic method and that is the connection to the controller. That connection is often re-established within 3 minutes, but it may also take much longer. Note that the probe continues doing measurements while the connection to the connection to the controller is down, so when it is back up it is possible to verify what happened exactly. We are trying to figure out where that delay is coming from, but at the moment we don't have the answer yet. From mohacsi at niif.hu Wed Dec 21 11:57:17 2011 From: mohacsi at niif.hu (Mohacsi Janos) Date: Wed, 21 Dec 2011 11:57:17 +0100 (CET) Subject: [atlas] New measurement target suggestion: 6to4 anycast In-Reply-To: <20111221020830.54499eb3@natsu> References: <20111221020830.54499eb3@natsu> Message-ID: Dear All, 6to4 should not used any longer. However it would be nice to see how 6to4 usage decreasing over the time.... Janos Mohacsi Head of HBONE+ project Network Engineer, Deputy Director of Network Planning and Projects NIIF/HUNGARNET, HUNGARY Key 70EF9882: DEC2 C685 1ED4 C95A 145F 4300 6F64 7B00 70EF 9882 On Wed, 21 Dec 2011, Roman Mamedov wrote: > Hello, > > I'd like to suggest adding to the list of monitored addresses a new one: > > 192.88.99.1 - 6to4 anycast IPv4 to IPv6 gateway; > > https://en.wikipedia.org/wiki/6to4 > https://tools.ietf.org/html/rfc3068 > > This could provide interesting data on what percentage of networks have this address blocked/inaccessible (resulting in broken operation of 6to4), and also what is the average latency to the closest 6to4 gateway across various countries/regions. > > The next step would possibly be the collection of statistics which ASes 'see' whose 6to4 gateways, this can be inferred from the AS of the traceroute hop that is right before the 192.88.99.1 on the trace. > > -- > With respect, > Roman > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Stallman had a printer, > with code he could not see. > So he began to tinker, > and set the software free." > From inigo at infornografia.net Wed Dec 21 12:21:14 2011 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 21 Dec 2011 12:21:14 +0100 Subject: [atlas] New measurement target suggestion: 6to4 anycast In-Reply-To: References: <20111221020830.54499eb3@natsu> Message-ID: On Wed, Dec 21, 2011 at 11:57 AM, Mohacsi Janos wrote: > Dear All, > ? ? ? ?6to4 should not used any longer. However it would be nice to see how > 6to4 usage decreasing over the time.... > I agree. It may be interesting to see its eventual sunset, which is already showing up according to Google's stats: http://www.google.com/intl/en/ipv6/statistics/ Also, quoting Robert Kisteleki: " We are aware that in some cases the lookup has a surprising result. One example is 6to4: for IPv6 related ASNs the prefix is 2002::/16 but the ASN can be misleading. We'll most likely stop looking up ASNs for 6to4 (and Teredo) prefixes. If you see anomalies *not* related to this, you can let us know at atlas-dev at ripe.net " it is unclear (to me) how much interest and resources should be put into these measurements. > Janos Mohacsi > Head of HBONE+ project > Network Engineer, Deputy Director of Network Planning and Projects > NIIF/HUNGARNET, HUNGARY > Key 70EF9882: DEC2 C685 1ED4 C95A 145F ?4300 6F64 7B00 70EF 9882 > Best, > > On Wed, 21 Dec 2011, Roman Mamedov wrote: > >> Hello, >> >> I'd like to suggest adding to the list of monitored addresses a new one: >> >> ?192.88.99.1 - 6to4 anycast IPv4 to IPv6 gateway; >> >> https://en.wikipedia.org/wiki/6to4 >> https://tools.ietf.org/html/rfc3068 >> >> This could provide interesting data on what percentage of networks have >> this address blocked/inaccessible (resulting in broken operation of 6to4), >> and also what is the average latency to the closest 6to4 gateway across >> various countries/regions. >> >> The next step would possibly be the collection of statistics which ASes >> 'see' whose 6to4 gateways, this can be inferred from the AS of the >> traceroute hop that is right before the 192.88.99.1 on the trace. >> >> -- >> With respect, >> Roman >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> "Stallman had a printer, >> with code he could not see. >> So he began to tinker, >> and set the software free." >> > From robert at ripe.net Wed Dec 21 13:37:11 2011 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 21 Dec 2011 13:37:11 +0100 Subject: [atlas] New measurement target suggestion: 6to4 anycast In-Reply-To: References: <20111221020830.54499eb3@natsu> Message-ID: <4EF1D2F7.6070804@ripe.net> On 2011.12.21. 12:21, I?igo Ortiz de Urbina wrote: > On Wed, Dec 21, 2011 at 11:57 AM, Mohacsi Janos wrote: >> Dear All, >> 6to4 should not used any longer. However it would be nice to see how >> 6to4 usage decreasing over the time.... >> > > I agree. It may be interesting to see its eventual sunset, which is > already showing up according to Google's stats: > > http://www.google.com/intl/en/ipv6/statistics/ It seems that there is interest for doing this measurement, so we'll add it to the list -- most likely in January, after the holiday break. > Also, quoting Robert Kisteleki: > > " > We are aware that in some cases the lookup has a surprising result. One > example is 6to4: for IPv6 related ASNs the prefix is 2002::/16 but the ASN > can be misleading. We'll most likely stop looking up ASNs for 6to4 (and > Teredo) prefixes. If you see anomalies *not* related to this, you can let us > know at atlas-dev at ripe.net > " > > it is unclear (to me) how much interest and resources should be put > into these measurements. With the current setup we have enough control that setting up a new system-wide measurement is not difficult. However, we have to balance the usefulness of such measurements with the measurement capacity they consume. Regards, Robert From BECHA at ripe.net Fri Dec 23 10:11:08 2011 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Dec 2011 10:11:08 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) Message-ID: <4EF445AC.8060404@ripe.net> Hi everyone, *you* are part of our big success: more then 1024 probes before the end of this year! We've published an article on Labs about that yesterday: https://labs.ripe.net/Members/becha/ripe-atlas-has-reasons-to-celebrate Thank you very much for participating in this exciting project, and Happy New Year! Vesna From bortzmeyer at nic.fr Fri Dec 23 10:17:11 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 23 Dec 2011 10:17:11 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF445AC.8060404@ripe.net> References: <4EF445AC.8060404@ripe.net> Message-ID: <20111223091711.GA16648@nic.fr> On Fri, Dec 23, 2011 at 10:11:08AM +0100, Vesna Manojlovic wrote a message of 12 lines which said: > *you* are part of our big success: more then 1024 probes > before the end of this year! I hope that, in 2012, we'll celebrate the release of the source code, with instructions on how to build your own probe and/or to add measurements. From BECHA at ripe.net Fri Dec 23 11:13:40 2011 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Dec 2011 11:13:40 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <20111223091711.GA16648@nic.fr> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> Message-ID: <4EF45454.606@ripe.net> Dear Stephane, On 12/23/11 10:17 AM, Stephane Bortzmeyer wrote: > On Fri, Dec 23, 2011 at 10:11:08AM +0100, > Vesna Manojlovic wrote > a message of 12 lines which said: > >> *you* are part of our big success: more then 1024 probes >> before the end of this year! > > I hope that, in 2012, we'll celebrate the release of the source code, I have noted your interest in opening the source code. > with instructions on how to build your own probe > and/or to add measurements. If you join the beta-testers of User Defined Measurements (UDM), you can already try out adding some of your measurements, and then let us know what is the further functionality you would like to have. Please write to atlas-dev at ripe.net if you are interested. Regards, Vesna From simon at josefsson.org Fri Dec 23 11:24:51 2011 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 23 Dec 2011 11:24:51 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF45454.606@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF45454.606@ripe.net> Message-ID: <1324635891.29833.18.camel@latte.josefsson.org> fre 2011-12-23 klockan 11:13 +0100 skrev Vesna Manojlovic: > Dear Stephane, > > On 12/23/11 10:17 AM, Stephane Bortzmeyer wrote: > > On Fri, Dec 23, 2011 at 10:11:08AM +0100, > > Vesna Manojlovic wrote > > a message of 12 lines which said: > > > >> *you* are part of our big success: more then 1024 probes > >> before the end of this year! > > > > I hope that, in 2012, we'll celebrate the release of the source code, > > I have noted your interest in opening the source code. A +1 to that. Merry Christmas, Simon From philip.homburg at ripe.net Fri Dec 23 12:12:51 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 23 Dec 2011 12:12:51 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <20111223091711.GA16648@nic.fr> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> Message-ID: <4EF46233.1010608@ripe.net> On 12/23/11 10:17 , Stephane Bortzmeyer wrote: > I hope that, in 2012, we'll celebrate the release of the source code, > with instructions on how to build your own probe and/or to add > measurements. Looking at it purely from a technical point of view, releasing the source code should be doable. Of course it will require time to clean it up a bit and make it run on a generic Linux system instead of just on Lantronix modules. But I have no idea how we could allow probes with unknown firmware connect to the atlas infrastructure. At moment we can rely on the probes to faithfully report what they see. And we know exactly what software the probes are running. When probes can run arbitrary firmware, analyzing the results may become much harder. From bortzmeyer at nic.fr Fri Dec 23 12:23:19 2011 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 23 Dec 2011 12:23:19 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF46233.1010608@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> Message-ID: <20111223112319.GA1314@nic.fr> On Fri, Dec 23, 2011 at 12:12:51PM +0100, Philip Homburg wrote a message of 16 lines which said: > releasing the source code [...] allow probes with unknown firmware > connect to the atlas infrastructure. That's two completely different things. I mentioned only the first one. In my vision, modified probes were intended for another C&C, not for the Atlas service. From philip.homburg at ripe.net Fri Dec 23 12:35:00 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 23 Dec 2011 12:35:00 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <20111223112319.GA1314@nic.fr> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <20111223112319.GA1314@nic.fr> Message-ID: <4EF46764.80505@ripe.net> On 12/23/11 12:23 , Stephane Bortzmeyer wrote: > On Fri, Dec 23, 2011 at 12:12:51PM +0100, > Philip Homburg wrote > a message of 16 lines which said: > >> releasing the source code [...] allow probes with unknown firmware >> connect to the atlas infrastructure. > That's two completely different things. I mentioned only the first > one. In my vision, modified probes were intended for another C&C, not > for the Atlas service. > Okay. I assumed that with 'with instructions on how to build your own probe' you meant how to connect it to the Atlas infrastructure. But if you want to connect the probe to another C&C then you may also need the source code for the back-end. The software that runs on the probe is quite simple. The back-end is a completely different story. From BECHA at ripe.net Fri Dec 23 15:08:38 2011 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 23 Dec 2011 15:08:38 +0100 Subject: [atlas] Happy UDM & Happy New Year :) Message-ID: <4EF48B66.8000908@ripe.net> Dear all, One more article on RIPE Labs: about User Defined Measurements: https://labs.ripe.net/Members/becha/happy-beta-testers-of-atlas-udm Thank you for your feedback and contribution! Regards, Vesna From kix at kix.es Fri Dec 23 17:27:48 2011 From: kix at kix.es (Rodolfo kix Garcia) Date: Fri, 23 Dec 2011 17:27:48 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF46233.1010608@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> Message-ID: <4EF4AC04.9050504@kix.es> On 23/12/11 12:12, Philip Homburg wrote: > On 12/23/11 10:17 , Stephane Bortzmeyer wrote: >> I hope that, in 2012, we'll celebrate the release of the source code, >> with instructions on how to build your own probe and/or to add >> measurements. > Looking at it purely from a technical point of view, releasing the > source code should be doable. Of course it will require time to clean it > up a bit and make it run on a generic Linux system instead of just on > Lantronix modules. > > But I have no idea how we could allow probes with unknown firmware > connect to the atlas infrastructure. At moment we can rely on the probes > to faithfully report what they see. And we know exactly what software > the probes are running. You can release the source code in git/mercurial/... and the probes can run the same (open) source code. People can help to get a better source code. This is a good point because, if the source code is available, some people can implement the probe in other devices, for example linux-based DSL routers (open-wrt,...). If some people want to run different code, they need the interface to communicate with the atlas infrastructure (commands, arguments,...), and probably this info is in the source code ;-) therefore, you won't have problems. > > When probes can run arbitrary firmware, analyzing the results may become > much harder. > Best Regards, kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ From kix at kix.es Fri Dec 23 17:14:43 2011 From: kix at kix.es (Rodolfo kix Garcia) Date: Fri, 23 Dec 2011 17:14:43 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <1324635891.29833.18.camel@latte.josefsson.org> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF45454.606@ripe.net> <1324635891.29833.18.camel@latte.josefsson.org> Message-ID: <4EF4A8F3.2060207@kix.es> On 23/12/11 11:24, Simon Josefsson wrote: > fre 2011-12-23 klockan 11:13 +0100 skrev Vesna Manojlovic: >> Dear Stephane, >> >> On 12/23/11 10:17 AM, Stephane Bortzmeyer wrote: >>> On Fri, Dec 23, 2011 at 10:11:08AM +0100, >>> Vesna Manojlovic wrote >>> a message of 12 lines which said: >>> >>>> *you* are part of our big success: more then 1024 probes >>>> before the end of this year! >>> >>> I hope that, in 2012, we'll celebrate the release of the source code, >> >> I have noted your interest in opening the source code. > > A +1 to that. +1 :-) > > Merry Christmas, +1 too. Merry Christmas. > Simon > > -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ From philip.homburg at ripe.net Fri Dec 23 17:36:41 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 23 Dec 2011 17:36:41 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF4AC04.9050504@kix.es> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> Message-ID: <4EF4AE19.2060004@ripe.net> On 12/23/11 17:27 , Rodolfo kix Garcia wrote: > If some people want to run different code, they need the interface to > communicate with the atlas infrastructure (commands, arguments,...), > and probably this info is in the source code ;-) therefore, you won't > have problems. I'm not worried about people getting their modified firmware to talk to the atlas infrastructure. A lot of that stuff is even documented :-) The problem is, do you trust those results to be correct? And it is not just faking results. That can be done today, to some extent. But more, what if somebody decides to improve traceroute and it works just slightly different and gives also just slightly different results? From patrick at vande-walle.eu Fri Dec 23 18:15:52 2011 From: patrick at vande-walle.eu (Patrick Vande Walle) Date: Fri, 23 Dec 2011 18:15:52 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF445AC.8060404@ripe.net> References: <4EF445AC.8060404@ripe.net> Message-ID: <4EF4B748.9010407@vande-walle.eu> Congrats ! And note that, in pure geek logic, 1K equals 2^10 here, and not one thousand :-) Congrats again. And a very Happy New Year, too. Patrick Vande Walle On 23/12/11 10:11, Vesna Manojlovic wrote: > Hi everyone, > > *you* are part of our big success: more then 1024 probes > before the end of this year! > > We've published an article on Labs about that yesterday: > https://labs.ripe.net/Members/becha/ripe-atlas-has-reasons-to-celebrate > > Thank you very much for participating in this exciting project, > and Happy New Year! > > Vesna > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon at josefsson.org Fri Dec 23 19:10:41 2011 From: simon at josefsson.org (Simon Josefsson) Date: Fri, 23 Dec 2011 19:10:41 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF4AE19.2060004@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> Message-ID: <1324663841.29833.20.camel@latte.josefsson.org> fre 2011-12-23 klockan 17:36 +0100 skrev Philip Homburg: > On 12/23/11 17:27 , Rodolfo kix Garcia wrote: > > If some people want to run different code, they need the interface to > > communicate with the atlas infrastructure (commands, arguments,...), > > and probably this info is in the source code ;-) therefore, you won't > > have problems. > I'm not worried about people getting their modified firmware to talk to > the atlas infrastructure. A lot of that stuff is even documented :-) > > The problem is, do you trust those results to be correct? And it is not > just faking results. That can be done today, to some extent. But more, > what if somebody decides to improve traceroute and it works just > slightly different and gives also just slightly different results? One way to deal with that is to let the probes send in the hash value of its firmware or something similar, which can be used to detect problems like that. And you could prepare "official" reports based only on the probes running "official" firmware. I really think this is orthogonal to releasing source code though. If you haven't built in any security mechanism, people can already do what you appear to be afraid of today. /Simon From philip.homburg at ripe.net Fri Dec 23 19:33:10 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 23 Dec 2011 19:33:10 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <1324663841.29833.20.camel@latte.josefsson.org> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> <1324663841.29833.20.camel@latte.josefsson.org> Message-ID: <4EF4C966.8030706@ripe.net> On 12/23/11 19:10 , Simon Josefsson wrote: > One way to deal with that is to let the probes send in the hash value of > its firmware or something similar, which can be used to detect problems > like that. And you could prepare "official" reports based only on the > probes running "official" firmware. You want untrusted firmware to send a hash value of itself? How do you know it is not lying? > I really think this is orthogonal to releasing source code though. If > you haven't built in any security mechanism, people can already do what > you appear to be afraid of today. > (From a technical point of view) releasing the source is not an issue. The probes come with key material that allows them to connect to the Atlas infrastructure. In theory you can get that out of the probe. But, you would violate the agreement as a probe host and it would be quite tricky to do. And, you can take over only one probe at a time which has to be in your physical possession. If we would allow 'third party' probes to connect to the Atlas infrastructure then all of that changes. No need to physically obtain a probe. Just download the source, request a key. And start hacking away. From simon at josefsson.org Sun Dec 25 20:45:16 2011 From: simon at josefsson.org (Simon Josefsson) Date: Sun, 25 Dec 2011 20:45:16 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF4C966.8030706@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> <1324663841.29833.20.camel@latte.josefsson.org> <4EF4C966.8030706@ripe.net> Message-ID: <1324842316.29833.37.camel@latte.josefsson.org> fre 2011-12-23 klockan 19:33 +0100 skrev Philip Homburg: > On 12/23/11 19:10 , Simon Josefsson wrote: > > One way to deal with that is to let the probes send in the hash value of > > its firmware or something similar, which can be used to detect problems > > like that. And you could prepare "official" reports based only on the > > probes running "official" firmware. > You want untrusted firmware to send a hash value of itself? How do you > know it is not lying? > > > I really think this is orthogonal to releasing source code though. If > > you haven't built in any security mechanism, people can already do what > > you appear to be afraid of today. > > > (From a technical point of view) releasing the source is not an issue. > The probes come with key material that allows them to connect to the > Atlas infrastructure. In theory you can get that out of the probe. But, > you would violate the agreement as a probe host and it would be quite > tricky to do. And, you can take over only one probe at a time which has > to be in your physical possession. > > If we would allow 'third party' probes to connect to the Atlas > infrastructure then all of that changes. No need to physically obtain a > probe. Just download the source, request a key. And start hacking away. How does this keying work today? I haven't seen this documented anywhere. If you embed a symmetric or asymmetric key in the probes, which sounds like what you are suggesting (and is more advanced than what I expected), there shouldn't be any threat to publish source code for the firmware: people will not have access to any private key that you will trust. I was assuming that your current threat model was that you aren't concerned about fake probes, but if you have embedded keys in the probes, that suggests a different threat model. Solving that is relatively complicated, and describing your setup would be a useful contribution. My proposed solution to send a hash of the firmware was to be able to diagnose on the server side which firmware sent what information and to do larger-scale data mining. It is not a solution to malicious probes. Sorry if anything I said implied that. Cheers, /Simon From philip.homburg at ripe.net Tue Dec 27 11:58:24 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 27 Dec 2011 11:58:24 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <1324842316.29833.37.camel@latte.josefsson.org> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> <1324663841.29833.20.camel@latte.josefsson.org> <4EF4C966.8030706@ripe.net> <1324842316.29833.37.camel@latte.josefsson.org> Message-ID: <4EF9A4D0.1050004@ripe.net> On 12/25/11 20:45 , Simon Josefsson wrote: > fre 2011-12-23 klockan 19:33 +0100 skrev Philip Homburg: >> (From a technical point of view) releasing the source is not an issue. >> The probes come with key material that allows them to connect to the >> Atlas infrastructure. In theory you can get that out of the probe. But, >> you would violate the agreement as a probe host and it would be quite >> tricky to do. And, you can take over only one probe at a time which has >> to be in your physical possession. >> >> If we would allow 'third party' probes to connect to the Atlas >> infrastructure then all of that changes. No need to physically obtain a >> probe. Just download the source, request a key. And start hacking away. > How does this keying work today? I haven't seen this documented > anywhere. The slides should give you a general idea of how it works: > > If you embed a symmetric or asymmetric key in the probes, which sounds > like what you are suggesting (and is more advanced than what I > expected), there shouldn't be any threat to publish source code for the > firmware: people will not have access to any private key that you will > trust. That's right. > > My proposed solution to send a hash of the firmware was to be able to > diagnose on the server side which firmware sent what information and to > do larger-scale data mining. It is not a solution to malicious probes. > Sorry if anything I said implied that. > > So, assuming for a moment that we cannot let 'third party' probes connect to the Atlas infrastructure, because we cannot trust the results, what would be the point of releasing the source? One is that somebody may want to run his own private copy of the whole Atlas system. But that is going to to be a lot of work setting it all up. If we would allow third party probes to connect, but it ignore their results and not schedule any UDMs on those probes. Just publish the raw results somewhere. Would that be a net benefit to the community, or just a PR disaster waiting to happen? From rbarnes at bbn.com Wed Dec 28 18:52:37 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Wed, 28 Dec 2011 12:52:37 -0500 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF9A4D0.1050004@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> <1324663841.29833.20.camel@latte.josefsson.org> <4EF4C966.8030706@ripe.net> <1324842316.29833.37.camel@latte.josefsson.org> <4EF9A4D0.1050004@ripe.net> Message-ID: <15AE858A-BF41-4510-938F-12AECA824ED9@bbn.com> Hi Philip, On this point: > So, assuming for a moment that we cannot let 'third party' probes connect to the Atlas infrastructure, because we cannot trust the results, what would be the point of releasing the source? One is that somebody may want to run his own private copy of the whole Atlas system. But that is going to to be a lot of work setting it all up. ... > If we would allow third party probes to connect, but it ignore their results and not schedule any UDMs on those probes. Just publish the raw results somewhere. Would that be a net benefit to the community, or just a PR disaster waiting to happen? I think you may be skipping a potential middle point here. Thinking back to RIPE 61, there were some folks who were offering to manufacture probes if the firmware were open-source. That seems to indicate that a "partnership" model might be viable, in which anyone can get the source code, but if a probe maker signs a contract with RIPE, then their probes can feed information into the real RIPE Atlas system. Having contracts would provide a way for RIPE NCC to get guarantees related to security, fraud, etc. A more open model might not be useless, either. After all, one can make much richer decisions based on data sources than "accept/ignore". As long as the data is source-tagged, then different sources can be compared for consistency, which would provide some validation that the probes aren't providing completely bogus data. Putting these two ideas together, it seems like you could enable two "classes" of data, "high assurance" from probes made by RIPE NCC and its partners, and "low assurance" from anyone else. Think of it as a "freemium" model -- it's cheap and easy for small-scale projects to feed into the "low assurance" class, but if you want to be a real contributor, do the work to get into the "high assurance" class. You could even provide additional features to "high assurance" sources (UDM access / management, say) as an incentive. --Richard From rbarnes at bbn.com Wed Dec 28 18:55:06 2011 From: rbarnes at bbn.com (Richard L. Barnes) Date: Wed, 28 Dec 2011 12:55:06 -0500 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF4A8F3.2060207@kix.es> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF45454.606@ripe.net> <1324635891.29833.18.camel@latte.josefsson.org> <4EF4A8F3.2060207@kix.es> Message-ID: It seems like +1 is slightly too few dimensions in this poll, so I wrote a quick Google poll to capture a few more dimension: On Dec 23, 2011, at 11:14 AM, Rodolfo kix Garcia wrote: > On 23/12/11 11:24, Simon Josefsson wrote: >> fre 2011-12-23 klockan 11:13 +0100 skrev Vesna Manojlovic: >>> Dear Stephane, >>> >>> On 12/23/11 10:17 AM, Stephane Bortzmeyer wrote: >>>> On Fri, Dec 23, 2011 at 10:11:08AM +0100, >>>> Vesna Manojlovic wrote >>>> a message of 12 lines which said: >>>> >>>>> *you* are part of our big success: more then 1024 probes >>>>> before the end of this year! >>>> >>>> I hope that, in 2012, we'll celebrate the release of the source code, >>> >>> I have noted your interest in opening the source code. >> >> A +1 to that. > > +1 :-) > >> >> Merry Christmas, > > +1 too. Merry Christmas. > >> Simon >> >> > > > -- > ||// //\\// Rodolfo "kix" Garcia > ||\\// //\\ http://www.kix.es/ > From philip.homburg at ripe.net Wed Dec 28 19:51:56 2011 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 28 Dec 2011 19:51:56 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <15AE858A-BF41-4510-938F-12AECA824ED9@bbn.com> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> <1324663841.29833.20.camel@latte.josefsson.org> <4EF4C966.8030706@ripe.net> <1324842316.29833.37.camel@latte.josefsson.org> <4EF9A4D0.1050004@ripe.net> <15AE858A-BF41-4510-938F-12AECA824ED9@bbn.com> Message-ID: <4EFB654C.9080309@ripe.net> On 12/28/11 18:52 , Richard L. Barnes wrote: > Hi Philip, > > On this point: > >> So, assuming for a moment that we cannot let 'third party' probes connect to the Atlas infrastructure, because we cannot trust the results, what would be the point of releasing the source? One is that somebody may want to run his own private copy of the whole Atlas system. But that is going to to be a lot of work setting it all up. > ... > >> If we would allow third party probes to connect, but it ignore their results and not schedule any UDMs on those probes. Just publish the raw results somewhere. Would that be a net benefit to the community, or just a PR disaster waiting to happen? > I think you may be skipping a potential middle point here. Thinking back to RIPE 61, there were some folks who were offering to manufacture probes if the firmware were open-source. That seems to indicate that a "partnership" model might be viable, in which anyone can get the source code, but if a probe maker signs a contract with RIPE, then their probes can feed information into the real RIPE Atlas system. Having contracts would provide a way for RIPE NCC to get guarantees related to security, fraud, etc. Let me once again emphasize that I'm looking at this from a technical point of view. There are many other issues to consider, which I'm ignoring here. I'd say if a party were to manufacture probes under supervision of RIPE NCC then that is independent of the issue of open source. That's just a normal business relationship. It is possible that an organization would agree to sponsor probes in return for Atlas to become open source. But then the source would effectively be payment for something. That would be similar to the Android model: you can download the source, but there is no guarantee that you can actually install it on your own phone and some functionality, like connecting the Android market, may be unavailable. From a technical point of view, just releasing the probe sources is the easiest, because it is a relatively small amount of code. Relatively easy to compile and install. The back-end systems are way more complex. > A more open model might not be useless, either. After all, one can make much richer decisions based on data sources than "accept/ignore". As long as the data is source-tagged, then different sources can be compared for consistency, which would provide some validation that the probes aren't providing completely bogus data. At the moment, analysis is already hard. The Internet is an extremely diverse landscape. It is very much a research question whether adding untrusted data is good or not. I certainly don't know the answer to that question. > Putting these two ideas together, it seems like you could enable two "classes" of data, "high assurance" from probes made by RIPE NCC and its partners, and "low assurance" from anyone else. Think of it as a "freemium" model -- it's cheap and easy for small-scale projects to feed into the "low assurance" class, but if you want to be a real contributor, do the work to get into the "high assurance" class. You could even provide additional features to "high assurance" sources (UDM access / management, say) as an incentive. > One issue is what do you do with the data in the low assurance class. At the moment, probe hosts have access to data of their own probe and RIPE NCC researchers have access to all data. If researchers want to have that low assurance data, then great. If not, then it may be a waste of resources. From Piotr.Strzyzewski at polsl.pl Wed Dec 28 20:06:53 2011 From: Piotr.Strzyzewski at polsl.pl (Piotr Strzyzewski) Date: Wed, 28 Dec 2011 20:06:53 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: <4EF9A4D0.1050004@ripe.net> References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF46233.1010608@ripe.net> <4EF4AC04.9050504@kix.es> <4EF4AE19.2060004@ripe.net> <1324663841.29833.20.camel@latte.josefsson.org> <4EF4C966.8030706@ripe.net> <1324842316.29833.37.camel@latte.josefsson.org> <4EF9A4D0.1050004@ripe.net> Message-ID: <20111228190653.GA1809@hydra.ck.polsl.pl> On Tue, Dec 27, 2011 at 11:58:24AM +0100, Philip Homburg wrote: > So, assuming for a moment that we cannot let 'third party' probes connect > to the Atlas infrastructure, because we cannot trust the results, what > would be the point of releasing the source? One is that somebody may want > to run his own private copy of the whole Atlas system. But that is going to > to be a lot of work setting it all up. Open source means that everybody can search for potential bugs, problems, etc. On the other hand - everybody can submit some patches with improvements and help develop ATLAS. -- gucio -> Piotr Strzy?ewski E-mail: Piotr.Strzyzewski at polsl.pl From kix at kix.es Wed Dec 28 23:32:14 2011 From: kix at kix.es (Rodolfo kix Garcia) Date: Wed, 28 Dec 2011 23:32:14 +0100 Subject: [atlas] Reasons to celebrate - passed 1K active probes :) In-Reply-To: References: <4EF445AC.8060404@ripe.net> <20111223091711.GA16648@nic.fr> <4EF45454.606@ripe.net> <1324635891.29833.18.camel@latte.josefsson.org> <4EF4A8F3.2060207@kix.es> Message-ID: <4EFB98EE.3040201@kix.es> On 28/12/11 18:55, Richard L. Barnes wrote: > It seems like +1 is slightly too few dimensions in this poll, so I wrote a quick Google poll to capture a few more dimension: > Nice! Thanks a lot. > > > On Dec 23, 2011, at 11:14 AM, Rodolfo kix Garcia wrote: > >> On 23/12/11 11:24, Simon Josefsson wrote: >>> fre 2011-12-23 klockan 11:13 +0100 skrev Vesna Manojlovic: >>>> Dear Stephane, >>>> >>>> On 12/23/11 10:17 AM, Stephane Bortzmeyer wrote: >>>>> On Fri, Dec 23, 2011 at 10:11:08AM +0100, >>>>> Vesna Manojlovic wrote >>>>> a message of 12 lines which said: >>>>> >>>>>> *you* are part of our big success: more then 1024 probes >>>>>> before the end of this year! >>>>> >>>>> I hope that, in 2012, we'll celebrate the release of the source code, >>>> >>>> I have noted your interest in opening the source code. >>> >>> A +1 to that. >> >> +1 :-) >> >>> >>> Merry Christmas, >> >> +1 too. Merry Christmas. >> >>> Simon >>> >>> >> >> >> -- >> ||// //\\// Rodolfo "kix" Garcia >> ||\\// //\\ http://www.kix.es/ >> > -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ From kix at kix.es Thu Dec 29 12:01:02 2011 From: kix at kix.es (Rodolfo kix Garcia) Date: Thu, 29 Dec 2011 13:01:02 +0200 Subject: [atlas] Probe location Message-ID: <56b2ae3d4548d69b15ff24652aebd8ab@kix.es> Hi, what's the method to set the probe location? When I set up my probe, I locate it in the nearest subway station (of course, is not there), but now in the map the probe is too near of my home. The probe location is moved about 300 meters. Are you using other method to locate the probe (IP addresses, Google wifi map,...)? Cheers. kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ From daniel.karrenberg at ripe.net Thu Dec 29 12:06:09 2011 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 29 Dec 2011 12:06:09 +0100 Subject: [atlas] Probe location In-Reply-To: <56b2ae3d4548d69b15ff24652aebd8ab@kix.es> References: <56b2ae3d4548d69b15ff24652aebd8ab@kix.es> Message-ID: <3249CCDC-0053-4920-94C6-EBF78B78B204@ripe.net> On 29.12.2011, at 12:01, Rodolfo kix Garcia wrote: > Hi, > > what's the method to set the probe location? > > When I set up my probe, I locate it in the nearest subway station (of course, is not there), but now in the map the probe is too near of my home. The probe location is moved about 300 meters. > > Are you using other method to locate the probe (IP addresses, Google wifi map,...)? This is top secret! If we told you we'd have to kill you. ;-) ;-) ;-) Seriously: We dither the location in the public maps for privacy reasons. It should remain accurate in the change dialog on your probe pages. So there is no harm setting it close to where it really is on that page. Daniel