From cs at fnx.li Tue Aug 1 16:37:12 2017 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Tue, 1 Aug 2017 16:37:12 +0200 Subject: [atlas] SOS History empty since 2017-07-20 In-Reply-To: References: Message-ID: Thanks! :-) -- Mit freundlichen Gr??en Christian Schr?tter From mgalante at ripe.net Fri Aug 4 16:20:59 2017 From: mgalante at ripe.net (Michela Galante) Date: Fri, 4 Aug 2017 16:20:59 +0200 Subject: [atlas] Update to RIPE Atlas Anchors Article Message-ID: <89F712B3-AC7B-41FD-8441-82B1294BD999@ripe.net> Dear colleagues, We just published an update to the RIPE Labs article ?The Next Generation of RIPE Atlas Anchors?. You can read it here: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors Best regards, Michela Galante RIPE NCC From hsalgado at nic.cl Fri Aug 4 16:29:39 2017 From: hsalgado at nic.cl (Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?=) Date: Fri, 4 Aug 2017 10:29:39 -0400 Subject: [atlas] Update to RIPE Atlas Anchors Article In-Reply-To: <89F712B3-AC7B-41FD-8441-82B1294BD999@ripe.net> References: <89F712B3-AC7B-41FD-8441-82B1294BD999@ripe.net> Message-ID: <20170804142939.GD2365@nic.cl> Dear Michela, Thanks for the update. One doubt about the existing anchors, are you planning to update all of them at once? Or it will be incrementally deployed to new hosts, and then at end of life on existing ones? Thanks, Hugo On 16:20 04/08, Michela Galante wrote: > Dear colleagues, > > We just published an update to the RIPE Labs article ?The Next Generation of RIPE Atlas Anchors?. > You can read it here: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors > > Best regards, > Michela Galante > RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From mgalante at ripe.net Mon Aug 7 17:09:45 2017 From: mgalante at ripe.net (Michela Galante) Date: Mon, 7 Aug 2017 17:09:45 +0200 Subject: [atlas] Update to RIPE Atlas Anchors Article In-Reply-To: <20170804142939.GD2365@nic.cl> References: <89F712B3-AC7B-41FD-8441-82B1294BD999@ripe.net> <20170804142939.GD2365@nic.cl> Message-ID: Hi Hugo, > On 4 Aug 2017, at 16:29, Hugo Salgado-Hern?ndez wrote: > > Dear Michela, > Thanks for the update. One doubt about the existing anchors, > are you planning to update all of them at once? Or it will > be incrementally deployed to new hosts, and then at end of life > on existing ones? We will continue to support the v2 anchors ("Soekris") in parallel with the v3 anchors (new hardware) so there is no need to replace the hardware. Regarding new hosts, we stopped confirming new anchor applications until a decision is made on the new hardware. When we resume operations by mid September and approve the applications, the new hosts should order the v3 anchor. I hope this answers your questions. Best regards, Michela > > Thanks, > > Hugo > > On 16:20 04/08, Michela Galante wrote: >> Dear colleagues, >> >> We just published an update to the RIPE Labs article ?The Next Generation of RIPE Atlas Anchors?. >> You can read it here: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors >> >> Best regards, >> Michela Galante >> RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP URL: From BECHA at ripe.net Tue Aug 8 10:59:54 2017 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 8 Aug 2017 10:59:54 +0200 Subject: [atlas] Join RIPE NCC Hackathon Version 6, 4-5. November, Copenhagen, Denmark In-Reply-To: <0a863911-4afa-caf8-6a74-623e799b1d70@ripe.net> References: <0a863911-4afa-caf8-6a74-623e799b1d70@ripe.net> Message-ID: <3103eb90-7894-e55b-499e-e3c41d3e75fa@ripe.net> Dear colleagues, The sixth RIPE NCC hackathon will take place on Saturday and Sunday, 4-5 November 2017 in Copenhagen, Denmark. The topic is: IPv6! We're looking for creative thinkers: front-end developers, UI designers, network operators, researchers, hackers and other enthusiastic coders, to help us develop new tools that would enable deployment of IPv6 and visualizations based on IPv6 measurements data. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/version6/#!application-form *The application deadline is 9.9.* (9th September) We look forward to seeing you there! Find out more in this RIPE Labs article: https://labs.ripe.net/Members/becha/join-the-ripe-ncc-hackathon-version-6 Regards, Vesna Manojlovic Community Builder RIPE NCC From mgalante at ripe.net Tue Aug 8 11:06:24 2017 From: mgalante at ripe.net (Michela Galante) Date: Tue, 8 Aug 2017 11:06:24 +0200 Subject: [atlas] Update to RIPE Atlas Anchors Article In-Reply-To: <20170804142939.GD2365@nic.cl> References: <89F712B3-AC7B-41FD-8441-82B1294BD999@ripe.net> <20170804142939.GD2365@nic.cl> Message-ID: Hi Hugo, > On 4 Aug 2017, at 16:29, Hugo Salgado-Hern?ndez wrote: > > Dear Michela, > Thanks for the update. One doubt about the existing anchors, > are you planning to update all of them at once? Or it will > be incrementally deployed to new hosts, and then at end of life > on existing ones? We will continue to support the v2 anchors ("Soekris") in parallel with the v3 anchors (new hardware) so there is no need to replace the hardware. Regarding new hosts, we stopped confirming new anchor applications until a decision is made on the new hardware. When we resume operations by mid September and approve the applications, the new hosts should order the v3 anchor. I hope this answers your questions. Best regards, Michela > > Thanks, > > Hugo > > On 16:20 04/08, Michela Galante wrote: >> Dear colleagues, >> >> We just published an update to the RIPE Labs article ?The Next Generation of RIPE Atlas Anchors?. >> You can read it here: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors >> >> Best regards, >> Michela Galante >> RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP URL: From robert at ripe.net Tue Aug 8 13:44:37 2017 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 8 Aug 2017 13:44:37 +0200 Subject: [atlas] Test, please ignore Message-ID: From mcandela at ripe.net Wed Aug 9 10:50:34 2017 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 9 Aug 2017 10:50:34 +0200 Subject: [atlas] Updated RIPE Atlas measurements listing page Message-ID: Dear RIPE Atlas users, With the increasing number of measurements supported by RIPE Atlas, the measurement listing page [1] was slowing down. Today we deployed a new release with improved performance and functionality. The new page contains a re-arrangement of the tabs, allowing the user to more easily access the types of measurement they are interested in. The searching has also been improved, allowing more precise filtering of the measurements. If you experience any issues, try to refresh the cache for the page. And of course, let us know if you have any feedback about this change. Best regards, Massimo Candela Software Engineer - RIPE Atlas project [1] https://atlas.ripe.net/measurements/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajarnspencer at gmail.com Tue Aug 15 07:58:19 2017 From: ajarnspencer at gmail.com (Spencer Littlewood) Date: Tue, 15 Aug 2017 07:58:19 +0200 Subject: [atlas] Your probe is currently disconnected In-Reply-To: Message-ID: Dear Conrad, Your Name and Website has turned up in a HSTS Plist coocies file on my Mac, along with the names and websites of many other hacker Websites, and i wonder why. I am not a Hacker, but my friend in Singapore is Chief Comissioner of the Cybercrime Division, and i wanted to ask you before sending all the data i have to hjim (including the info about you which is in my HSTS plist and all its redirects), if you have a moral and decent explanation for why your websites and scripts seem to be trying to invade my mac? Otherwise i shall be forced to send the data to my friend at the International Cybercrime Division of Singapore, for him to investigate for me. Please explain why you are in my binary cookies and hsts plists? Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From emil at emilstahl.dk Tue Aug 15 18:48:48 2017 From: emil at emilstahl.dk (Emil Stahl) Date: Tue, 15 Aug 2017 18:48:48 +0200 Subject: [atlas] Your probe is currently disconnected In-Reply-To: Message-ID: Hi Spencer This is clearly the wrong forum. Not sure if you are trolling or not.. Anyone can submit their domains to the HSTS preload list: list, and if the domain live up to the requirements, it will be included in the HSTS preload list, and hardcoded (compiled) in the next browser release. No one is hacking your Mac. https://hstspreload.org/ https://tools.ietf.org/html/rfc6797 Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mkh at rqc.ru Thu Aug 17 09:15:06 2017 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 17 Aug 2017 10:15:06 +0300 Subject: [atlas] Notify time setting does not work Message-ID: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> Probes have very handy feature of sending a notification when the probe is disconnected. I have mine set to 10 minutes, however last two such notifications only arrived 30 minutes after the probe was disconnected. Probe #26656 if that's important. One would think that probe itself was slow to react, but last time I monitored outage from the very beginning and the probe's page correctly showed "Disconnected for: 1 minute" and so on. Neither it is a case of slow email arrival, since according to Received header in the email it was indeed received from worker1.atlas.ripe.net 30+ minutes after disconnection time mentioned in the email body. Can it be that "Notify time" setting just doesn't work and some default value of 30 minutes is used? -- With Best Regards, Marat Khalili From carsten at schiefner.de Thu Aug 17 12:20:16 2017 From: carsten at schiefner.de (Carsten Schiefner) Date: Thu, 17 Aug 2017 12:20:16 +0200 Subject: [atlas] Notify time setting does not work In-Reply-To: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> Message-ID: Hi Marat, On 17.08.2017 09:15, Marat Khalili wrote: > [...] Neither it is a case of > slow email arrival, since according to Received header in the email it > was indeed received from worker1.atlas.ripe.net 30+ minutes after > disconnection time mentioned in the email body. smells a bit as if greylisting would have been deployed for 'rqc.ru'. Cheers, -C. From mkh at rqc.ru Thu Aug 17 13:02:04 2017 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 17 Aug 2017 14:02:04 +0300 Subject: [atlas] Notify time setting does not work In-Reply-To: References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> Message-ID: <86c1207c-cda6-d777-aef9-d2cc55244a64@rqc.ru> > smells a bit as if greylisting would have been deployed for 'rqc.ru'. You may be right, but why? It all happens still well within RIPE: > Received: from worker1.atlas.ripe.net ([193.0.19.216]) > by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) > (Exim 4.89) > (envelope-from ) > id 1dhueG-0001AI-Sl > for redacted at rqc.ru; Wed, 16 Aug 2017 11:30:02 +0200 > Received: from [127.0.0.1] (helo=worker1.atlas.ripe.net) > by worker1.atlas.ripe.net with esmtp (Exim 4.89) > (envelope-from ) > id 1dhueG-0003zF-Qf > for redacted at rqc.ru; Wed, 16 Aug 2017 09:30:00 +0000 > Content-Type: text/plain; charset="utf-8" > MIME-Version: 1.0 > Content-Transfer-Encoding: 7bit > Subject: Probe 26656 is disconnected (RQC Ural bld.) > From: RIPE Atlas (no reply) > To: redacted at rqc.ru > Reply-To: RIPE Atlas (no reply) > Date: Wed, 16 Aug 2017 09:30:00 -0000 > Message-ID: <20170816093000.18245.96974 at worker1.atlas.ripe.net> > X-ACL-Warn: Delaying message > X-RIPE-Spam-Level: ---- > X-RIPE-Spam-Report: Spam Total Points: -4.0 points > pts rule name description > ---- ---------------------- ------------------------------------ > -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP > 3.5 DCC_CHECK Detected as bulk mail by DCC (dcc-servers.net) > X-RIPE-Signature: b7d297f3462a5391c8f90e217ab85ce69eb69a6fc89c21df31133e5b7354304c > > Dear Marat Khalili, > > Your probe 26656 has been disconnected from the RIPE Atlas infrastructure since 2017-08-16 08:58:54 UTC. [...] My provider did not treat it as spam and delivered almost instantly after receiving from RIPE. -- With Best Regards, Marat Khalili From carsten at schiefner.de Thu Aug 17 13:17:06 2017 From: carsten at schiefner.de (Carsten Schiefner) Date: Thu, 17 Aug 2017 13:17:06 +0200 Subject: [atlas] Notify time setting does not work In-Reply-To: <86c1207c-cda6-d777-aef9-d2cc55244a64@rqc.ru> References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> <86c1207c-cda6-d777-aef9-d2cc55244a64@rqc.ru> Message-ID: <763f1bf8-72b9-8dd5-88c6-e52428019b0b@schiefner.de> Hi Marat, On 17.08.2017 13:02, Marat Khalili wrote: >> smells a bit as if greylisting would have been deployed for 'rqc.ru'. > You may be right, but why? It all happens still well within RIPE: nope - the devil, as always, is in the detail: >> Received: from worker1.atlas.ripe.net ([193.0.19.216]) >> by mahimahi.ripe.net with esmtps >> (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) >> (Exim 4.89) >> (envelope-from ) >> id 1dhueG-0001AI-Sl >> for redacted at rqc.ru; Wed, 16 Aug 2017 11:30:02 +0200 11:30:02 +0200 is 09:30:02 +0000 (aka. UTC) >> Received: from [127.0.0.1] (helo=worker1.atlas.ripe.net) >> by worker1.atlas.ripe.net with esmtp (Exim 4.89) >> (envelope-from ) >> id 1dhueG-0003zF-Qf >> for redacted at rqc.ru; Wed, 16 Aug 2017 09:30:00 +0000 09:30:00 +0000 is 11:30:00 +0200 >> Content-Type: text/plain; charset="utf-8" >> MIME-Version: 1.0 >> Content-Transfer-Encoding: 7bit >> Subject: Probe 26656 is disconnected (RQC Ural bld.) >> From: RIPE Atlas (no reply) >> To: redacted at rqc.ru >> Reply-To: RIPE Atlas (no reply) >> Date: Wed, 16 Aug 2017 09:30:00 -0000 - so it took at least that very message "only" two seconds to hop from one NCC host to another NCC host: no "significant" delay here. Best, -C. From mkh at rqc.ru Thu Aug 17 13:34:54 2017 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 17 Aug 2017 14:34:54 +0300 Subject: [atlas] Notify time setting does not work In-Reply-To: <763f1bf8-72b9-8dd5-88c6-e52428019b0b@schiefner.de> References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> <86c1207c-cda6-d777-aef9-d2cc55244a64@rqc.ru> <763f1bf8-72b9-8dd5-88c6-e52428019b0b@schiefner.de> Message-ID: <57e454ad-7fd7-113b-aba2-48353540b641@rqc.ru> But: > Your probe 26656 has been disconnected from the RIPE Atlas > infrastructure since 2017-08-16 08:58:54 UTC What happened between 08:58:54 UTC and 09:30:00 +0000? -- With Best Regards, Marat Khalili On 17/08/17 14:17, Carsten Schiefner wrote: > Hi Marat, > > On 17.08.2017 13:02, Marat Khalili wrote: >>> smells a bit as if greylisting would have been deployed for 'rqc.ru'. >> You may be right, but why? It all happens still well within RIPE: > nope - the devil, as always, is in the detail: > >>> Received: from worker1.atlas.ripe.net ([193.0.19.216]) >>> by mahimahi.ripe.net with esmtps >>> (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) >>> (Exim 4.89) >>> (envelope-from ) >>> id 1dhueG-0001AI-Sl >>> for redacted at rqc.ru; Wed, 16 Aug 2017 11:30:02 +0200 > 11:30:02 +0200 is 09:30:02 +0000 (aka. UTC) > >>> Received: from [127.0.0.1] (helo=worker1.atlas.ripe.net) >>> by worker1.atlas.ripe.net with esmtp (Exim 4.89) >>> (envelope-from ) >>> id 1dhueG-0003zF-Qf >>> for redacted at rqc.ru; Wed, 16 Aug 2017 09:30:00 +0000 > 09:30:00 +0000 is 11:30:00 +0200 > >>> Content-Type: text/plain; charset="utf-8" >>> MIME-Version: 1.0 >>> Content-Transfer-Encoding: 7bit >>> Subject: Probe 26656 is disconnected (RQC Ural bld.) >>> From: RIPE Atlas (no reply) >>> To: redacted at rqc.ru >>> Reply-To: RIPE Atlas (no reply) >>> Date: Wed, 16 Aug 2017 09:30:00 -0000 > - so it took at least that very message "only" two seconds to hop from > one NCC host to another NCC host: no "significant" delay here. > > Best, > > -C. From carsten at schiefner.de Fri Aug 18 12:23:51 2017 From: carsten at schiefner.de (Carsten Schiefner) Date: Fri, 18 Aug 2017 12:23:51 +0200 Subject: [atlas] Notify time setting does not work In-Reply-To: <57e454ad-7fd7-113b-aba2-48353540b641@rqc.ru> References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> <86c1207c-cda6-d777-aef9-d2cc55244a64@rqc.ru> <763f1bf8-72b9-8dd5-88c6-e52428019b0b@schiefner.de> <57e454ad-7fd7-113b-aba2-48353540b641@rqc.ru> Message-ID: <5e0785bb-fa7f-0a85-09b1-c9d0f666202c@schiefner.de> On 17.08.2017 13:34, Marat Khalili wrote: > But: > >> Your probe 26656 has been disconnected from the RIPE Atlas >> infrastructure since 2017-08-16 08:58:54 UTC > What happened between 08:58:54 UTC and 09:30:00 +0000? Erm, yes... Didn't check the mail body. Sorry, my bad. So it appears that this indeed *IS* onyl to the Atlas team @ NCC to answer. Cheers, -C. From vnaumov at ripe.net Fri Aug 18 13:01:48 2017 From: vnaumov at ripe.net (Viktor Naumov) Date: Fri, 18 Aug 2017 13:01:48 +0200 Subject: [atlas] Notify time setting does not work In-Reply-To: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> Message-ID: <708a8c68-0e61-5493-34ed-18e2d9f68ae9@ripe.net> Hi Marat, Here how it (always) works. There is a job started every 30 minutes. If a probe is down longer than the "Notify time" you will get a notification. So in your case (10 minutes) you should get an email within interval of [10 , 40) minutes. wbr /vty On 8/17/17 9:15 AM, Marat Khalili wrote: > Probes have very handy feature of sending a notification when the > probe is disconnected. I have mine set to 10 minutes, however last two > such notifications only arrived 30 minutes after the probe was > disconnected. Probe #26656 if that's important. > > One would think that probe itself was slow to react, but last time I > monitored outage from the very beginning and the probe's page > correctly showed "Disconnected for: 1 minute" and so on. Neither it is > a case of slow email arrival, since according to Received header in > the email it was indeed received from worker1.atlas.ripe.net 30+ > minutes after disconnection time mentioned in the email body. > > Can it be that "Notify time" setting just doesn't work and some > default value of 30 minutes is used? > > -- > > With Best Regards, > Marat Khalili > > From gert at space.net Fri Aug 18 14:03:43 2017 From: gert at space.net (Gert Doering) Date: Fri, 18 Aug 2017 14:03:43 +0200 Subject: [atlas] Notify time setting does not work In-Reply-To: <708a8c68-0e61-5493-34ed-18e2d9f68ae9@ripe.net> References: <67899b7c-af8b-55dd-2433-f96eff6746a8@rqc.ru> <708a8c68-0e61-5493-34ed-18e2d9f68ae9@ripe.net> Message-ID: <20170818120343.GS45648@Space.Net> Hi, On Fri, Aug 18, 2017 at 01:01:48PM +0200, Viktor Naumov wrote: > Here how it (always) works. > > There is a job started every 30 minutes. If a probe is down longer than > the "Notify time" you will get a notification. So in your case (10 > minutes) you should get an email within interval of [10 , 40) minutes. This is a bit awkward... can this be improved, like, run this job every minute or so? A single "select id from probes where downtime>notify and not is_notified" statement shouldn't cost much... (no ideas about your table setup, though :-) ) Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mir at ripe.net Mon Aug 21 14:47:35 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 21 Aug 2017 14:47:35 +0200 Subject: [atlas] New on RIPE Labs: Processing RIPE Atlas Results with jq Message-ID: <0e0752d2-dfe0-71b7-6108-220368706674@ripe.net> Dear colleagues, Please find this new article by Stephane Bortzmeyer on RIPE Labs: Processing RIPE Atlas Results with jq https://labs.ripe.net/Members/stephane_bortzmeyer/processing-ripe-atlas-results-with-jq Kind regards, Mirjam Kuhne RIPE NCC From bortzmeyer at nic.fr Tue Aug 22 09:05:54 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 22 Aug 2017 09:05:54 +0200 Subject: [atlas] [rfc-editor@rfc-editor.org: RFC 8193 on Information Model for Large-Scale Measurement Platforms (LMAPs)] Message-ID: <20170822070554.dzl7gddj27l4inl5@nic.fr> This recent RFC on the data model for Internet measurements platform is of course of interest for RIPE Atlas. Note that their model separates controller and collector, which are one in Atlas. -------------- next part -------------- An embedded message was scrubbed... From: rfc-editor at rfc-editor.org Subject: [lmap] RFC 8193 on Information Model for Large-Scale Measurement Platforms (LMAPs) Date: Mon, 21 Aug 2017 17:03:44 -0700 (PDT) Size: 8721 URL: From gboonie at gmail.com Tue Aug 22 10:14:14 2017 From: gboonie at gmail.com (Dave .) Date: Tue, 22 Aug 2017 10:14:14 +0200 Subject: [atlas] DNS results visualisation Message-ID: Hi, For the traceroute results there is a icon at the right side where you can get the complete traceroute. (View Latest Result) This is beautifully presented. Could we please have a similar icon for DNS results? Thanks, Dave Boonstra -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgreene at senki.org Tue Aug 22 12:19:42 2017 From: bgreene at senki.org (Barry Raveendran Greene) Date: Tue, 22 Aug 2017 18:19:42 +0800 Subject: [atlas] DNS results visualisation In-Reply-To: References: Message-ID: <38F4E4C9-4256-4EEA-917D-7CB364E17DD8@senki.org> > On Aug 22, 2017, at 4:14 PM, Dave . wrote: > For the traceroute results there is a icon at the right side where you can get the complete traceroute. (View Latest Result) This is beautifully presented. > > Could we please have a similar icon for DNS results? What would be illustrated? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From wilhelm at ripe.net Tue Aug 22 16:19:19 2017 From: wilhelm at ripe.net (Rene Wilhelm) Date: Tue, 22 Aug 2017 16:19:19 +0200 Subject: [atlas] measurement UI on 12hour clock? Message-ID: See attached screenshot. I created a couple of measurements which were to start at 16:05 local time, 14:05 UTC. The measurement page https://atlas.ripe.net/measurements however states a start time of 22-08-2017 02:05 UTC which is of course 12 hours in the past and had me worried for a bit I made a mistake filling in the form. Can this be fixed? it is confusing and looks a bit clumsy :) -- Rene -------------- next part -------------- A non-text attachment was scrubbed... Name: atlasUI.png Type: image/png Size: 56546 bytes Desc: not available URL: From mcandela at ripe.net Tue Aug 22 16:33:10 2017 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 22 Aug 2017 16:33:10 +0200 Subject: [atlas] measurement UI on 12hour clock? In-Reply-To: References: Message-ID: <230E11D5-4607-4382-94E2-722C68CC7BF9@ripe.net> Ops, the date is erroneously in 12 hours format (with AM/PM missing). I?ll switch it to 24 hours format. Ciao, Massimo > On 22 Aug 2017, at 16:19, Rene Wilhelm wrote: > > See attached screenshot. > > I created a couple of measurements which were to start at 16:05 local time, 14:05 UTC. > > The measurement page https://atlas.ripe.net/measurements however states a start time of 22-08-2017 02:05 UTC which is of course 12 hours in the past and had me worried for a bit I made a mistake filling in the form. > > Can this be fixed? it is confusing and looks a bit clumsy :) > > -- Rene > > > From gboonie at gmail.com Tue Aug 22 16:43:02 2017 From: gboonie at gmail.com (Dave .) Date: Tue, 22 Aug 2017 16:43:02 +0200 Subject: [atlas] DNS results visualisation In-Reply-To: <38F4E4C9-4256-4EEA-917D-7CB364E17DD8@senki.org> References: <38F4E4C9-4256-4EEA-917D-7CB364E17DD8@senki.org> Message-ID: What would be illustrated would preferably be the output of dig. Something like this ; <<>> DiG 9.10.3-P4-Ubuntu <<>> fok.nl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17015 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;fok.nl. IN A ;; ANSWER SECTION: fok.nl. 120 IN A 104.20.93.55 fok.nl. 120 IN A 104.20.94.55 ;; Query time: 9 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Tue Aug 22 16:41:54 CEST 2017 ;; MSG SIZE rcvd: 67 2017-08-22 12:19 GMT+02:00 Barry Raveendran Greene : > > > > > On Aug 22, 2017, at 4:14 PM, Dave . wrote: > > > For the traceroute results there is a icon at the right side where you > can get the complete traceroute. (View Latest Result) This is beautifully > presented. > > > > Could we please have a similar icon for DNS results? > > What would be illustrated? > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgreene at senki.org Thu Aug 24 05:56:23 2017 From: bgreene at senki.org (Barry Raveendran Greene) Date: Thu, 24 Aug 2017 11:56:23 +0800 Subject: [atlas] Sharing Credits seems broken ..... Message-ID: Hi Team, We have a problem with the sharing credits. I?ve got plenty of credits on my account. I?ve granted access to my colleague (Jim Gilbert) and a test group account (atlas-network at akamai.com). Just to be clear, it states: Sharing Access - If you don?t want to set limits on the number of credits you share, you can also allow other RIPE Atlas users to use your credits directly for their own measurements. Select the ?Share Access? tab on your credits page and enter the RIPE Atlas users you want to give access to. Users who have been given access to others? credits will be able to choose whose account to charge when they create a new measurement from a drop-down menu. This option can also be set via the measurement API. A running measurement can be stopped by both you and the person with access to your credits. If you decide to stop giving someone else access to your credits, any measurements they have running will start using their own credits instead. This means I should be able to log into atlas-network at akamai.com select ?bgreene at senki.org? and create/run test. Correct???? This is what I get: What are we missing? Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: RIPE Atlas Troubleshooting Credit Sharing.png Type: image/png Size: 61327 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP URL: From mcandela at ripe.net Thu Aug 24 09:50:24 2017 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 24 Aug 2017 09:50:24 +0200 Subject: [atlas] Sharing Credits seems broken ..... In-Reply-To: References: Message-ID: Hello Barry, Thank you for the report. I?m fixing this issue right now. Best regards, Massimo Candela > On 24 Aug 2017, at 05:56, Barry Raveendran Greene wrote: > > Hi Team, > > We have a problem with the sharing credits. I?ve got plenty of credits on my account. I?ve granted access to my colleague (Jim Gilbert) and a test group account (atlas-network at akamai.com ). Just to be clear, it states: > > Sharing Access - If you don?t want to set limits on the number of credits you share, you can also allow other RIPE Atlas users to use your credits directly for their own measurements. Select the ?Share Access? tab on your credits page and enter the RIPE Atlas users you want to give access to. Users who have been given access to others? credits will be able to choose whose account to charge when they create a new measurement from a drop-down menu. This option can also be set via the measurement API. A running measurement can be stopped by both you and the person with access to your credits. If you decide to stop giving someone else access to your credits, any measurements they have running will start using their own credits instead. > > This means I should be able to log into atlas-network at akamai.com select ?bgreene at senki.org ? and create/run test. Correct???? > > This is what I get: > > > > > What are we missing? > > Barry -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcandela at ripe.net Thu Aug 24 10:11:07 2017 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 24 Aug 2017 10:11:07 +0200 Subject: [atlas] Sharing Credits seems broken ..... In-Reply-To: References: Message-ID: <25BB1D10-7755-4A06-8820-0172D344428E@ripe.net> Fixed. Please, refresh the page without browser cache. Best regards, Massimo Candela > On 24 Aug 2017, at 09:50, Massimo Candela wrote: > > Hello Barry, > > Thank you for the report. > I?m fixing this issue right now. > > Best regards, > Massimo Candela > >> On 24 Aug 2017, at 05:56, Barry Raveendran Greene > wrote: >> >> Hi Team, >> >> We have a problem with the sharing credits. I?ve got plenty of credits on my account. I?ve granted access to my colleague (Jim Gilbert) and a test group account (atlas-network at akamai.com ). Just to be clear, it states: >> >> Sharing Access - If you don?t want to set limits on the number of credits you share, you can also allow other RIPE Atlas users to use your credits directly for their own measurements. Select the ?Share Access? tab on your credits page and enter the RIPE Atlas users you want to give access to. Users who have been given access to others? credits will be able to choose whose account to charge when they create a new measurement from a drop-down menu. This option can also be set via the measurement API. A running measurement can be stopped by both you and the person with access to your credits. If you decide to stop giving someone else access to your credits, any measurements they have running will start using their own credits instead. >> >> This means I should be able to log into atlas-network at akamai.com select ?bgreene at senki.org ? and create/run test. Correct???? >> >> This is what I get: >> >> >> >> >> What are we missing? >> >> Barry > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Aug 24 16:47:23 2017 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 24 Aug 2017 16:47:23 +0200 Subject: [atlas] Infrastructure upgrades Message-ID: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> Dear all, Yesterday we began infrastructure (OS) upgrades on our controllers. As a consequence each probe will be disconnected for an hour or two. This can trigger notifications, if you have that configured to a sensitive enough setting. Regards, Robert Kisteleki RIPE NCC From me at anuragbhatia.com Tue Aug 29 22:44:06 2017 From: me at anuragbhatia.com (Anurag Bhatia) Date: Wed, 30 Aug 2017 02:14:06 +0530 Subject: [atlas] Plan to Implement RIPE Atlas WiFi Measurements In-Reply-To: <56FBBCF3.5010606@ripe.net> References: <56FBBCF3.5010606@ripe.net> Message-ID: Hello Very interesting information and since this email is old. Can you share latest updates around it? On Wed, Mar 30, 2016 at 5:18 PM, Robert Kisteleki wrote: > Dear colleagues, > > We wanted to update the community and let you know that we plan to start > work on the proposed experiment with WiFi measurements in mid-2016. As we > communicated in a recent RIPE Labs article, we will work with G?ANT as a > test partner to learn more about the operational effects of introducing > WiFi > measurements to the RIPE Atlas system, in addition to the benefits we > believe this could provide for the entire RIPE Atlas community. Please see > the article for more details if you are interested: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe- > atlas-wifi-measurements-part-2 > > We will continue to update you once we?ve begun work on this plan, and we > welcome your comments in the meantime. > > Regards, > > Robert Kisteleki > RIPE NCC > > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Aug 30 09:32:36 2017 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 30 Aug 2017 09:32:36 +0200 Subject: [atlas] Plan to Implement RIPE Atlas WiFi Measurements In-Reply-To: References: <56FBBCF3.5010606@ripe.net> Message-ID: Hi, The wifi measurements are technically possible, and can measure eduroam as planned. You can find these in the UI. We only have a handful of probes "upgraded" to support them, since we're still looking at their behavior. We have the mans to opt more probes in, so if you have a probe in eduroam vicinity and would like to help testing the feature, please let us know by writing to atlas at rtipe.net Regards, Robert On 2017-08-29 22:44, Anurag Bhatia wrote: > Hello > > > Very interesting information and since this email is old. Can you share > latest updates around it?? > > On Wed, Mar 30, 2016 at 5:18 PM, Robert Kisteleki > wrote: > > Dear colleagues, > > We wanted to update the community and let you know that we plan to start > work on the proposed experiment with WiFi measurements in mid-2016. > As we > communicated in a recent RIPE Labs article, we will work with G?ANT as a > test partner to learn more about the operational effects of > introducing WiFi > measurements to the RIPE Atlas system, in addition to the benefits we > believe this could provide for the entire RIPE Atlas community. > Please see > the article for more details if you are interested: > > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-wifi-measurements-part-2 > > > We will continue to update you once we?ve begun work on this plan, > and we > welcome your comments in the meantime. > > Regards, > > Robert Kisteleki > RIPE NCC > > > > > -- > > > Anurag Bhatia > anuragbhatia.com