From rbarnes at bbn.com Wed Jan 4 15:01:36 2012 From: rbarnes at bbn.com (Richard L. Barnes) Date: Wed, 4 Jan 2012 09:01:36 -0500 Subject: [atlas] Survey results on Atlas open-sourcing Message-ID: The brief survey I put out a couple weeks ago has gotten 34 responses. The response rate seems to be tailing off, so I've closed the survey. Here's a summary of results. First, the simple things: -- All but one respondent is an Atlas probe host. -- Respondents preferred source to binary release 26:4 (4 abstentions) The responses as to reasons for wanting the Atlas platform opened up are a little more challenging to read. There were four options that respondents, from which respondents could choose as many as they wanted. 0 - I'm not interested in RIPE NCC releasing the Atlas firmware 1 - So that parties other than RIPE to build probes that can feed into the Atlas system 2 - So that I can easily build Atlas-like probes for my own, independent measurement network 3 - So that I can re-use some Atlas features for a non-measurement-related purpose The response patterns, ordered by frequency Pattern Frequency 1 8 2+3 6 0 5 1+2 3 1+2+3 3 2 3 3 1 (who noted: "I don't care too much") Respondents could also fill in an "other" response for their reason. There were two major themes to these responses: -- Security, in the sense both of making the device more secure, and of assuring probe hosts of what the device is doing -- Contributions, i.e., that the community could contribute to probe development One respondent also noted in an "other" response that responses 1 and 2 are not necessarily mutually exclusive; a modified probe could feed both the RIPE system and a private system. Analyze as you will :) --Richard From simon at josefsson.org Wed Jan 4 16:11:03 2012 From: simon at josefsson.org (Simon Josefsson) Date: Wed, 04 Jan 2012 16:11:03 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: (Richard L. Barnes's message of "Wed, 4 Jan 2012 09:01:36 -0500") References: Message-ID: <87fwfvlczc.fsf@latte.josefsson.org> "Richard L. Barnes" writes: > Analyze as you will :) One thing that strikes me from the discussion has been an absence of answers to this question: What would reasons be to _not_ release the source code? I believe that unless there is a strong reason not to release the source, it should be done because there is interest in it and there is potential to get improvements out of it. One reason could be that the current security architecture is based on obscurity, but that discussion wasn't conclusive if I remember correctly. In that case, releasing things gradually might be a good compromise, so that people can contribute a better security architecture. /Simon From philip.homburg at ripe.net Wed Jan 4 16:45:03 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 04 Jan 2012 16:45:03 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <87fwfvlczc.fsf@latte.josefsson.org> References: <87fwfvlczc.fsf@latte.josefsson.org> Message-ID: <4F0473FF.10006@ripe.net> On 1/4/12 16:11 , Simon Josefsson wrote: > "Richard L. Barnes" writes: > >> Analyze as you will :) > One thing that strikes me from the discussion has been an absence of > answers to this question: What would reasons be to _not_ release the > source code? > > I believe that unless there is a strong reason not to release the > source, it should be done because there is interest in it and there is > potential to get improvements out of it. > There are some non-technical arguments that I won't list here. One argument for not releasing is security by obscurity. It is easier to find security holes if you can just download the source. Instead of trying to obtain a probe, getting the firmware out of it and decompiling the binaries. In short, within RIPE NCC the question needs to be answered whether the source can released as is, or whether a security audit is required. Needless to say, a security audit is likely to cost money. Dumping the source just as a tar file on a web site is easy. But that will be one way communication. And most likely fork the project. Not good. If you want to turn it into an open source project, then a lot of stuff has to happen. In particular, the project has to be mature enough that it can actually be installed without too much pain. Of course, this costs time and money. From inigo at infornografia.net Wed Jan 4 17:07:10 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 4 Jan 2012 17:07:10 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F0473FF.10006@ripe.net> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> Message-ID: As the survey shows, and as Simon just stated, I do not think that security through obscurity is the way to go, provided the nature of this volunteering measurement platform. However, it is not all that simple, IMHO. I particularly support the idea of releasing the source code gradually, even under temporary NDAs if necessary, in order to improve the security of probe or controllers by getting the code audited by more people. Enhancing the system by introducing more features (different traceroute algorithms and options) or polishing the existing ones (IPv6 support, which is currently limited by the busybox version probes are running atm, IIRC) is something possible and desirable, if we dont forget that its Atlas itself what has to improve. I personally do not endorse the creation of further parallel, *public* measurement platforms. This is a hairy topic that guarantees a nice discussion on its own thread or meeting, but if I had to say something, I would say Atlas is doing pretty well and that a hybrid model allowing independent probes to join in a controlled fashion (as it has already been suggested) making Atlas grow... that'd be the way to go. There are way too many factors to consider here (tampering, tweaking, faking, validating the measurement results; reasearch interest in the measurements performed and archived data, how to deal with that possible variety of measurement types...) and so a single post is clearly not enough to elaborate, so... please take it with a grain of salt. Philip has been able to articulate my ideas much better than myself, so I will simply +1 his educated points: On Wed, Jan 4, 2012 at 4:45 PM, Philip Homburg wrote: > On 1/4/12 16:11 , Simon Josefsson wrote: >> >> "Richard L. Barnes" ?writes: >> >>> Analyze as you will :) >> >> One thing that strikes me from the discussion has been an absence of >> answers to this question: What would reasons be to _not_ release the >> source code? >> >> I believe that unless there is a strong reason not to release the >> source, it should be done because there is interest in it and there is >> potential to get improvements out of it. >> > There are some non-technical arguments that I won't list here. > > One argument for not releasing is security by obscurity. It is easier to > find security holes if you can just download the source. Instead of trying > to obtain a probe, getting the firmware out of it and decompiling the > binaries. In short, within RIPE NCC the question needs to be answered > whether the source can released as is, or whether a security audit is > required. Needless to say, a security audit is likely to cost money. > > Dumping the source just as a tar file on a web site is easy. But that will > be one way communication. And most likely fork the project. Not good. > +1 I couldnt be more openly against unnecessary forks. > If you want to turn it into an open source project, then a lot of stuff has > to happen. In particular, the project has to be mature enough that it can > actually be installed without too much pain. Of course, this costs time and > money. > +1 Its always good to deal with any subject around Atlas, but perhaps it is not the _optimal_ moment to release the source, to say the least. > > > > From philip.homburg at ripe.net Thu Jan 5 00:23:29 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 05 Jan 2012 00:23:29 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> Message-ID: <4F04DF71.2090101@ripe.net> On 1/4/12 17:07 , I?igo Ortiz de Urbina wrote: > As the survey shows, and as Simon just stated, I do not think that > security through obscurity is the way to go, provided the nature of > this volunteering measurement platform. However, it is not all that > simple, IMHO. > I particularly support the idea of releasing the source code > gradually, even under temporary NDAs if necessary, in order to improve > the security of probe or controllers by getting the code audited by > more people. Doing stuff under NDA is of course something completely different. > Enhancing the system by introducing more features > (different traceroute algorithms and options) or polishing the > existing ones (IPv6 support, which is currently limited by the busybox > version probes are running atm, IIRC) is something possible and > desirable, if we dont forget that its Atlas itself what has to > improve. We are not limited by any code we already have. In particular, we are not saying: we cannot do this or that because it is not in busybox. The probes are out there and we want to make the most of them. So if you have any ideas on what kind of measurements are worth doing that we currently cannot do, please let us know, in particular, make sure that Vesna or Ann keep track of what you want. :-) From jens.weibler at h-da.de Thu Jan 5 00:51:23 2012 From: jens.weibler at h-da.de (Jens Weibler) Date: Thu, 05 Jan 2012 00:51:23 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F04DF71.2090101@ripe.net> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> Message-ID: <4F04E5FB.7010709@h-da.de> Hi, On 05.01.2012 00:23, Philip Homburg wrote: > So if you have any ideas on what kind of measurements are worth doing > that we currently cannot do, please let us know, in particular, make > sure that Vesna or Ann keep track of what you want. :-) Test the respond-time of services like DNS and http. Maybe even checking the reply. ICMP-Echo is blocking by our central firewall :( -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Sch?fferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler at h-da.de -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4678 bytes Desc: S/MIME Cryptographic Signature URL: From tis at foobar.fi Thu Jan 5 09:14:56 2012 From: tis at foobar.fi (Tuomo Soini) Date: Thu, 5 Jan 2012 10:14:56 +0200 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F04E5FB.7010709@h-da.de> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> <4F04E5FB.7010709@h-da.de> Message-ID: <20120105101456.163e6a77@evelb.foobar.fi> > Test the respond-time of services like DNS and http. Maybe even > checking the reply. > > ICMP-Echo is blocking by our central firewall :( And some top-level dns servers block icmp echo too so stats by icmp echo are not right thing to do. dns response time would be better way to measure root dns servers. -- Tuomo Soini Foobar Linux services +358 40 5240030 Foobar Oy From inigo at infornografia.net Thu Jan 5 09:26:50 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Thu, 5 Jan 2012 09:26:50 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F04DF71.2090101@ripe.net> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> Message-ID: Morning everyone On Thu, Jan 5, 2012 at 12:23 AM, Philip Homburg wrote: > On 1/4/12 17:07 , I?igo Ortiz de Urbina wrote: >> >> As the survey shows, and as Simon just stated, I do not think that >> security through obscurity is the way to go, provided the nature of >> this volunteering measurement platform. However, it is not all that >> simple, IMHO. >> I particularly support the idea of releasing the source code >> gradually, even under temporary NDAs if necessary, in order to improve >> the security of probe or controllers by getting the code audited by >> more people. > > > Doing stuff under NDA is of course something completely different. > > >> Enhancing the system by introducing more features >> (different traceroute algorithms and options) or polishing the >> existing ones (IPv6 support, which is currently limited by the busybox >> version probes are running atm, IIRC) is something possible and >> desirable, if we dont forget that its Atlas itself what has to >> improve. > > > We are not limited by any code we already have. In particular, we are not > saying: we cannot do this or that because it is not in busybox. The probes > are out there and we want to make the most of them. > This is good to hear. I was meaning that according to the FAQ, there seems to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q: I have an IPv6-only network. Will the probe work on it? A: Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure. The measurements themselves can run on IPv6. " > So if you have any ideas on what kind of measurements are worth doing that > we currently cannot do, please let us know, in particular, make sure that > Vesna or Ann keep track of what you want. :-) > Sure, so far they both have been very kind and responsive to user feedback :-) But, as Jens already jumped in, I want to support his comments on adding DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the user experience is degraded due to HTTP, DNS response times themselves, and not the latency. From philip.homburg at ripe.net Thu Jan 5 13:00:45 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 05 Jan 2012 13:00:45 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F04E5FB.7010709@h-da.de> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> <4F04E5FB.7010709@h-da.de> Message-ID: <4F0590ED.9050601@ripe.net> On 1/5/12 0:51 , Jens Weibler wrote: > Hi, > > On 05.01.2012 00:23, Philip Homburg wrote: >> So if you have any ideas on what kind of measurements are worth doing >> that we currently cannot do, please let us know, in particular, make >> sure that Vesna or Ann keep track of what you want. :-) > > Test the respond-time of services like DNS and http. Maybe even > checking the reply. > The probe firmware can do that already :-) The problem with DNS is that switching would break the historical continuity (for the measurements of the DNS root servers). For UDM, it depends on when there is time to add more features. Enabling http in UDM has a security risk, so that will take even more time. From philip.homburg at ripe.net Thu Jan 5 13:11:21 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 05 Jan 2012 13:11:21 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> Message-ID: <4F059369.1060701@ripe.net> On 1/5/12 9:26 , I?igo Ortiz de Urbina wrote: > This is good to hear. I was meaning that according to the FAQ, there > seems to be something around IPv6 (not affecting ping6 or > traceroute6). See: " Q: I have an IPv6-only network. Will the probe > work on it? A: Although the probe itself is IPv6-ready in general, > some of the off-the-shelf software components on it are not (yet). We > hope that this will be resolved soon, but until then the probe needs > IPv4 to communicate with our infrastructure. The measurements > themselves can run on IPv6. " The main limiting factor is DNS. For static configurations it should work. For normal (dynamic) configuration, the problem is that we have no support for either DHCPv6 or the DNS resolver option in RA. So without IPv4, the probe will not have a DNS resolver. But I guess the FAQ needs to be updated to say that it can be made to work with static configuration. > But, as Jens already jumped in, I want to support his comments on > adding DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the > user experience is degraded due to HTTP, DNS response times > themselves, and not the latency. For DNS it is just a matter of adding it to the user interface. Http requires a policy decision on how to avoid getting probe hosts in trouble. From inigo at infornografia.net Thu Jan 5 14:25:47 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Thu, 5 Jan 2012 14:25:47 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F059369.1060701@ripe.net> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> <4F059369.1060701@ripe.net> Message-ID: On Thu, Jan 5, 2012 at 1:11 PM, Philip Homburg wrote: > On 1/5/12 9:26 , I?igo Ortiz de Urbina wrote: >> >> This is good to hear. I was meaning that according to the FAQ, there seems >> to be something around IPv6 (not affecting ping6 or traceroute6). See: " Q: >> I have an IPv6-only network. Will the probe work on it? A: Although the >> probe itself is IPv6-ready in general, some of the off-the-shelf software >> components on it are not (yet). We hope that this will be resolved soon, but >> until then the probe needs IPv4 to communicate with our infrastructure. The >> measurements themselves can run on IPv6. " > > The main limiting factor is DNS. For static configurations it should work. > > For normal (dynamic) configuration, the problem is that we have no support > for either DHCPv6 or the DNS resolver option in RA. > So without IPv4, the probe will not have a DNS resolver. > > But I guess the FAQ needs to be updated to say that it can be made to work > with static configuration. > Thank you so much for making these points clear. I'd like to suggest this addition to the FAQ, it can be used as a draft to start from: " Although the probe itself is IPv6-ready in general, some of the off-the-shelf software components on it are not (yet). More particularly, current firmware does not support DHCPv6 (RFC3345) or DNS resolver option in RA (RFC6106) and thus no way of dynamically acquiring DNS information to function properly. We hope that this will be resolved soon, but until then the probe needs IPv4 to communicate with our infrastructure, unless full IPv6 configuration is performed manually. The measurements themselves can run on IPv6. " >> But, as Jens already jumped in, I want to support his comments on adding >> DNS or HTTP checks. Sometimes ICMP cant be unfiltered, or the user >> experience is degraded due to HTTP, DNS response times themselves, and not >> the latency. > > For DNS it is just a matter of adding it to the user interface. Http > requires a policy decision on how to avoid getting probe hosts in trouble. > My particular use case would require HTTP probing first, rather than DNS probing. Both of them are interesting for many scenarios, though. Have a nice day, From jens.weibler at h-da.de Thu Jan 5 14:46:11 2012 From: jens.weibler at h-da.de (Jens Weibler) Date: Thu, 05 Jan 2012 14:46:11 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F059369.1060701@ripe.net> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <4F04DF71.2090101@ripe.net> <4F059369.1060701@ripe.net> Message-ID: <4F05A9A3.40401@h-da.de> Hi, On 05.01.2012 13:11, Philip Homburg wrote: > On 1/5/12 9:26 , I?igo Ortiz de Urbina wrote: > > This is good to hear. I was meaning that according to the FAQ, > > there seems to be something around IPv6 (not affecting ping6 or > > traceroute6). See: " Q: I have an IPv6-only network. Will the probe > > work on it? A: Although the probe itself is IPv6-ready in general, > > some of the off-the-shelf software components on it are not (yet). > > We hope that this will be resolved soon, but until then the probe > > needs IPv4 to communicate with our infrastructure. The measurements > > themselves can run on IPv6. " > The main limiting factor is DNS. For static configurations it should > work. > > For normal (dynamic) configuration, the problem is that we have no > support for either DHCPv6 or the DNS resolver option in RA. So > without IPv4, the probe will not have a DNS resolver. maybe while waiting for an implementation of dhcpv6 or dns option in RA for the nodes you could simple use |fec0:0:0:ffff::1 as fallback. Well, it's deprecated but used in a well known OS.. Just an idea, no need for me - I've got ipv4+ipv6 for my node ;) |// -- Jens Weibler IT-Services Hochschule Darmstadt www.h-da.de University of Applied Sciences Fachbereich Informatik www.fbi.h-da.de Sch?fferstr. 8b D-64295 Darmstadt Tel +49 6151 16-8425 Fax +49 6151 16-8935 jens.weibler at h-da.de -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4678 bytes Desc: S/MIME Cryptographic Signature URL: From bortzmeyer at nic.fr Thu Jan 5 15:46:54 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 5 Jan 2012 15:46:54 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <4F0473FF.10006@ripe.net> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> Message-ID: <20120105144654.GB23502@nic.fr> On Wed, Jan 04, 2012 at 04:45:03PM +0100, Philip Homburg wrote a message of 33 lines which said: > Dumping the source just as a tar file on a web site is easy. But > that will be one way communication. And most likely fork the > project. Not good. That's a very strange argument. Nobody asked the RIPE-NCC to spend money and time on doing a perfect tarball, complete with correct README, INSTALL and Makefile (or configure.ac). Yes, just dump the source, it will be a good step in the right direction and it will help in at least one use case (learn how the box works). One of the alternatives, Grenouille , is currently at this step (code, zero doc). The argument about the fork is also very 20th century. The entire point of free software is the ability to use it... freely and of course this freedom implies the right to fork (whether it is a good idea or not is a separate topic). > If you want to turn it into an open source project, then a lot of > stuff has to happen. No. > In particular, the project has to be mature enough that it can > actually be installed without too much pain. No. Nobody requested a perfect system. From bortzmeyer at nic.fr Thu Jan 5 15:49:26 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 5 Jan 2012 15:49:26 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> Message-ID: <20120105144926.GC23502@nic.fr> On Wed, Jan 04, 2012 at 05:07:10PM +0100, I?igo Ortiz de Urbina wrote a message of 81 lines which said: > I personally do not endorse the creation of further parallel, *public* > measurement platforms. They already exist (SamKnows, Grenouille, Bismark) so what's the point? Whether you endorse it or not, it happens. I am involved in a national measurement project in France and Atlas is considered for the implementation but, of course, not being able to modify Atlas is a no-no. From daniel.karrenberg at ripe.net Thu Jan 5 15:59:08 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 5 Jan 2012 15:59:08 +0100 Subject: [atlas] Survey results on Atlas open-sourcing In-Reply-To: <20120105144926.GC23502@nic.fr> References: <87fwfvlczc.fsf@latte.josefsson.org> <4F0473FF.10006@ripe.net> <20120105144926.GC23502@nic.fr> Message-ID: <93BB95B8-D56B-4EC8-9263-A180581BB9A1@ripe.net> On 05.01.2012, at 15:49, Stephane Bortzmeyer wrote: > On Wed, Jan 04, 2012 at 05:07:10PM +0100, > I?igo Ortiz de Urbina wrote > a message of 81 lines which said: > >> I personally do not endorse the creation of further parallel, *public* >> measurement platforms. > > They already exist (SamKnows, Grenouille, Bismark) so what's the > point? Whether you endorse it or not, it happens. I am involved in a > national measurement project in France > > and Atlas is considered for the implementation but, of course, not > being able to modify Atlas is a no-no. Stephane, while we are not ready to open-source RIPE Atlas we are very interested to cooperate with initiatives like this provided that the data gathered is shared for the benefit of the RIPE community. Of course such cooperation can very well include transfer or exchange of technology. But we have to be sure that the RIPE community benefits from the cooperation. Maybe we should discuss this further privately? Cordialment Daniel NB: I believe in open software and I have been contributing before the term even existed. But that does not mean that it useful in all cases at all times. From kyriacos at sakkas.eu Fri Jan 27 13:33:21 2012 From: kyriacos at sakkas.eu (Kyriacos Sakkas) Date: Fri, 27 Jan 2012 14:33:21 +0200 Subject: [atlas] Possible issue with DNS/tests getting stuck? Message-ID: <4F229991.6030609@sakkas.eu> Dear all, I have a statically configured probe, FW version 4270. If the internet connection goes down/flaps the probe seems to get confused and stops communicating (is shown as Down) even when the connection is back up and stable, but can actually be pinged etc from inside and outside my network fine. I have a second probe that is on DHCP (FW 4280) on a different network, this one seems not to have the same issue, don't know which is the important differentiator. Wondering if anyone has similar issues and a solution other than switch it off and on again. Thanks to All, Kyriacos From philip.homburg at ripe.net Fri Jan 27 13:53:45 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 27 Jan 2012 13:53:45 +0100 Subject: [atlas] Possible issue with DNS/tests getting stuck? In-Reply-To: <4F229991.6030609@sakkas.eu> References: <4F229991.6030609@sakkas.eu> Message-ID: <4F229E59.1050402@ripe.net> On 1/27/12 13:33 , Kyriacos Sakkas wrote: > > I have a statically configured probe, FW version 4270. If the internet > connection goes down/flaps the probe seems to get confused and stops > communicating (is shown as Down) even when the connection is back up and > stable, but can actually be pinged etc from inside and outside my > network fine. > > I have a second probe that is on DHCP (FW 4280) on a different network, > this one seems not to have the same issue, don't know which is the > important differentiator. > > Wondering if anyone has similar issues and a solution other than switch > it off and on again. > > Firmware version 4270 has an issue where if the connection to the controller goes down, it may not come back until the probe reboots. This fixed in 4280. It looks like your probe is now upgrading to 4280. Philip Homburg ps. it helps if you list probe ids when talking about specific probes. It saves me the time to figure out who you are and what probes you own. From kyriacos at sakkas.eu Fri Jan 27 13:57:36 2012 From: kyriacos at sakkas.eu (Kyriacos Sakkas) Date: Fri, 27 Jan 2012 14:57:36 +0200 Subject: [atlas] Possible issue with DNS/tests getting stuck? In-Reply-To: <4F229E59.1050402@ripe.net> References: <4F229991.6030609@sakkas.eu> <4F229E59.1050402@ripe.net> Message-ID: <4F229F40.60908@sakkas.eu> On 27/01/2012 14:53, Philip Homburg wrote: > On 1/27/12 13:33 , Kyriacos Sakkas wrote: >> >> I have a statically configured probe, FW version 4270. If the internet >> connection goes down/flaps the probe seems to get confused and stops >> communicating (is shown as Down) even when the connection is back up and >> stable, but can actually be pinged etc from inside and outside my >> network fine. >> >> I have a second probe that is on DHCP (FW 4280) on a different network, >> this one seems not to have the same issue, don't know which is the >> important differentiator. >> >> Wondering if anyone has similar issues and a solution other than switch >> it off and on again. >> >> > Firmware version 4270 has an issue where if the connection to the > controller goes down, it may not come back until the probe reboots. > This fixed in 4280. It looks like your probe is now upgrading to 4280. > > Philip Homburg > > ps. it helps if you list probe ids when talking about specific probes. > It saves me the time to figure out who you are and what probes you own. Thanks for the info. Will include probe ids in the future, was unsure of the protocol. No been on the mailing list long. Kyriacos Sakkas