From rm at romanrm.ru Thu Feb 2 17:01:57 2012 From: rm at romanrm.ru (Roman Mamedov) Date: Thu, 2 Feb 2012 22:01:57 +0600 Subject: [atlas] Transfer graphs Message-ID: <20120202220157.04e3dde8@natsu> Hello, Is there any logic in the placement of the upper two graphs? http://ompldr.org/vY2xhZQ/2012-02-02T155731Z-atlas.png Looks like they were dropped randomly somewhere onto the page, without any concern of how they would fit with the rest of the content. -- 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 daniel.karrenberg at ripe.net Thu Feb 2 17:30:23 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 2 Feb 2012 17:30:23 +0100 Subject: [atlas] Transfer graphs In-Reply-To: <20120202220157.04e3dde8@natsu> References: <20120202220157.04e3dde8@natsu> Message-ID: Must be browser specific. My rendering: On 02.02.2012, at 17:01, Roman Mamedov wrote: > Hello, > > Is there any logic in the placement of the upper two graphs? > http://ompldr.org/vY2xhZQ/2012-02-02T155731Z-atlas.png > Looks like they were dropped randomly somewhere onto the page, without any > concern of how they would fit with the rest of the content. > > -- > 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 -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2012-02-02 at 17.28.41.png Type: image/png Size: 228113 bytes Desc: not available URL: From inigo at infornografia.net Thu Feb 2 17:36:37 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Thu, 2 Feb 2012 17:36:37 +0100 Subject: [atlas] Transfer graphs In-Reply-To: References: <20120202220157.04e3dde8@natsu> Message-ID: On Thu, Feb 2, 2012 at 5:30 PM, Daniel Karrenberg < daniel.karrenberg at ripe.net> wrote: > Must be browser specific. My rendering: > > > On 02.02.2012, at 17:01, Roman Mamedov wrote: > > Hello, > > Is there any logic in the placement of the upper two graphs? > http://ompldr.org/vY2xhZQ/2012-02-02T155731Z-atlas.png > Looks like they were dropped randomly somewhere onto the page, without any > concern of how they would fit with the rest of the content. > > -- > With respect, > Roman > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > "Stallman had a printer, > with code he could not see. > So he began to tinker, > and set the software free." > > > I am experiencing the same graph layout problems Roman has pointed out, at least from my current location. Running Windows XP and Chrome v16.0.912.77. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2012-02-02 at 17.28.41.png Type: image/png Size: 228113 bytes Desc: not available URL: From astrikos at ripe.net Thu Feb 2 18:03:48 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Thu, 02 Feb 2012 18:03:48 +0100 Subject: [atlas] Transfer graphs In-Reply-To: <20120202220157.04e3dde8@natsu> References: <20120202220157.04e3dde8@natsu> Message-ID: <4F2AC1F4.3080202@ripe.net> Hello, Although we tested in several environments we never saw it before. We will check it. In the meantime it would useful to tell us also your OS and browser versions. Regards, Andreas On 2/2/12 5:01 PM, Roman Mamedov wrote: > Hello, > > Is there any logic in the placement of the upper two graphs? > http://ompldr.org/vY2xhZQ/2012-02-02T155731Z-atlas.png > Looks like they were dropped randomly somewhere onto the page, without any > concern of how they would fit with the rest of the content. > From astrikos at ripe.net Fri Feb 3 11:48:31 2012 From: astrikos at ripe.net (Andreas Strikos) Date: Fri, 03 Feb 2012 11:48:31 +0100 Subject: [atlas] Transfer graphs In-Reply-To: <20120202220157.04e3dde8@natsu> References: <20120202220157.04e3dde8@natsu> Message-ID: <4F2BBB7F.1000203@ripe.net> Hi, Problem with the layout should be fixed now for all of you. It was a mistake from our side that we couldn't catch on time because usually we connect with our admin accounts. In addition, today we are doing some internal maintenance and some graphs for some probes might not be accessible. In the next hours we expect to finish and everything will be back to normal. Sorry for any inconvenience. Regards, Andreas On 2/2/12 5:01 PM, Roman Mamedov wrote: > Hello, > > Is there any logic in the placement of the upper two graphs? > http://ompldr.org/vY2xhZQ/2012-02-02T155731Z-atlas.png > Looks like they were dropped randomly somewhere onto the page, without any > concern of how they would fit with the rest of the content. > From pavelveselovskiy at gmail.com Sat Feb 4 13:48:59 2012 From: pavelveselovskiy at gmail.com (Pavel V. Veselovskiy) Date: Sat, 4 Feb 2012 16:48:59 +0400 Subject: [atlas] Tweaking RRDs for built-in measurements UPDATE Message-ID: Hello, For our purposes, we use RRD image generator and get plots from the different probes. We used the recommendations that described on this page: http://atlas.ripe.net/doc/api . We found, that this information is not actual. So we would like to suggest you to update it: ? probe ID < 500: zpm01.atlas.ripe.net. ? probe ID >= 500 and probe ID < 1000: zpm02.atlas.ripe.net. ? probe ID >= 1000 and probe ID < 2000: zpm03.atlas.ripe.net. ? probe ID >= 2000 and probe ID < 3000: zpm04.atlas.ripe.net. In addition, it would be nice if the page with the documentation will contain more extensive and detailed information about the API. -- Thanks in advance & Best Regards -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- Pavel Veselovskiy Email: pavelveselovskiy at gmail.com Phone: +7 927 686 12 32 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Sun Feb 5 11:45:43 2012 From: robert at ripe.net (Robert Kisteleki) Date: Sun, 05 Feb 2012 11:45:43 +0100 Subject: [atlas] Tweaking RRDs for built-in measurements UPDATE In-Reply-To: References: Message-ID: <4F2E5DD7.8020507@ripe.net> Hello, On 2012.02.04. 13:48, Pavel V. Veselovskiy wrote: > Hello, > For our purposes, we use RRD image generator and get plots from the > different probes. We used the recommendations that described on this page: > http://atlas.ripe.net/doc/api . > We found, that this information is not actual. So we would like to suggest > you to update it: > ? probe ID < 500: zpm01.atlas.ripe.net . > ? probe ID >= 500 and probe ID < 1000: zpm02.atlas.ripe.net > . > ? probe ID >= 1000 and probe ID < 2000: zpm03.atlas.ripe.net > . > ? probe ID >= 2000 and probe ID < 3000: zpm04.atlas.ripe.net > . Nice catch. We've reshuffled this distribution on Thursday-Friday, and did not update the documentation page then. Now it should be up to date again -- with almost exactly what you wrote above. > In addition, it would be nice if the page with the documentation will > contain more extensive and detailed information about the API. Recently we developed some APIs that are used to provide more information to the UI. Also, the more interactive the system becomes (especially with User Defined Measurements) the more APIs we'll expose. We'll add descriptions of these to the documentation. Regards, Robert > -- > Thanks in advance > & Best Regards > > -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- > Pavel Veselovskiy > Email: pavelveselovskiy at gmail.com > Phone: +7 927 686 12 32 > From richardmcraven at googlemail.com Sun Feb 5 23:57:28 2012 From: richardmcraven at googlemail.com (Richard Craven) Date: Sun, 05 Feb 2012 22:57:28 +0000 Subject: [atlas] Minor spelling error on probe settings popup In-Reply-To: <33552045.4396261328360094903.JavaMail.root@opayq.com> References: <33552045.4396261328360094903.JavaMail.root@opayq.com> Message-ID: <4F2F0958.3030106@gmail.com> Hello Looking at http://atlas.ripe.net/atlas/myprobes.html and going to Probe's settings | notifications, it says "if downtime longer then (minutes):" but it should say "if downtime longer than (minutes):" "than", instead of "then". Best wishes From vnaumov at ripe.net Mon Feb 6 11:03:49 2012 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 06 Feb 2012 11:03:49 +0100 Subject: [atlas] Tweaking RRDs for built-in measurements UPDATE In-Reply-To: <4F2E5DD7.8020507@ripe.net> References: <4F2E5DD7.8020507@ripe.net> Message-ID: <4F2FA585.1090607@ripe.net> Hi Pavel, The actual shards data for your automation you can get from http://atlas.ripe.net/atlas/myprobes.html page This is in the Atlas.ShardFix() function: Atlas.ShardFix= function(prb_id) { varsn= Math.floor(prb_id/100)+""; vars= { "0": "http://zpm01.atlas.ripe.net", "1": "http://zpm01.atlas.ripe.net", "2": "http://zpm01.atlas.ripe.net", "3": "http://zpm01.atlas.ripe.net", "4": "http://zpm01.atlas.ripe.net", "5": "http://zpm02.atlas.ripe.net", "6": "http://zpm02.atlas.ripe.net", "7": "http://zpm02.atlas.ripe.net", "8": "http://zpm02.atlas.ripe.net", "9": "http://zpm02.atlas.ripe.net", "10": "http://zpm03.atlas.ripe.net", "11": "http://zpm03.atlas.ripe.net", "12": "http://zpm03.atlas.ripe.net", "13": "http://zpm03.atlas.ripe.net", "14": "http://zpm03.atlas.ripe.net", "15": "http://zpm03.atlas.ripe.net", "20": "http://zpm04.atlas.ripe.net", "21": "http://zpm04.atlas.ripe.net", "22": "http://zpm04.atlas.ripe.net", "23": "http://zpm04.atlas.ripe.net", "24": "http://zpm04.atlas.ripe.net" }; return(snins? s[sn] : ''); } In near future we will implement a Ajax call for that if people want. Best regards Viktor On 2/5/12 11:45 AM, Robert Kisteleki wrote: > Hello, > > On 2012.02.04. 13:48, Pavel V. Veselovskiy wrote: >> Hello, >> For our purposes, we use RRD image generator and get plots from the >> different probes. We used the recommendations that described on this page: >> http://atlas.ripe.net/doc/api . >> We found, that this information is not actual. So we would like to suggest >> you to update it: >> ? probe ID< 500: zpm01.atlas.ripe.net. >> ? probe ID>= 500 and probe ID< 1000: zpm02.atlas.ripe.net >> . >> ? probe ID>= 1000 and probe ID< 2000: zpm03.atlas.ripe.net >> . >> ? probe ID>= 2000 and probe ID< 3000: zpm04.atlas.ripe.net >> . > Nice catch. We've reshuffled this distribution on Thursday-Friday, and did > not update the documentation page then. Now it should be up to date again -- > with almost exactly what you wrote above. > >> In addition, it would be nice if the page with the documentation will >> contain more extensive and detailed information about the API. > Recently we developed some APIs that are used to provide more information to > the UI. Also, the more interactive the system becomes (especially with User > Defined Measurements) the more APIs we'll expose. > > We'll add descriptions of these to the documentation. > > Regards, > Robert > >> -- >> Thanks in advance >> & Best Regards >> >> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.- >> Pavel Veselovskiy >> Email: pavelveselovskiy at gmail.com >> Phone: +7 927 686 12 32 >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-atlas at darstelecom.ru Mon Feb 6 12:19:43 2012 From: ripe-atlas at darstelecom.ru (Konstantin V Bekreyev) Date: Mon, 06 Feb 2012 15:19:43 +0400 Subject: [atlas] New measurement target suggestion: 6to4 anycast Message-ID: <4F2FB74F.8050606@darstelecom.ru> Hello, Please inform me your decision about this interesting matter: >> 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; >> >> 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. > 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. Maybe we'll see some interesting results before June 6. Could you add it, please? -- With best regards, Konstantin V Bekreyev (CVB-RIPE) DARS Telecom (AS43782), Ulyanovsk, Russia From registrations at sardone.org Sat Feb 11 18:53:58 2012 From: registrations at sardone.org (Software Registrations) Date: Sat, 11 Feb 2012 18:53:58 +0100 Subject: [atlas] Probe DNS entry A more useful than AAAA for dynamic IP hosts Message-ID: Hello everybody, I have just received and put in service my probe. This is my first post to the list (I have been monitoring the traffic for a while: none). I wish to take the chance to admire the design and compact packaging ! Great work! Back on topic, for us low-lies with dynamic IP addresses using the probe DNS entry (maybe with a CNAME entry) could be a great way to ensure our Dynamic DNS entries are up to date and our network could be reached from remote. I am running a full IPv6 network receiving a /48 from Hurricane Electric and the probe tend to select (at least in my short experience) the autoconfigure (from MAC) IPv6 address as its Internet Address to use in the DNS record: fabio at atlantic:~$ host -t A pdxxxxx.probes.atlas.ripe.net pd456a699.probes.atlas.ripe.net has no A record fabio at atlantic:~$ host -t AAAA pdxxxxx.probes.atlas.ripe.net pd456a699.probes.atlas.ripe.net has IPv6 address 2001:470:xxxx:2:220:4aff:fee0:xxxx fabio at atlantic:~$ I saw that there are plans (in the FAQ) to add support both for AAAA and A records at the same time but I believe it would be beneficial for users to be able to select which record is generated or have the A record as default while waiting for the support for both to be implemented. Thanks for listening. Fabio From daniel at sokolov.eu.org Sun Feb 12 07:00:47 2012 From: daniel at sokolov.eu.org (Daniel AJ Sokolov) Date: Sun, 12 Feb 2012 02:00:47 -0400 Subject: [atlas] Protocol/Technology testing? Message-ID: <4F37558F.8090007@sokolov.eu.org> Hello, Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? For example: Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? Is encryption available (https, ssh, starttls, etc.)? Some countries and/or ISPs restrict what users can do. Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. Then again, the probes might not be mighty enough? BR Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik From fred at cisco.com Mon Feb 13 04:22:29 2012 From: fred at cisco.com (Fred Baker) Date: Sun, 12 Feb 2012 22:22:29 -0500 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <4F37558F.8090007@sokolov.eu.org> References: <4F37558F.8090007@sokolov.eu.org> Message-ID: <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> Question for you: RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: > Hello, > > Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? > > For example: > Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? > Is encryption available (https, ssh, starttls, etc.)? > > Some countries and/or ISPs restrict what users can do. > > Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! > > Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) > > It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. > > Then again, the probes might not be mighty enough? > > BR > Daniel AJ > > -- > Follow me on twitter @newstik http://twitter.com/newstik > From philip.homburg at ripe.net Mon Feb 13 11:06:47 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 13 Feb 2012 11:06:47 +0100 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <4F37558F.8090007@sokolov.eu.org> References: <4F37558F.8090007@sokolov.eu.org> Message-ID: <4F38E0B7.8030809@ripe.net> On 2/12/12 7:00 , Daniel AJ Sokolov wrote: > > Are there any plans to extend the Atlas probe's functionality from > simple Pings to more sophisticated testing? > At the moment, probes do pings, traceroutes and DNS queries. > For example: > Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and > with which parameters? There is support in the probe firmware for doing more, but it is not enabled in User Defined Measurements. For http it is an open issue whether that is safe. We haven't really thought about ftp, smtp, nttp. > Is encryption available (https, ssh, starttls, etc.)? > Probes use ssh to connect to the Atlas infrastructure, but there are no measurements that try to set up an encrypted channel. > Some countries and/or ISPs restrict what users can do. > > Currently, Iran is inhibiting all encrypted international connection. > For the users on the ground this is horrible - no gmail, no yahoo, no > online banking, no Tor network - no proivacy! > > Yet on the Atlas network everything seems to be fine, as pings still > work. (However, only one of the six probes is online, the rest has > been offline for weeks. And the one that is online was offline for > weeks until a few days ago. I'm not sure what the issue is there.) > Atlas is not fine. Last time I looked (early this year), all probes in Iran were unable to connect to the infrastructure. They can do measurements, but they cannot report their results over ssh. I'm amazed that one is now connected again. > It would be good to know if some protocols are not available in a > certain jurisdiction. Of course, such tests could be done at a much > lower rate than Pings - some maybe every hour, others every couple of > hours. > Are there more countries than Iran that have this issue? (We implicitly measure ssh, and that doesn't seem to an issue except in Iran) From philip.homburg at ripe.net Mon Feb 13 11:14:51 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 13 Feb 2012 11:14:51 +0100 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> Message-ID: <4F38E29B.1090508@ripe.net> On 2/13/12 4:22 , Fred Baker wrote: > Question for you: > > RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. > > For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. > > What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? > > At the moment, the Atlas system does not include targets with special software. We rely only on well defined protocols that are up and running on the Internet. Note that for time measurements, we could just use the ntp packet format. At the moment, the probes also do not run ntpd. The current time synchronization is in the order of seconds. So for one-way delay measurements, the first step would be to enable ntp on the probes and see if on the whole the synchronization distance is low enough that these kinds of measurements would make sense. From 58d2b8fb-9c68-41ba-8786-856d17decf29 at robert.id.au Mon Feb 13 13:08:27 2012 From: 58d2b8fb-9c68-41ba-8786-856d17decf29 at robert.id.au (Robert) Date: Mon, 13 Feb 2012 23:08:27 +1100 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <4F38E0B7.8030809@ripe.net> References: <4F37558F.8090007@sokolov.eu.org> <4F38E0B7.8030809@ripe.net> Message-ID: Yes, there certainly are countries that block certain protocols! See here https://blog.torproject.org/blog/ - there's even a recent post on Iran. However, Iran is far from the only offender. -----Original Message----- From: ripe-atlas-bounces at ripe.net [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Philip Homburg Sent: Monday, 13 February 2012 21:07 To: ripe-atlas at ripe.net Subject: Re: [atlas] Protocol/Technology testing? On 2/12/12 7:00 , Daniel AJ Sokolov wrote: > > Are there any plans to extend the Atlas probe's functionality from > simple Pings to more sophisticated testing? > At the moment, probes do pings, traceroutes and DNS queries. > For example: > Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and > with which parameters? There is support in the probe firmware for doing more, but it is not enabled in User Defined Measurements. For http it is an open issue whether that is safe. We haven't really thought about ftp, smtp, nttp. > Is encryption available (https, ssh, starttls, etc.)? > Probes use ssh to connect to the Atlas infrastructure, but there are no measurements that try to set up an encrypted channel. > Some countries and/or ISPs restrict what users can do. > > Currently, Iran is inhibiting all encrypted international connection. > For the users on the ground this is horrible - no gmail, no yahoo, no > online banking, no Tor network - no proivacy! > > Yet on the Atlas network everything seems to be fine, as pings still > work. (However, only one of the six probes is online, the rest has > been offline for weeks. And the one that is online was offline for > weeks until a few days ago. I'm not sure what the issue is there.) > Atlas is not fine. Last time I looked (early this year), all probes in Iran were unable to connect to the infrastructure. They can do measurements, but they cannot report their results over ssh. I'm amazed that one is now connected again. > It would be good to know if some protocols are not available in a > certain jurisdiction. Of course, such tests could be done at a much > lower rate than Pings - some maybe every hour, others every couple of > hours. > Are there more countries than Iran that have this issue? (We implicitly measure ssh, and that doesn't seem to an issue except in Iran) From dan.tappan at gmail.com Mon Feb 13 14:15:25 2012 From: dan.tappan at gmail.com (Dan Tappan) Date: Mon, 13 Feb 2012 08:15:25 -0500 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> Message-ID: <4F390CED.3020500@gmail.com> On 02/12/2012 10:22 PM, Fred Baker wrote: > Question for you: > > RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. > > For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. > > What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? It's been 5 years since I thought about any of this but I think the way to parse the text in section 4 is that the ECHO Request and Reply messages fall into the category of: > Many ICMP messages are extensible as currently defined. Protocol > designers can extend ICMP messages by simply appending fields or data > structures to them. I _think_ the idea was that the existing field in the ECHO messages could be replaced with an extension structure, which would be validated using the checksum. I don't know why this wasn't spelled out more explicitly, since technically responding to or updating the extension would be in violation of the text : > The data received in the echo message must be returned in the echo > reply message. > in 792 or > Data The data from the invoking Echo Request message. in 4443 Maybe because changing that behavior would be beyond the scope of 4884. > > > On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: > >> Hello, >> >> Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? >> >> For example: >> Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? >> Is encryption available (https, ssh, starttls, etc.)? >> >> Some countries and/or ISPs restrict what users can do. >> >> Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! >> >> Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) >> >> It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. >> >> Then again, the probes might not be mighty enough? >> >> BR >> Daniel AJ >> >> -- >> Follow me on twitter @newstik http://twitter.com/newstik >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpignata at cisco.com Mon Feb 13 15:33:14 2012 From: cpignata at cisco.com (Carlos Pignataro) Date: Mon, 13 Feb 2012 09:33:14 -0500 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <4F390CED.3020500@gmail.com> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> <4F390CED.3020500@gmail.com> Message-ID: <4F391F2A.40801@cisco.com> Hi Dan, On 2/13/2012 8:15 AM, Dan Tappan wrote: > On 02/12/2012 10:22 PM, Fred Baker wrote: >> Question for you: >> >> RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. >> >> For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. >> >> What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? > > It's been 5 years since I thought about any of this but I think the way > to parse the text in section 4 is that the ECHO Request and Reply > messages fall into the category of: > >> Many ICMP messages are extensible as currently defined. Protocol >> designers can extend ICMP messages by simply appending fields or data >> structures to them. > > I _think_ the idea was that the existing field in the ECHO > messages could be replaced with an extension structure, which would be > validated using the checksum. I don't know why this wasn't spelled out > more explicitly, since technically responding to or updating the > extension would be in violation of the text : > >> The data received in the echo message must be returned in the echo >> reply message. >> > in 792 > or >> Data The data from the invoking Echo Request message. > in 4443 > > Maybe because changing that behavior would be beyond the scope of 4884. > If I remember correctly, additionally, RFC 4884 encountered pushback when we were trying to define an object extension at a fixed location, and therefore we ended up needing to add a "Length" field in the ICMP header. And since Echo / Echo Reply did not have room for a field in the ICMP header, it was out of scope for RFC 4884. Because also RFC 4884 extended error messages that were including part of the original datagram. Thanks, -- Carlos. >> >> >> On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: >> >>> Hello, >>> >>> Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? >>> >>> For example: >>> Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? >>> Is encryption available (https, ssh, starttls, etc.)? >>> >>> Some countries and/or ISPs restrict what users can do. >>> >>> Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! >>> >>> Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) >>> >>> It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. >>> >>> Then again, the probes might not be mighty enough? >>> >>> BR >>> Daniel AJ >>> >>> -- >>> Follow me on twitter @newstik http://twitter.com/newstik >>> > From cpignata at cisco.com Mon Feb 13 15:27:47 2012 From: cpignata at cisco.com (Carlos Pignataro) Date: Mon, 13 Feb 2012 09:27:47 -0500 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> Message-ID: <4F391DE3.2000102@cisco.com> Fred, That is correct, RFC 4884 does not allow the use of the extensions in Echo / Echo Reply ICMP messages. Moreover, RFC 4884 only defines the "return path" extensions. However, draft-shen-traceroute-ping-ext was attempting to do just that (among other thing or two) -- to allow extensions on a probe and ability to use them with ICMP. Thanks, -- Carlos. On 2/12/2012 10:22 PM, Fred Baker wrote: > Question for you: > > RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. > > For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. > > What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? > > > On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: > >> Hello, >> >> Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? >> >> For example: >> Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? >> Is encryption available (https, ssh, starttls, etc.)? >> >> Some countries and/or ISPs restrict what users can do. >> >> Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! >> >> Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) >> >> It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. >> >> Then again, the probes might not be mighty enough? >> >> BR >> Daniel AJ >> >> -- >> Follow me on twitter @newstik http://twitter.com/newstik >> > > From naiming at cisco.com Mon Feb 13 20:36:32 2012 From: naiming at cisco.com (Naiming Shen) Date: Mon, 13 Feb 2012 11:36:32 -0800 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <4F391DE3.2000102@cisco.com> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> <4F391DE3.2000102@cisco.com> Message-ID: <39FCD5C7-B38B-4EE9-89EB-F9D9A6EAA24B@cisco.com> thanks Carlos. attached the newer version of the draft (hasn't been posted), which is under discussion in the int-area list. Regards, - Naiming -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: trace-ping-ext-4.txt URL: -------------- next part -------------- On Feb 13, 2012, at 6:27 AM, Carlos Pignataro wrote: > Fred, > > That is correct, RFC 4884 does not allow the use of the extensions in > Echo / Echo Reply ICMP messages. Moreover, RFC 4884 only defines the > "return path" extensions. > > However, draft-shen-traceroute-ping-ext was attempting to do just that > (among other thing or two) -- to allow extensions on a probe and ability > to use them with ICMP. > > Thanks, > > -- Carlos. > > On 2/12/2012 10:22 PM, Fred Baker wrote: >> Question for you: >> >> RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, but as I read it doesn't permit the use of that structure with the Echo Request or Reply. It seems like RFC 4884 would help in this context. >> >> For example, if Atlas Probes and their servers use NTP to synchronize time, an Echo Request could contain the time the message was sent, and the service could deduce one-way delay. The response could similarly include a timestamp, the probe could calculate one-way delay, and report the time and delta-time of that response in its next request. Additionally, the service could command a probe to additionally traceroute to another probe, and the probe could later report its experience. >> >> What would it take to facilitate the use of RFC 4884 extensions with ICMP/ICMPv6? >> >> >> On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: >> >>> Hello, >>> >>> Are there any plans to extend the Atlas probe's functionality from simple Pings to more sophisticated testing? >>> >>> For example: >>> Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and with which parameters? >>> Is encryption available (https, ssh, starttls, etc.)? >>> >>> Some countries and/or ISPs restrict what users can do. >>> >>> Currently, Iran is inhibiting all encrypted international connection. For the users on the ground this is horrible - no gmail, no yahoo, no online banking, no Tor network - no proivacy! >>> >>> Yet on the Atlas network everything seems to be fine, as pings still work. (However, only one of the six probes is online, the rest has been offline for weeks. And the one that is online was offline for weeks until a few days ago. I'm not sure what the issue is there.) >>> >>> It would be good to know if some protocols are not available in a certain jurisdiction. Of course, such tests could be done at a much lower rate than Pings - some maybe every hour, others every couple of hours. >>> >>> Then again, the probes might not be mighty enough? >>> >>> BR >>> Daniel AJ >>> >>> -- >>> Follow me on twitter @newstik http://twitter.com/newstik >>> >> >> From rbonica at juniper.net Tue Feb 14 00:36:00 2012 From: rbonica at juniper.net (Ronald Bonica) Date: Mon, 13 Feb 2012 18:36:00 -0500 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> Message-ID: <13205C286662DE4387D9AF3AC30EF456D7653D83B3@EMBX01-WF.jnpr.net> Folks, Considering Daniel's initial question, I don't think that an extension to ICMP will help. Most probably, the solution is for ATLAS nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) and report results. While discussion of RFC 4884 and draft-shen was interesting, it doesn't solve Daniel's problem. Ron > -----Original Message----- > From: Fred Baker [mailto:fred at cisco.com] > Sent: Sunday, February 12, 2012 10:22 PM > To: Carlos Pignataro; Dan.Tappan at gmail.com; derhwagan at yahoo.com; Ronald > Bonica > Cc: ripe-atlas at ripe.net; Daniel AJ Sokolov > Subject: Re: [atlas] Protocol/Technology testing? > > Question for you: > > RFC 4884 says that ICMP/ICMPv6 define an Echo Request/Reply message, > but as I read it doesn't permit the use of that structure with the Echo > Request or Reply. It seems like RFC 4884 would help in this context. > > For example, if Atlas Probes and their servers use NTP to synchronize > time, an Echo Request could contain the time the message was sent, and > the service could deduce one-way delay. The response could similarly > include a timestamp, the probe could calculate one-way delay, and > report the time and delta-time of that response in its next request. > Additionally, the service could command a probe to additionally > traceroute to another probe, and the probe could later report its > experience. > > What would it take to facilitate the use of RFC 4884 extensions with > ICMP/ICMPv6? > > > On Feb 12, 2012, at 1:00 AM, Daniel AJ Sokolov wrote: > > > Hello, > > > > Are there any plans to extend the Atlas probe's functionality from > simple Pings to more sophisticated testing? > > > > For example: > > Can actual payloads be transferred (http, ftp, SMTP, NNTP etc.) and > with which parameters? > > Is encryption available (https, ssh, starttls, etc.)? > > > > Some countries and/or ISPs restrict what users can do. > > > > Currently, Iran is inhibiting all encrypted international connection. > For the users on the ground this is horrible - no gmail, no yahoo, no > online banking, no Tor network - no proivacy! > > > > Yet on the Atlas network everything seems to be fine, as pings still > work. (However, only one of the six probes is online, the rest has been > offline for weeks. And the one that is online was offline for weeks > until a few days ago. I'm not sure what the issue is there.) > > > > It would be good to know if some protocols are not available in a > certain jurisdiction. Of course, such tests could be done at a much > lower rate than Pings - some maybe every hour, others every couple of > hours. > > > > Then again, the probes might not be mighty enough? > > > > BR > > Daniel AJ > > > > -- > > Follow me on twitter @newstik http://twitter.com/newstik > > From daniel at sokolov.eu.org Tue Feb 14 04:58:05 2012 From: daniel at sokolov.eu.org (Daniel AJ Sokolov) Date: Mon, 13 Feb 2012 23:58:05 -0400 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7653D83B3@EMBX01-WF.jnpr.net> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> <13205C286662DE4387D9AF3AC30EF456D7653D83B3@EMBX01-WF.jnpr.net> Message-ID: <4F39DBCD.70801@sokolov.eu.org> On 2012-02-13 19:36 wrote Ronald Bonica: > Considering Daniel's initial question, I don't think that an > extension to ICMP will help. Most probably, the solution is for ATLAS > nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) > and report results. > > While discussion of RFC 4884 and draft-shen was interesting, it > doesn't solve Daniel's problem. Yes, thank you for pointing that out! BR Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik From robert at ripe.net Tue Feb 14 10:46:31 2012 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 14 Feb 2012 10:46:31 +0100 Subject: [atlas] Probe DNS entry A more useful than AAAA for dynamic IP hosts In-Reply-To: References: Message-ID: <4F3A2D77.7020909@ripe.net> Hello, We found that it's way easier to implement this (adding both A and AAAA, if applicable) than to change the UI. So this is done now. On a related note: we think it would be useful to add a time limit for producing these records for disconnected probes. That is, remove these entries if your probe has been down for some time, for example a week. Regards, Robert On 2012.02.11. 18:53, Software Registrations wrote: > Hello everybody, > > I have just received and put in service my probe. This is my first post to the list (I have been monitoring the traffic for a while: none). > I wish to take the chance to admire the design and compact packaging ! Great work! > > Back on topic, for us low-lies with dynamic IP addresses using the probe DNS entry (maybe with a CNAME entry) could be a great way to ensure our Dynamic DNS entries are up to date and our network could be reached from remote. > > I am running a full IPv6 network receiving a /48 from Hurricane Electric and the probe tend to select (at least in my short experience) the autoconfigure (from MAC) IPv6 address as its Internet Address to use in the DNS record: > > fabio at atlantic:~$ host -t A pdxxxxx.probes.atlas.ripe.net > pd456a699.probes.atlas.ripe.net has no A record > fabio at atlantic:~$ host -t AAAA pdxxxxx.probes.atlas.ripe.net > pd456a699.probes.atlas.ripe.net has IPv6 address 2001:470:xxxx:2:220:4aff:fee0:xxxx > fabio at atlantic:~$ > > I saw that there are plans (in the FAQ) to add support both for AAAA and A records at the same time but I believe it would be beneficial for users to be able to select which record is generated or have the A record as default while waiting for the support for both to be implemented. > > Thanks for listening. > > Fabio > From registrations at sardone.org Tue Feb 14 12:52:03 2012 From: registrations at sardone.org (Software Registrations) Date: Tue, 14 Feb 2012 12:52:03 +0100 Subject: [atlas] Probe DNS entry A more useful than AAAA for dynamic IP hosts In-Reply-To: <4F3A2D77.7020909@ripe.net> References: <4F3A2D77.7020909@ripe.net> Message-ID: <9F43C536-F1AD-4B24-8BCE-1FD885724659@sardone.org> Hello Robert, thanks for your reply but I do not understand your point about changing the UI and having A and AAAA records. I do not have A and AAAA records for my probe only AAAA. Are you saying that the probe now supports both? What firmware release are you referring to? Regards Fabio Sent from my iPad On 14/feb/2012, at 10:46, Robert Kisteleki wrote: > Hello, > > We found that it's way easier to implement this (adding both A and AAAA, if > applicable) than to change the UI. So this is done now. > > On a related note: we think it would be useful to add a time limit for > producing these records for disconnected probes. That is, remove these > entries if your probe has been down for some time, for example a week. > > Regards, > Robert > > > On 2012.02.11. 18:53, Software Registrations wrote: >> Hello everybody, >> >> I have just received and put in service my probe. This is my first post to the list (I have been monitoring the traffic for a while: none). >> I wish to take the chance to admire the design and compact packaging ! Great work! >> >> Back on topic, for us low-lies with dynamic IP addresses using the probe DNS entry (maybe with a CNAME entry) could be a great way to ensure our Dynamic DNS entries are up to date and our network could be reached from remote. >> >> I am running a full IPv6 network receiving a /48 from Hurricane Electric and the probe tend to select (at least in my short experience) the autoconfigure (from MAC) IPv6 address as its Internet Address to use in the DNS record: >> >> fabio at atlantic:~$ host -t A pdxxxxx.probes.atlas.ripe.net >> pd456a699.probes.atlas.ripe.net has no A record >> fabio at atlantic:~$ host -t AAAA pdxxxxx.probes.atlas.ripe.net >> pd456a699.probes.atlas.ripe.net has IPv6 address 2001:470:xxxx:2:220:4aff:fee0:xxxx >> fabio at atlantic:~$ >> >> I saw that there are plans (in the FAQ) to add support both for AAAA and A records at the same time but I believe it would be beneficial for users to be able to select which record is generated or have the A record as default while waiting for the support for both to be implemented. >> >> Thanks for listening. >> >> Fabio >> > From robert at ripe.net Tue Feb 14 12:56:37 2012 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 14 Feb 2012 12:56:37 +0100 Subject: [atlas] Probe DNS entry A more useful than AAAA for dynamic IP hosts In-Reply-To: <9F43C536-F1AD-4B24-8BCE-1FD885724659@sardone.org> References: <4F3A2D77.7020909@ripe.net> <9F43C536-F1AD-4B24-8BCE-1FD885724659@sardone.org> Message-ID: <4F3A4BF5.1060407@ripe.net> Hi, On 2012.02.14. 12:52, Software Registrations wrote: > Hello Robert, > > thanks for your reply but I do not understand your point about changing the UI and having A and AAAA records. > > I do not have A and AAAA records for my probe only AAAA. You do. At least, we generate them and I can see them from two different networks using simple DNS queries. > Are you saying that the probe now supports both? > What firmware release are you referring to? There's not probe firmware change needed, this is happening purely on our side. Regards, Robert > Regards > > Fabio > > Sent from my iPad From registrations at sardone.org Tue Feb 14 13:18:56 2012 From: registrations at sardone.org (Software Registrations) Date: Tue, 14 Feb 2012 13:18:56 +0100 Subject: [atlas] Probe DNS entry A more useful than AAAA for dynamic IP hosts In-Reply-To: <4F3A4BF5.1060407@ripe.net> References: <4F3A2D77.7020909@ripe.net> <9F43C536-F1AD-4B24-8BCE-1FD885724659@sardone.org> <4F3A4BF5.1060407@ripe.net> Message-ID: <1D87CFBA-4C39-47A0-999E-C129AE387DCC@sardone.org> Hi Robert, thanks for your reply once again. I did a lookup both using the host commando (both with -t A and -t AAAA options) and you can see that my host (wich is running bind recursively for my network using root nameservers) returns the lack of the A record for my probe. I then used dig (@localhost) with same result. Right now trying from on-line services DNS returns error both fro AAAA and A records. Once I will go back home I will check again against different nameservers. Any particular one recommanded? Also I would seggest updating the news reflecting that now the probes have both A and AAAA records, it still shows as future implementation there. Cheers Fabio Sent from my iPad On 14/feb/2012, at 12:56, Robert Kisteleki wrote: > Hi, > > On 2012.02.14. 12:52, Software Registrations wrote: >> Hello Robert, >> >> thanks for your reply but I do not understand your point about changing the UI and having A and AAAA records. >> >> I do not have A and AAAA records for my probe only AAAA. > > You do. At least, we generate them and I can see them from two different > networks using simple DNS queries. > >> Are you saying that the probe now supports both? >> What firmware release are you referring to? > > There's not probe firmware change needed, this is happening purely on our side. > > Regards, > Robert > >> Regards >> >> Fabio >> >> Sent from my iPad From daniel at sokolov.eu.org Wed Feb 15 02:39:48 2012 From: daniel at sokolov.eu.org (Daniel AJ Sokolov) Date: Tue, 14 Feb 2012 21:39:48 -0400 Subject: [atlas] Protocol/Technology testing? In-Reply-To: <13205C286662DE4387D9AF3AC30EF456D7653D83B3@EMBX01-WF.jnpr.net> References: <4F37558F.8090007@sokolov.eu.org> <63A29A2D-CD48-42A2-9176-8E66B9F3F3A5@cisco.com> <13205C286662DE4387D9AF3AC30EF456D7653D83B3@EMBX01-WF.jnpr.net> Message-ID: <4F3B0CE4.4030307@sokolov.eu.org> On 2012-02-13 19:36 wrote Ronald Bonica: > Folks, > > Considering Daniel's initial question, I don't think that an > extension to ICMP will help. Most probably, the solution is for ATLAS > nodes to send a more diverse mix of traffic (ICMP, HTTP, HTTPS IPSEC) > and report results. > > While discussion of RFC 4884 and draft-shen was interesting, it > doesn't solve Daniel's problem. BTW, my article on the Iran situation has been translated into English: http://www.h-online.com/security/news/item/Reports-Iran-disrupts-secure-internet-connections-Update-1433341.html FYI Daniel AJ From Woeber at CC.UniVie.ac.at Wed Feb 15 14:55:00 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Wed, 15 Feb 2012 13:55:00 +0000 Subject: [atlas] OT(?) SamKnows/EC Test Project Message-ID: <4F3BB934.9020704@CC.UniVie.ac.at> Maybe this is a tad off-topic, but maybe not... Has anyone been able to get in touch with a human being (over eMail) regarding the participation in their measurement project? Any and all of my attempts till now failed miserably, they just keep sending me reminders to accept their fine print; and I am just about to pull out/unsubscribe. Any input or advice gratefully accepted. Best regards, Wilfried. From bortzmeyer at nic.fr Wed Feb 15 15:12:43 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 15 Feb 2012 15:12:43 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <4F3BB934.9020704@CC.UniVie.ac.at> References: <4F3BB934.9020704@CC.UniVie.ac.at> Message-ID: <20120215141243.GA29169@nic.fr> On Wed, Feb 15, 2012 at 01:55:00PM +0000, Wilfried Woeber, UniVie/ACOnet wrote a message of 14 lines which said: > Has anyone been able to get in touch with a human being (over eMail) > regarding the participation in their measurement project? Yes, I did (filled in the form on their web site and got a reply, then several messages exchanged). From bwijnen at ripe.net Wed Feb 15 15:52:02 2012 From: bwijnen at ripe.net (Bert Wijnen) Date: Wed, 15 Feb 2012 15:52:02 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <20120215141243.GA29169@nic.fr> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> Message-ID: <4F3BC692.4070505@ripe.net> On 2/15/12 3:12 PM, Stephane Bortzmeyer wrote: > On Wed, Feb 15, 2012 at 01:55:00PM +0000, > Wilfried Woeber, UniVie/ACOnet wrote > a message of 14 lines which said: > >> Has anyone been able to get in touch with a human being (over eMail) >> regarding the participation in their measurement project? > > Yes, I did (filled in the form on their web site and got a reply, then > several messages exchanged). > Same here. And then I got a final one where I needed to accept all their rule. I asked "how can I be sure that your devices does not capture/steal my data?". They gave me access to their source. So I can check what their code does. So then I agreed and then received the device a week or two later. I can not (or at least have not been told how to) pickup their code, compile it and install it on their device, so that I am sure that the code that I inspect is indeed the code that is running. Anyway, so I have received a device. Still have to install it though. Bert From marco.davids at sidn.nl Wed Feb 15 15:43:56 2012 From: marco.davids at sidn.nl (Marco Davids (SIDN)) Date: Wed, 15 Feb 2012 15:43:56 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <20120215141243.GA29169@nic.fr> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> Message-ID: <4F3BC4AC.8000200@sidn.nl> On 02/15/12 15:12, Stephane Bortzmeyer wrote: > On Wed, Feb 15, 2012 at 01:55:00PM +0000, > Wilfried Woeber, UniVie/ACOnet wrote > a message of 14 lines which said: > >> Has anyone been able to get in touch with a human being (over eMail) >> regarding the participation in their measurement project? > Yes, I did (filled in the form on their web site and got a reply, then > several messages exchanged). > > > Stephane, I too exchanged several messages, but the replies seemed automated. In any case I haven't 100% confirmed an interaction with a human being. Did you receive your SamKnows box already btw? (I haven't) Regards, -- Marco From bortzmeyer at nic.fr Wed Feb 15 16:24:25 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 15 Feb 2012 16:24:25 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <4F3BC4AC.8000200@sidn.nl> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> Message-ID: <20120215152425.GA6264@nic.fr> On Wed, Feb 15, 2012 at 03:43:56PM +0100, Marco Davids (SIDN) wrote a message of 24 lines which said: > I too exchanged several messages, but the replies seemed > automated. In any case I haven't 100% confirmed an interaction with > a human being. In my case, the other party passed the Turing test. > Did you receive your SamKnows box already btw? No. From patrick at vande-walle.eu Wed Feb 15 18:02:06 2012 From: patrick at vande-walle.eu (Patrick Vande Walle) Date: Wed, 15 Feb 2012 18:02:06 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <4F3BC4AC.8000200@sidn.nl> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> Message-ID: <4F3BE50E.1060405@vande-walle.eu> On 15/02/12 15:43, Marco Davids (SIDN) wrote: > I too exchanged several messages, but the replies seemed automated. In > any case I haven't 100% confirmed an interaction with a human being. > Did you receive your SamKnows box already btw? (I haven't) Marco, I received mine a few days before Christmas. More or less 3 weeks after I applied. I did have some email exchanges with a human being when I enquired for more details about which tests they performed and how. They did not go into the details, though. If anyone is interested, i can share more info offlistn, in order not to spam the Atlas list. . Regards, Patrick Vande Walle From colinj at mx5.org.uk Wed Feb 15 18:19:25 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 15 Feb 2012 17:19:25 +0000 Subject: [atlas] manchester uk adsl atlas setup :) In-Reply-To: <4F3BE50E.1060405@vande-walle.eu> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> <4F3BE50E.1060405@vande-walle.eu> Message-ID: setup my adsl atlas today, connected usb for power to usb connection on bt homehub and lan to port1 on homehub. all seems to be working fine, HSO adsl connectivity ipv4 Colin From colinj at mx5.org.uk Wed Feb 15 19:46:18 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 15 Feb 2012 18:46:18 +0000 Subject: [atlas] uydm when live for all In-Reply-To: References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> <4F3BE50E.1060405@vande-walle.eu> Message-ID: <3059E53B-B10B-4245-899A-73079007F15F@mx5.org.uk> Hi all Any idea when UDM is live for all, would be great to remotely see connectivity into specific UK networks to check bgp failover is working as designed Colin From bortzmeyer at nic.fr Wed Feb 15 21:40:27 2012 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 15 Feb 2012 21:40:27 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <3707_1329335052_4F3C0B0C_3707_545364_1_17606_1329321430_4F3BD5B6_17606_75_1_20120215152425.GA6264@nic.fr> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> <3707_1329335052_4F3C0B0C_3707_545364_1_17606_1329321430_4F3BD5B6_17606_75_1_20120215152425.GA6264@nic.fr> Message-ID: <20120215204027.GA10086@sources.org> On Wed, Feb 15, 2012 at 04:24:25PM +0100, Stephane Bortzmeyer wrote a message of 13 lines which said: > > Did you receive your SamKnows box already btw? > > No. Two hours after, it arrived :-) http://www.bortzmeyer.org/samknows.html From daniel.karrenberg at ripe.net Thu Feb 16 09:46:14 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 16 Feb 2012 09:46:14 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <4F3BE50E.1060405@vande-walle.eu> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> <4F3BE50E.1060405@vande-walle.eu> Message-ID: <29E4653D-E3D9-470E-8B63-4DB066E0430F@ripe.net> On 15.02.2012, at 18:02, Patrick Vande Walle wrote: > I did have some email exchanges with a human being when I enquired for > more details about which tests they performed and how. They did not go > into the details, though. > If anyone is interested, i can share more info offlistn, in order not to > spam the Atlas list. . There is a white paper on the samknows web site with some details: http://www.samknows.com/broadband/methodology I received my box this morning and will install it soon. It is the newer TP-link version. If one has questions, I suggest to mail Sam (Crawford) personally. Robert and I met him last week and he seems to be a reasonable nerd like the rest of us ;-). I do not consider talking about this here SPAM just yet and until we stop talking about Atlas completely. ;-) ;-) ;-) Daniel From daniel.karrenberg at ripe.net Fri Feb 17 16:35:18 2012 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 17 Feb 2012 16:35:18 +0100 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <20120215204027.GA10086@sources.org> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> <3707_1329335052_4F3C0B0C_3707_545364_1_17606_1329321430_4F3BD5B6_17606_75_1_20120215152425.GA6264@nic.fr> <20120215204027.GA10086@sources.org> Message-ID: Just for your entertainment: Here is my Samknows picture. I accepted their terms on Feb 4th, box sent Feb 9th, arrived Feb 16th, installed Feb 17th. This is in my basement and sits on top of my cable modem. The box does not have the WLAN antennas installed because it is in the basement and my WLAN traffic actually passes thru the wire, so it sees it there. Of course I have a little more RIPE Atlas kit: Test set-up courtesy of Antony. This is three Atlas probes per broadband connection: one each on the production, test and development networks. My broadband is now thoroughly tested. ;-) Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: SAMKNOWS1.jpg Type: image/jpg Size: 108799 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RIPEATLAS1.jpg Type: image/jpg Size: 109280 bytes Desc: not available URL: From Woeber at CC.UniVie.ac.at Tue Feb 21 12:16:25 2012 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber, UniVie/ACOnet) Date: Tue, 21 Feb 2012 11:16:25 +0000 Subject: [atlas] OT(?) SamKnows/EC Test Project In-Reply-To: <20120215152425.GA6264@nic.fr> References: <4F3BB934.9020704@CC.UniVie.ac.at> <20120215141243.GA29169@nic.fr> <4F3BC4AC.8000200@sidn.nl> <20120215152425.GA6264@nic.fr> Message-ID: <4F437D09.4020603@CC.UniVie.ac.at> Stephane Bortzmeyer wrote: [...] > In my case, the other party passed the Turing test. Thanks to everyone who provided feedback, either here or out of band! I also, eventually, succeeded to get hold of a (very resonable) human being (Neil C.). Maybe it was the use of CAPITALS in the subject line that did the trick, although it is not my style to do that... :-) I'm about to agree to their "fine print" now (which was the background for some issues/questions) and hope to receive their box. Regards, Wilfried. From olisek at gmail.com Wed Feb 22 13:38:50 2012 From: olisek at gmail.com (xs) Date: Wed, 22 Feb 2012 13:38:50 +0100 Subject: [atlas] Port 21 Message-ID: Why probe have port 21 opened? -- Ta wiadomo?? zawiera poufne informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k?, prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. Odmienne zachowanie jest niezgodne z interesem (xs, 1993-2011) i mo?e narusza? prawo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Wed Feb 22 13:50:02 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 22 Feb 2012 13:50:02 +0100 Subject: [atlas] Port 21 In-Reply-To: References: Message-ID: <4F44E47A.5080802@ripe.net> On 2/22/12 13:38 , xs wrote: > Why probe have port 21 opened? As far as I know, they don't have that port open. How did you find it? From inigo at infornografia.net Wed Feb 22 13:51:51 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 22 Feb 2012 13:51:51 +0100 Subject: [atlas] Port 21 In-Reply-To: <4F44E47A.5080802@ripe.net> References: <4F44E47A.5080802@ripe.net> Message-ID: 2012/2/22 Philip Homburg > On 2/22/12 13:38 , xs wrote: > >> Why probe have port 21 opened? >> > As far as I know, they don't have that port open. How did you find it? > > Olisek, could you post the tcpdump/nmap/* output where you noticed the port open, as well as a small setup description of your test? -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidp at preshweb.co.uk Wed Feb 22 13:56:27 2012 From: davidp at preshweb.co.uk (David Precious) Date: Wed, 22 Feb 2012 12:56:27 +0000 Subject: [atlas] Port 21 In-Reply-To: References: Message-ID: <20120222125627.5672ad75@columbia> On Wed, 22 Feb 2012 13:38:50 +0100 xs wrote: > Why probe have port 21 opened? Mine doesn't: [davidp at supernova:~]$ sudo nmap atlasprobe Starting Nmap 4.62 ( http://nmap.org ) at 2012-02-22 12:54 GMT All 1715 scanned ports on atlasprobe.preshweb.co.uk (10.1.10.34) are closed MAC Address: 00:20:4A:E0:21:1F (Pronet Gmbh) Nmap done: 1 IP address (1 host up) scanned in 1.194 seconds -- 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 lukasz at wsisiz.edu.pl Wed Feb 22 14:08:31 2012 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Wed, 22 Feb 2012 14:08:31 +0100 Subject: [atlas] Proble rebooting several times a day. Message-ID: Hello Why my probe (id 2598, Firmware Version: 4280) rebooting several times a day? My routers and uplinks connections works correctly and stable. Internet Address: Connect at: Disconnect at: Up time: Down time (until next connection): 2001:1a68:a::56 2012-02-22 08:56:46 UTC (still connected) 0d, 3h, 59m (still connected) 2001:1a68:a::56 2012-02-22 07:48:06 UTC 2012-02-22 08:53:05 UTC 0d, 1h, 4m 0d, 0h, 3m 2001:1a68:a::56 2012-02-22 03:50:31 UTC 2012-02-22 07:44:41 UTC 0d, 3h, 54m 0d, 0h, 3m 2001:1a68:a::56 2012-02-21 17:04:30 UTC 2012-02-22 03:47:02 UTC 0d, 10h, 42m 0d, 0h, 3m 2001:1a68:a::56 2012-02-21 07:33:19 UTC 2012-02-21 16:57:49 UTC 0d, 9h, 24m 0d, 0h, 6m 2001:1a68:a::56 2012-02-21 04:42:18 UTC 2012-02-21 07:29:42 UTC 0d, 2h, 47m 0d, 0h, 3m 2001:1a68:a::56 2012-02-20 10:35:17 UTC 2012-02-21 04:35:13 UTC 0d, 17h, 59m 0d, 0h, 7m 2001:1a68:a::56 2012-02-19 14:55:21 UTC 2012-02-20 10:31:40 UTC 0d, 19h, 36m 0d, 0h, 3m 2001:1a68:a::56 2012-02-19 10:34:47 UTC 2012-02-19 14:51:58 UTC 0d, 4h, 17m 0d, 0h, 3m 2001:1a68:a::56 2012-02-19 04:35:15 UTC 2012-02-19 10:31:17 UTC 0d, 5h, 56m 0d, 0h, 3m 2001:1a68:a::56 2012-02-19 01:05:26 UTC 2012-02-19 04:31:43 UTC 0d, 3h, 26m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 23:54:45 UTC 2012-02-19 01:01:59 UTC 0d, 1h, 7m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 23:02:20 UTC 2012-02-18 23:51:06 UTC 0d, 0h, 48m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 22:23:42 UTC 2012-02-18 22:52:58 UTC 0d, 0h, 29m 0d, 0h, 9m 2001:1a68:a::56 2012-02-18 18:55:25 UTC 2012-02-18 22:13:36 UTC 0d, 3h, 18m 0d, 0h, 10m 2001:1a68:a::56 2012-02-18 02:50:04 UTC 2012-02-18 18:51:44 UTC 0d, 16h, 1m 0d, 0h, 3m 2001:1a68:a::56 2012-02-18 01:02:47 UTC 2012-02-18 02:46:09 UTC 0d, 1h, 43m 0d, 0h, 3m 2001:1a68:a::56 2012-02-17 19:34:11 UTC 2012-02-18 00:59:04 UTC 0d, 5h, 24m 0d, 0h, 3m 2001:1a68:a::56 2012-02-17 14:08:25 UTC 2012-02-17 19:30:28 UTC 0d, 5h, 22m 0d, 0h, 3m 2001:1a68:a::56 2012-02-17 13:14:37 UTC 2012-02-17 14:04:52 UTC 0d, 0h, 50m 0d, 0h, 3m From inigo at infornografia.net Wed Feb 22 14:16:04 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 22 Feb 2012 14:16:04 +0100 Subject: [atlas] Port 21 In-Reply-To: <20120222125627.5672ad75@columbia> References: <20120222125627.5672ad75@columbia> Message-ID: On Wed, Feb 22, 2012 at 1:56 PM, David Precious wrote: > On Wed, 22 Feb 2012 13:38:50 +0100 > xs wrote: > > > Why probe have port 21 opened? > > Mine doesn't: > > [davidp at supernova:~]$ sudo nmap atlasprobe > > Starting Nmap 4.62 ( http://nmap.org ) at 2012-02-22 12:54 GMT > All 1715 scanned ports on atlasprobe.preshweb.co.uk (10.1.10.34) are > closed > MAC Address: 00:20:4A:E0:21:1F (Pronet Gmbh) > > Nmap done: 1 IP address (1 host up) scanned in 1.194 seconds > > > Mine neither. When I first made the scans and packet captures months ago I did not find anything this weird. I guess this will be all clear once OP shares more info and developers answer. Best, > > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidp at preshweb.co.uk Wed Feb 22 14:32:28 2012 From: davidp at preshweb.co.uk (David Precious) Date: Wed, 22 Feb 2012 13:32:28 +0000 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: Message-ID: <20120222133228.790290c2@columbia> On Wed, 22 Feb 2012 14:08:31 +0100 Lukasz Trabinski wrote: > Hello > > > Why my probe (id 2598, Firmware Version: 4280) rebooting several > times a day? My routers and uplinks connections works correctly and > stable. Only a random stab in the dark, but what USB port is it powered by? Could the device supplying the power be going into a power-saving mode and shutting down power to that port? -- 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 me at anuragbhatia.com Wed Feb 22 14:34:35 2012 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 22 Feb 2012 19:04:35 +0530 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <20120222133228.790290c2@columbia> References: <20120222133228.790290c2@columbia> Message-ID: Good point David. I had similar issue during 1st two days when I was hosting via my laptop. No issues after I attached it to external USB adapter. On Wed, Feb 22, 2012 at 7:02 PM, David Precious wrote: > On Wed, 22 Feb 2012 14:08:31 +0100 > Lukasz Trabinski wrote: > > > Hello > > > > > > Why my probe (id 2598, Firmware Version: 4280) rebooting several > > times a day? My routers and uplinks connections works correctly and > > stable. > > Only a random stab in the dark, but what USB port is it powered by? > Could the device supplying the power be going into a power-saving mode > and shutting down power to that port? > > > > > -- > 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 > > -- Anurag Bhatia anuragbhatia.com or simply - http://[2001:470:26:78f::5] if you are on IPv6 connected network! Twitter: @anurag_bhatia Linkedin: http://linkedin.anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at wsisiz.edu.pl Wed Feb 22 14:47:15 2012 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Wed, 22 Feb 2012 14:47:15 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <20120222133228.790290c2@columbia> References: <20120222133228.790290c2@columbia> Message-ID: 2012/2/22 David Precious : > On Wed, 22 Feb 2012 14:08:31 +0100 > Lukasz Trabinski wrote: >> Why my probe (id 2598, Firmware Version: 4280) rebooting several >> times a day? My routers and uplinks connections works correctly and >> stable. > > Only a random stab in the dark, but what USB port is it powered by? > Could the device supplying the power be going into a power-saving mode > and shutting down power to that port? It's connected to USB port in PC router (Linux, FC16, with Quagga). I know that probe send and recive packets all the time. (sniffing packets by tcpdump) In my opinion usb port shouldn't go into sleep or power-saving mode. I dont's see any action related with that usb port in my logs files but on switch where probe is connected I observe flap port (down/up). From colinj at mx5.org.uk Wed Feb 22 14:56:14 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 22 Feb 2012 13:56:14 +0000 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <20120222133228.790290c2@columbia> References: <20120222133228.790290c2@columbia> Message-ID: > > > Only a random stab in the dark, but what USB port is it powered by? > Could the device supplying the power be going into a power-saving mode > and shutting down power to that port? > usb port on BT homehub works well :) Colin From philip.homburg at ripe.net Wed Feb 22 15:02:50 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 22 Feb 2012 15:02:50 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> Message-ID: <4F44F58A.4000103@ripe.net> On 2/22/12 14:47 , Lukasz Trabinski wrote: > 2012/2/22 David Precious: >> On Wed, 22 Feb 2012 14:08:31 +0100 >> Lukasz Trabinski wrote: >>> Why my probe (id 2598, Firmware Version: 4280) rebooting several >>> times a day? My routers and uplinks connections works correctly and >>> stable. >> Only a random stab in the dark, but what USB port is it powered by? >> Could the device supplying the power be going into a power-saving mode >> and shutting down power to that port? > It's connected to USB port in PC router (Linux, FC16, with Quagga). > I know that probe send and recive packets all the time. (sniffing > packets by tcpdump) > In my opinion usb port shouldn't go into sleep or power-saving mode. I > dont's see any > action related with that usb port in my logs files but on switch where > probe is connected I > observe flap port (down/up). > I can see from the logs that it does reboot (as opposed to just losing the connection to the controller). But I have no clue why it does that. From robert at ripe.net Wed Feb 22 15:04:03 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 22 Feb 2012 15:04:03 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> Message-ID: <4F44F5D3.2090900@ripe.net> On 2012.02.22. 14:47, Lukasz Trabinski wrote: > 2012/2/22 David Precious : >> On Wed, 22 Feb 2012 14:08:31 +0100 >> Lukasz Trabinski wrote: > >>> Why my probe (id 2598, Firmware Version: 4280) rebooting several >>> times a day? My routers and uplinks connections works correctly and >>> stable. >> >> Only a random stab in the dark, but what USB port is it powered by? >> Could the device supplying the power be going into a power-saving mode >> and shutting down power to that port? > > It's connected to USB port in PC router (Linux, FC16, with Quagga). > I know that probe send and recive packets all the time. (sniffing > packets by tcpdump) > In my opinion usb port shouldn't go into sleep or power-saving mode. I > dont's see any > action related with that usb port in my logs files but on switch where > probe is connected I > observe flap port (down/up). The reference to USB power source issues is an interesting one -- we haven't seen that as a "structural" reason for disconnection before. Having said that, the fact that the probe is up for hours at a time suggests that the local network and power conditions are fine. Please keep in mind that our definition of "up" is when the probe is connected to us, ie. a permanent TCP connection to one of our servers is maintained. This connection may be broken for a number of reasons, including local (transient) network problems at either end. Also, the probe continues its measurements even if it's disconnected, and submits all the data once it reconnects. In short: it's not a big deal if a probe disconnects, as long as it can reconnect in a reasonable time. Regards, Robert From colinj at mx5.org.uk Wed Feb 22 15:07:50 2012 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 22 Feb 2012 14:07:50 +0000 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <4F44F5D3.2090900@ripe.net> References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> Message-ID: > > In short: it's not a big deal if a probe disconnects, as long as it can > reconnect in a reasonable time. > Newbie light question How does one make sure the probe is using the up to date firmware. I have not seen this change since installed last week. Probe ID: 2317 Firmware Version: None MAC Address: 00:20:4A:E0:24:F7 Colin -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Wed Feb 22 15:15:06 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 22 Feb 2012 15:15:06 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> Message-ID: <4F44F86A.8030003@ripe.net> On 2/22/12 15:07 , Colin Johnston wrote: >> >> In short: it's not a big deal if a probe disconnects, as long as it can >> reconnect in a reasonable time. >> > > Newbie light question > > How does one make sure the probe is using the up to date firmware. > I have not seen this change since installed last week. > Probes will update themselves. Just this morning a new firmware was released, so it should update itself within the next couple of days. From lukasz at trabinski.net Wed Feb 22 15:23:58 2012 From: lukasz at trabinski.net (Lukasz Trabinski) Date: Wed, 22 Feb 2012 15:23:58 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <4F44F5D3.2090900@ripe.net> References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> Message-ID: 2012/2/22 Robert Kisteleki : > Also, the probe continues its measurements even if it's disconnected, and > submits all the data once it reconnects. > > In short: it's not a big deal if a probe disconnects, as long as it can > reconnect in a reasonable time. Thank's. Anyway I will try buy for 1 euro external usb power supply for my probe :) From robert at ripe.net Wed Feb 22 16:04:06 2012 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 22 Feb 2012 16:04:06 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> Message-ID: <4F4503E6.40105@ripe.net> On 2012.02.22. 15:23, Lukasz Trabinski wrote: > 2012/2/22 Robert Kisteleki : > >> Also, the probe continues its measurements even if it's disconnected, and >> submits all the data once it reconnects. >> >> In short: it's not a big deal if a probe disconnects, as long as it can >> reconnect in a reasonable time. > > Thank's. Anyway I will try buy for 1 euro external usb power supply > for my probe :) We can give you one if you come to the next RIPE meeting :-) Robert From davidp at preshweb.co.uk Wed Feb 22 16:16:41 2012 From: davidp at preshweb.co.uk (David Precious) Date: Wed, 22 Feb 2012 15:16:41 +0000 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> Message-ID: <20120222151641.425f61ea@columbia> On Wed, 22 Feb 2012 15:23:58 +0100 Lukasz Trabinski wrote: > Thank's. Anyway I will try buy for 1 euro external usb power supply > for my probe :) That's probably the easiest and most reliable way :) In the meantime, you could always check whether your USB ports are set to automatic power management: [davidp at columbia:~]$ cat /sys/bus/usb/devices/usb*/power/level auto auto If you get "auto", you could try forcing them to stay on - e.g. as root: echo on > /sys/bus/usb/devices/usb1/power/level Worth a try at least, if you're interested. Of course, you'd need to figure out which "usb$n" to use, depending on which port it's connected to - or just set them all to on: for file in /sys/bus/usb/devices/usb*/power/level; \ do echo "on" > $file; done Whether the above will actually make a difference, I don't know, but could be worth a try if you're curious. If you do, report back whether it helped, so everyone knows if that's a potential fix for anyone else who experiences the same problem :) -- 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 inigo at infornografia.net Wed Feb 22 16:22:47 2012 From: inigo at infornografia.net (=?ISO-8859-1?Q?I=F1igo_Ortiz_de_Urbina?=) Date: Wed, 22 Feb 2012 16:22:47 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <20120222151641.425f61ea@columbia> References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> <20120222151641.425f61ea@columbia> Message-ID: On Wed, Feb 22, 2012 at 4:16 PM, David Precious wrote: > On Wed, 22 Feb 2012 15:23:58 +0100 > Lukasz Trabinski wrote: > > Thank's. Anyway I will try buy for 1 euro external usb power supply > > for my probe :) > > That's probably the easiest and most reliable way :) > > In the meantime, you could always check whether your USB ports are set > to automatic power management: > > [davidp at columbia:~]$ > cat /sys/bus/usb/devices/usb*/power/level > auto > auto > > If you get "auto", you could try forcing them to stay on - e.g. as root: > > echo on > /sys/bus/usb/devices/usb1/power/level > > Worth a try at least, if you're interested. > > Of course, you'd need to figure out which "usb$n" to use, depending on > which port it's connected to - or just set them all to on: > > for file in /sys/bus/usb/devices/usb*/power/level; \ > do echo "on" > $file; done > > Whether the above will actually make a difference, I don't know, but > could be worth a try if you're curious. If you do, report back whether > it helped, so everyone knows if that's a potential fix for anyone else > who experiences the same problem :) > > > It may be worth to write down this tip on the Atlas FAQ, just in case other Linux users are experiencing random reboots and want to start troubleshooting bottom-up. Just my two cents Best, > -- > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukasz at wsisiz.edu.pl Wed Feb 22 17:50:27 2012 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Wed, 22 Feb 2012 17:50:27 +0100 (CET) Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> <20120222151641.425f61ea@columbia> Message-ID: On Wed, 22 Feb 2012, I?igo Ortiz de Urbina wrote: > Whether the above will actually make a difference, I don't know, but > could be worth a try if you're curious. ?If you do, report back > whether > it helped, so everyone knows if that's a potential fix for anyone else > who experiences the same problem :) Thank You, I will try your soultions, I will report back if it solved problem with restart probe. From lukasz at wsisiz.edu.pl Thu Feb 23 10:31:19 2012 From: lukasz at wsisiz.edu.pl (Lukasz Trabinski) Date: Thu, 23 Feb 2012 10:31:19 +0100 (CET) Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> <20120222151641.425f61ea@columbia> Message-ID: > On Wed, 22 Feb 2012, I?igo Ortiz de Urbina wrote: > >> Whether the above will actually make a difference, I don't know, but >> could be worth a try if you're curious. ?If you do, report back >> whether >> it helped, so everyone knows if that's a potential fix for anyone else >> who experiences the same problem :) > > Thank You, I will try your soultions, I will report back if it solved problem > with restart probe. Yesterday I puted "on" to power/level on usb devices [root at voices ~]# cat /sys/bus/usb/devices/usb*/power/level on on on on on on on on But in logs I can see that probe rebooted last night nternet Address: Connect at: Disconnect at: Up time: Down time (until next connection): 2001:1a68:a::56 2012-02-23 05:34:18 UTC (still connected) 0d, 3h, 50m (still connected) 2001:1a68:a::56 2012-02-22 08:56:46 UTC 2012-02-23 05:30:37 UTC 0d, 20h, 33m 0d, 0h, 3m 2001:1a68:a::56 2012-02-22 07:48:06 UTC 2012-02-22 08:53:05 UTC 0d, 1h, 4m 0d, 0h, 3m From daniel at sokolov.eu.org Thu Feb 23 10:51:45 2012 From: daniel at sokolov.eu.org (Daniel AJ Sokolov) Date: Thu, 23 Feb 2012 05:51:45 -0400 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> <20120222151641.425f61ea@columbia> Message-ID: <4F460C31.8050604@sokolov.eu.org> On 2012-02-23 05:31 wrote Lukasz Trabinski: > > But in logs I can see that probe rebooted last night > > nternet Address: Connect at: Disconnect at: Up time: Down time > (until next connection): > 2001:1a68:a::56 2012-02-23 05:34:18 UTC (still connected) 0d, > 3h, 50m (still connected) > 2001:1a68:a::56 2012-02-22 08:56:46 UTC 2012-02-23 05:30:37 UTC > 0d, 20h, 33m 0d, 0h, 3m > 2001:1a68:a::56 2012-02-22 07:48:06 UTC 2012-02-22 08:53:05 UTC > 0d, 1h, 4m 0d, 0h, 3m That does not necessarily mean that you probe rebooted. Often this would be related to the internet connection or your router/modem. BR Daniel AJ -- Follow me on twitter @newstik http://twitter.com/newstik From antoine at jacot-descombes.ch Thu Feb 23 11:16:07 2012 From: antoine at jacot-descombes.ch (Antoine Jacot-Descombes) Date: Thu, 23 Feb 2012 11:16:07 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <4F460C31.8050604@sokolov.eu.org> References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> <20120222151641.425f61ea@columbia> <4F460C31.8050604@sokolov.eu.org> Message-ID: <4F4611E7.6070802@jacot-descombes.ch> >> But in logs I can see that probe rebooted last night >> >> nternet Address: Connect at: Disconnect at: Up time: Down time >> (until next connection): >> 2001:1a68:a::56 2012-02-23 05:34:18 UTC (still connected) 0d, >> 3h, 50m (still connected) >> 2001:1a68:a::56 2012-02-22 08:56:46 UTC 2012-02-23 05:30:37 UTC >> 0d, 20h, 33m 0d, 0h, 3m >> 2001:1a68:a::56 2012-02-22 07:48:06 UTC 2012-02-22 08:53:05 UTC >> 0d, 1h, 4m 0d, 0h, 3m > That does not necessarily mean that you probe rebooted. Often this would > be related to the internet connection or your router/modem. Or firmware upgrade. My probe apparently upgraded to v4310 last night. Regards, Antoine From robert at ripe.net Thu Feb 23 16:01:48 2012 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 23 Feb 2012 16:01:48 +0100 Subject: [atlas] Proble rebooting several times a day. In-Reply-To: <4F4611E7.6070802@jacot-descombes.ch> References: <20120222133228.790290c2@columbia> <4F44F5D3.2090900@ripe.net> <20120222151641.425f61ea@columbia> <4F460C31.8050604@sokolov.eu.org> <4F4611E7.6070802@jacot-descombes.ch> Message-ID: <4F4654DC.6020404@ripe.net> >> That does not necessarily mean that you probe rebooted. Often this would >> be related to the internet connection or your router/modem. > Or firmware upgrade. My probe apparently upgraded to v4310 last night. For firmware updates we're using a lazy approach: the probes only check for newer firmware when they reconnect. Of course we can request probes to upgrade, but we only use that if there's a good reason. If a probe is up an running happily, then we don't really want to disconnect it... :-) As an interesting data point: the top two probes in terms of continuous uptime are: ID 2197 (up since 2011-12-05 22:19:32 ~80 days) ID 917 (up since 2011-12-07 00:48:47 ~79 days) (Both are in France!) Regards, Robert From bicknell at ufp.org Fri Feb 24 21:41:30 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Fri, 24 Feb 2012 12:41:30 -0800 Subject: [atlas] Request to test TCP and UDP to the root servers separately. Message-ID: <20120224204130.GA86727@ussenterprise.ufp.org> My day job has had some interesting discussions lately about TCP to the root servers based on a few odd behaviors we've had reported to us over the past few years. There aren't any surprises in this data, it's been known for a long time some people think DNS is UDP only for instance, some firewalls are broken, and so on. What we realized though is that there is no wide-spread measurement of how often TCP is a problem. Immediately my thought went to the Atlas probe network. It's distributed enough it could give an interesting indication of how often TCP DNS fails compared to UDP DNS. Perhaps the rates are so similar it's a non-issue, perhaps TCP fails much more often. Would it be of interest to the Atlas community to have the probes try and query "." via both UDP and TDP from each of the 13 root servers (perhaps v4 and v6 separately), report back that data, and then generate a report on the results? I would be happy to assist in preparing or presenting a report on the results! -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ From philip.homburg at ripe.net Sat Feb 25 10:49:04 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 25 Feb 2012 10:49:04 +0100 Subject: [atlas] Request to test TCP and UDP to the root servers separately. In-Reply-To: <20120224204130.GA86727@ussenterprise.ufp.org> References: <20120224204130.GA86727@ussenterprise.ufp.org> Message-ID: <4F48AE90.2000507@ripe.net> On 2/24/12 21:41 , Leo Bicknell wrote: > Would it be of interest to the Atlas community to have the probes > try and query "." via both UDP and TDP from each of the 13 root > servers (perhaps v4 and v6 separately), report back that data, and > then generate a report on the results? I would be happy to assist > in preparing or presenting a report on the results! > The probes are already measuring this. I don't think we made any graphs of the results. From liman at autonomica.se Sat Feb 25 21:18:43 2012 From: liman at autonomica.se (Lars-Johan Liman) Date: Sat, 25 Feb 2012 21:18:43 +0100 Subject: [atlas] Request to test TCP and UDP to the root servers separately. In-Reply-To: <4F48AE90.2000507@ripe.net> (Philip Homburg's message of "Sat, 25 Feb 2012 10:49:04 +0100") References: <20120224204130.GA86727@ussenterprise.ufp.org> <4F48AE90.2000507@ripe.net> Message-ID: <22399yoee4.fsf@ziptop.autonomica.net> philip.homburg at ripe.net: > The probes are already measuring this. I don't think we made any > graphs of the results. Do you also measure whether the path to root servers (other DNS servers?) allow for fragmented UDP packets? If you announce an EDNS(0) buffer size of 4K and ask for some DNSSEC related records, you often receive fragmented UDP messages. It would be interesting to see whether those fragments make it back to the client. If not, there will be timeouts and TCP resends, which I call bad (YMMV). The query produced by the command dig @X.root-servers.net . ANY +dnssec ticles the root servers to send a 3966-byte message, which triggers interesting behaviour in my neck of the woods - such as fragment reordering and consequential reassembly failure - so it's important to not only look at the IP result of the query, but to actually look at the arriving packets. Just a thought ... Cheers, /Lars-Johan Liman #---------------------------------------------------------------------- # Lars-Johan Liman, M.Sc. ! E-mail: liman at netnod.se # Senior Systems Specialist ! Tel: +46 8 - 562 860 12 # Netnod Internet Exchange, Stockholm ! http://www.netnod.se/ #---------------------------------------------------------------------- From philip.homburg at ripe.net Sat Feb 25 22:38:35 2012 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 25 Feb 2012 22:38:35 +0100 Subject: [atlas] Request to test TCP and UDP to the root servers separately. In-Reply-To: <22399yoee4.fsf@ziptop.autonomica.net> References: <20120224204130.GA86727@ussenterprise.ufp.org> <4F48AE90.2000507@ripe.net> <22399yoee4.fsf@ziptop.autonomica.net> Message-ID: <4F4954DB.3080504@ripe.net> On 2/25/12 21:18 , Lars-Johan Liman wrote: > philip.homburg at ripe.net: >> The probes are already measuring this. I don't think we made any >> graphs of the results. > > dig @X.root-servers.net . ANY +dnssec At the moment we don't have EDNS or ANY. That should get added whenever we get around to doing DNSSEC. > ticles the root servers to send a 3966-byte message, which triggers > interesting behaviour in my neck of the woods - such as fragment > reordering and consequential reassembly failure - so it's important to > not only look at the IP result of the query, but to actually look at the > arriving packets. > Why does packet reordering lead to reassembly failures? At the moment we also don't have code for capturing fragments. That may be non-trivial to add. From liman at autonomica.se Sun Feb 26 08:51:12 2012 From: liman at autonomica.se (Lars-Johan Liman) Date: Sun, 26 Feb 2012 08:51:12 +0100 Subject: [atlas] Request to test TCP and UDP to the root servers separately. In-Reply-To: <4F4954DB.3080504@ripe.net> (Philip Homburg's message of "Sat, 25 Feb 2012 22:38:35 +0100") References: <20120224204130.GA86727@ussenterprise.ufp.org> <4F48AE90.2000507@ripe.net> <22399yoee4.fsf@ziptop.autonomica.net> <4F4954DB.3080504@ripe.net> Message-ID: <22fwdykp73.fsf@ziptop.autonomica.net> [Changing my From: address to the one used in my subscription, to avoid sender filters.] philip.homburg at ripe.net: > Why does packet reordering lead to reassembly failures? That's what I would like to know too. :-) I have noticed it (with tcpdump), but I haven't had the the time to drill into what essentially has to be a kernel reassembly problem, or incorrect coding of the fragment headers. There are lots of small ones and zeroes, and deep hacking is needed to reach a solid conclusion, and time is a scarece resource. > At the moment we also don't have code for capturing fragments. That > may be non-trivial to add. Understood. May I suggest a middle ground test, which might be easier for you to implement, and which might still give some useful feedback. First send a nomal UDP DNS query, without DNSSEC and without any EDNS(0) features, and aim for a purposely a small DNS response. That will test normal UDP connectivity. (This you already do, but ensure that the expected response is small.) Then send a TCP DNS query. That will test normal TCP connectivity. (This you obviously already do.) Finally, send a UDP DNS query, with EDNS(0) with a large (but reasonable - maybe 4k?) buffer size, the DO bit set, and many "bells and whistles", to purposely tickle the server to produce a large answer. If you don't receive a parseable DNS response for this, something along the path generates problems for you (fragmenting unit, intermediate firewall, or reassebmly unit), and that in itself is interesting information (me thinks). It may even be that the responding server sets the IP "DF" (don't fragment) bit, which unfortunately seems to be default in some Linux distributions. Or maybe you test this already? ;-) Cheers, /Liman From bicknell at ufp.org Sun Feb 26 16:36:49 2012 From: bicknell at ufp.org (Leo Bicknell) Date: Sun, 26 Feb 2012 07:36:49 -0800 Subject: [atlas] Request to test TCP and UDP to the root servers separately. In-Reply-To: <4F48AE90.2000507@ripe.net> References: <20120224204130.GA86727@ussenterprise.ufp.org> <4F48AE90.2000507@ripe.net> Message-ID: <20120226153649.GA85511@ussenterprise.ufp.org> In a message written on Sat, Feb 25, 2012 at 10:49:04AM +0100, Philip Homburg wrote: > On 2/24/12 21:41 , Leo Bicknell wrote: > >Would it be of interest to the Atlas community to have the probes > >try and query "." via both UDP and TDP from each of the 13 root > >servers (perhaps v4 and v6 separately), report back that data, and > >then generate a report on the results? I would be happy to assist > >in preparing or presenting a report on the results! > > > The probes are already measuring this. I don't think we made any graphs > of the results. I'm not sure a graph would be the best representation of this data. The interesting questions to me are: - Compare Failure Levels - What is the overall level of UDP failure? - What is the overall level of UDP+EDNS0 failure? - What is the overall level of TCP failure? - Exploring the differences in the ecosystem - Is there a statistical difference in the failure rate between IPv4 and IPv6? (Are we getting better or worse) - Is there a statistical difference in the failure rate between two different root servers? (Does the root server deployment model matter) - What is the difference in response time of TCP queries compared to UDP queries? (What's the penalty to fall back to TCP) -- Leo Bicknell - bicknell at ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available URL: