From spointer at humdai.net Fri Jul 1 14:13:12 2016 From: spointer at humdai.net (Steve Pointer) Date: Fri, 01 Jul 2016 13:13:12 +0100 Subject: [atlas] Is there something up with atlas.ripe.net at the moment ? Message-ID: <1467375192.493886.654130481.2338B22D@webmail.messagingengine.com> Hi I am trying to add a couple of new measurements, however it has been "...calculating" for about an hour now. Is there a known issue? Many Thanks Steve P -- Steve Pointer spointer at humdai.net ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Tue Jul 5 14:15:19 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 5 Jul 2016 15:15:19 +0300 Subject: [atlas] Is the Atlas probe hackable? Message-ID: I received a report from one of our security monitoring systems about one of our probes (#17846) - https://atlas.ripe.net/probes/17846/ which appears to be infected with Tinba: > Security incident #1 - Tinba infection > Involved internal Hosts: > atlas-probe.cc.biu.ac.il 132.70.248.150 spotted since > 2016-06-30 > 23:58:54 till 2016-07-01 05:01:20 > Malicious activities found: > Tinba infection > related indication of compromise: > Communication with CnC > 192.112.36.4 > 192.203.230.10 > 192.228.79.201 > 192.33.4.12 > 192.36.148.17 > 193.0.14.129 > 198.41.0.4 > 198.97.190.53 > 199.7.83.42 > 199.7.91.13 > 202.12.27.33 Should we be worried? Thanks, Hank -------------- next part -------------- An HTML attachment was scrubbed... URL: From mark at santcroos.net Tue Jul 5 14:20:09 2016 From: mark at santcroos.net (Mark Santcroos) Date: Tue, 5 Jul 2016 14:20:09 +0200 Subject: [atlas] Is the Atlas probe hackable? In-Reply-To: References: Message-ID: FYI: the addresses are those of the root name servers. On Tue, Jul 5, 2016 at 2:15 PM, Hank Nussbacher wrote: > I received a report from one of our security monitoring systems about one of > our probes (#17846) - https://atlas.ripe.net/probes/17846/ which appears to > be infected with Tinba: > > >> Security incident #1 - Tinba infection > >> Involved internal Hosts: > >> atlas-probe.cc.biu.ac.il 132.70.248.150 spotted since > >> 2016-06-30 > >> 23:58:54 till 2016-07-01 05:01:20 > >> Malicious activities found: > >> Tinba infection > >> related indication of compromise: > >> Communication with CnC > >> 192.112.36.4 > >> 192.203.230.10 > >> 192.228.79.201 > >> 192.33.4.12 > >> 192.36.148.17 > >> 193.0.14.129 > >> 198.41.0.4 > >> 198.97.190.53 > >> 199.7.83.42 > >> 199.7.91.13 > >> 202.12.27.33 > > > Should we be worried? > > > Thanks, > > Hank From pk at DENIC.DE Tue Jul 5 14:24:35 2016 From: pk at DENIC.DE (Peter Koch) Date: Tue, 5 Jul 2016 14:24:35 +0200 Subject: [atlas] Is the Atlas probe hackable? In-Reply-To: References: Message-ID: <20160705122435.GU7209@x28.adm.denic.de> On Tue, Jul 05, 2016 at 03:15:19PM +0300, Hank Nussbacher wrote: > Should we be worried? yes, about the selection of IoC. -Peter From robert at ripe.net Tue Jul 5 15:40:44 2016 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 5 Jul 2016 15:40:44 +0200 Subject: [atlas] Is there something up with atlas.ripe.net at the moment ? In-Reply-To: <1467375192.493886.654130481.2338B22D@webmail.messagingengine.com> References: <1467375192.493886.654130481.2338B22D@webmail.messagingengine.com> Message-ID: <93aa15ab-209e-0ea4-2a4f-2e1964eddb51@ripe.net> On 2016-07-01 14:13, Steve Pointer wrote: > Hi > > I am trying to add a couple of new measurements, however it has been > "...calculating" for about an hour now. > > Is there a known issue? > > Many Thanks > Steve P > -- > Steve Pointer > spointer at humdai.net > Hi, We had some minor database hickups on Friday, nothing that should have permanent effect. Regards, Robert From spointer at humdai.net Tue Jul 5 15:42:10 2016 From: spointer at humdai.net (Steve Pointer) Date: Tue, 05 Jul 2016 14:42:10 +0100 Subject: [atlas] Is there something up with atlas.ripe.net at the moment ? In-Reply-To: <93aa15ab-209e-0ea4-2a4f-2e1964eddb51@ripe.net> References: <1467375192.493886.654130481.2338B22D@webmail.messagingengine.com> <93aa15ab-209e-0ea4-2a4f-2e1964eddb51@ripe.net> Message-ID: <1467726130.2569163.657312289.1C624842@webmail.messagingengine.com> Thanks Robert > We had some minor database hickups on Friday, nothing that should have > permanent effect. I can confirm that normal operation has returned. Steve P -- Steve Pointer spointer at humdai.net From daniel.karrenberg at ripe.net Wed Jul 6 08:56:35 2016 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 6 Jul 2016 08:56:35 +0200 Subject: [atlas] Is the Atlas probe hackable? In-Reply-To: References: Message-ID: <1610d8ef-f93f-b598-27ff-3ace2b252521@ripe.net> I am positive tinba cannot run on the probes. So either that IDS is brain damaged or some joker made a UDM that acts like tinba or both. What Marc said: the 'CnC' appears to be at the root name servers. Queue conspiracy theory ..... Daniel On 5.07.16 14:15 , Hank Nussbacher wrote: > I received a report from one of our security monitoring systems about > one of our probes (#17846) - https://atlas.ripe.net/probes/17846/ which > appears to be infected with Tinba: > > >> Security incident #1 - Tinba infection > >> Involved internal Hosts: > >> atlas-probe.cc.biu.ac.il 132.70.248.150 spotted since > >> 2016-06-30 > >> 23:58:54 till 2016-07-01 05:01:20 > >> Malicious activities found: > >> Tinba infection > >> related indication of compromise: > >> Communication with CnC > >> 192.112.36.4 > >> 192.203.230.10 > >> 192.228.79.201 > >> 192.33.4.12 > >> 192.36.148.17 > >> 193.0.14.129 > >> 198.41.0.4 > >> 198.97.190.53 > >> 199.7.83.42 > >> 199.7.91.13 > >> 202.12.27.33 > > > Should we be worried? > > > Thanks, > > Hank > From hank at efes.iucc.ac.il Wed Jul 6 12:45:14 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 6 Jul 2016 13:45:14 +0300 Subject: [atlas] Is the Atlas probe hackable? In-Reply-To: <1610d8ef-f93f-b598-27ff-3ace2b252521@ripe.net> References: <1610d8ef-f93f-b598-27ff-3ace2b252521@ripe.net> Message-ID: <59036e91-276d-ff07-0fb2-36dcb7787d75@efes.iucc.ac.il> On 06/07/2016 09:56, Daniel Karrenberg wrote: It is indeed a FP. There was a collision between variant of Tinba DGA and legit domain - thinksquare.net. As you can see it the below link, a lot of malwares samples communicated with thinksquare.net on the exact same day. https://www.virustotal.com/en/domain/thinksquare.net/information/ -Hank > I am positive tinba cannot run on the probes. > > So either that IDS is brain damaged or some joker made a UDM that acts > like tinba or both. What Marc said: the 'CnC' appears to be at the root > name servers. Queue conspiracy theory ..... > > Daniel > > On 5.07.16 14:15 , Hank Nussbacher wrote: >> I received a report from one of our security monitoring systems about >> one of our probes (#17846) - https://atlas.ripe.net/probes/17846/ which >> appears to be infected with Tinba: >> >> >>> Security incident #1 - Tinba infection >>> Involved internal Hosts: >>> atlas-probe.cc.biu.ac.il 132.70.248.150 spotted since >>> 2016-06-30 >>> 23:58:54 till 2016-07-01 05:01:20 >>> Malicious activities found: >>> Tinba infection >>> related indication of compromise: >>> Communication with CnC >>> 192.112.36.4 >>> 192.203.230.10 >>> 192.228.79.201 >>> 192.33.4.12 >>> 192.36.148.17 >>> 193.0.14.129 >>> 198.41.0.4 >>> 198.97.190.53 >>> 199.7.83.42 >>> 199.7.91.13 >>> 202.12.27.33 >> >> Should we be worried? >> >> >> Thanks, >> >> Hank >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto+ripe at keltia.net Wed Jul 6 14:28:15 2016 From: roberto+ripe at keltia.net (Ollivier Robert) Date: Wed, 6 Jul 2016 14:28:15 +0200 Subject: [atlas] development server? Message-ID: <20160706122815.GC28398@roberto-aw.eurocontrol.fr> Hello, I've been hosting a probe for quite sometimes and now that APIv2 is out, I've writing a Go library to access it. Is there a development server I could hit instead of the regular one in order to clutter the DB with temporary/trash measurements? Thanks. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto at keltia.net In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ From bob at rudis.net Wed Jul 6 14:29:40 2016 From: bob at rudis.net (boB Rudis) Date: Wed, 6 Jul 2016 08:29:40 -0400 Subject: [atlas] development server? In-Reply-To: <20160706122815.GC28398@roberto-aw.eurocontrol.fr> References: <20160706122815.GC28398@roberto-aw.eurocontrol.fr> Message-ID: +1 for this. I'm in the process of writing an R pkg as well. Wld rather not hit prod just for dev work. On Wed, Jul 6, 2016 at 8:28 AM, Ollivier Robert wrote: > Hello, > > I've been hosting a probe for quite sometimes and now that APIv2 is out, I've writing a Go library to access it. Is there a development server I could hit instead of the regular one in order to clutter the DB with temporary/trash measurements? > > > Thanks. > > -- > Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- roberto at keltia.net > In memoriam to Ondine, our 2nd child: http://ondine.keltia.net/ > > From antranig at cert.am Wed Jul 6 14:33:54 2016 From: antranig at cert.am (Antranig Vartanian) Date: Wed, 6 Jul 2016 16:33:54 +0400 Subject: [atlas] development server? In-Reply-To: References: <20160706122815.GC28398@roberto-aw.eurocontrol.fr> Message-ID: +1. altho I do use the Python libraries, in free time I try to "port" them to the Oberon-2 programming language, and having a simple development server (or maybe even a self-hosted example) would be amazing. thanks for the idea :) Antranig Vartanian | PGP Key ID : 0xDAB81456 https://antranigv.am | https://cert.am (* do one thing and do it well *) On 07/06/2016 04:29 PM, boB Rudis wrote: > +1 for this. I'm in the process of writing an R pkg as well. Wld > rather not hit prod just for dev work. > > On Wed, Jul 6, 2016 at 8:28 AM, Ollivier Robert > wrote: >> Hello, >> >> I've been hosting a probe for quite sometimes and now that APIv2 >> is out, I've writing a Go library to access it. Is there a >> development server I could hit instead of the regular one in >> order to clutter the DB with temporary/trash measurements? >> >> >> Thanks. >> >> -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- >> roberto at keltia.net In memoriam to Ondine, our 2nd child: >> http://ondine.keltia.net/ >> >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From BECHA at ripe.net Fri Jul 8 07:54:06 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 8 Jul 2016 07:54:06 +0200 Subject: [atlas] Troubleshooting USB stick issues - reaching out Message-ID: <63889f11-7f79-5cae-0280-d6a1e2e8b66a@ripe.net> Dear colleagues, recently, some of the third version of RIPE Atlas probes have had an issue with their USB sticks. We're still investigating what may be causing this issue, and in the meantime we have a possible solution, outlined in this RIPE Labs article (and below in the email) https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks These steps might not be a surprise to the users on this list, but on the 4th of July we reached out to almost 5000 hosts of "abandoned" probes, and we see immediate positive results! As you can see from some screenshots I quickly made, number of active probes have increased - from 8883 on 1st July, to 9323 this morning. Allowing for normal fluctuations, this is still a considerable increase -- and we are grateful! Thank you for all the effort that you put into keeping the RIPE Atlas network strong by keeping your probes connected. Kind regards, Vesna (and the RIPE Atlas team) === Steps to power-cycle probe without USB stick: 1. Unplug the probe from its power source 2. Remove the USB stick from the probe 3. Plug in the probe WITHOUT the USB stick 4. Wait for ten minutes 5. Insert the USB stick After an hour, check SOS-messages & "Status" tab Note: Only on a network with working DHCP. If you have configured probe to use static IP, this setting would be lost if trying the steps. If this didn't help, try using a new, brand-name USB stick that is at least 4GB in size (it does not need any preparation but its contents will be erased so make sure it does not store anything crucial) If the problem is still there, please contact us at atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: active probes first july 2016.png Type: image/png Size: 11168 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: connected probes 8th july 2016.png Type: image/png Size: 12914 bytes Desc: not available URL: From antranig at cert.am Fri Jul 8 11:38:02 2016 From: antranig at cert.am (Antranig Vartanian) Date: Fri, 8 Jul 2016 13:38:02 +0400 Subject: [atlas] sometimes no RTT? Message-ID: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> Hi all! I'm new to RIPE Atlas, and right now using it for educational purposes :)) lately I've seen that some of my traceroute measurements do not have RTT. although it's not completely ignored by the hop (I get the data like from, size, ttl), but only rtt is missing :)) any idea how, why and when does this happen? :) for a live example, check Measurement #4458653. 48th probe's 11th hop's 1st query (counting from zero, btw) does not have rtt :) thanks in advance! side question: is there an (un)official IRC channel? :) -- Antranig Vartanian | PGP Key ID : 0xDAB81456 https://antranigv.am | https://cert.am (* do one thing and do it well *) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Fri Jul 8 11:46:10 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 8 Jul 2016 11:46:10 +0200 Subject: [atlas] sometimes no RTT? In-Reply-To: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> Message-ID: <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> Hi, On 2016/07/08 11:38 , Antranig Vartanian wrote: > I'm new to RIPE Atlas, and right now using it for educational purposes > :)) lately I've seen that some of my traceroute measurements do not have > RTT. although it's not completely ignored by the hop (I get the data > like from, size, ttl), but only rtt is missing :)) > > any idea how, why and when does this happen? :) > > for a live example, check Measurement #4458653. 48th probe's 11th hop's > 1st query (counting from zero, btw) does not have rtt :) Maybe you can give the actual probe ID? Or better yet, a copy of the JSON result for that probe and the actual hop number in the JSON blob? Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From antranig at cert.am Fri Jul 8 12:07:53 2016 From: antranig at cert.am (Antranig Vartanian) Date: Fri, 8 Jul 2016 14:07:53 +0400 Subject: [atlas] sometimes no RTT? In-Reply-To: <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> Message-ID: <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> Hi, sure! Probe ID: 938. Hop: 12 I uploaded that probe's json part - https://antranigv.am/misc/result_prb_id_938.json :) -- Antranig Vartanian | PGP Key ID : 0xDAB81456 https://antranigv.am | https://cert.am (* do one thing and do it well *) On 07/08/2016 01:46 PM, Philip Homburg wrote: > Hi, > > On 2016/07/08 11:38 , Antranig Vartanian wrote: >> I'm new to RIPE Atlas, and right now using it for educational purposes >> :)) lately I've seen that some of my traceroute measurements do not have >> RTT. although it's not completely ignored by the hop (I get the data >> like from, size, ttl), but only rtt is missing :)) >> >> any idea how, why and when does this happen? :) >> >> for a live example, check Measurement #4458653. 48th probe's 11th hop's >> 1st query (counting from zero, btw) does not have rtt :) > > Maybe you can give the actual probe ID? > > Or better yet, a copy of the JSON result for that probe and the actual > hop number in the JSON blob? > > Philip > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From philip.homburg at ripe.net Fri Jul 8 14:06:49 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 8 Jul 2016 14:06:49 +0200 Subject: [atlas] sometimes no RTT? In-Reply-To: <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> Message-ID: <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> On 2016/07/08 12:07 , Antranig Vartanian wrote: > sure! Probe ID: 938. Hop: 12 I uploaded that probe's json part - > https://antranigv.am/misc/result_prb_id_938.json :) Hi, There is a 'late' field. Basically that means that the packet arrived after the traceroute code already timed out. The current implementation stores just one transmit time. So after it moved on, there is no way to compute the rtt. Philip -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From alexsaroyan at gmail.com Fri Jul 8 14:19:49 2016 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 8 Jul 2016 16:19:49 +0400 Subject: [atlas] sometimes no RTT? In-Reply-To: <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> Message-ID: Philip, I am a bit confused, is that "late reply from the probe" or it is "late reply from router - basically timed out reply" ? Should it be treated like packet loss ? Regards. /Alex Saroyan On Fri, Jul 8, 2016 at 4:06 PM, Philip Homburg wrote: > On 2016/07/08 12:07 , Antranig Vartanian wrote: > > sure! Probe ID: 938. Hop: 12 I uploaded that probe's json part - > > https://antranigv.am/misc/result_prb_id_938.json :) > > Hi, > > There is a 'late' field. Basically that means that the packet arrived > after the traceroute code already timed out. The current implementation > stores just one transmit time. So after it moved on, there is no way to > compute the rtt. > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Fri Jul 8 14:24:27 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 8 Jul 2016 14:24:27 +0200 Subject: [atlas] sometimes no RTT? In-Reply-To: References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> Message-ID: <743f0734-511b-630c-fb61-643a584205aa@ripe.net> On 2016/07/08 14:19 , Alex Saroyan wrote: > I am a bit confused, is that "late reply from the probe" or it is "late > reply from router - basically timed out reply" ? > Should it be treated like packet loss ? It is replies received by the probe. So it is usually from routers, but it could be from the target. The reply did arrive, so technically it is not packet loss. But it makes processing a lot easier to treat them as lost. Philip From alexsaroyan at gmail.com Fri Jul 8 14:27:16 2016 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 8 Jul 2016 16:27:16 +0400 Subject: [atlas] sometimes no RTT? In-Reply-To: <743f0734-511b-630c-fb61-643a584205aa@ripe.net> References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> <743f0734-511b-630c-fb61-643a584205aa@ripe.net> Message-ID: Do you mean packet was returned later then timeout value ? How long is timeout value then ? On Fri, Jul 8, 2016 at 4:24 PM, Philip Homburg wrote: > On 2016/07/08 14:19 , Alex Saroyan wrote: > > I am a bit confused, is that "late reply from the probe" or it is "late > > reply from router - basically timed out reply" ? > > Should it be treated like packet loss ? > > It is replies received by the probe. So it is usually from routers, but > it could be from the target. > > The reply did arrive, so technically it is not packet loss. But it makes > processing a lot easier to treat them as lost. > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Fri Jul 8 14:32:36 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 8 Jul 2016 14:32:36 +0200 Subject: [atlas] sometimes no RTT? In-Reply-To: References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> <743f0734-511b-630c-fb61-643a584205aa@ripe.net> Message-ID: <07b4ab13-7e82-fb59-8a2f-80c374f0eb4c@ripe.net> On 2016/07/08 14:27 , Alex Saroyan wrote: > Do you mean packet was returned later then timeout value ? > How long is timeout value then ? Yes, otherwise there would be a rtt value. The per packet timeout defaults to 4 seconds but can be set explicitly when the measurement is created. Philip From alexsaroyan at gmail.com Fri Jul 8 14:54:32 2016 From: alexsaroyan at gmail.com (Alex Saroyan) Date: Fri, 8 Jul 2016 16:54:32 +0400 Subject: [atlas] sometimes no RTT? In-Reply-To: <07b4ab13-7e82-fb59-8a2f-80c374f0eb4c@ripe.net> References: <0d97e4c5-59a0-22e0-f731-343687dc8b94@cert.am> <1ff9bfe2-bfaa-296b-0322-c19424ce8d92@ripe.net> <12ca5582-93af-4d49-80b3-ae25a5cdb104@cert.am> <500e16d2-4b51-50e1-8dc5-37795a1eb7b5@ripe.net> <743f0734-511b-630c-fb61-643a584205aa@ripe.net> <07b4ab13-7e82-fb59-8a2f-80c374f0eb4c@ripe.net> Message-ID: Thanks On Fri, Jul 8, 2016 at 4:32 PM, Philip Homburg wrote: > On 2016/07/08 14:27 , Alex Saroyan wrote: > > Do you mean packet was returned later then timeout value ? > > How long is timeout value then ? > > Yes, otherwise there would be a rtt value. The per packet timeout > defaults to 4 seconds but can be set explicitly when the measurement is > created. > > Philip > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From budiwijaya at ipv6.or.id Mon Jul 11 09:08:12 2016 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Mon, 11 Jul 2016 14:08:12 +0700 Subject: [atlas] Troubleshooting USB stick issues - reaching out In-Reply-To: <63889f11-7f79-5cae-0280-d6a1e2e8b66a@ripe.net> References: <63889f11-7f79-5cae-0280-d6a1e2e8b66a@ripe.net> Message-ID: Hi, One other solution is to format the USB then plug it back to the atlas. It's quicker. Thank you Budiwijaya On Fri, Jul 8, 2016 at 12:54 PM, Vesna Manojlovic wrote: > Dear colleagues, > > recently, some of the third version of RIPE Atlas probes have had an issue > with their USB sticks. > > We're still investigating what may be causing this issue, > and in the meantime we have a possible solution, outlined in this RIPE Labs > article (and below in the email) > https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks > > These steps might not be a surprise to the users on this list, > but on the 4th of July we reached out to almost 5000 hosts of "abandoned" > probes, and we see immediate positive results! > > As you can see from some screenshots I quickly made, > number of active probes have increased - from 8883 on 1st July, > to 9323 this morning. Allowing for normal fluctuations, > this is still a considerable increase -- and we are grateful! > > Thank you for all the effort that you put into keeping the > RIPE Atlas network strong by keeping your probes connected. > > Kind regards, > Vesna (and the RIPE Atlas team) > > === > > Steps to power-cycle probe without USB stick: > > 1. Unplug the probe from its power source > 2. Remove the USB stick from the probe > 3. Plug in the probe WITHOUT the USB stick > 4. Wait for ten minutes > 5. Insert the USB stick > > After an hour, check SOS-messages & "Status" tab > > Note: Only on a network with working DHCP. > If you have configured probe to use static IP, > this setting would be lost if trying the steps. > > If this didn't help, try using a new, brand-name USB stick that is at least > 4GB in size (it does not need any preparation but its contents will be > erased so make sure it does not store anything crucial) > > If the problem is still there, please contact us at atlas at ripe.net From raymon at van-der-meijden.com Mon Jul 11 09:25:21 2016 From: raymon at van-der-meijden.com (Raymon van der Meijden) Date: Mon, 11 Jul 2016 09:25:21 +0200 Subject: [atlas] Troubleshooting USB stick issues - reaching out In-Reply-To: References: <63889f11-7f79-5cae-0280-d6a1e2e8b66a@ripe.net> Message-ID: <8e131b0ae53880f52c3d4ca4e38745d9.squirrel@webmail.raqxs.nl> Hi, I have replaced the usb sticks on both of my atlas probes. They seem to eat a stick once a year (SanDisk) I`m unable to recover the stick so it really seems broken. (input/output error on Ubuntu Notebook as wel) Greetings, Raymon > Hi, > > One other solution is to format the USB then plug it back to the > atlas. It's quicker. > > Thank you > Budiwijaya > > > On Fri, Jul 8, 2016 at 12:54 PM, Vesna Manojlovic wrote: >> Dear colleagues, >> >> recently, some of the third version of RIPE Atlas probes have had an >> issue >> with their USB sticks. >> >> We're still investigating what may be causing this issue, >> and in the meantime we have a possible solution, outlined in this RIPE >> Labs >> article (and below in the email) >> https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks >> >> These steps might not be a surprise to the users on this list, >> but on the 4th of July we reached out to almost 5000 hosts of >> "abandoned" >> probes, and we see immediate positive results! >> >> As you can see from some screenshots I quickly made, >> number of active probes have increased - from 8883 on 1st July, >> to 9323 this morning. Allowing for normal fluctuations, >> this is still a considerable increase -- and we are grateful! >> >> Thank you for all the effort that you put into keeping the >> RIPE Atlas network strong by keeping your probes connected. >> >> Kind regards, >> Vesna (and the RIPE Atlas team) >> >> === >> >> Steps to power-cycle probe without USB stick: >> >> 1. Unplug the probe from its power source >> 2. Remove the USB stick from the probe >> 3. Plug in the probe WITHOUT the USB stick >> 4. Wait for ten minutes >> 5. Insert the USB stick >> >> After an hour, check SOS-messages & "Status" tab >> >> Note: Only on a network with working DHCP. >> If you have configured probe to use static IP, >> this setting would be lost if trying the steps. >> >> If this didn't help, try using a new, brand-name USB stick that is at >> least >> 4GB in size (it does not need any preparation but its contents will be >> erased so make sure it does not store anything crucial) >> >> If the problem is still there, please contact us at atlas at ripe.net > > From florencia.alvarezetcheverry at telecom-bretagne.eu Tue Jul 12 15:47:18 2016 From: florencia.alvarezetcheverry at telecom-bretagne.eu (Florencia Alvarez Etcheverry) Date: Tue, 12 Jul 2016 15:47:18 +0200 Subject: [atlas] Result streams not working Message-ID: Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? I tried with Cousteau and also directly with socketIO but it has the same behavior. When I took off the parameters "packets=1,interval=60" of the request (leaving default values), I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? Thank you, Florencia. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mcandela at ripe.net Tue Jul 12 16:18:29 2016 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 12 Jul 2016 16:18:29 +0200 Subject: [atlas] Result streams not working In-Reply-To: References: Message-ID: Hello Florencia, Thanks for using RIPE Atlas. > On 12 Jul 2016, at 15:47, Florencia Alvarez Etcheverry wrote: > > Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. The one-off measurement executes the measurement only once and gets stopped immediately. > > So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? > > I tried with Cousteau and also directly with socketIO but it has the same behavior. > When I took off the parameters "packets=1,interval=60" of the request (leaving default values), What does it mean? These look like parameters for creating a (periodic) measurement, not for listening it. Can I see your code or at least the subscription parameters? Ciao, Massimo > I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? > > Thank you, > Florencia. > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From florencia.alvarezetcheverry at telecom-bretagne.eu Tue Jul 12 16:58:05 2016 From: florencia.alvarezetcheverry at telecom-bretagne.eu (Florencia Alvarez Etcheverry) Date: Tue, 12 Jul 2016 16:58:05 +0200 Subject: [atlas] Result streams not working In-Reply-To: Message-ID: Thank you for your answer. I create a one-off measurement and then I want its results (as soon as they're available). Here is my test code: http://pastebin.com/7p4zy388 On 2016-07-12 16:18:29 CET, Massimo Candela wrote: > Hello Florencia, > > Thanks for using RIPE Atlas. > > > On 12 Jul 2016, at 15:47, Florencia Alvarez Etcheverry wrote: > > > > Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. > > The one-off measurement executes the measurement only once and gets stopped immediately. > But how immediately is that?, because I saw the results of the measurement but it was still running and I don't understand why. How long should I wait since I launch the measurement (1 ping packet) to get the result? Is this time shorter than if I wait for the measurement to stop? (But is it possible to know that time?) > > > > So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? > > > > I tried with Cousteau and also directly with socketIO but it has the same behavior. > > > > When I took off the parameters "packets=1,interval=60" of the request (leaving default values), > > What does it mean? These look like parameters for creating a (periodic) measurement, not for listening it. > Can I see your code or at least the subscription parameters? > > Ciao, > Massimo > > > I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? > > > > Thank you, > > Florencia. > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mcandela at ripe.net Tue Jul 12 17:17:14 2016 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 12 Jul 2016 17:17:14 +0200 Subject: [atlas] Result streams not working In-Reply-To: References: Message-ID: <95B9E769-126B-44C8-97B4-3251F1CB2E84@ripe.net> Some correction on fly, you should remove: start_time and interval since you are trying to do a one_off as soon as possible. I would suggest you to understand better the concepts here: https://atlas.ripe.net/docs/api/v2/manual/ or on the REST API manual. Remove also seconds=240 a and let me know if you see something. Its way way too small the timeout for a probe to get the schedule and send you some results. > On 12 Jul 2016, at 16:58, Florencia Alvarez Etcheverry wrote: > > Thank you for your answer. > I create a one-off measurement and then I want its results (as soon as they're available). > Here is my test code: http://pastebin.com/7p4zy388 > > On 2016-07-12 16:18:29 CET, Massimo Candela wrote: >> Hello Florencia, >> >> Thanks for using RIPE Atlas. >> >>> On 12 Jul 2016, at 15:47, Florencia Alvarez Etcheverry wrote: >>> >>> Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. >> >> The one-off measurement executes the measurement only once and gets stopped immediately. >> > But how immediately is that?, because I saw the results of the measurement but it was still running and I don't understand why. > How long should I wait since I launch the measurement (1 ping packet) to get the result? Is this time shorter than if I wait for the measurement to stop? (But is it possible to know that time?) > >>> >>> So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? >>> >>> I tried with Cousteau and also directly with socketIO but it has the same behavior. >> >> >>> When I took off the parameters "packets=1,interval=60" of the request (leaving default values), >> >> What does it mean? These look like parameters for creating a (periodic) measurement, not for listening it. >> Can I see your code or at least the subscription parameters? >> >> Ciao, >> Massimo >> >>> I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? >>> >>> Thank you, >>> Florencia. >>> > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mcandela at ripe.net Tue Jul 12 17:46:41 2016 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 12 Jul 2016 17:46:41 +0200 Subject: [atlas] Result streams not working In-Reply-To: <95B9E769-126B-44C8-97B4-3251F1CB2E84@ripe.net> References: <95B9E769-126B-44C8-97B4-3251F1CB2E84@ripe.net> Message-ID: <444AECCE-7B23-4216-B1D8-6E9F766E760D@ripe.net> In addition: - subscribe to the channel ?error", so you can see if there is any error; - let me know what version of Cousteau are you using. Ciao, Massimo > On 12 Jul 2016, at 17:17, Massimo Candela wrote: > > Some correction on fly, you should remove: start_time and interval since you are trying to do a one_off as soon as possible. > I would suggest you to understand better the concepts here: https://atlas.ripe.net/docs/api/v2/manual/ or on the REST API manual. > > Remove also seconds=240 a and let me know if you see something. Its way way too small the timeout for a probe to get the schedule and send you some results. > > >> On 12 Jul 2016, at 16:58, Florencia Alvarez Etcheverry wrote: >> >> Thank you for your answer. >> I create a one-off measurement and then I want its results (as soon as they're available). >> Here is my test code: http://pastebin.com/7p4zy388 >> >> On 2016-07-12 16:18:29 CET, Massimo Candela wrote: >>> Hello Florencia, >>> >>> Thanks for using RIPE Atlas. >>> >>>> On 12 Jul 2016, at 15:47, Florencia Alvarez Etcheverry wrote: >>>> >>>> Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. >>> >>> The one-off measurement executes the measurement only once and gets stopped immediately. >>> >> But how immediately is that?, because I saw the results of the measurement but it was still running and I don't understand why. >> How long should I wait since I launch the measurement (1 ping packet) to get the result? Is this time shorter than if I wait for the measurement to stop? (But is it possible to know that time?) >> >>>> >>>> So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? >>>> >>>> I tried with Cousteau and also directly with socketIO but it has the same behavior. >>> >>> >>>> When I took off the parameters "packets=1,interval=60" of the request (leaving default values), >>> >>> What does it mean? These look like parameters for creating a (periodic) measurement, not for listening it. >>> Can I see your code or at least the subscription parameters? >>> >>> Ciao, >>> Massimo >>> >>>> I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? >>>> >>>> Thank you, >>>> Florencia. >>>> >> >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mcandela at ripe.net Tue Jul 12 19:21:29 2016 From: mcandela at ripe.net (Massimo Candela) Date: Tue, 12 Jul 2016 19:21:29 +0200 Subject: [atlas] Result streams not working In-Reply-To: <95B9E769-126B-44C8-97B4-3251F1CB2E84@ripe.net> References: <95B9E769-126B-44C8-97B4-3251F1CB2E84@ripe.net> Message-ID: <4A0F5317-B88C-4564-B298-2CC9684A65B0@ripe.net> > On 12 Jul 2016, at 17:17, Massimo Candela wrote: > > Some correction on fly, you should remove: start_time and interval since you are trying to do a one_off as soon as possible. > I would suggest you to understand better the concepts here: https://atlas.ripe.net/docs/api/v2/manual/ or on the REST API manual. > > Remove also seconds=240 a and let me know if you see something. Its way way too small the timeout for a probe to get the schedule and send you some results. > Sorry, for some reason I read 240ms. 5 minutes are instead enough for a one-off. > >> On 12 Jul 2016, at 16:58, Florencia Alvarez Etcheverry wrote: >> >> Thank you for your answer. >> I create a one-off measurement and then I want its results (as soon as they're available). >> Here is my test code: http://pastebin.com/7p4zy388 >> >> On 2016-07-12 16:18:29 CET, Massimo Candela wrote: >>> Hello Florencia, >>> >>> Thanks for using RIPE Atlas. >>> >>>> On 12 Jul 2016, at 15:47, Florencia Alvarez Etcheverry wrote: >>>> >>>> Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. >>> >>> The one-off measurement executes the measurement only once and gets stopped immediately. >>> >> But how immediately is that?, because I saw the results of the measurement but it was still running and I don't understand why. >> How long should I wait since I launch the measurement (1 ping packet) to get the result? Is this time shorter than if I wait for the measurement to stop? (But is it possible to know that time?) >> >>>> >>>> So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? >>>> >>>> I tried with Cousteau and also directly with socketIO but it has the same behavior. >>> >>> >>>> When I took off the parameters "packets=1,interval=60" of the request (leaving default values), >>> >>> What does it mean? These look like parameters for creating a (periodic) measurement, not for listening it. >>> Can I see your code or at least the subscription parameters? >>> >>> Ciao, >>> Massimo >>> >>>> I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? >>>> >>>> Thank you, >>>> Florencia. >>>> >> >> >> Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From florencia.alvarezetcheverry at telecom-bretagne.eu Wed Jul 13 16:51:22 2016 From: florencia.alvarezetcheverry at telecom-bretagne.eu (Florencia Alvarez Etcheverry) Date: Wed, 13 Jul 2016 16:51:22 +0200 Subject: [atlas] Result streams not working In-Reply-To: <4A0F5317-B88C-4564-B298-2CC9684A65B0@ripe.net> Message-ID: Hello, I'm using Python3.4 and Cousteau v1.2 I've tried to subscribe to the error channel but I don't know if I'm doing it well since I couldn't find documentation or examples of it. I added the lines: channel = "error" atlas_stream.bind_channel(channel, on_error_response) Yesterday I tried executing my program without timeout, I got the results within 20 seconds and I had to interrupt it since it was blocked in the wait(). Then I tried putting again 240 seconds of timeout and I also got the results. One strange thing I saw was that when I got the results, printed them and then I printed the state of the measurement, there are times that the state is 1 (Scheduled) and I think most of the time the state is 2 (Ongoing), and I don't understand why is this. Today I run it again several times, but I only got the results 5 of 12 times I executed it. (The results are always available on the web page, but I don't receive them by the stream.) I also tried to add a Semaphore that is released when the callback is called (and waits/is acquired with a timeout before disconnecting), but since it wasn't working I deleted it. Thank you, Florencia. > On 2016-07-12 19:21:29 CET, Massimo Candela wrote: > > On 12 Jul 2016, at 17:17, Massimo Candela wrote: > > > > Some correction on fly, you should remove: start_time and interval since you are trying to do a one_off as soon as possible. > > I would suggest you to understand better the concepts here: https://atlas.ripe.net/docs/api/v2/manual/ or on the REST API manual. > > > > Remove also seconds=240 a and let me know if you see something. Its way way too small the timeout for a probe to get the schedule and send you some results. > > > > Sorry, for some reason I read 240ms. 5 minutes are instead enough for a one-off. > > > > >> On 12 Jul 2016, at 16:58, Florencia Alvarez Etcheverry wrote: > >> > >> Thank you for your answer. > >> I create a one-off measurement and then I want its results (as soon as they're available). > >> Here is my test code: http://pastebin.com/7p4zy388 > >> > >> On 2016-07-12 16:18:29 CET, Massimo Candela wrote: > >>> Hello Florencia, > >>> > >>> Thanks for using RIPE Atlas. > >>> > >>>> On 12 Jul 2016, at 15:47, Florencia Alvarez Etcheverry wrote: > >>>> > >>>> Hello, I started working with RIPE Atlas last week, when I made a script to create a one-off ping measurement between two specific probes (which I ping to check if they were working). I used Cousteau API, by default I sent 3 packets and I had 5 seconds of timeout. I got the results one time and then it stopped working. I changed the timeout to 3 or 4 minutes and while waiting for the callback function to execute I checked on the webpage and I can see the results for every measure I launched. > >>> > >>> The one-off measurement executes the measurement only once and gets stopped immediately. > >>> > >> But how immediately is that?, because I saw the results of the measurement but it was still running and I don't understand why. > >> How long should I wait since I launch the measurement (1 ping packet) to get the result? Is this time shorter than if I wait for the measurement to stop? (But is it possible to know that time?) > >> > >>>> > >>>> So I see the results on the page but they don't get to the stream and the callback function is never called. I also saw the status changed from "ongoing" to "stopped" several minutes after I've seen the results; which leads me to another question, when a measurement stops?, why if I already have the results of a ping (that is the only thing I've launched) it's still running? > >>>> > >>>> I tried with Cousteau and also directly with socketIO but it has the same behavior. > >>> > >>> > >>>> When I took off the parameters "packets=1,interval=60" of the request (leaving default values), > >>> > >>> What does it mean? These look like parameters for creating a (periodic) measurement, not for listening it. > >>> Can I see your code or at least the subscription parameters? > >>> > >>> Ciao, > >>> Massimo > >>> > >>>> I got the result with Cousteau API, but not with the socket directly. When I run it again it didn't work, so it looks like it works one of 20 times. Is there something I could do or am I doing something wrong? > >>>> > >>>> Thank you, > >>>> Florencia. > >>>> > >> > >> > >> > >> > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From corebug at corebug.net Thu Jul 14 11:00:56 2016 From: corebug at corebug.net (=?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KLRg9GA0L7QstC10YY=?=) Date: Thu, 14 Jul 2016 12:00:56 +0300 Subject: [atlas] Probe down Message-ID: Hello there! I've got a probe #20190 (https://atlas.ripe.net/probes/20190/) and it shows disconnected status it Atlas Web UI. I've tried to reboot the probe, it gets the IP address from my router via DHCP and i can ping it, the probe opens TCP connection to 193.0.19.25:443 and that's it. The question: how do i make it connect to Atlas again? -- ~~~ WBR, Vitalii Turovets Software Engineer VITU-RIPE -------------- next part -------------- An HTML attachment was scrubbed... URL: From raymon at van-der-meijden.com Thu Jul 14 11:04:55 2016 From: raymon at van-der-meijden.com (Raymon van der Meijden) Date: Thu, 14 Jul 2016 11:04:55 +0200 Subject: [atlas] Probe down In-Reply-To: References: Message-ID: <408f88327ca3e4f0b3ffa8519aca7e30.squirrel@webmail.raqxs.nl> If only the first led is burning and the second is blinking try to change the usb stick with a new blank stick. It solved my issue 3 times now on 2 probes > Hello there! > > I've got a probe #20190 (https://atlas.ripe.net/probes/20190/) and it > shows > disconnected status it Atlas Web UI. > > I've tried to reboot the probe, it gets the IP address from my router via > DHCP and i can ping it, the probe opens TCP connection to 193.0.19.25:443 > and that's it. > > The question: how do i make it connect to Atlas again? > > -- > > > > > ~~~ > WBR, > Vitalii Turovets > Software Engineer > VITU-RIPE > From jared at puck.nether.net Thu Jul 14 19:24:59 2016 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 14 Jul 2016 13:24:59 -0400 Subject: [atlas] Error creating one-off ping measurement Message-ID: <4B1C6889-3E07-4787-B73C-B8B754E41DA7@puck.nether.net> We are attempting to test some things and I?m getting this error. "A one-off measurement cannot have the interval field set? It seems to be a problem if this field is even blank, anyone else experience this? - Jared From job at instituut.net Thu Jul 14 19:29:11 2016 From: job at instituut.net (Job Snijders) Date: Thu, 14 Jul 2016 19:29:11 +0200 Subject: [atlas] Error creating one-off ping measurement In-Reply-To: <4B1C6889-3E07-4787-B73C-B8B754E41DA7@puck.nether.net> References: <4B1C6889-3E07-4787-B73C-B8B754E41DA7@puck.nether.net> Message-ID: <20160714172911.GF1326@vurt.meerval.net> On Thu, Jul 14, 2016 at 01:24:59PM -0400, Jared Mauch wrote: > We are attempting to test some things and I?m getting this error. > > "A one-off measurement cannot have the interval field set? > > It seems to be a problem if this field is even blank, anyone else > experience this? Same here From mcandela at ripe.net Thu Jul 14 22:45:28 2016 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 14 Jul 2016 22:45:28 +0200 Subject: [atlas] Error creating one-off ping measurement In-Reply-To: <20160714172911.GF1326@vurt.meerval.net> References: <4B1C6889-3E07-4787-B73C-B8B754E41DA7@puck.nether.net> <20160714172911.GF1326@vurt.meerval.net> Message-ID: Hello, We introduced this bug during the deployment of today. We are working on fixing it. In the meanwhile you can use the API to create measurements. The API example generated by the UI form still a valid API call. Sorry for the inconvenience. Best regards, Massimo Candela > On 14 Jul 2016, at 19:29, Job Snijders wrote: > > On Thu, Jul 14, 2016 at 01:24:59PM -0400, Jared Mauch wrote: >> We are attempting to test some things and I?m getting this error. >> >> "A one-off measurement cannot have the interval field set? >> >> It seems to be a problem if this field is even blank, anyone else >> experience this? > > Same here > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From mcandela at ripe.net Fri Jul 15 11:05:12 2016 From: mcandela at ripe.net (Massimo Candela) Date: Fri, 15 Jul 2016 11:05:12 +0200 Subject: [atlas] Error creating one-off ping measurement In-Reply-To: References: <4B1C6889-3E07-4787-B73C-B8B754E41DA7@puck.nether.net> <20160714172911.GF1326@vurt.meerval.net> Message-ID: <3A9587A2-72A9-4CD0-B0ED-BFD00C35EAF3@ripe.net> Hello, The bug has been fixed. Let us know if you have any other issue. Best regards, Massimo Candela > On 14 Jul 2016, at 22:45, Massimo Candela wrote: > > Hello, > > We introduced this bug during the deployment of today. We are working on fixing it. > > In the meanwhile you can use the API to create measurements. > The API example generated by the UI form still a valid API call. > > Sorry for the inconvenience. > > Best regards, > Massimo Candela > > >> On 14 Jul 2016, at 19:29, Job Snijders wrote: >> >> On Thu, Jul 14, 2016 at 01:24:59PM -0400, Jared Mauch wrote: >>> We are attempting to test some things and I?m getting this error. >>> >>> "A one-off measurement cannot have the interval field set? >>> >>> It seems to be a problem if this field is even blank, anyone else >>> experience this? >> >> Same here >> > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From job at instituut.net Fri Jul 15 12:48:08 2016 From: job at instituut.net (Job Snijders) Date: Fri, 15 Jul 2016 12:48:08 +0200 Subject: [atlas] start one-off from probe overview page Message-ID: <20160715104808.GK1006@57.rev.meerval.net> Hi all, UI feature requests: It would be cool if there is a button to start a one-off measurement from a certain probe's overview pages. If I am at https://atlas.ripe.net/probes/25606/ - would be nice if I can immediately jump into a one-off, rather then copy-pasting the probe's ID and creating a new one-off UDM. Kind regards, Job From fenner at fenron.com Sat Jul 16 13:31:26 2016 From: fenner at fenron.com (Bill Fenner) Date: Sat, 16 Jul 2016 13:31:26 +0200 Subject: [atlas] Stop time not retained when creating new measurement Message-ID: Hi, I created a new measurement this morning, https://atlas.ripe.net/measurements/4467029/ . Its status says: Timing 2016-07-16 07:35 No stop time defined but I filled in the stop time when I created the measurement via the web page; I saved the command that it gave me to invoke the API and it includes: ... "is_oneoff": false, "bill_to": "fenner at fenron.com", "stop_time": 1469361631 } a) this feels like a bug. Is it a bug? b) can I add the stop time post-facto, or should I remember to go back and click "stop"? Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcandela at ripe.net Mon Jul 18 10:45:54 2016 From: mcandela at ripe.net (Massimo Candela) Date: Mon, 18 Jul 2016 10:45:54 +0200 Subject: [atlas] Stop time not retained when creating new measurement In-Reply-To: References: Message-ID: <2710F73A-DB7F-478B-B1C1-55B22A4F3AC2@ripe.net> Hello Bill, Thank you for your email. The bug has been fixed. You cannot change the stop time after creation, you will need to stop it manually. Sorry for the inconvenience. Best regards, Massimo Candela > On 16 Jul 2016, at 13:31, Bill Fenner wrote: > > Hi, > > I created a new measurement this morning, https://atlas.ripe.net/measurements/4467029/ . Its status says: > > Timing 2016-07-16 07:35 No stop time defined > > but I filled in the stop time when I created the measurement via the web page; I saved the command that it gave me to invoke the API and it includes: > > ... > "is_oneoff": false, > "bill_to": "fenner at fenron.com ", > "stop_time": 1469361631 > } > > a) this feels like a bug. Is it a bug? > b) can I add the stop time post-facto, or should I remember to go back and click "stop"? > > Thanks, > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From Rafal.Jankowski at thomsonreuters.com Wed Jul 20 14:46:09 2016 From: Rafal.Jankowski at thomsonreuters.com (Rafal.Jankowski at thomsonreuters.com) Date: Wed, 20 Jul 2016 12:46:09 +0000 Subject: [atlas] Identifying widespread outages using atlas? Message-ID: <634D66B732BF1341916FCBD902B868A61D7D7076@C111WBSLMBX06.ERF.thomson.com> Hi I'm wondering if there is any good statistic tool that helps identyfing any widespread Internet outages using ripe atlas probes such as ISP issues (like todays http://www.bbc.co.uk/news/technology-36844712), cable cuts, etc. Normally I select probe and look into public measurements but it does not seem to be very effective. ________________________________ This e-mail is for the sole use of the intended recipient and contains information that may be privileged and/or confidential. If you are not an intended recipient, please notify the sender by return e-mail and delete this e-mail and any attachments. Certain required legal entity disclosures can be accessed on our website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From emile.aben at ripe.net Wed Jul 20 15:02:18 2016 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 20 Jul 2016 15:02:18 +0200 Subject: [atlas] Identifying widespread outages using atlas? In-Reply-To: <634D66B732BF1341916FCBD902B868A61D7D7076@C111WBSLMBX06.ERF.thomson.com> References: <634D66B732BF1341916FCBD902B868A61D7D7076@C111WBSLMBX06.ERF.thomson.com> Message-ID: On 20/07/16 14:46, Rafal.Jankowski at thomsonreuters.com wrote: > Hi I?m wondering if there is any good statistic tool that helps > identyfing any widespread Internet outages using ripe atlas probes such > as ISP issues (like todays > http://www.bbc.co.uk/news/technology-36844712), cable cuts, etc. > Normally I select probe and look into public measurements but it does > not seem to be very effective. yes, this is still an active topic of research. we've made some inroads into anomaly detection and RIPE Atlas traceroutes (http://arxiv.org/abs/1605.04784), and there is work in progress on making data from that available near-realtime. we do have a live-stream of probe connect/disconnect events (docs at: https://atlas.ripe.net/docs/result-streaming/ ), and are also working on detecting outage-type signals from that. and we do one-off analysis of events, examples: https://labs.ripe.net/Members/emileaben/internet-access-disruption-in-turkey https://labs.ripe.net/Members/emileaben/does-the-internet-route-around-damage that said, we can help investigate particular events, if we expect the outcome to yield interesting data/insight to our community. cheers, Emile Aben From Rafal.Jankowski at thomsonreuters.com Wed Jul 20 16:03:23 2016 From: Rafal.Jankowski at thomsonreuters.com (Rafal.Jankowski at thomsonreuters.com) Date: Wed, 20 Jul 2016 14:03:23 +0000 Subject: [atlas] Identifying widespread outages using atlas? In-Reply-To: References: <634D66B732BF1341916FCBD902B868A61D7D7076@C111WBSLMBX06.ERF.thomson.com> Message-ID: <634D66B732BF1341916FCBD902B868A61D7D7104@C111WBSLMBX06.ERF.thomson.com> Emile, Thank you for your response, that's lot of interesting reading. By the way I tried to follow one of the links from your articles: https://labs.ripe.net/Members/cristel_pelsser/pinpointing-delay-and-forwarding-anomalies-in-ripe-atlas-built-in-measurements but it seems to have endless HTTP redirection loop (screenshot attached) So please correct me if I'm wrong but except for the http://atlas-stream.ripe.net API there is no tool for end user to detect massive disruptions but you are working on it and can help with investigations if you find the case interesting? What would be the good address to discuss observed Internet outages, would it be this mailing list? By the way what is the preferred quoting style here. Is it top posting or is it better to reply inline? Is it ok to use RTF/HTML formatted e-mails or should we keep them in clean plain text? Regards, Rafa? -----Original Message----- From: Emile Aben [mailto:emile.aben at ripe.net] Sent: Wednesday, July 20, 2016 3:02 PM To: Jankowski, Rafal (Financial&Risk); ripe-atlas at ripe.net Subject: Re: [atlas] Identifying widespread outages using atlas? On 20/07/16 14:46, Rafal.Jankowski at thomsonreuters.com wrote: > Hi I'm wondering if there is any good statistic tool that helps > identyfing any widespread Internet outages using ripe atlas probes > such as ISP issues (like todays > https://urldefense.proofpoint.com/v2/url?u=http-3A__www.bbc.co.uk_news_technology-2D36844712&d=CwIDEA&c=4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r=uSdRM1m6v9tUqQwN60nzfridakyp61O-UW1qUYv1tD30FWDjrpwJLIAUAzixBHEl&m=5Z3UBNnSbSlYNxkm4daW5IWTFOymc9kWmslsB9BB6FA&s=R-eUK6LIyFAWRqJFzf0kcTZlSyhZMWrdwUcZ5224mFc&e= ), cable cuts, etc. > Normally I select probe and look into public measurements but it does > not seem to be very effective. yes, this is still an active topic of research. we've made some inroads into anomaly detection and RIPE Atlas traceroutes (https://urldefense.proofpoint.com/v2/url?u=http-3A__arxiv.org_abs_1605.04784&d=CwIDEA&c=4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r=uSdRM1m6v9tUqQwN60nzfridakyp61O-UW1qUYv1tD30FWDjrpwJLIAUAzixBHEl&m=5Z3UBNnSbSlYNxkm4daW5IWTFOymc9kWmslsB9BB6FA&s=6v3gFLshi6q1A59mMGda4KF2UatbRQwaEl309nBMOfQ&e= ), and there is work in progress on making data from that available near-realtime. we do have a live-stream of probe connect/disconnect events (docs at: https://urldefense.proofpoint.com/v2/url?u=https-3A__atlas.ripe.net_docs_result-2Dstreaming_&d=CwIDEA&c=4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r=uSdRM1m6v9tUqQwN60nzfridakyp61O-UW1qUYv1tD30FWDjrpwJLIAUAzixBHEl&m=5Z3UBNnSbSlYNxkm4daW5IWTFOymc9kWmslsB9BB6FA&s=lfTSWyrtr1sUJolSXZG39CASEyDt2NTBc8dB8gwO3Ks&e= ), and are also working on detecting outage-type signals from that. and we do one-off analysis of events, examples: https://urldefense.proofpoint.com/v2/url?u=https-3A__labs.ripe.net_Members_emileaben_internet-2Daccess-2Ddisruption-2Din-2Dturkey&d=CwIDEA&c=4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r=uSdRM1m6v9tUqQwN60nzfridakyp61O-UW1qUYv1tD30FWDjrpwJLIAUAzixBHEl&m=5Z3UBNnSbSlYNxkm4daW5IWTFOymc9kWmslsB9BB6FA&s=PysqQZMBZEFJyG9eRri5na69aiwD1PIj_7tjFJxYwgQ&e= https://urldefense.proofpoint.com/v2/url?u=https-3A__labs.ripe.net_Members_emileaben_does-2Dthe-2Dinternet-2Droute-2Daround-2Ddamage&d=CwIDEA&c=4ZIZThykDLcoWk-GVjSLm9hvvvzvGv0FLoWSRuCSs5Q&r=uSdRM1m6v9tUqQwN60nzfridakyp61O-UW1qUYv1tD30FWDjrpwJLIAUAzixBHEl&m=5Z3UBNnSbSlYNxkm4daW5IWTFOymc9kWmslsB9BB6FA&s=-e_e9VuElKj5S0jQePMj7uryH4KzZHXx0I3jwUB2KfM&e= that said, we can help investigate particular events, if we expect the outcome to yield interesting data/insight to our community. cheers, Emile Aben -------------- next part -------------- A non-text attachment was scrubbed... Name: ripe_anomaly_detector.png Type: image/png Size: 53800 bytes Desc: ripe_anomaly_detector.png URL: From emile.aben at ripe.net Wed Jul 20 16:32:10 2016 From: emile.aben at ripe.net (Emile Aben) Date: Wed, 20 Jul 2016 16:32:10 +0200 Subject: [atlas] Identifying widespread outages using atlas? In-Reply-To: <634D66B732BF1341916FCBD902B868A61D7D7104@C111WBSLMBX06.ERF.thomson.com> References: <634D66B732BF1341916FCBD902B868A61D7D7076@C111WBSLMBX06.ERF.thomson.com> <634D66B732BF1341916FCBD902B868A61D7D7104@C111WBSLMBX06.ERF.thomson.com> Message-ID: <01203ee3-7190-2c20-19a3-cb41d500ae71@ripe.net> Hi Rafa?, On 20/07/16 16:03, Rafal.Jankowski at thomsonreuters.com wrote: > Emile, > > Thank you for your response, that's lot of interesting reading. > > By the way I tried to follow one of the links from your articles: > https://labs.ripe.net/Members/cristel_pelsser/pinpointing-delay-and-forwarding-anomalies-in-ripe-atlas-built-in-measurements > > but it seems to have endless HTTP redirection loop (screenshot attached) Apologies for that. I'll ask our web team to take a look at this. > > So please correct me if I'm wrong but except for the > http://atlas-stream.ripe.net API there is no tool for end user to > detect massive disruptions but you are working on it and can help > with investigations if you find the case interesting? What would be Yes, that sounds like a good summary. Others will comment if i missed something of course. We had some nice hackathon projects on visualising probe disconnects (for instance https://github.com/RIPE-Atlas-Community/ripe-atlas-halo/tree/master/src/halo), but as far as i understand these took the raw signal and didn't do any additional statistical processing, which is something we have under research currently. > the good address to discuss observed Internet outages, would it be > this mailing list? There is a mailing list dedicated to discuss Internet outages (https://puck.nether.net/mailman/listinfo/outages); the specific GB outage you referred to earlier has been discussed there some: https://puck.nether.net/pipermail/outages/2016-July/009281.html > By the way what is the preferred quoting style here. Is it top > posting or is it better to reply inline? Is it ok to use RTF/HTML > formatted e-mails or should we keep them in clean plain text? I prefer inline, and plain text, and i have a sense that many share that preference. cheers, emile From john9871j at yahoo.com Mon Jul 25 14:19:07 2016 From: john9871j at yahoo.com (kinjo beti) Date: Mon, 25 Jul 2016 14:19:07 +0200 Subject: [atlas] Fwd: Probe 2317 is down (home fibre) In-Reply-To: <20150622123452.GA16433@gweep.net> Message-ID: also having the same problem but finally i found the fix http://www.deskdecode.com/err_connection_timed_out/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From john9871j at yahoo.com Mon Jul 25 14:19:27 2016 From: john9871j at yahoo.com (kinjo beti) Date: Mon, 25 Jul 2016 14:19:27 +0200 Subject: [atlas] Fwd: Probe 2317 is down (home fibre) In-Reply-To: <09619879-9C86-4020-8156-9F06D9A1C6EA@mx5.org.uk> Message-ID: also having the same problem but finally i found the fix http://www.deskdecode.com/err_connection_timed_out/ Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From fuller at beif.de Thu Jul 14 16:47:07 2016 From: fuller at beif.de (fuller at beif.de) Date: Thu, 14 Jul 2016 16:47:07 +0200 (CEST) Subject: [atlas] Is the Atlas probe hackable? Message-ID: <1783074904.621665.78429629-7c02-4569-90f9-343476f98d1d.open-xchange@webmail.strato.de> related to? http://mailman.nanog.org/pipermail/nanog/2016-March/084946.html From ripe at djefke.be Thu Jul 28 09:48:31 2016 From: ripe at djefke.be (Christophe Van Reeth) Date: Thu, 28 Jul 2016 09:48:31 +0200 Subject: [atlas] Troubleshooting USB stick issues - reaching out In-Reply-To: References: <63889f11-7f79-5cae-0280-d6a1e2e8b66a@ripe.net> Message-ID: <003a6f53a80ac28b22cc3dfc77b4611f.squirrel@s163.webhostingserver.nl> Hi, It's not just the Sandisk sticks that go into permanent readonly mode. The Verbatim have the same problem. Mine went into readonly mode after only 10.5 months of service. Kind regards, Christophe Van Reeth > Dear colleagues, > > recently, some of the third version of RIPE Atlas probes have had an > issue with their USB sticks. > > We're still investigating what may be causing this issue, > and in the meantime we have a possible solution, outlined in this RIPE > Labs article (and below in the email) > https://labs.ripe.net/Members/philip_homburg/troubleshooting-ripe-atlas-probes-usb-sticks > > These steps might not be a surprise to the users on this list, > but on the 4th of July we reached out to almost 5000 hosts of > "abandoned" probes, and we see immediate positive results! > > As you can see from some screenshots I quickly made, > number of active probes have increased - from 8883 on 1st July, > to 9323 this morning. Allowing for normal fluctuations, > this is still a considerable increase -- and we are grateful! > > Thank you for all the effort that you put into keeping the > RIPE Atlas network strong by keeping your probes connected. > > Kind regards, > Vesna (and the RIPE Atlas team) > > === > > Steps to power-cycle probe without USB stick: > > 1. Unplug the probe from its power source > 2. Remove the USB stick from the probe > 3. Plug in the probe WITHOUT the USB stick > 4. Wait for ten minutes > 5. Insert the USB stick > > After an hour, check SOS-messages & "Status" tab > > Note: Only on a network with working DHCP. > If you have configured probe to use static IP, > this setting would be lost if trying the steps. > > If this didn't help, try using a new, brand-name USB stick that is at > least 4GB in size (it does not need any preparation but its contents > will be erased so make sure it does not store anything crucial) > > If the problem is still there, please contact us at atlas at ripe.net >