From me at anuragbhatia.com Tue Oct 4 11:42:35 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Tue, 4 Oct 2016 15:12:35 +0530 Subject: [atlas] SSL error on OpenIPMap In-Reply-To: References: Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cool. Thanks for update Emile. -----BEGIN PGP SIGNATURE----- Version: Mailvelope v1.5.2 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJX83mGCRDAbdUkJF5Y4gAAzT4P+wdxbCjfOzQzNYu0G51N CYMT/jLHJ8vqU29p0fki1I+3Ngao2O4SyWaSnT/gB6QGJ6jVB+rvWJxlvzmG +p01UHhGS3Qb/O4SNBB7jPGQKTIGv4jFadfmclK/87BI8BEe4PkABGbn6xMg rfvm2k5CnGVOmjnoNbi5BpTjT9Isg+ebCQTHHYg2+5Pk3Qx0Fm4YrAErizj6 aIm67zoWEnF2lOt8faBAAPGf6qufI27qsQ7OcQYuwmoJUQ0Jn1pPAxiAtG2c uUlP/ddHimcwXQEXgatC3/+HhwSTSLdg+Nv3hDpd8hQ4xVo/AQidLA8ye77x kP+3sqVAck9dZ4cMhsoKSX0Z+K64SMxL95Ipw2XmDS3rbXWo+pfwYQPgDUTi LZ/wxwhOwTBDJh8u1JYDp5u9ZzAI8nWk0rpJlgjO01Mlde18SLy+vzWCPg0x eKxbqVBSBQwgCMTrR69A6D1291lV7VPKAFHSt8kWg687Y/dehrhBVl/LBK/m RpPiuFsiQwu1/wum6fH6/lmh78dLUZJfZkKxBDYGKjsXKmNPrMYcOQCO69f1 2uHdL5AiDkANbMSSVFpKOW7G3bRn9C2zuZam9xPHm5FAbvk1WRaupUOL4ePs BcZqtWgMe1x2aS/jeOtxQqoQH/BloyIR/o8IAAKwpPmiZ1HL/5zcfspG7BRU x4+y =UaMi -----END PGP SIGNATURE----- On Sat, Oct 1, 2016 at 12:29 AM, Emile Aben wrote: > Hi Anurag, > > On 30/09/16 19:54, Anurag Bhatia wrote: > > Hello everyone. > > > > > > > > Is it just me or anyone else getting SSL error on OpenIPMap? I can see > that SSL cert of atlas.ripe.net is valid but when > we open OpenIP Map, it calls one specific map image from fastly on HTTP > resulting in "mixed content" making Chrome to throw SSL error. > > > > This is the URL of that image: > > http://stamen-tiles-c.a.ssl.fastly.net/toner-lite/3/5/5.png > > > > > > > > It does seems to be available on https already and so probably someone > at RIPE need to update URL to call https in URL and avoid the false > positive it's giving. > > > > it did work for me in chrome. i saw warnings in console, but nothing > that would stop the OpenIPMap pages from functioning. > > that said, i changed tile loading from http to https , so that shouldn't > be a problem anymore. > > Note that OpenIPMap is a prototype, and is scheduled to be replaced by a > production version. > > cheers, > emile > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From mm at 42com.com Wed Oct 5 13:54:59 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Wed, 5 Oct 2016 13:54:59 +0200 Subject: [atlas] ripe.atlas.net issues Message-ID: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> "Oops - this page experienced an error while loading." My atlas / My probe does not work, the checks are failing. (Since ~12 minutes) Please don't tell me that it's maintenance work again, without any announcement? ;) Max M. From bortzmeyer at nic.fr Wed Oct 5 13:58:35 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 5 Oct 2016 13:58:35 +0200 Subject: [atlas] ripe.atlas.net issues In-Reply-To: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> Message-ID: <20161005115835.6rrnpuyutvqocb34@nic.fr> On Wed, Oct 05, 2016 at 01:54:59PM +0200, Max M?hlbronner wrote a message of 8 lines which said: > "Oops - this page experienced an error while loading." My atlas / My probe > does not work, the checks are failing. (Since ~12 minutes) RIPE Atlas Web site works for me (but ripe.atlas.net is indeed very slow :-) From mm at 42com.com Wed Oct 5 13:59:44 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Wed, 5 Oct 2016 13:59:44 +0200 Subject: [atlas] ripe.atlas.net issues In-Reply-To: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> Message-ID: <42d75087-eb29-7051-b529-e73cd45a3321@42com.com> Now it works again. On 05.10.2016 13:54, Max M?hlbronner wrote: > "Oops - this page experienced an error while loading." My atlas / My > probe does not work, the checks are failing. (Since ~12 minutes) > > Please don't tell me that it's maintenance work again, without any > announcement? ;) > > > Max M. > -- Max M?hlbronner 42com Telecommunication GmbH Stra?e der Pariser Kommune 12-16 10243 Berlin E-Mail: mm at 42com.com Web: www.42com.com Firmenangaben/Company information: Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B Umsatzsteuer-ID/VAT-ID: DE223812306 Gesch?ftsf?hrer/CEO: Thomas Reinig, Alexander Reinig Diese E-Mail enth?lt Informationen von 42com Telecommunication GmbH. Diese sind m?glicherweise vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Sollten Sie diese elektronische Nachricht irrt?mlicherweise erhalten haben, so informieren Sie uns bitte unverz?glich telefonisch oder per E-Mail. This message is intended only for the use of the individual or entity to which it is addressed. If you have received this message by mistake, please notify us immediately. From mm at 42com.com Wed Oct 5 14:00:56 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Wed, 5 Oct 2016 14:00:56 +0200 Subject: [atlas] ripe.atlas.net issues In-Reply-To: <20161005115835.6rrnpuyutvqocb34@nic.fr> References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> <20161005115835.6rrnpuyutvqocb34@nic.fr> Message-ID: <18a5cf74-b17e-9c21-0885-95ee9eb61c74@42com.com> sorry typo, atlas.ripe.net of course. But it's already ok again. On 05.10.2016 13:58, Stephane Bortzmeyer wrote: > On Wed, Oct 05, 2016 at 01:54:59PM +0200, > Max M?hlbronner wrote > a message of 8 lines which said: > >> "Oops - this page experienced an error while loading." My atlas / My probe >> does not work, the checks are failing. (Since ~12 minutes) > RIPE Atlas Web site works for me (but ripe.atlas.net is indeed very > slow :-) > -- Max M?hlbronner 42com Telecommunication GmbH Stra?e der Pariser Kommune 12-16 10243 Berlin E-Mail: mm at 42com.com Web: www.42com.com Firmenangaben/Company information: Handelsregister/Commercial register: Amtsgericht Berlin HRB 99071 B Umsatzsteuer-ID/VAT-ID: DE223812306 Gesch?ftsf?hrer/CEO: Thomas Reinig, Alexander Reinig Diese E-Mail enth?lt Informationen von 42com Telecommunication GmbH. Diese sind m?glicherweise vertraulich und ausschlie?lich f?r den Adressaten bestimmt. Sollten Sie diese elektronische Nachricht irrt?mlicherweise erhalten haben, so informieren Sie uns bitte unverz?glich telefonisch oder per E-Mail. This message is intended only for the use of the individual or entity to which it is addressed. If you have received this message by mistake, please notify us immediately. From robert at ripe.net Wed Oct 5 14:10:56 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 5 Oct 2016 14:10:56 +0200 Subject: [atlas] ripe.atlas.net issues In-Reply-To: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> Message-ID: <085c7b94-3fff-17fa-93dd-302e764331f8@ripe.net> On 2016-10-05 13:54, Max M?hlbronner wrote: > "Oops - this page experienced an error while loading." My atlas / My probe > does not work, the checks are failing. (Since ~12 minutes) > > Please don't tell me that it's maintenance work again, without any > announcement? ;) > > > Max M. Indeed this is/was caused by new code deployment, which in this instance also meant some DB maintenance. Sorry about the hickup, things should go back to normal in a moment. Regards, Robert From colinj at mx5.org.uk Thu Oct 6 14:58:07 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 6 Oct 2016 13:58:07 +0100 Subject: [atlas] ripe.atlas.net issues In-Reply-To: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> Message-ID: <8866981B-2113-47CC-899B-1DD1EAE853B6@mx5.org.uk> yes, announcement of updates would be great as per normal IT day jobs. whilst the subject of IT, UK folks will be doing ByteNight tomorrow in various UK sites https://www.facebook.com/ByteNight contact myself if want to donate. yours Colin Johnston > On 5 Oct 2016, at 12:54, Max M?hlbronner wrote: > > "Oops - this page experienced an error while loading." My atlas / My probe does not work, the checks are failing. (Since ~12 minutes) > > Please don't tell me that it's maintenance work again, without any announcement? ;) > > > Max M. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Oct 6 16:09:09 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 6 Oct 2016 16:09:09 +0200 Subject: [atlas] Service downtime Message-ID: <461f5410-9a93-2404-d45a-e52137f25040@ripe.net> Hello, We seem to experience a database backend problem, rendering the whole service unavailable. We're busy fixing it and investigating the cause. Ill report on progress as soon as I have more information. Regards, Robert From mm at 42com.com Thu Oct 6 16:11:19 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Thu, 6 Oct 2016 16:11:19 +0200 Subject: [atlas] ripe.atlas.net issues In-Reply-To: <8866981B-2113-47CC-899B-1DD1EAE853B6@mx5.org.uk> References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> <8866981B-2113-47CC-899B-1DD1EAE853B6@mx5.org.uk> Message-ID: Btw, at the moment the whole site is offline again, since ~1 hour. (atlas.ripe.net) BR Max M. On 06.10.2016 14:58, Colin Johnston wrote: > yes, announcement of updates would be great as per normal IT day jobs. > > whilst the subject of IT, UK folks will be doing ByteNight tomorrow in various UK sites > https://www.facebook.com/ByteNight > contact myself if want to donate. > > > yours > > Colin Johnston > >> On 5 Oct 2016, at 12:54, Max M?hlbronner wrote: >> >> "Oops - this page experienced an error while loading." My atlas / My probe does not work, the checks are failing. (Since ~12 minutes) >> >> Please don't tell me that it's maintenance work again, without any announcement? ;) >> >> >> Max M. >> > From annikaw at penguinfriends.org Thu Oct 6 16:13:30 2016 From: annikaw at penguinfriends.org (Annika Wickert) Date: Thu, 6 Oct 2016 16:13:30 +0200 Subject: [atlas] ripe.atlas.net issues In-Reply-To: References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> <8866981B-2113-47CC-899B-1DD1EAE853B6@mx5.org.uk> Message-ID: <73b6e248-7db1-4f7e-e0fb-22cc1ae8577f@penguinfriends.org> Yes, can confirm that. Yours, Annika Wickert On 06/10/2016 16:11, Max M?hlbronner wrote: > Btw, at the moment the whole site is offline again, since ~1 hour. > (atlas.ripe.net) > > > BR > > Max M. > > On 06.10.2016 14:58, Colin Johnston wrote: >> yes, announcement of updates would be great as per normal IT day jobs. >> >> whilst the subject of IT, UK folks will be doing ByteNight tomorrow >> in various UK sites >> https://www.facebook.com/ByteNight >> contact myself if want to donate. >> >> >> yours >> >> Colin Johnston >> >>> On 5 Oct 2016, at 12:54, Max M?hlbronner wrote: >>> >>> "Oops - this page experienced an error while loading." My atlas / My >>> probe does not work, the checks are failing. (Since ~12 minutes) >>> >>> Please don't tell me that it's maintenance work again, without any >>> announcement? ;) >>> >>> >>> Max M. >>> >> > > > From robert at ripe.net Thu Oct 6 17:16:51 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 6 Oct 2016 17:16:51 +0200 Subject: [atlas] Service downtime In-Reply-To: <461f5410-9a93-2404-d45a-e52137f25040@ripe.net> References: <461f5410-9a93-2404-d45a-e52137f25040@ripe.net> Message-ID: <5336f725-9d36-f3c6-070f-de97582060c6@ripe.net> On 2016-10-06 16:09, Robert Kisteleki wrote: > Hello, > > We seem to experience a database backend problem, rendering the whole > service unavailable. We're busy fixing it and investigating the cause. > > Ill report on progress as soon as I have more information. > > Regards, > Robert Update: the service is back up, after a total downtime of about an hour. The outage was caused by the main database server becoming unresponsive; we're still investigating the root cause for that. Regards, Robert From colinj at mx5.org.uk Mon Oct 10 09:28:28 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 10 Oct 2016 08:28:28 +0100 Subject: [atlas] ripe atlas probe v1 cat sylvester (Colin BT) In-Reply-To: References: <242c6de8-a5d2-0376-d7c0-44094a362dfd@42com.com> <8866981B-2113-47CC-899B-1DD1EAE853B6@mx5.org.uk> Message-ID: <9CDF3E40-A873-4A38-A87B-6221F2B47222@mx5.org.uk> smaller pic now to so hopefully auto approved :) Managed to raise over 2500 pounds for Byte Night NW (Action for Children) https://www.facebook.com/ByteNight contact myself if want to donate Here is Sylvester on Bus to event, sleeping out and on Bus back home. yours Colin Johnston -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WP_20161007_23_58_22_Pro-small.jpg Type: image/jpeg Size: 46387 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WP_20161007_17_16_13_Pro-small.jpg Type: image/jpeg Size: 63576 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: WP_20161007_17_16_22_Pro-small.jpg Type: image/jpeg Size: 58531 bytes Desc: not available URL: From yang.yu.list at gmail.com Tue Oct 11 04:35:45 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Mon, 10 Oct 2016 21:35:45 -0500 Subject: [atlas] firmware download test? Message-ID: Hi, I have 2 probes that are connected but shown as offline even after several power cycles. I performed USB stick troubleshooting procedures by removing the USB stick and saw NO-USB SOS message. But after inserting the USB stick there wasn't any new SOS messages. Plugged the USB stick to computer and saw corrupted file system. Formatted the stick and inserted it back, still no SOS messages. What kind of filesystem layout is expected on the stick? From what I read the probe should automatically partition/format the stick. Maybe the stick is bad. I do see a good amount of packet loss between the probe's network and the registration server. How robust is the firmware download process (e.g does it abort on TCP RST)? Is there any way to manually load the firmware? Thanks. Yang From budiwijaya at ipv6.or.id Tue Oct 11 07:52:05 2016 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Tue, 11 Oct 2016 12:52:05 +0700 Subject: [atlas] firmware download test? In-Reply-To: References: Message-ID: Usually, I formatted the disk to FAT32. Let the probe on and connected to internet for about 1/2 hour. On Tue, Oct 11, 2016 at 9:35 AM, Yang Yu wrote: > Hi, > > I have 2 probes that are connected but shown as offline even after > several power cycles. > > I performed USB stick troubleshooting procedures by removing the USB > stick and saw NO-USB SOS message. But after inserting the USB stick > there wasn't any new SOS messages. > > Plugged the USB stick to computer and saw corrupted file system. > Formatted the stick and inserted it back, still no SOS messages. What > kind of filesystem layout is expected on the stick? From what I read > the probe should automatically partition/format the stick. Maybe the > stick is bad. > > I do see a good amount of packet loss between the probe's network and > the registration server. How robust is the firmware download process > (e.g does it abort on TCP RST)? Is there any way to manually load the > firmware? Thanks. > > Yang > From yang.yu.list at gmail.com Tue Oct 11 07:56:31 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Tue, 11 Oct 2016 00:56:31 -0500 Subject: [atlas] firmware download test? In-Reply-To: References: Message-ID: On Tue, Oct 11, 2016 at 12:52 AM, Budiwijaya wrote: > Usually, I formatted the disk to FAT32. > Let the probe on and connected to internet for about 1/2 hour. In my case it has been on for much longer than an hour, still not even an SOS message. Does the probe stop sending SOS once the USB stick without firmware is inserted? Yang From ripe-atlas at noroutetohost.net Tue Oct 11 11:46:02 2016 From: ripe-atlas at noroutetohost.net (David Wilkinson) Date: Tue, 11 Oct 2016 10:46:02 +0100 Subject: [atlas] firmware download test? In-Reply-To: References: Message-ID: <7519d198-7ad1-7bfe-61d9-838c84efc34a@noroutetohost.net> Is the probe able to get an IP via DHCP? I have found that when you format the USB drive it looks for a DHCP server to get an IP before it will download the firmware, once it has formatted the USB drive it will then pull down the static IP configuration from the Atlas servers. On 11/10/16 06:56, Yang Yu wrote: > On Tue, Oct 11, 2016 at 12:52 AM, Budiwijaya wrote: >> Usually, I formatted the disk to FAT32. >> Let the probe on and connected to internet for about 1/2 hour. > In my case it has been on for much longer than an hour, still not even > an SOS message. > > Does the probe stop sending SOS once the USB stick without firmware is inserted? > > > Yang > From mir at ripe.net Wed Oct 12 09:49:01 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 12 Oct 2016 09:49:01 +0200 Subject: [atlas] New on RIPE Labs: What Can You Do with One Million RIPE Atlas Credits? In-Reply-To: References: Message-ID: <39e9cca5-d3c9-3743-30fb-c499cde01fbc@ripe.net> Dear colleagues, Ever wondered what to do with all those RIPE Atlas credits you earned? Find out on RIPE Labs how you can best spend your credits to check your services' connectivity and troubleshoot potential issues. https://labs.ripe.net/Members/becha/what-can-you-do-with-one-million-ripe-atlas-credits Kind regards, Mirjam Kuehne RIPE NCC From yang.yu.list at gmail.com Wed Oct 12 14:12:04 2016 From: yang.yu.list at gmail.com (Yang Yu) Date: Wed, 12 Oct 2016 07:12:04 -0500 Subject: [atlas] firmware download test? In-Reply-To: <7519d198-7ad1-7bfe-61d9-838c84efc34a@noroutetohost.net> References: <7519d198-7ad1-7bfe-61d9-838c84efc34a@noroutetohost.net> Message-ID: On Tue, Oct 11, 2016 at 4:46 AM, David Wilkinson wrote: > Is the probe able to get an IP via DHCP? Yes. It is configured for DHCP on portal also. > I have found that when you format the USB drive it looks for a DHCP server > to get an IP before it will download the firmware, once it has formatted the > USB drive it will then pull down the static IP configuration from the Atlas > servers. After a few more attempts one probe came online. Firmware download was probably a challenge due to high packet loss. It would be nice to have SOS messages indicating no firmware/firmware downloading. Yang From mkh at rqc.ru Thu Oct 13 09:46:13 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 13 Oct 2016 10:46:13 +0300 Subject: [atlas] Connect/disconnect timestamps on probe page disappeared Message-ID: Connect/disconnect timestamps on a probe page like https://atlas.ripe.net/probes/26656/#!tab-network disappeared this morning; durations still shown. Probably some problem with server side scripts? -- -- With Best Regards, Marat Khalili From camin at ripe.net Thu Oct 13 14:51:11 2016 From: camin at ripe.net (Chris Amin) Date: Thu, 13 Oct 2016 14:51:11 +0200 Subject: [atlas] Connect/disconnect timestamps on probe page disappeared In-Reply-To: References: Message-ID: <02d64ba5-8832-e62c-dedd-134d9d777ffb@ripe.net> On 13/10/2016 09:46, Marat Khalili wrote: > Connect/disconnect timestamps on a probe page like > https://atlas.ripe.net/probes/26656/#!tab-network disappeared this > morning; durations still shown. Probably some problem with server side > scripts? Dear Marat, Many thanks for pointing this issue out. There was indeed a problem with the presentation layer on this page, although the actual connect/disconnect events were properly recorded. We have now fixed this issue so you can see connect/disconnect timestamps again. Apologies for any inconvenience caused! Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mozafary at greenweb.ir Sat Oct 15 09:52:24 2016 From: mozafary at greenweb.ir (Mozafary Mohammad) Date: Sat, 15 Oct 2016 11:22:24 +0330 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: References: Message-ID: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> Hello I've got "Only anchors may be targeted." on HTTP measurement creation.Any body can advise what the problem is? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: onlyanchor.png Type: image/png Size: 126774 bytes Desc: not available URL: From mkh at rqc.ru Sat Oct 15 10:36:58 2016 From: mkh at rqc.ru (Marat Khalili) Date: Sat, 15 Oct 2016 11:36:58 +0300 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> Message-ID: I understand that you can only measure HTTP connectivity from probes to pre-defined RIPE anchor sites. You cannot measure HTTP connectivity of a real web sites, probably in fear of inadvertently DDOSing them. Which is pity, because with proper safeguards this feature would be very useful. -- With Best Regards, Marat Khalili On 15/10/16 10:52, Mozafary Mohammad wrote: > > > Hello > I've got "Only anchors may be targeted." on HTTP measurement > creation.Any body can advise what the problem is? > Thanks > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenqin.shao at telecom-paristech.fr Sun Oct 16 22:23:47 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Sun, 16 Oct 2016 22:23:47 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <3d9a75db-5236-07d4-4695-1fce463e0bf1@ripe.net> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> <3d9a75db-5236-07d4-4695-1fce463e0bf1@ripe.net> Message-ID: <896954DF-0D51-448B-9A6E-7E28C47F2DE0@telecom-paristech.fr> Hi list, A couple of weeks ago, I asked in this thread why some built-in measurements are missing, or not performed at scheduled interval. Cristel and Robert very kindly shared what they thought could be the causes: scheduling, probe reboot, updating task list, etc. The discussion gave me the idea to verify if there are as well missing measurements while the probe is powered and connected to an Atlas controller, i.e. probe seemly works in a good condition. Here, I would like to share one case among many I?ve observed where built-in measurements are missed continuously for a long time, even when the probe is well connected to a controller. Let?s look at a time window from '2016-06-16 21:53:20 +0000? to '2016-06-18 20:16:40 +0000? for probe 22144. First, I queried its connection events to Atlas controller (msm_id 7000). The result says the probe connected to a controller at '2016-06-16 21:54:19 +0000? and became disconnected at '2016-06-18 20:13:48 +0000?. Between these two moments, the probe is supposed to remain connected, and thus continuously powered. Then, I queried the built-in ping measurements toward b-root (msm_id 1010) within the time window. Here below the timestamps at which measurements are performed. [?2016-06-16 22:51:08 +0000?, '2016-06-17 02:07:08 +0000?, '2016-06-17 03:11:02 +0000', '2016-06-17 04:03:07 +0000?, '2016-06-17 05:23:03 +0000?, '2016-06-17 07:35:17 +0000', '2016-06-17 10:51:06 +0000?, '2016-06-17 14:07:04 +0000?, '2016-06-17 15:11:03 +0000?, '2016-06-17 17:23:06 +0000?, '2016-06-17 18:27:04 +0000?, '2016-06-17 20:39:04 +0000?, '2016-06-17 22:51:09 +0000?, '2016-06-17 23:55:03 +0000?, '2016-06-18 02:07:08 +0000', '2016-06-18 03:11:04 +0000?, '2016-06-18 06:27:05 +0000?, '2016-06-18 08:39:02 +0000', '2016-06-18 10:27:13 +0000?, '2016-06-18 10:51:08 +0000?, '2016-06-18 11:55:13 +0000', '2016-06-18 12:03:13 +0000?, '2016-06-18 15:11:04 +0000?, '2016-06-18 17:23:05 +0000', '2016-06-18 18:27:09 +0000?, '2016-06-18 18:43:13 +0000?, '2016-06-18 19:35:18 +0000', '2016-06-18 20:15:06 +0000?] We can see the intervals between neighbouring measurements are much larger than the planned value 240sec. I investigated as well other built-in ping measurements, say toward k-root (msm_id 1001). Here below are the timestamps: ['2016-06-16 22:51:08 +0000?, '2016-06-17 02:07:07 +0000?, '2016-06-17 03:11:05 +0000', '2016-06-17 04:03:08 +0000?, 2016-06-17 05:23:03 +0000?, '2016-06-17 07:35:17 +0000', '2016-06-17 10:51:10 +0000?, '2016-06-17 14:07:04 +0000?, '2016-06-17 15:11:04 +0000', ?] Very similar phenomenon is observed. Between the first two measurements in the above lists, there is an interval of more than one hour, which can hardly be explained by measurement secluding issue or temporarily high load. What?s more, the probe remained connected at those moments, therefore is free of reboot and power-off.. As a reference, probe 12657 has all the measurements coming at due interval within the time window. What could be the possible causes behind such missing is my doubt. And I do appreciate your thinkings on this so that the measurements can be processed and analysed with propre caution. Thanks. Regards, wenqin > On 02 Sep 2016, at 12:57, Robert Kisteleki wrote: > > On 2016-09-02 12:20, Wenqin SHAO wrote: >> Thanks for confirming. The specified frequency is indeed well respected. When there is no data-missing, the interval shift rarely exceed 14s, small compared to 240s the scheduled interval. >> What intrigues me is that the exact phase/timing is as well kept after power cut and reboot. > > The probes have a crontab-like mechanism to remember what they need to do. > As long as their clock is more or less ok, they will stick to the > pre-allocated times and tasks. > >> By the way, can a measurement be as well skipped, as designed behaviour, due to scheduling issues mentioned by @Cristel? > > We're trying to avoid overloading probes, but not everything is under our > full control. Some measurements can pile up; Cristel & Randy & co. had a > paper about the observed (worst-case) behaviour. > > Regards, > Robert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Mon Oct 17 16:35:45 2016 From: camin at ripe.net (Chris Amin) Date: Mon, 17 Oct 2016 16:35:45 +0200 Subject: [atlas] Out of date system probe tags Message-ID: Dear all, Some of you have noticed that certain system tags (see below) remained applied to probes when they should have been removed. This is because the process that adds and removes these tags was temporarily disabled following the service issues that we experienced earlier in the month. This process has now been re-enabled after verifying that it was not a cause of the service downtime, and these tags have been applied correctly. The affected tags were: * Flaky connection * Firewall problem suspected * DNS problem suspected * No flash drive * Readonly flash drive * Hardware problem suspected Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From compyblog at gmail.com Tue Oct 18 07:46:07 2016 From: compyblog at gmail.com (Andre Heinrichs) Date: Tue, 18 Oct 2016 07:46:07 +0200 Subject: [atlas] probe offline - troubleshooting requested Message-ID: Last night my probe (#29384) was declared offline after the daily Internet disconnection my FritzBox executes to keep the provider from disconnecting me after 24 hours online. According to the SOS history the probe gets DNS requests out but somehow fails to connect completely. I tried rebooting every network component i could locally get my hands on but that didn't seem to help much. The LEDs on the probe don't actually fit any of the descriptions from the FAQ: They are On, Off, fast(er) blink (at least if compared to shortly after booting (Network Test?), On, On. I'm guessing it means the network somehow managed to fail. Although I don't notice anything missing from what I did on the network this morning. Any ideas what I could try to get the probe reconnected? Just to be complete: Here are the last lines of the SOS history: 62.109.121.35 2016-10-18 05:43:27 A 3h 59m 62.109.121.35 2016-10-18 05:43:27 AAAA 3h 59m TIA, Andre, currently not in reach of the probe From mkh at rqc.ru Tue Oct 18 10:04:04 2016 From: mkh at rqc.ru (Marat Khalili) Date: Tue, 18 Oct 2016 11:04:04 +0300 Subject: [atlas] Problems with f.root-servers.net in Russia? Message-ID: Sorry for slight offtopic, but does anybody know what is up with Russian instance of F root server? I observe periods of very high packet loss since 11th of October. I used to measure my own internet connectivity pinging it, but seems like by internet works better than that of the root server. Here's a measurement with 50 Russian probes, 34 of them show "Unreachable" right now: https://atlas.ripe.net/measurements/6886549/#!probes -- -- With Best Regards, Marat Khalili From sebastian.wiesinger at noris.net Tue Oct 18 10:11:46 2016 From: sebastian.wiesinger at noris.net (Sebastian Wiesinger) Date: Tue, 18 Oct 2016 10:11:46 +0200 Subject: [atlas] Problems with f.root-servers.net in Russia? In-Reply-To: References: Message-ID: <20161018081146.GA2859@sol.office.noris.de> * Marat Khalili [2016-10-18 10:04]: > Sorry for slight offtopic, but does anybody know what is up with Russian > instance of F root server? I observe periods of very high packet loss since > 11th of October. I used to measure my own internet connectivity pinging it, > but seems like by internet works better than that of the root server. > > Here's a measurement with 50 Russian probes, 34 of them show "Unreachable" > right now: https://atlas.ripe.net/measurements/6886549/#!probes You might get an answer on the dns-operations mailinglist. Root server operatiors are reading there. Best Regards Sebastian -- noris network AG - Thomas-Mann-Stra?e 16-20 - D-90471 N?rnberg Tel +49-911-9352-1335 - Fax +49-911-9352-100 http://www.noris.de - The IT-Outsourcing Company Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel - Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG N?rnberg HRB 17689 From romeo.zwart at ripe.net Tue Oct 18 10:37:57 2016 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Tue, 18 Oct 2016 10:37:57 +0200 Subject: [atlas] Temporary Reduction of Available History on RIPE Atlas and RIPEstat Message-ID: <56f32ca4-d32d-7b61-c146-f62d7f6fdb80@ripe.net> Dear colleagues, Today, Tuesday, 18 October 2016, between 09:00 and 10:00 UTC, the back-end storage cluster for RIPE Atlas and RIPEstat will be switched to a backup environment. This is part of planned maintenance work. The backup facility has a more limited amount of storage space, which means that RIPEstat and RIPE Atlas, including specific applications like DNSMON and DomainMon, will not serve data older than one year. We expect this to have no impact on ongoing RIPE Atlas measurements, scheduling new measurements, or the retrieval of more recent data from RIPE Atlas, RIPEstat or DNSMON. We apologise for any inconvenience. Kind regards, Romeo Zwart From mir at ripe.net Tue Oct 18 11:39:27 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 18 Oct 2016 11:39:27 +0200 Subject: [atlas] Shall we continue non-public measurements in RIPE Atlas? In-Reply-To: References: Message-ID: Dear colleagues, "Non-public measurements" is a feature of RIPE Atlas that allows users to use the infrastructure to measure things while not sharing those results with the public. Is that still a useful feature? Should it exist in the future? For more details, see this new post on RIPE Labs: https://labs.ripe.net/Members/kistel/non-public-measurements-in-ripe-atlas Please also take the polls at the end of the article. Kind regards, Mirjam Kuehne RIPE NCC From philip.homburg at ripe.net Tue Oct 18 12:24:25 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 18 Oct 2016 12:24:25 +0200 Subject: [atlas] probe offline - troubleshooting requested In-Reply-To: References: Message-ID: <3af3a709-9198-06d7-19a1-ae367d03a58e@ripe.net> On 2016/10/18 7:46 , Andre Heinrichs wrote: > Any ideas what I could try to get the probe reconnected? > > Just to be complete: Here are the last lines of the SOS history: > 62.109.121.35 2016-10-18 05:43:27 A 3h 59m > 62.109.121.35 2016-10-18 05:43:27 AAAA 3h 59m The best thing to try is to reflash the USB stick (i.e. connect the probe without USB stick, wait for a out 10 minutes and insert the USB stick). Unfortunately, corruption of the filesystem on the USB stick can result in weird behavior, like your probe is showing. SOS works fine but it doesn't connect. From mir at ripe.net Wed Oct 19 13:57:17 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 19 Oct 2016 13:57:17 +0200 Subject: [atlas] New on RIPE Labs: Orange Blacklisting: A Case for Measuring Censorship In-Reply-To: References: Message-ID: Dear colleagues, Please find a short a article on measuring censorship on RIPE Labs: https://labs.ripe.net/Members/stephane_bortzmeyer/orange-blacklisting-a-case-for-measuring-censorship Kind regards, Mirjam Kuehne RIPE NCC From compyblog at gmail.com Wed Oct 19 14:18:41 2016 From: compyblog at gmail.com (Andre Heinrichs) Date: Wed, 19 Oct 2016 14:18:41 +0200 Subject: [atlas] ripe-atlas Digest, Vol 62, Issue 14 In-Reply-To: References: Message-ID: On Wed, Oct 19, 2016 at 12:00 PM, wrote: > Date: Tue, 18 Oct 2016 12:24:25 +0200 > From: Philip Homburg > To: ripe-atlas at ripe.net > Subject: Re: [atlas] probe offline - troubleshooting requested > Message-ID: <3af3a709-9198-06d7-19a1-ae367d03a58e at ripe.net> > Content-Type: text/plain; charset=utf-8 > > On 2016/10/18 7:46 , Andre Heinrichs wrote: >> Any ideas what I could try to get the probe reconnected? >> >> Just to be complete: Here are the last lines of the SOS history: >> 62.109.121.35 2016-10-18 05:43:27 A 3h 59m >> 62.109.121.35 2016-10-18 05:43:27 AAAA 3h 59m > > The best thing to try is to reflash the USB stick (i.e. connect the > probe without USB stick, wait for a out 10 minutes and insert the USB > stick). > > Unfortunately, corruption of the filesystem on the USB stick can result > in weird behavior, like your probe is showing. SOS works fine but it > doesn't connect. Just for the record: the probe works again after I did the USB fix Philip described. I'm guessing the status tab only showed the hint about Firewall trouble because that would have been another possible cause for the symptoms. Thanks, Andre From robert at ripe.net Wed Oct 19 14:23:53 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 19 Oct 2016 14:23:53 +0200 Subject: [atlas] ripe-atlas Digest, Vol 62, Issue 14 In-Reply-To: References: Message-ID: <531823f0-fa48-e6d4-eb51-6f732f0a3de9@ripe.net> > Just for the record: the probe works again after I did the USB fix > Philip described. I'm guessing the status tab only showed the hint > about Firewall trouble because that would have been another possible > cause for the symptoms. The status tab is trying to be helpful in providing the "best guess" of what's wrong, based on the observable symptoms at the infrastructure end. This works most of the time, as long as the problems are caused by network (mis)configuration. But as the example shows it's not always accurate in other cases. We'll most likely cover more failure cases as we discover and understand them. Regards, Robert From astrikos at ripe.net Wed Oct 19 14:28:21 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 19 Oct 2016 14:28:21 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <896954DF-0D51-448B-9A6E-7E28C47F2DE0@telecom-paristech.fr> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> <3d9a75db-5236-07d4-4695-1fce463e0bf1@ripe.net> <896954DF-0D51-448B-9A6E-7E28C47F2DE0@telecom-paristech.fr> Message-ID: <2634baef-8720-f897-417d-851633f86eed@ripe.net> Hi Wenqin, that was a weird case where specific probe has time synchronization issues. We saw a lot of debug messages in our raw logs coming from probe complaining about time sync issues. If you have more examples including other probes please send us details and we will happily check it for you. Regards, Andreas On 16/10/16 22:23, Wenqin SHAO wrote: > Hi list, > > A couple of weeks ago, I asked in this thread why some built-in > measurements are missing, or not performed at scheduled interval. > Cristel and Robert very kindly shared what they thought could be the > causes: scheduling, probe reboot, updating task list, etc. > > The discussion gave me the idea to verify if there are as well missing > measurements while the probe is powered and connected to an Atlas > controller, i.e. probe seemly works in a good condition. > > Here, I would like to share one case among many I?ve observed where > built-in measurements are missed continuously for a long time, even > when the probe is well connected to a controller. > > Let?s look at a time window from '2016-06-16 21:53:20 +0000? to > '2016-06-18 20:16:40 +0000? for probe 22144. > > First, I queried its connection events to Atlas controller (msm_id 7000). > The result says the probe connected to a controller at '2016-06-16 > 21:54:19 +0000? and became disconnected at '2016-06-18 20:13:48 > +0000?. Between these two moments, the probe is supposed to remain > connected, and thus continuously powered. > > Then, I queried the built-in ping measurements toward b-root (msm_id > 1010) within the time window. > Here below the timestamps at which measurements are performed. > [?2016-06-16 22:51:08 +0000?, '2016-06-17 02:07:08 +0000?, '2016-06-17 > 03:11:02 +0000', > '2016-06-17 04:03:07 +0000?, '2016-06-17 05:23:03 +0000?, '2016-06-17 > 07:35:17 +0000', > '2016-06-17 10:51:06 +0000?, '2016-06-17 14:07:04 +0000?, '2016-06-17 > 15:11:03 +0000?, > '2016-06-17 17:23:06 +0000?, '2016-06-17 18:27:04 +0000?, '2016-06-17 > 20:39:04 +0000?, > '2016-06-17 22:51:09 +0000?, '2016-06-17 23:55:03 +0000?, '2016-06-18 > 02:07:08 +0000', > '2016-06-18 03:11:04 +0000?, '2016-06-18 06:27:05 +0000?, '2016-06-18 > 08:39:02 +0000', > '2016-06-18 10:27:13 +0000?, '2016-06-18 10:51:08 +0000?, '2016-06-18 > 11:55:13 +0000', > '2016-06-18 12:03:13 +0000?, '2016-06-18 15:11:04 +0000?, '2016-06-18 > 17:23:05 +0000', > '2016-06-18 18:27:09 +0000?, '2016-06-18 18:43:13 +0000?, '2016-06-18 > 19:35:18 +0000', > '2016-06-18 20:15:06 +0000?] > We can see the intervals between neighbouring measurements are much > larger than the planned value 240sec. > > I investigated as well other built-in ping measurements, say toward > k-root (msm_id 1001). > Here below are the timestamps: > ['2016-06-16 22:51:08 +0000?, '2016-06-17 02:07:07 +0000?, '2016-06-17 > 03:11:05 +0000', > '2016-06-17 04:03:08 +0000?, 2016-06-17 05:23:03 +0000?, '2016-06-17 > 07:35:17 +0000', > '2016-06-17 10:51:10 +0000?, '2016-06-17 14:07:04 +0000?, '2016-06-17 > 15:11:04 +0000', > ?] > Very similar phenomenon is observed. > > Between the first two measurements in the above lists, there is an > interval of more than one hour, which can hardly be explained by > measurement secluding issue or temporarily high load. > What?s more, the probe remained connected at those moments, therefore > is free of reboot and power-off.. > As a reference, probe 12657 has all the measurements coming at due > interval within the time window. > > What could be the possible causes behind such missing is my doubt. > And I do appreciate your thinkings on this so that the measurements > can be processed and analysed with propre caution. > > Thanks. > > Regards, > wenqin >> On 02 Sep 2016, at 12:57, Robert Kisteleki > > wrote: >> >> On 2016-09-02 12:20, Wenqin SHAO wrote: >>> Thanks for confirming. The specified frequency is indeed well >>> respected. When there is no data-missing, the interval shift rarely >>> exceed 14s, small compared to 240s the scheduled interval. >>> What intrigues me is that the exact phase/timing is as well kept >>> after power cut and reboot. >> >> The probes have a crontab-like mechanism to remember what they need >> to do. >> As long as their clock is more or less ok, they will stick to the >> pre-allocated times and tasks. >> >>> By the way, can a measurement be as well skipped, as designed >>> behaviour, due to scheduling issues mentioned by @Cristel? >> >> We're trying to avoid overloading probes, but not everything is under our >> full control. Some measurements can pile up; Cristel & Randy & co. had a >> paper about the observed (worst-case) behaviour. >> >> Regards, >> Robert >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wenqin.shao at telecom-paristech.fr Thu Oct 20 09:21:18 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Thu, 20 Oct 2016 09:21:18 +0200 Subject: [atlas] Actual measurement interval much larger than planned In-Reply-To: <2634baef-8720-f897-417d-851633f86eed@ripe.net> References: <160E4483-6CE5-49E8-949C-B862EB9B4CB8@telecom-paristech.fr> <84240a28-f63b-3464-4de0-05ef15a4044c@ripe.net> <71de87fe-4411-5162-bc20-a551b5f1d67c@ripe.net> <3d9a75db-5236-07d4-4695-1fce463e0bf1@ripe.net> <896954DF-0D51-448B-9A6E-7E28C47F2DE0@telecom-paristech.fr> <2634baef-8720-f897-417d-851633f86eed@ripe.net> Message-ID: <6BC5F320-124B-4ADA-9508-B2EDD39CBB6D@telecom-paristech.fr> Hi Andreas, Thank you for showing interest and looking into this case. Here attached is a non-exhaustive list of the probes and corresponding time vicinity where missing happens for built-in ping toward b-root (mom id 1010). Hope it could be useful. Regards, wenqin > On 19 Oct 2016, at 14:28, Andreas Strikos wrote: > > Hi Wenqin, > > that was a weird case where specific probe has time synchronization issues. > We saw a lot of debug messages in our raw logs coming from probe complaining about time sync issues. > If you have more examples including other probes please send us details and we will happily check it for you. > > Regards, > Andreas > > On 16/10/16 22:23, Wenqin SHAO wrote: >> Hi list, >> >> A couple of weeks ago, I asked in this thread why some built-in measurements are missing, or not performed at scheduled interval. >> Cristel and Robert very kindly shared what they thought could be the causes: scheduling, probe reboot, updating task list, etc. >> >> The discussion gave me the idea to verify if there are as well missing measurements while the probe is powered and connected to an Atlas controller, i.e. probe seemly works in a good condition. >> >> Here, I would like to share one case among many I?ve observed where built-in measurements are missed continuously for a long time, even when the probe is well connected to a controller. >> >> Let?s look at a time window from '2016-06-16 21:53:20 +0000? to '2016-06-18 20:16:40 +0000? for probe 22144. >> >> First, I queried its connection events to Atlas controller (msm_id 7000). >> The result says the probe connected to a controller at '2016-06-16 21:54:19 +0000? and became disconnected at '2016-06-18 20:13:48 +0000?. Between these two moments, the probe is supposed to remain connected, and thus continuously powered. >> >> Then, I queried the built-in ping measurements toward b-root (msm_id 1010) within the time window. >> Here below the timestamps at which measurements are performed. >> [?2016-06-16 22:51:08 +0000?, '2016-06-17 02:07:08 +0000?, '2016-06-17 03:11:02 +0000', >> '2016-06-17 04:03:07 +0000?, '2016-06-17 05:23:03 +0000?, '2016-06-17 07:35:17 +0000', >> '2016-06-17 10:51:06 +0000?, '2016-06-17 14:07:04 +0000?, '2016-06-17 15:11:03 +0000?, >> '2016-06-17 17:23:06 +0000?, '2016-06-17 18:27:04 +0000?, '2016-06-17 20:39:04 +0000?, >> '2016-06-17 22:51:09 +0000?, '2016-06-17 23:55:03 +0000?, '2016-06-18 02:07:08 +0000', >> '2016-06-18 03:11:04 +0000?, '2016-06-18 06:27:05 +0000?, '2016-06-18 08:39:02 +0000', >> '2016-06-18 10:27:13 +0000?, '2016-06-18 10:51:08 +0000?, '2016-06-18 11:55:13 +0000', >> '2016-06-18 12:03:13 +0000?, '2016-06-18 15:11:04 +0000?, '2016-06-18 17:23:05 +0000', >> '2016-06-18 18:27:09 +0000?, '2016-06-18 18:43:13 +0000?, '2016-06-18 19:35:18 +0000', >> '2016-06-18 20:15:06 +0000?] >> We can see the intervals between neighbouring measurements are much larger than the planned value 240sec. >> >> I investigated as well other built-in ping measurements, say toward k-root (msm_id 1001). >> Here below are the timestamps: >> ['2016-06-16 22:51:08 +0000?, '2016-06-17 02:07:07 +0000?, '2016-06-17 03:11:05 +0000', >> '2016-06-17 04:03:08 +0000?, 2016-06-17 05:23:03 +0000?, '2016-06-17 07:35:17 +0000', >> '2016-06-17 10:51:10 +0000?, '2016-06-17 14:07:04 +0000?, '2016-06-17 15:11:04 +0000', >> ?] >> Very similar phenomenon is observed. >> >> Between the first two measurements in the above lists, there is an interval of more than one hour, which can hardly be explained by measurement secluding issue or temporarily high load. >> What?s more, the probe remained connected at those moments, therefore is free of reboot and power-off.. >> As a reference, probe 12657 has all the measurements coming at due interval within the time window. >> >> What could be the possible causes behind such missing is my doubt. >> And I do appreciate your thinkings on this so that the measurements can be processed and analysed with propre caution. >> >> Thanks. >> >> Regards, >> wenqin >>> On 02 Sep 2016, at 12:57, Robert Kisteleki > wrote: >>> >>> On 2016-09-02 12:20, Wenqin SHAO wrote: >>>> Thanks for confirming. The specified frequency is indeed well respected. When there is no data-missing, the interval shift rarely exceed 14s, small compared to 240s the scheduled interval. >>>> What intrigues me is that the exact phase/timing is as well kept after power cut and reboot. >>> >>> The probes have a crontab-like mechanism to remember what they need to do. >>> As long as their clock is more or less ok, they will stick to the >>> pre-allocated times and tasks. >>> >>>> By the way, can a measurement be as well skipped, as designed behaviour, due to scheduling issues mentioned by @Cristel? >>> >>> We're trying to avoid overloading probes, but not everything is under our >>> full control. Some measurements can pile up; Cristel & Randy & co. had a >>> paper about the observed (worst-case) behaviour. >>> >>> Regards, >>> Robert >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: example.csv Type: text/csv Size: 72674 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From georg.kahest at internet.ee Thu Oct 20 13:06:52 2016 From: georg.kahest at internet.ee (Georg Kahest) Date: Thu, 20 Oct 2016 14:06:52 +0300 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> Message-ID: <34c51d73-5577-ea04-57b7-903c94cd924e@internet.ee> 15.10.2016 11:36 Marat Khalili kirjutas: > I understand that you can only measure HTTP connectivity from probes to > pre-defined RIPE anchor sites. You cannot measure HTTP connectivity of a > real web sites, probably in fear of inadvertently DDOSing them. Which is > pity, because with proper safeguards this feature would be very useful. > > -- > > With Best Regards, > Marat Khalili > > > On 15/10/16 10:52, Mozafary Mohammad wrote: >> >> >> Hello >> I've got "Only anchors may be targeted." on HTTP measurement >> creation.Any body can advise what the problem is? >> Thanks >> > Indeed, it would be really useful to be able to measure http/https sites from atlas probes. -- Georg Kahest System Administrator / S?steemiadministraator Eesti Interneti SA Paldiski mnt 80, 10617 Tallinn Tel 727 1016 www.internet.ee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From josephb at f-m.fm Fri Oct 21 06:49:07 2016 From: josephb at f-m.fm (Joseph B) Date: Fri, 21 Oct 2016 15:19:07 +1030 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: <34c51d73-5577-ea04-57b7-903c94cd924e@internet.ee> References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> <34c51d73-5577-ea04-57b7-903c94cd924e@internet.ee> Message-ID: <1477025347.3944334.762766313.32501464@webmail.messagingengine.com> > Indeed, it would be really useful to be able to measure http/https sites > from atlas probes. As a network operator, even if those measurements were only allowed inside our own (or downstream) AS's that would be vary useful. Cheers, Joseph From mkh at rqc.ru Fri Oct 21 09:29:59 2016 From: mkh at rqc.ru (Marat Khalili) Date: Fri, 21 Oct 2016 10:29:59 +0300 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: <1477025347.3944334.762766313.32501464@webmail.messagingengine.com> References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> <34c51d73-5577-ea04-57b7-903c94cd924e@internet.ee> <1477025347.3944334.762766313.32501464@webmail.messagingengine.com> Message-ID: I don't know how hard it'd be to implement, but it'd be natural to use robots.txt for this. Something like: > User-agent: RIPE-ATLAS > Allow: /test-me-here/ It would need to be checked both on control centers (to make sure probing is allowed at all) and on probes (to react on changes quickly). -- With Best Regards, Marat Khalili On 21/10/16 07:49, Joseph B wrote: >> Indeed, it would be really useful to be able to measure http/https sites >> from atlas probes. > As a network operator, even if those measurements were only allowed > inside our own (or downstream) AS's that would be vary useful. > > Cheers, > > Joseph > From thomas at bartelmess.io Fri Oct 21 15:05:46 2016 From: thomas at bartelmess.io (Thomas Bartelmess) Date: Fri, 21 Oct 2016 09:05:46 -0400 Subject: [atlas] Error: Only anchors may be targeted. In-Reply-To: References: <54f29c64-0f4a-ed5e-c1eb-1f99f101ff2c@greenweb.ir> <34c51d73-5577-ea04-57b7-903c94cd924e@internet.ee> <1477025347.3944334.762766313.32501464@webmail.messagingengine.com> Message-ID: <670C3512-617B-4DCA-A195-6FE39488443C@bartelmess.io> My wish list would look like: - Limits on how many tests are run against a specific target (globally) - Robots.txt/SRV Record to increase the limit - Ability to see if ISP injected Headers (Supercookies) - Ability if the server changes anything about the website (Ads etc). - Verify TLS certificates - Thomas > On Oct 21, 2016, at 3:29 , Marat Khalili wrote: > > I don't know how hard it'd be to implement, but it'd be natural to use robots.txt for this. Something like: > >> User-agent: RIPE-ATLAS >> Allow: /test-me-here/ > It would need to be checked both on control centers (to make sure probing is allowed at all) and on probes (to react on changes quickly). > > > -- > > With Best Regards, > Marat Khalili > > On 21/10/16 07:49, Joseph B wrote: >>> Indeed, it would be really useful to be able to measure http/https sites >>> from atlas probes. >> As a network operator, even if those measurements were only allowed >> inside our own (or downstream) AS's that would be vary useful. >> >> Cheers, >> >> Joseph >> > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4564 bytes Desc: not available URL: From jzp-ripeatlas at rsuc.gweep.net Thu Oct 27 17:24:40 2016 From: jzp-ripeatlas at rsuc.gweep.net (Joe Provo) Date: Thu, 27 Oct 2016 11:24:40 -0400 Subject: [atlas] Probe pickup at meeting? Message-ID: <20161027152440.GB89092@gweep.net> Hey, Are any $SMALLNUM probes available for pickup tonight/tomorrow? I found I only have one "to be distributed" probe left, and in a couple weeks will be taking holiday in Columbia (in current coverage voids :-). Cheers! Joe -- RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG From mgalante at ripe.net Thu Oct 27 17:54:24 2016 From: mgalante at ripe.net (Michela Galante) Date: Thu, 27 Oct 2016 17:54:24 +0200 Subject: [atlas] Probe pickup at meeting? In-Reply-To: <20161027152440.GB89092@gweep.net> References: <20161027152440.GB89092@gweep.net> Message-ID: <9E14CE5B-2753-4F84-B2A3-A5336EF9F054@ripe.net> Hi Joe, Thank you for your email! I'll reply to you shortly. Michela RIPE NCC > On 27 Oct 2016, at 17:24, Joe Provo wrote: > > Hey, > > Are any $SMALLNUM probes available for pickup tonight/tomorrow? > I found I only have one "to be distributed" probe left, and in > a couple weeks will be taking holiday in Columbia (in current > coverage voids :-). > > Cheers! > > Joe > > -- > RSUC / GweepNet / Spunk / FnB / CotSG / Usenix / NANOG > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: