From bortzmeyer at nic.fr Fri Apr 1 19:28:34 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 1 Apr 2016 14:28:34 -0300 Subject: [atlas] Implementing structured error reports ("Problem Details for HTTP APIs")? In-Reply-To: <56CAEAF6.80504@ripe.net> References: <20160222100820.GA28287@nic.fr> <56CAEAF6.80504@ripe.net> Message-ID: <20160401172834.GA20986@laperouse.bortzmeyer.org> On Mon, Feb 22, 2016 at 12:03:18PM +0100, Robert Kisteleki wrote a message of 17 lines which said: > Thanks for the heads up! We'll look at this, most likely when it actually > becomes an RFC :) RFC 7807 has been published (no, not today :-) From sarah.wassermann at student.ulg.ac.be Sat Apr 2 13:06:54 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sat, 2 Apr 2016 13:06:54 +0200 (CEST) Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <56DD31D2.4070808@ripe.net> Message-ID: <1887070151.708976.1459595214557.JavaMail.root@student.ulg.ac.be> Hi Viktor, Sorry for my long silence. I tried everything related to the USB drive you suggested, but nothing helped. Even worse, the probe corrupted one of my USB drives and I had to recover it with diskpart. (The USB drive worked fine just before the test, but it became unreadable afterwards and I had only 1 GB at my disposal, whereas it was a USB drive with a capacity of 16 GB) Do you have any other ideas to fix this probe or should I simply order a new one? Thanks! Sarah ----- Mail original ----- De: "Viktor Naumov" ?: "sarah wassermann" Cc: ripe-atlas at ripe.net, hank at efes.iucc.ac.il Envoy?: Lundi 7 Mars 2016 08:46:26 Objet: Re: [atlas] probe tagged as "system: Firewall problem suspected" Hi Sarah, Did you try to boot the probe without USB drive plugged in and replugging it back in 10 minutes while being powered? Did you try to replace the USB drive with a new one with capacity >= 4G? If you tried everything please write to atlas at ripe.net it will create a ticket and we will look further what we can do together about it. Cheers! /vty On 3/6/16 12:25 PM, sarah.wassermann at student.ulg.ac.be wrote: > Hi Viktor, > > I tried all your pieces of advice, but my probe is still disconnected (with 3rd light slowly blinking). > I also attempted to connect it to my router in Li?ge, on which another probe is also connected and working fine, but even there the probe didn't come back to life. > > Thanks to several generous credit-donations, I don't need credits anymore, but can I send the probe somewhere so that it can be fixed? There are not that many probes here in Luxembourg and I would be happy to host a working probe to help extend the network! > > Best regards, > > Sarah > > ----- Mail original ----- > De: "Viktor Naumov" > ?: "sarah wassermann" > Cc: ripe-atlas at ripe.net > Envoy?: Mercredi 17 F?vrier 2016 10:53:02 > Objet: Re: [atlas] probe tagged as "system: Firewall problem suspected" > > Hi Sarah, > > The tagging is done by heuristic that analyzes the probe connection > attempts, SOS, timing between them and some other attributes like > messages about flash drive. It has to have a quite large window for > looking into data and it can take up to a few days for addressing a > probe to a special controller if needed and resetting tags. > > In your case I see that it was disconnected at 2016-02-12 12:26:09. Up > till this time your probe had no problem connecting regservers and > controllers (tcp/443). After that time I see only SOS (DNS > (tcp|udp)/53). That suggests the network problem with the highest > probability - DNS is open but tcp/443 is closed. The lowest probability > has the hardware problem (flash drive) in this case. > > Please use the tag as a suggestion where to begin your local > diagnostics. If the network is good you can try to reinit the flash drive. > > wbr > > /vty > > On 2/16/16 7:29 PM, sarah.wassermann at student.ulg.ac.be wrote: >> Hi, >> >> I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... >> This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. >> >> Anybody knows how to fix this? >> >> (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) >> >> My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( >> >> Thanks! >> >> Sarah >> From BECHA at ripe.net Mon Apr 4 12:04:54 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 4 Apr 2016 12:04:54 +0200 Subject: [atlas] Credits sharing and other new features In-Reply-To: <56FBC54F.3010004@ripe.net> References: <56FBC54F.3010004@ripe.net> Message-ID: <57023C46.9010201@ripe.net> Dear colleagues, many of you have been asking for the credits sharing options, and now we have added two new ways that you can go about it: - standing orders - share access - and the transfers are still possible too All about credits: https://atlas.ripe.net/docs/credits/ In addition to that, in the past few months, we've added some other new features and functionality to RIPE Atlas, including making the DNSMON code available on GitHub for personal use, displaying IPv4 vs IPv6 comparisons in LatencyMON, and new limits on probes per measurement and results per day. Learn more about the latest updates on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-altas-update-dnsmon-on-github-latencymon-comparisons-new-credit-sharing-and-more Regards, Vesna From romeo.zwart at ripe.net Mon Apr 4 13:58:36 2016 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Mon, 4 Apr 2016 13:58:36 +0200 Subject: [atlas] [ripe.net #1204062] request to add three more ccTLDs to, DNSMON: CR, SG, and TW Message-ID: <570256EC.3080403@ripe.net> Hi Peter, You have recently requested to have three ccTLD zones be added to DNSMON. Unfortunately, since the zones do not fall into the RIPE service region and the zone owners are not members of the RIPE NCC, the request does not qualify according to ripe-661. If the zone owners do wish their zones to be monitored by DNSMON we need to ask them to become members of the RIPE NCC. Alternatively they could argument an exception for their case with the DNS working group. Apologies for the confusion. Feel free to contact us if you have further questions. Kind regards, Romeo -------- Forwarded Message -------- Subject: Re: [ripe.net #1204062] request to add three more ccTLDs to DNSMON: CR, SG, and TW Date: Mon, 04 Apr 2016 10:39:21 +0200 From: pk at denic.de Reply-To: atlas at ripe.net CC: becha at ripe.net, mgalante at ripe.net Hi Alastair, On Thu, Mar 31, 2016 at 11:40:48AM +0200, Alastair Strachan wrote: > Could you please provide me with the points of contact who gave you their consent for an independent verification? sure, we'll dig it out of our ticketing system. Regards, Peter From hank at efes.iucc.ac.il Mon Apr 4 20:57:35 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Mon, 4 Apr 2016 14:57:35 -0400 (EDT) Subject: [atlas] Credits sharing and other new features In-Reply-To: <57023C46.9010201@ripe.net> References: <56FBC54F.3010004@ripe.net> <57023C46.9010201@ripe.net> Message-ID: On Mon, 4 Apr 2016, Vesna Manojlovic wrote Thanks! Can a future improvement option be added to "shared access", whereby a limit is applied? I'd like to give some users shared access but not unlimited to eat up my entire allocation. Thanks, Hank > Dear colleagues, > > many of you have been asking for the credits sharing options, > and now we have added two new ways that you can go about it: > - standing orders > - share access > - and the transfers are still possible too > > All about credits: https://atlas.ripe.net/docs/credits/ > > In addition to that, in the past few months, we've added some other new > features and functionality to RIPE Atlas, including making the DNSMON code > available on GitHub for personal use, displaying IPv4 vs IPv6 comparisons in > LatencyMON, and new limits on probes per measurement and results per day. > > Learn more about the latest updates on RIPE Labs: > https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-altas-update-dnsmon-on-github-latencymon-comparisons-new-credit-sharing-and-more > > Regards, > Vesna > > > > > From BECHA at ripe.net Tue Apr 5 14:39:40 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 5 Apr 2016 14:39:40 +0200 Subject: [atlas] Research using RIPE Atlas probes: How Pingable are the Pingables? In-Reply-To: <5703AE86.2020701@ripe.net> References: <5703AE86.2020701@ripe.net> Message-ID: <5703B20C.4090009@ripe.net> Dear colleagues, take a look at how the "pingable:" and "ping-hdl:" attributes have been adopted in the last five years and how reachable the pingable addresses registered in the RIPE Database are when pinged from RIPE Atlas. Spoiler alert: It could be better. Please find the details on RIPE Labs: https://labs.ripe.net/Members/wilhelm/how-pingable-are-the-pingables Kind regards, Vesna From wenqin.shao at telecom-paristech.fr Tue Apr 5 20:53:59 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Tue, 5 Apr 2016 20:53:59 +0200 Subject: [atlas] Flow-id of built-in traceroute measurement Message-ID: <64699FAF-D965-4E96-9708-0CD2D410D5A0@telecom-paristech.fr> Dear list, I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help. As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. With this behaviour, it is supposed to reveal the diversity of underlying IP paths. In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer? Many thanks in advance. Best regards, Wenqin ==== Wenqin SHAO PhD Candidate Telecom ParisTech From philip.homburg at ripe.net Wed Apr 6 10:36:16 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 6 Apr 2016 10:36:16 +0200 Subject: [atlas] Flow-id of built-in traceroute measurement In-Reply-To: <64699FAF-D965-4E96-9708-0CD2D410D5A0@telecom-paristech.fr> References: <64699FAF-D965-4E96-9708-0CD2D410D5A0@telecom-paristech.fr> Message-ID: <5704CA80.5000808@ripe.net> Hi, On 2016/04/05 20:53 , Wenqin SHAO wrote: > I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help. > > As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. > With this behaviour, it is supposed to reveal the diversity of underlying IP paths. > > In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? > If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? > If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer? Basically, the wider the range, the longer you have to wait for two traceroute results that take the same path. Of course, if you want to investigate one particular path, you can just schedule your own measurement with different parameters. I have not seen any analysis that estimates what percentage of source, destinations pairs would have more than 16 different paths. If that percentage is significant, then it's worth considering raising the value. Philip From jared at puck.Nether.net Wed Apr 6 13:06:35 2016 From: jared at puck.Nether.net (Jared Mauch) Date: Wed, 6 Apr 2016 07:06:35 -0400 Subject: [atlas] Scheduling a test for all probes? In-Reply-To: <56A8A91F.5050903@ripe.net> References: <6DA0773E-8FA8-4269-B170-84591D8B1E36@puck.nether.net> <56A8A91F.5050903@ripe.net> Message-ID: <20160406110635.GA11523@puck.nether.net> On Wed, Jan 27, 2016 at 12:25:19PM +0100, Robert Kisteleki wrote: > (Excuse me for the belated answer -- I'm picking up topics that were not > answered by us or the community.) > > On 2015-12-09 20:00, Jared Mauch wrote: > > Is there a way to schedule a one-off test on all the probes to be run ?at a leisurely pace?, eg: looking up a specific DNS QNAME? > > > > (I?ll call it a lazy query/scheduling). > > > > - Jared > > Not at the moment -- one-off really means "it's important, do it now!" Yeah, I'm looking for something that says "I'd like to run this one item on all probes". > One can always schedule a short-running regular measurement and use the > (new) spread control mechanism to distribute the probes over a longer period. I'll have to look closer at this. - Jared -- Jared Mauch | pgp key available via finger from jared at puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. From wenqin.shao at telecom-paristech.fr Fri Apr 8 11:18:37 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Fri, 8 Apr 2016 11:18:37 +0200 Subject: [atlas] Flow-id of built-in traceroute measurement In-Reply-To: <5704CA80.5000808@ripe.net> References: <64699FAF-D965-4E96-9708-0CD2D410D5A0@telecom-paristech.fr> <5704CA80.5000808@ripe.net> Message-ID: <077BD281-19F5-4785-8214-C40F4A1FC10C@telecom-paristech.fr> Hi Philip, Thank you for replying. I have some observations, but not really statistics, as they only tell the story of my fairly limited sample set. I selected built-in traceroute measurement to b-root from 128 probes hosted in European DC. 123 of them have no more than 16 different IP paths over a weeks' time, i.e. 336 traceroute measurements in all. 3 of them have more than 50 different IP paths, among which 1 have more than 200. Regards, wenqin -------------- next part -------------- A non-text attachment was scrubbed... Name: ip_diver_cdf.pdf Type: application/pdf Size: 5149 bytes Desc: not available URL: -------------- next part -------------- > On 06 Apr 2016, at 10:36, Philip Homburg wrote: > > Hi, > > On 2016/04/05 20:53 , Wenqin SHAO wrote: >> I have some questions concerning the flow-id of built-in traceroute measurements and are seeking for your help. >> >> As many of you may have already noticed, the flow-id of the built-in traceroute measurement periodically varies form 0 to 15, in a circular manner. >> With this behaviour, it is supposed to reveal the diversity of underlying IP paths. >> >> In the case that there are more than 16 unique IP paths between a source and destination pair, could this scheme reveal all of these IP paths? >> If it can, which leads to more than one IP paths per flow-id? Is it normal, from a load balancer point of view? >> If it can not, then why not a wider range of flow-id (more nuances in header hash results), say [0, 63]? Is it related to common realisation of load balancer? > > Basically, the wider the range, the longer you have to wait for two > traceroute results that take the same path. > > Of course, if you want to investigate one particular path, you can just > schedule your own measurement with different parameters. > > I have not seen any analysis that estimates what percentage of source, > destinations pairs would have more than 16 different paths. If that > percentage is significant, then it's worth considering raising the value. > > Philip > From becha at ripe.net Mon Apr 11 13:24:11 2016 From: becha at ripe.net (Vesna Manojlovic) Date: Mon, 11 Apr 2016 13:24:11 +0200 Subject: [atlas] Introducing the RIPE Forum In-Reply-To: None Message-ID: Dear colleagues, There?s a new way to participate on the RIPE Atlas mailing list! We are introducing the RIPE Forum, a web-based interface for reading and sending emails on RIPE community mailing lists. We developed the RIPE Forum in-house based on feedback we received from members of the RIPE community who wanted the option to interact and share information in a more modern way. But it?s important to note that this new interface is completely optional ? those who like using the established mailing list system can continue on as they always have, and won?t notice any difference. RIPE Atlas mailing list will be the first one. We have plans to make the RIPE Forum available for other RIPE Community mailings lists after the RIPE 72 Meeting in May. If you?re interested, you can start using it here: https://www.ripe.net/participate/mail/forum/ We created a special mailing list for testing purposes, so that any conversations about the platform itself can be contained there without disrupting the regular flow of discussions on the RIPE Atlas mailing list. Feel free to send test messages and try out the RIPE Forum on this special list: https://www.ripe.net/participate/mail/forum/ripe-forum-test Learn more how the forum works and the background of the project: https://labs.ripe.net/Members/marco_schmidt/introducing-the-ripe-forum The forum is still in "beta" status ? there are likely still some bugs and we are continuously working to improve things, so please keep that in mind while exploring the forum. You can give your feedback by clicking on the ?Report a bug? button on the forum, or leave a comment on the above RIPE Labs article. We hope you?ll enjoy the RIPE Forum, and look forward to your feedback! Kind regards, Vesna Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ripecontact at markyate.net Mon Apr 11 13:34:53 2016 From: ripecontact at markyate.net (Alison Wheeler) Date: Mon, 11 Apr 2016 13:34:53 +0200 Subject: [atlas] Local network checks In-Reply-To: None Message-ID: Recently my probe stopped responding to RIPE even though it was pingable through the local network. Putting aside what the cause might have been* is there any way to 're-awaken' or cycle in some way a probe without physical access to it? (* sfaict it didn't restart when the USB socket on the server it takes power from was remotely restarted) Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From gert at space.net Mon Apr 11 13:39:21 2016 From: gert at space.net (Gert Doering) Date: Mon, 11 Apr 2016 13:39:21 +0200 Subject: [atlas] Local network checks In-Reply-To: References: Message-ID: <20160411113921.GH56633@Space.Net> Hi, On Mon, Apr 11, 2016 at 01:34:53PM +0200, Alison Wheeler wrote: > Recently my probe stopped responding to RIPE even though it was pingable through the local network. Putting aside what the cause might have been* is there any way to 're-awaken' or cycle in some way a probe without physical access to it? > > (* sfaict it didn't restart when the USB socket on the server it takes power from was remotely restarted) Check the SOS messages on the "my probes -> network" web page - most likely the USB flash is borked. The probe will signal this (and other errors) to the NCC controller, but the controller doesn't bother tell to this anyone but list it on the web page, next to the "beware of the leopard" sign. 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: 819 bytes Desc: not available URL: From ripecontact at markyate.net Mon Apr 11 13:49:04 2016 From: ripecontact at markyate.net (Alison Wheeler) Date: Mon, 11 Apr 2016 13:49:04 +0200 Subject: [atlas] Local network checks In-Reply-To: <20160411113921.GH56633@Space.Net> Message-ID: Sadly, there was nothing in there to indicate a problem, other than no records: 
74.125.47.144 	2016-04-07 18:57:44 	A 	0h 1m 	
74.125.47.140 	2016-04-07 18:57:44 	AAAA 	0h 1m 	
2a00:1450:400c:c08::116 	2016-03-26 00:58:46 	A 	8d 9h 17m 	
74.125.47.14 	2016-03-26 00:58:46 	AAAA 	8d 9h 17m
and as I don't check the probe's status daily (mea culpa!) it wasn't until I was mailed after a week of it being down that I knew there was an issue. But even then, if the RIPE servers can't 'see' the probe I can't do anything via the web interface, hence my wondering if there is any way to awaken it via a local network action (analogous to sending a WakeOnLAN ping) Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From gert at space.net Mon Apr 11 13:54:40 2016 From: gert at space.net (Gert Doering) Date: Mon, 11 Apr 2016 13:54:40 +0200 Subject: [atlas] Local network checks In-Reply-To: References: <20160411113921.GH56633@Space.Net> Message-ID: <20160411115440.GI56633@Space.Net> Hi, On Mon, Apr 11, 2016 at 01:49:04PM +0200, Alison Wheeler wrote: > Sadly, there was nothing in there to indicate a problem, other than no records: > 
> 74.125.47.144 	2016-04-07 18:57:44 	A 	0h 1m 	
> 74.125.47.140 	2016-04-07 18:57:44 	AAAA 	0h 1m 	
> 2a00:1450:400c:c08::116 	2016-03-26 00:58:46 	A 	8d 9h 17m 	
> 74.125.47.14 	2016-03-26 00:58:46 	AAAA 	8d 9h 17m
>
These are not the SOS messages. > and as I don't check the probe's status daily (mea culpa!) it wasn't until I was mailed after a week of it being down that I knew there was an issue. But even then, if the RIPE servers can't 'see' the probe I can't do anything via the web interface, hence my wondering if there is any way to awaken it via a local network action (analogous to sending a WakeOnLAN ping) Most likely it will need flash stick cyling. But you'll see that in the SOS messages. (Repating myself, it would be *so* helpful if the mail "hey, your probe is down!" actually included availble SOS diagnostics...) 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: 819 bytes Desc: not available URL: From philip.homburg at ripe.net Mon Apr 11 13:57:52 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 11 Apr 2016 13:57:52 +0200 Subject: [atlas] Local network checks In-Reply-To: <20160411115440.GI56633@Space.Net> References: <20160411113921.GH56633@Space.Net> <20160411115440.GI56633@Space.Net> Message-ID: <570B9140.3080506@ripe.net> On 2016/04/11 13:54 , Gert Doering wrote: > Most likely it will need flash stick cyling. But you'll see that in the > SOS messages. > > (Repating myself, it would be *so* helpful if the mail "hey, your probe > is down!" actually included availble SOS diagnostics...) There is a project to try to have a section of the probe web site dedicated to diagnosing probe problems. I think that is close to going live. -------------- 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 Mon Apr 11 14:02:15 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 11 Apr 2016 14:02:15 +0200 Subject: [atlas] Local network checks In-Reply-To: References: Message-ID: <570B9247.8070500@ripe.net> On 2016/04/11 13:49 , Alison Wheeler wrote: > Sadly, there was nothing in there to indicate a problem, other than no records: > 
> 74.125.47.144 	2016-04-07 18:57:44 	A 	0h 1m 	
> 74.125.47.140 	2016-04-07 18:57:44 	AAAA 	0h 1m 	
> 2a00:1450:400c:c08::116 	2016-03-26 00:58:46 	A 	8d 9h 17m 	
> 74.125.47.14 	2016-03-26 00:58:46 	AAAA 	8d 9h 17m
>
> and as I don't check the probe's status daily (mea culpa!) it wasn't until I was mailed after a week of it being down that I knew there was an issue. But even then, if the RIPE servers can't 'see' the probe I can't do anything via the web interface, hence my wondering if there is any way to awaken it via a local network action (analogous to sending a WakeOnLAN ping) Unfortunately, there is an issue where after some time the filesystem on the USB stick just becomes corrupt. There is no obvious pattern. Some probes are running for years without any problem. If the filesystem is corrupt, then to recover it should be sufficient the connect the probe without the USB stick wait for about 10 minutes and insert the USB stick. This works only if the probe can get address from DHCP. It doesn't work in all case, sometimes the USB is actually broken. And there is at least one way that the filesystem can be corrupt in a way that can fool this trick. From gert at space.net Mon Apr 11 14:39:27 2016 From: gert at space.net (Gert Doering) Date: Mon, 11 Apr 2016 14:39:27 +0200 Subject: [atlas] Local network checks In-Reply-To: <570B9140.3080506@ripe.net> References: <20160411113921.GH56633@Space.Net> <20160411115440.GI56633@Space.Net> <570B9140.3080506@ripe.net> Message-ID: <20160411123927.GJ56633@Space.Net> Hi, On Mon, Apr 11, 2016 at 01:57:52PM +0200, Philip Homburg wrote: > On 2016/04/11 13:54 , Gert Doering wrote: > > Most likely it will need flash stick cyling. But you'll see that in the > > SOS messages. > > > > (Repating myself, it would be *so* helpful if the mail "hey, your probe > > is down!" actually included availble SOS diagnostics...) > > There is a project to try to have a section of the probe web site > dedicated to diagnosing probe problems. I think that is close to going live. While that is an improvement, actually having diagnostic info in the *mails* sent (especially about "we're having USB troubles, so better bring a fresh USB stick with you before you drive out to the probe site!") would be even better. The reason why I'm so insistant about this: I have two probes sitting in remote locations and both needed *multiple* visits because the flash was broken, the system *knew* about it ("ROUSB"), and didn't tell me (and yes, because I'm old and stupid and forgot to check the well-hidden SOS message list when the second probe broke...) - would have saved me about three visits, which accumulate to about half a day human life time. Far too valuable to waste on lack of proper diagnostics. 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: 819 bytes Desc: not available URL: From alarig at grifon.fr Mon Apr 11 14:40:57 2016 From: alarig at grifon.fr (Alarig Le Lay) Date: Mon, 11 Apr 2016 14:40:57 +0200 Subject: [atlas] Introducing the RIPE Forum In-Reply-To: References: Message-ID: <20160411124057.GQ27352@drscott.swordarmor.fr> Hi, Good news :) Is the code will be published someday? -- alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From philip.homburg at ripe.net Mon Apr 11 14:48:14 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 11 Apr 2016 14:48:14 +0200 Subject: [atlas] Local network checks In-Reply-To: <20160411123927.GJ56633@Space.Net> References: <20160411113921.GH56633@Space.Net> <20160411115440.GI56633@Space.Net> <570B9140.3080506@ripe.net> <20160411123927.GJ56633@Space.Net> Message-ID: <570B9D0E.5080505@ripe.net> On 2016/04/11 14:39 , Gert Doering wrote: > While that is an improvement, actually having diagnostic info in the > *mails* sent (especially about "we're having USB troubles, so better bring > a fresh USB stick with you before you drive out to the probe site!") would > be even better. > > The reason why I'm so insistant about this: I have two probes sitting > in remote locations and both needed *multiple* visits because the flash > was broken, the system *knew* about it ("ROUSB"), and didn't tell me > (and yes, because I'm old and stupid and forgot to check the well-hidden > SOS message list when the second probe broke...) - would have saved > me about three visits, which accumulate to about half a day human life > time. Far too valuable to waste on lack of proper diagnostics. Okay. I just created a ticket for this. No idea when someone gets around to actually doing it though. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From martin at linuxlounge.net Mon Apr 11 14:52:34 2016 From: martin at linuxlounge.net (Martin Weinelt) Date: Mon, 11 Apr 2016 14:52:34 +0200 Subject: [atlas] Failing 4GB USB on v3 probes? In-Reply-To: Message-ID: I also had a SanDisk Cruzer 4GB drive fail on me. I exchanged it via my RIPE Ambassador. Might be worth looking into, as I have colleagues that reported the same issue. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From ripecontact at markyate.net Mon Apr 11 14:54:44 2016 From: ripecontact at markyate.net (Alison Wheeler) Date: Mon, 11 Apr 2016 14:54:44 +0200 Subject: [atlas] Local network checks In-Reply-To: <20160411115440.GI56633@Space.Net> Message-ID: On 2016-04-11 13:54:40 CET, Gert Doering wrote: > > 74.125.47.144 2016-04-07 18:57:44 A 0h 1m > > 74.125.47.140 2016-04-07 18:57:44 AAAA 0h 1m > > 2a00:1450:400c:c08::116 2016-03-26 00:58:46 A 8d 9h 17m > > 74.125.47.14 2016-03-26 00:58:46 AAAA 8d 9h 17m > These are not the SOS messages. That's the content under the "SOS History" heading. I don't see anything which could be described as "the "beware of the leopard" sign. Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From mm at 42com.com Mon Apr 11 15:00:55 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Mon, 11 Apr 2016 15:00:55 +0200 Subject: [atlas] Incorrect probe connection information? Message-ID: <570BA007.6030509@42com.com> Hi, I think there is a small bug/issue with the statistics of the probe (Tab : "Network") : Connection Information Time Connected Percent Last Week 9d 10h 2m 100.00% Last Month 55d 10h 2m 100.00% How could it be that Last Month my probe was connected for 55 days? (It's only a single probe) Any idea? Best Regards Max M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From canadatechguy at gmail.com Mon Apr 11 15:07:58 2016 From: canadatechguy at gmail.com (Tanner Ryan) Date: Mon, 11 Apr 2016 09:07:58 -0400 Subject: [atlas] Incorrect probe connection information? In-Reply-To: <570BA007.6030509@42com.com> References: <570BA007.6030509@42com.com> Message-ID: I've noticed that well. My probe is displaying 100% uptime, even though it has been offline due to power outages. On Monday, April 11, 2016, Max M?hlbronner wrote: > Hi, > > > I think there is a small bug/issue with the statistics of the probe (Tab : > "Network") : > > Connection Information > > Time Connected Percent > Last Week 9d 10h 2m 100.00% > Last Month 55d 10h 2m 100.00% > > How could it be that Last Month my probe was connected for 55 days? (It's > only a single probe) > > Any idea? > > > Best Regards > > > Max M. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gert at space.net Mon Apr 11 15:38:01 2016 From: gert at space.net (Gert Doering) Date: Mon, 11 Apr 2016 15:38:01 +0200 Subject: [atlas] Local network checks In-Reply-To: References: <20160411115440.GI56633@Space.Net> Message-ID: <20160411133801.GL56633@Space.Net> Hi, On Mon, Apr 11, 2016 at 02:54:44PM +0200, Alison Wheeler wrote: > On 2016-04-11 13:54:40 CET, Gert Doering wrote: > > > 74.125.47.144 2016-04-07 18:57:44 A 0h 1m > > > 74.125.47.140 2016-04-07 18:57:44 AAAA 0h 1m > > > 2a00:1450:400c:c08::116 2016-03-26 00:58:46 A 8d 9h 17m > > > 74.125.47.14 2016-03-26 00:58:46 AAAA 8d 9h 17m > > These are not the SOS messages. > > That's the content under the "SOS History" heading. Oh, good point. I never looked there when one of my probes was actually *working* - if it's broken, but still *has* working DNS, you should see at least a few queries each time it's booting, and if the probe is unhappy, with something in the "Info" column (which is empty if everything is fine). Since you do not see anything - try powercycling again, and possibly sniffing on the probe's network port what it's doing... > I don't see anything which could be described as "the "beware of the leopard" sign. This is a reference to an obscure book :-) (and was intended to read "it's there, if you know where to find it"). 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: 819 bytes Desc: not available URL: From astrikos at ripe.net Mon Apr 11 16:12:40 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Mon, 11 Apr 2016 16:12:40 +0200 Subject: [atlas] Incorrect probe connection information? In-Reply-To: <570BA007.6030509@42com.com> References: <570BA007.6030509@42com.com> Message-ID: <570BB0D8.9070808@ripe.net> Hi, there seems to be a mishandling of special cases on the connections history. If you notice your connections history there is one entry that is almost the same as the previous one, which confuses also the uptime calculations. We are looking into it and will let you know as soon as it's fixed. Regards, Andreas On 11/04/16 15:00, Max M?hlbronner wrote: > Hi, > > > I think there is a small bug/issue with the statistics of the probe > (Tab : "Network") : > > > Connection Information > > > Time Connected Percent > Last Week 9d 10h 2m 100.00% > Last Month 55d 10h 2m 100.00% > > > > How could it be that Last Month my probe was connected for 55 days? > (It's only a single probe) > > Any idea? > > > Best Regards > > > Max M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gboonie at gmail.com Mon Apr 11 21:10:50 2016 From: gboonie at gmail.com (gboonie) Date: Mon, 11 Apr 2016 21:10:50 +0200 Subject: [atlas] change stop date? Message-ID: <570BF6BA.5000300@gmail.com> Hi, In the past, when you scheduled a measurement for some weeks, you could change the end date. This does not seem possible any more. Is that intentional? Could that be changed please? Also, can't we change measurements to private anymore? The field is there to show that it is public, but changing does not seem possible anymore. Thanks, Dave From mgrigore at ripe.net Tue Apr 12 19:02:47 2016 From: mgrigore at ripe.net (Mihnea-Costin Grigore) Date: Tue, 12 Apr 2016 19:02:47 +0200 Subject: [atlas] Introducing the RIPE Forum In-Reply-To: <20160411124057.GQ27352@drscott.swordarmor.fr> References: <20160411124057.GQ27352@drscott.swordarmor.fr> Message-ID: <570D2A37.7040906@ripe.net> Dear Alarig, Thank you for your feedback and for testing out the RIPE Forum. Currently we have no plans to publish the code powering the RIPE Forum as it is tightly integrated with our existing infrastructure such as RIPE NCC Access and would not work in another environment without extensive changes. If the project is successful and there is demand for it, we will consider creating a stand-alone version or releasing parts of the code for external use. If there is anything I can help with further please let me know. Regards, Mihnea-Costin Grigore Web Services Team Leader RIPE NCC On 11/04/2016 14:40, Alarig Le Lay wrote: > Hi, > > Good news :) Is the code will be published someday? > -- Mihnea-Costin Grigore RIPE NCC Web Services Team Leader - https://www.ripe.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From mkh at rqc.ru Wed Apr 13 10:23:35 2016 From: mkh at rqc.ru (Marat Khalili) Date: Wed, 13 Apr 2016 11:23:35 +0300 Subject: [atlas] LatencyMON Widget Y axis in milliseconds Message-ID: <570E0207.1090508@rqc.ru> I'm using LatencyMON widget to monitor my network performance. It's very convenient. Unfortunately, it always loads with latency shown in %% (of what?), not in milliseconds, so I have to make one extra click in order to view actual milliseconds. Is there some hidden switch that would make milliseconds the default? Shouldn't it be initially default in the first place? -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Wed Apr 13 14:01:48 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 13 Apr 2016 14:01:48 +0200 Subject: [atlas] Incorrect probe connection information? In-Reply-To: References: <570BA007.6030509@42com.com> Message-ID: <570E352C.3050709@ripe.net> Hi, these issues should now be fixed. You network history statistics should now be back to normal. If you encounter more of these please let us now. Regards, Andreas On 11/04/16 15:07, Tanner Ryan wrote: > I've noticed that well. > > My probe is displaying 100% uptime, even though it has been offline > due to power outages. > > On Monday, April 11, 2016, Max M?hlbronner > wrote: > > Hi, > > > I think there is a small bug/issue with the statistics of the > probe (Tab : "Network") : > > > Connection Information > > > Time Connected Percent > Last Week 9d 10h 2m 100.00% > Last Month 55d 10h 2m 100.00% > > > > How could it be that Last Month my probe was connected for 55 > days? (It's only a single probe) > > Any idea? > > > Best Regards > > > Max M. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact.anthoo at gmail.com Wed Apr 13 23:37:11 2016 From: contact.anthoo at gmail.com (Anthony) Date: Wed, 13 Apr 2016 23:37:11 +0200 Subject: [atlas] Open ports? Message-ID: <570EBC07.4030508@gmail.com> Hello, I received my probe today and I had to disable the firewall for my box that appears connected to the site. I reactivated and after all the work area, but I would have liked to know what need had to open? How to know if everything is ok? Sorry for my English, thank you in advance From c.estelmann at gmx.net Thu Apr 14 19:20:39 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Thu, 14 Apr 2016 19:20:39 +0200 Subject: [atlas] Open ports? In-Reply-To: <570EBC07.4030508@gmail.com> References: <570EBC07.4030508@gmail.com> Message-ID: <570FD167.3060805@gmx.net> Hi, the FAQ says "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) in order to allow the probe to connect to the network. However, this in itself is not enough to do measurements, which is the entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), TCP for traceroute and HTTP(S)." (https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work) Traceroute is port 33434 (when I am remembering right). Hope that helps. Greetings, Christian Am 13.04.2016 um 23:37 schrieb Anthony: > Hello, > I received my probe today and I had to disable the firewall for my box > that appears connected to the site. I reactivated and after all the work > area, but I would have liked to know what need had to open? > > > How to know if everything is ok? > > Sorry for my English, > > thank you in advance > From contact.anthoo at gmail.com Thu Apr 14 21:24:23 2016 From: contact.anthoo at gmail.com (Anthony) Date: Thu, 14 Apr 2016 21:24:23 +0200 Subject: [atlas] Open ports? In-Reply-To: <570FD167.3060805@gmx.net> References: <570EBC07.4030508@gmail.com> <570FD167.3060805@gmx.net> Message-ID: <570FEE67.1080605@gmail.com> Hello, Thank you for the answer. Do you everything seems to be good there? : http://planet-upload.net/images/8cefe43963593d4ce948f8d907551fc6.jpg Because I feel it lacks a LED. thank you in advance Le 14/04/2016 19:20, Estelmann, Christian a ?crit : > Hi, > > the FAQ says > "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 > (HTTPS) in order to allow the probe to connect to the network. > However, this in itself is not enough to do measurements, which is the > entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + > traceroute), TCP for traceroute and HTTP(S)." > (https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work) > > > Traceroute is port 33434 (when I am remembering right). > > Hope that helps. > > Greetings, > Christian > > Am 13.04.2016 um 23:37 schrieb Anthony: >> Hello, >> I received my probe today and I had to disable the firewall for my box >> that appears connected to the site. I reactivated and after all the work >> area, but I would have liked to know what need had to open? >> >> >> How to know if everything is ok? >> >> Sorry for my English, >> >> thank you in advance >> From contact.anthoo at gmail.com Thu Apr 14 21:28:00 2016 From: contact.anthoo at gmail.com (Anthony) Date: Thu, 14 Apr 2016 21:28:00 +0200 Subject: [atlas] Open ports? In-Reply-To: <570FD167.3060805@gmx.net> References: <570EBC07.4030508@gmail.com> <570FD167.3060805@gmx.net> Message-ID: <570FEF40.7010104@gmail.com> I think she is: Connected on off on on undetermined So logically any good? and if nothing is blocked? Le 14/04/2016 19:20, Estelmann, Christian a ?crit : > Hi, > > the FAQ says > "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 > (HTTPS) in order to allow the probe to connect to the network. > However, this in itself is not enough to do measurements, which is the > entire focus of RIPE Atlas, so you should also allow ICMP, UDP (DNS + > traceroute), TCP for traceroute and HTTP(S)." > (https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work) > > > Traceroute is port 33434 (when I am remembering right). > > Hope that helps. > > Greetings, > Christian > > Am 13.04.2016 um 23:37 schrieb Anthony: >> Hello, >> I received my probe today and I had to disable the firewall for my box >> that appears connected to the site. I reactivated and after all the work >> area, but I would have liked to know what need had to open? >> >> >> How to know if everything is ok? >> >> Sorry for my English, >> >> thank you in advance >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From boesen at belwue.de Fri Apr 15 10:57:15 2016 From: boesen at belwue.de (Andreas Boesen) Date: Fri, 15 Apr 2016 10:57:15 +0200 Subject: [atlas] Open ports? In-Reply-To: <570FD167.3060805@gmx.net> References: <570EBC07.4030508@gmail.com> <570FD167.3060805@gmx.net> Message-ID: <5710ACEB.2040400@belwue.de> Hi Anthony, Am 14.04.2016 um 19:20 schrieb Estelmann, Christian: > Am 13.04.2016 um 23:37 schrieb Anthony: >> Hello, >> I received my probe today and I had to disable the firewall for my box >> that appears connected to the site. I reactivated and after all the work >> area, but I would have liked to know what need had to open? as far as I understand the probe just needs to be able to establish _outgoing_ connections. When I connected the probe to my private DSL connection (a home router that does some NAT/firewalling) I did _not_ have to change anything in my setup. So there is usually no need to disable a Firewall as long as the firewall/NAT setup does allow _outgoing_ connections (at least for the probe). As Christian already linked the FAQ your probe should be allowed to: (1) establish outgoing TCP connections (2) establish outgoing UDP connections (3) send/receive ICMP packets So you do _not_ have to open ports for "incoming" connections / forward ports on your NAT. Just do not block outgoing connections. Also the probe can take some time before the website will list it as "connected". I just connected it and when I looked at the next day (after registering the probe) it was working fine. > > Hi, > > the FAQ says > "The absolute minimum set is DHCP, DNS and outgoing TCP port 443 (HTTPS) > in order to allow the probe to connect to the network. However, this > in itself is not enough to do measurements, which is the entire focus > of RIPE Atlas, so you should also allow ICMP, UDP (DNS + traceroute), > TCP for traceroute and HTTP(S)." > (https://atlas.ripe.net/about/faq/#so-which-services-do-i-need-for-my-probe-to-work) > > Traceroute is port 33434 (when I am remembering right). Depending on how the probe does traceroute this may not be the only method. Depending on the implementation (AFAIK!) this might be different as different protocols might be used in a combination. > > Hope that helps. > > Greetings, > Christian Best regards, Andreas PS at Christian: Sorry for the spam. In my first attempt to send the email I just replied to you and not to the list. :-/ -- Andreas Boesen, BelW?-Koordination, Universit?t Stuttgart Industriestr. 28, 70565 Stuttgart Tel. 0711/685-65750 - Fax 0711/6788363 boesen at belwue.de - http://www.belwue.de ~cd in and find out -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: OpenPGP digital signature URL: From daniel.karrenberg at ripe.net Fri Apr 15 14:39:36 2016 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Fri, 15 Apr 2016 14:39:36 +0200 Subject: [atlas] Open ports? In-Reply-To: <5710ACEB.2040400@belwue.de> References: <570EBC07.4030508@gmail.com> <570FD167.3060805@gmx.net> <5710ACEB.2040400@belwue.de> Message-ID: <5710E108.900@ripe.net> On 15.04.16 10:57 , Andreas Boesen wrote: > > as far as I understand the probe just needs to be able to establish > _outgoing_ connections. ... That is correct. No *incoming* ports need to be opened! Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From bjonglez at illyse.org Fri Apr 15 18:11:30 2016 From: bjonglez at illyse.org (Baptiste Jonglez) Date: Fri, 15 Apr 2016 18:11:30 +0200 Subject: [atlas] API filtering for looking at measurements? Message-ID: <20160415161129.GA11445@illyse.org> Hi, I would like to find measurements matching some specific conditions, so I tried to use the measurement API documented here: https://atlas.ripe.net/docs/rest/ However, filters don't seem to have the intended effect. For instance, I tried to restrict to a specific range of starting time: https://atlas.ripe.net/api/v1/measurement/?start_time__gte=1443654000&start_time_lte=1446336000 but looking at the first result (measurement ID 1411440), its start time is 1564618500, which is way outside of the requested range. Similarly when filtering by type: https://atlas.ripe.net/api/v1/measurement/?type=2 type=2 is supposed to be IPv4 traceroute, but the first result is measurement ID 1001, which is an IPv4 ping. Am I using the API incorrectly, or is there a bug somewhere? Thanks, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From jdenhertog at ripe.net Mon Apr 18 09:18:49 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Mon, 18 Apr 2016 09:18:49 +0200 Subject: [atlas] API filtering for looking at measurements? In-Reply-To: <20160415161129.GA11445@illyse.org> References: <20160415161129.GA11445@illyse.org> Message-ID: Baptiste, > On 15 Apr 2016, at 18:11, Baptiste Jonglez wrote: > > Hi, > > I would like to find measurements matching some specific conditions, so I > tried to use the measurement API documented here: > > https://atlas.ripe.net/docs/rest/ > > However, filters don't seem to have the intended effect. For instance, I > tried to restrict to a specific range of starting time: > > https://atlas.ripe.net/api/v1/measurement/?start_time__gte=1443654000&start_time_lte=1446336000 There is small type in your start_time__lte query-parameter. It should have double underscores between `start_time` and `lte`. It will work then > but looking at the first result (measurement ID 1411440), its start time > is 1564618500, which is way outside of the requested range. > > Similarly when filtering by type: > > https://atlas.ripe.net/api/v1/measurement/?type=2 type should be the name of the type as a string `?type=tracertoue` Also, I would like to advise you to use the v2 API from now on, we?re going to deprecate v1. There is a manual for V2 at https://atlas.ripe.net/docs/api/v2/tutorial/ and there is reference documentation at https://atlas.ripe.net/docs/api/v2/reference/ . This is till in beta, url?s for the documentation will change but it will be available then be linked from https://atlas.ripe.net/docs/ greetings, Jasper den Hertog -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From bjonglez at illyse.org Mon Apr 18 18:18:58 2016 From: bjonglez at illyse.org (Baptiste Jonglez) Date: Mon, 18 Apr 2016 18:18:58 +0200 Subject: [atlas] API filtering for looking at measurements? In-Reply-To: References: <20160415161129.GA11445@illyse.org> Message-ID: <20160418161857.GA31473@illyse.org> Hi Jasper, On Mon, Apr 18, 2016 at 09:18:49AM +0200, Jasper den Hertog wrote: > > On 15 Apr 2016, at 18:11, Baptiste Jonglez wrote: > > > > I would like to find measurements matching some specific conditions, so I > > tried to use the measurement API documented here: > > > > https://atlas.ripe.net/docs/rest/ > > > > However, filters don't seem to have the intended effect. For instance, I > > tried to restrict to a specific range of starting time: > > > > https://atlas.ripe.net/api/v1/measurement/?start_time__gte=1443654000&start_time_lte=1446336000 > There is small type in your start_time__lte query-parameter. It should have double underscores between `start_time` and `lte`. It will work then > > > but looking at the first result (measurement ID 1411440), its start time > > is 1564618500, which is way outside of the requested range. > > > > Similarly when filtering by type: > > > > https://atlas.ripe.net/api/v1/measurement/?type=2 > type should be the name of the type as a string `?type=tracertoue` You're right, with the corrected parameters, it works fine... I guess it's bad luck that I made a mistake in each of my two attempts. > Also, I would like to advise you to use the v2 API from now on, we?re going to deprecate v1. > > There is a manual for V2 at https://atlas.ripe.net/docs/api/v2/tutorial/ and there is reference documentation at https://atlas.ripe.net/docs/api/v2/reference/ . This is till in beta, url?s for the documentation will change but it will be available then be linked from https://atlas.ripe.net/docs/ Ok, thank you for the links. By the way, even the new API does not complain when passing invalid parameters (for instance "type=2" above). Shouldn't it return an error when a parameter is incorrect? Thanks, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From contact.anthoo at gmail.com Mon Apr 18 22:18:12 2016 From: contact.anthoo at gmail.com (Anthony) Date: Mon, 18 Apr 2016 22:18:12 +0200 Subject: [atlas] Question Message-ID: <57154104.8050602@gmail.com> Hello, I would have wanted to know if my graphs probe appears well is how well does the measures not? For you everything is ok or not? : https://atlas.ripe.net/probes/27379/ thank you in advance From robert at ripe.net Tue Apr 19 10:22:33 2016 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 19 Apr 2016 10:22:33 +0200 Subject: [atlas] Question In-Reply-To: <57154104.8050602@gmail.com> References: <57154104.8050602@gmail.com> Message-ID: <5715EAC9.7030804@ripe.net> On 2016-04-18 22:18, Anthony wrote: > Hello, > > I would have wanted to know if my graphs probe appears well is how well does > the measures not? > For you everything is ok or not? : https://atlas.ripe.net/probes/27379/ > > thank you in advance > Hi, Everything look good. The probe has a stable connection, has proper IPv4 and IPv6, all graphs look good. Regards, Robert From v.bajpai at jacobs-university.de Tue Apr 19 11:07:38 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 19 Apr 2016 09:07:38 +0000 Subject: [atlas] =?iso-2022-jp?b?Ki1jYXBhYmxlIBskQiFiGyhCICotd29ya3MgKyAq?= =?iso-2022-jp?b?LWRvZXNudC13b3Jr?= Message-ID: <7F441499-AA26-4CFB-BA61-6A0E4AEBFB6A@jacobs-university.de> Hello, I am looking at the probe API data for connected probes (status = 1) for day = 20160418 system-ipv6-capable = 3556 system-ipv6-works = 2995 system-ipv6-doesnt-work = 710 Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable? system-ipv4-capable = 9336 system-ipv4-works = 9187 system-ipv4-doesnt-work = 67 Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable? Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From BECHA at ripe.net Tue Apr 19 12:31:53 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 19 Apr 2016 12:31:53 +0200 Subject: [atlas] RIPE Atlas CLI Toolset now available on NLNOG RING In-Reply-To: <5716048A.2010003@ripe.net> References: <5716048A.2010003@ripe.net> Message-ID: <57160919.4000805@ripe.net> Dear colleagues, in the spirit of cooperation between the monitoring & measuring platforms, I am happy to announce: RIPE Atlas CLI Toolset have been installed on RING! If you are already participating in NLNOG RING, now you can use RIPE Atlas CLI Toolset for "quick & dirty" access to RIPE Atlas measurements & probes. More info about RING: https://ring.nlnog.net RING nodes are also available as targets through RIPE Atlas web interface for measurements creation: https://atlas.ripe.net/targets/ringnodes/list/ https://atlas.ripe.net/targets/ringnodes/map/ Regards, Vesna Reminder about CLI tools: Source: https://github.com/RIPE-NCC/ripe-atlas-tools/ Documentation: https://ripe-atlas-tools.readthedocs.org/ In addition to "raw install", tools are also packaged in many distros: OpenBSD, FreeBSD, Gentoo, Arch, Debian and Ubuntu (in progress: Fedora, Windows). Examples of usage of RIPE Atlas CLI tools on RING: ripe at ripe01:~$ ripe-atlas report 1001 --probes 1 20 bytes from probe #1 212.238.160.244 to 193.0.14.129 (193.0.14.129): ttl=59 times:6.658, 6.591, 6.298, ripe at ripe01:~$ ripe-atlas measurements --af 6 --status ongoing --limit 15 --search nlnog Filters: Search: nlnog Af: 6 Status in: (2,) Id Type Description Status ================================================================================ 1027844 traceroute Jump Ongoing 1027846 traceroute Clara DE Ongoing 1037103 ping tenet01.ring.nlnog.net Ongoing 1404594 ping RedpillLinpro-v6 Ongoing 1596748 ping world4you01.ring.nlnog.net Ongoing 1688325 ping ping6 on amazon03 Ongoing 3678270 traceroute Traceroute measurement to bluezonejordan01 Ongoing ================================================================================ Showing 7 of 7 total measurements ripe at ripe01:~$ ripe-atlas configure --setauthorisation.create=7b4c-xxxx ripe at ripe01:~$ ripe-atlas measure ping --target ping.xs4all.nl Looking good! Your measurement was created and details about it can be found here: https://atlas.ripe.net/measurements/3671547/ Connecting to stream... 48 bytes from probe #6174 217.10.140.74 to 194.109.6.8 (194.109.6.8): ttl=56 times:8.849, 8.781, 8.78, 48 bytes from probe #26941 88.85.47.152 to 194.109.6.8 (194.109.6.8): ttl=55 times:74.372, 74.487, 74.748, 48 bytes from probe #24596 176.144.180.224 to 194.109.6.8 (194.109.6.8): ttl=57 times:45.418, 45.249, 45.5, 48 bytes from probe #6187 196.10.54.135 to 194.109.6.8 (194.109.6.8): ttl=56 times:155.65, 155.58, 155.668, 48 bytes from probe #3207 37.49.102.93 to 194.109.6.8 (194.109.6.8): ttl=50 times:24.4, 27.627, 21.95, 48 bytes from probe #6186 82.195.72.11 to 194.109.6.8 (194.109.6.8): ttl=58 times:7.087, 7.101, 7.052, ... Read more about it on RIPE Labs: https://labs.ripe.net/Members/suzanne_taylor_muzzin/announcing-the-cli-toolset-for-ripe-atlas From camin at ripe.net Tue Apr 19 15:07:53 2016 From: camin at ripe.net (Chris Amin) Date: Tue, 19 Apr 2016 15:07:53 +0200 Subject: [atlas] =?utf-8?q?*-capable_=E2=89=A0_*-works_+_*-doesnt-work?= In-Reply-To: <7F441499-AA26-4CFB-BA61-6A0E4AEBFB6A@jacobs-university.de> References: <7F441499-AA26-4CFB-BA61-6A0E4AEBFB6A@jacobs-university.de> Message-ID: <57162DA9.5090106@ripe.net> On 19/04/2016 11:07, Bajpai, Vaibhav wrote: > Hello, > > I am looking at the probe API data for connected probes (status = 1) for day = 20160418 > > system-ipv6-capable = 3556 > system-ipv6-works = 2995 > system-ipv6-doesnt-work = 710 > > Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable? > > system-ipv4-capable = 9336 > system-ipv4-works = 9187 > system-ipv4-doesnt-work = 67 > > Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable? Dear Vaibhav, You are right that system-ipv6-works + system-ipv6-doesnt-work should be a subset of system-ipv6-capable. The -works and -doesnt-work tags are assigned based on measurement results from the past few hours, and there appears to be a bug whereby probes are continuing to carry out IPv6 measurements even when they no longer have IPv6 capability. This understandably results in unsuccessful results, which triggers the "doesnt-work" tag. Thank you for pointing this out to us, we are working on a fix now. The other case (system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable) makes more sense, because it's possible that a probe is marked as "capable" but doesn't actually return any measurement results for some reason -- for instance, it may be able to connect to the controller over IPv4 -- so we know for sure that it is "capable" of IPv4 -- but isn't able to report any IPv4 measurement results because of a faulty SD card, which isn't reflective of an IPv4 issue per se. We only mark a probe as "ipvX-doesnt-work" when we actually get unsuccessful results back from it, so in some cases a probe will have neither "works" nor "doesnt-work" tags. Kind regards, Chris Amin -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From contact.anthoo at gmail.com Tue Apr 19 23:26:30 2016 From: contact.anthoo at gmail.com (Anthony) Date: Tue, 19 Apr 2016 23:26:30 +0200 Subject: [atlas] Question In-Reply-To: <5715EAC9.7030804@ripe.net> References: <57154104.8050602@gmail.com> <5715EAC9.7030804@ripe.net> Message-ID: <5716A286.6030407@gmail.com> Hello, Okay thank you for the reply is happy to participate in the project :) Regards, Anthony Le 19/04/2016 10:22, Robert Kisteleki a ?crit : > On 2016-04-18 22:18, Anthony wrote: >> Hello, >> >> I would have wanted to know if my graphs probe appears well is how well does >> the measures not? >> For you everything is ok or not? : https://atlas.ripe.net/probes/27379/ >> >> thank you in advance >> > Hi, > > Everything look good. The probe has a stable connection, has proper IPv4 and > IPv6, all graphs look good. > > Regards, > Robert > From v.bajpai at jacobs-university.de Wed Apr 20 13:32:19 2016 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 20 Apr 2016 11:32:19 +0000 Subject: [atlas] =?iso-2022-jp?b?Ki1jYXBhYmxlIBskQiFiGyhCICotd29ya3MgKyAq?= =?iso-2022-jp?b?LWRvZXNudC13b3Jr?= In-Reply-To: <57162DA9.5090106@ripe.net> References: <7F441499-AA26-4CFB-BA61-6A0E4AEBFB6A@jacobs-university.de> <57162DA9.5090106@ripe.net> Message-ID: <56465215-6782-4105-8648-F8A4CA353BE4@jacobs-university.de> > On 19 Apr 2016, at 15:07, Chris Amin wrote: > > On 19/04/2016 11:07, Bajpai, Vaibhav wrote: > >> I am looking at the probe API data for connected probes (status = 1) for day = 20160418 >> >> system-ipv6-capable = 3556 >> system-ipv6-works = 2995 >> system-ipv6-doesnt-work = 710 >> >> Why is system-ipv6-works + system-ipv6-doesnt-work > system-ipv6-capable? >> >> system-ipv4-capable = 9336 >> system-ipv4-works = 9187 >> system-ipv4-doesnt-work = 67 >> >> Why is system-ipv4-works + system-ipv4-doesnt-work < system-ipv4-capable? > > Dear Vaibhav, > > You are right that system-ipv6-works + system-ipv6-doesnt-work should be > a subset of system-ipv6-capable. The -works and -doesnt-work tags are > assigned based on measurement results from the past few hours, and there > appears to be a bug whereby probes are continuing to carry out IPv6 > measurements even when they no longer have IPv6 capability. This > understandably results in unsuccessful results, which triggers the > "doesnt-work" tag. Thank you for pointing this out to us, we are working > on a fix now. Oh! OK. > The other case (system-ipv4-works + system-ipv4-doesnt-work < > system-ipv4-capable) makes more sense, because it's possible that a > probe is marked as "capable" but doesn't actually return any measurement > results for some reason -- for instance, it may be able to connect to > the controller over IPv4 -- so we know for sure that it is "capable" of > IPv4 -- but isn't able to report any IPv4 measurement results because of > a faulty SD card, which isn't reflective of an IPv4 issue per se. We > only mark a probe as "ipvX-doesnt-work" when we actually get > unsuccessful results back from it, so in some cases a probe will have > neither "works" nor "doesnt-work" tags. This is useful information. Thanks for sharing > Kind regards, > Chris Amin Best, Vaibhav =================================== Vaibhav Bajpai www.vaibhavbajpai.com Room 91, Research I School of Engineering and Sciences Jacobs University Bremen, Germany =================================== -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From robert at ripe.net Wed Apr 20 14:32:41 2016 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 20 Apr 2016 14:32:41 +0200 Subject: [atlas] Probe status / self-help Message-ID: <571776E9.4060606@ripe.net> Dear All, Today we released a new feature intended to help the probe hosts detecting, understanding and fixing various issued related to probes. You should be able to see a new "Status" tab on your probe page. This is where we explain various conditions, such as USB problems, non-working IPv6 or DNS resolutions quirks. Please note that this bit is in early stages (officially labeled as beta). We believe it works in general, however for now it only explains various system tags that mark error conditions. It will have more features in the future. It is also intended to be a place where we can add features that explain, for example, "your probe behaves differently than the rest" or "path MTU issues detected" or such. We think this will be a useful feature to hosts. Let us know if you have specific suggestions for improvement. Regards, Robert Kisteleki RIPE NCC From colinj at mx5.org.uk Wed Apr 20 14:49:47 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 20 Apr 2016 13:49:47 +0100 Subject: [atlas] Probe status / self-help In-Reply-To: <571776E9.4060606@ripe.net> References: <571776E9.4060606@ripe.net> Message-ID: <21F2F5B1-7D2D-4B48-925F-CAF008FB23B3@mx5.org.uk> seems to work ok for me, would bee good to get a status history maybe from sos logs ? Colin > On 20 Apr 2016, at 13:32, Robert Kisteleki wrote: > > Dear All, > > Today we released a new feature intended to help the probe hosts detecting, > understanding and fixing various issued related to probes. > > You should be able to see a new "Status" tab on your probe page. This is > where we explain various conditions, such as USB problems, non-working IPv6 > or DNS resolutions quirks. > > Please note that this bit is in early stages (officially labeled as beta). > We believe it works in general, however for now it only explains various > system tags that mark error conditions. It will have more features in the > future. It is also intended to be a place where we can add features that > explain, for example, "your probe behaves differently than the rest" or > "path MTU issues detected" or such. > > We think this will be a useful feature to hosts. Let us know if you have > specific suggestions for improvement. > > Regards, > Robert Kisteleki > RIPE NCC > > From hank at efes.iucc.ac.il Wed Apr 20 14:50:11 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Wed, 20 Apr 2016 15:50:11 +0300 Subject: [atlas] Probe status / self-help In-Reply-To: <571776E9.4060606@ripe.net> References: <571776E9.4060606@ripe.net> Message-ID: <57177B03.1080203@efes.iucc.ac.il> On 20/04/2016 15:32, Robert Kisteleki wrote: > Dear All, > > Today we released a new feature intended to help the probe hosts detecting, > understanding and fixing various issued related to probes. > > You should be able to see a new "Status" tab on your probe page. This is > where we explain various conditions, such as USB problems, non-working IPv6 > or DNS resolutions quirks. > > Please note that this bit is in early stages (officially labeled as beta). > We believe it works in general, however for now it only explains various > system tags that mark error conditions. It will have more features in the > future. It is also intended to be a place where we can add features that > explain, for example, "your probe behaves differently than the rest" or > "path MTU issues detected" or such. > > We think this will be a useful feature to hosts. Let us know if you have > specific suggestions for improvement. > > Regards, > Robert Kisteleki > RIPE NCC > > It would be nice if not only the probe owner but other users would be able to view this tab in order to help the users with problematic probes fix their issues. Thanks, Hank From BECHA at ripe.net Thu Apr 21 13:29:20 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 21 Apr 2016 13:29:20 +0200 Subject: [atlas] New on RIPE Labs: Looking at IXPs in Berlin with RIPE Atlas In-Reply-To: <57173929.8080507@ripe.net> References: <57173929.8080507@ripe.net> Message-ID: <5718B990.3020305@ripe.net> Dear colleagues, The IXP country jedi tool described in earlier RIPE Labs articles, can now also be used to analyse the situation in a specific city. This time we look at Berlin, Germany: https://labs.ripe.net/Members/mirjam/using-ripe-atlas-to-look-at-ixps-in-berlin Regards, Vesna From contact.anthoo at gmail.com Fri Apr 22 15:02:30 2016 From: contact.anthoo at gmail.com (Anthony) Date: Fri, 22 Apr 2016 15:02:30 +0200 Subject: [atlas] Led WPS / RESET Message-ID: <571A20E6.9030602@gmail.com> Hello everyone, I had a power outage, so I had to reboot my box and my probe, but now the LED button "WPS / RESET" lights is this normal? Before it off extinct. thank you in advance From c.estelmann at gmx.net Fri Apr 22 15:06:22 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Fri, 22 Apr 2016 15:06:22 +0200 Subject: [atlas] Led WPS / RESET In-Reply-To: <571A20E6.9030602@gmail.com> References: <571A20E6.9030602@gmail.com> Message-ID: <662f9adf-63da-a1a9-480b-2d978c02a00b@gmx.net> Hi, see https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean When the probe is connected the LED 5 (WPS / Reset) can do everything... Greetings, Christian Am 22.04.2016 um 15:02 schrieb Anthony: > Hello everyone, > > I had a power outage, so I had to reboot my box and my probe, but now > the LED button "WPS / RESET" lights is this normal? > Before it off extinct. > > thank you in advance > From contact.anthoo at gmail.com Fri Apr 22 15:25:35 2016 From: contact.anthoo at gmail.com (Anthony) Date: Fri, 22 Apr 2016 15:25:35 +0200 Subject: [atlas] Led WPS / RESET In-Reply-To: <662f9adf-63da-a1a9-480b-2d978c02a00b@gmx.net> References: <571A20E6.9030602@gmail.com> <662f9adf-63da-a1a9-480b-2d978c02a00b@gmx.net> Message-ID: <571A264F.7020008@gmail.com> Thank you for the answer, I read the documentation, but I did not understand well. So if I understand correctly, it can happen that the LED is lit? But everything is ok anyway? Sorry for my English :( Le 22/04/2016 15:06, Estelmann, Christian a ?crit : > Hi, > > see > https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean > > When the probe is connected the LED 5 (WPS / Reset) can do everything... > > Greetings, > Christian > > Am 22.04.2016 um 15:02 schrieb Anthony: >> Hello everyone, >> >> I had a power outage, so I had to reboot my box and my probe, but now >> the LED button "WPS / RESET" lights is this normal? >> Before it off extinct. >> >> thank you in advance >> From c.estelmann at gmx.net Fri Apr 22 15:37:53 2016 From: c.estelmann at gmx.net (Estelmann, Christian) Date: Fri, 22 Apr 2016 15:37:53 +0200 Subject: [atlas] Led WPS / RESET In-Reply-To: <571A264F.7020008@gmail.com> References: <571A20E6.9030602@gmail.com> <662f9adf-63da-a1a9-480b-2d978c02a00b@gmx.net> <571A264F.7020008@gmail.com> Message-ID: <21db02c8-ebf9-8cb7-f1ac-932591391d73@gmx.net> Yes, as long as the 1st, 3rd and 4th LED is on and the 2nd LED off the probe is connected and everything is working. The status of the 5th LED doesn't matter in this case (it can be on, off, blinking...). Just ignore the LED for the cases in which the status is labelled as "undetermined" in the table. Am 22.04.2016 um 15:25 schrieb Anthony: > Thank you for the answer, I read the documentation, but I did not > understand well. > > So if I understand correctly, it can happen that the LED is lit? But > everything is ok anyway? > > Sorry for my English :( > > Le 22/04/2016 15:06, Estelmann, Christian a ?crit : >> Hi, >> >> see >> https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean >> >> >> When the probe is connected the LED 5 (WPS / Reset) can do everything... >> >> Greetings, >> Christian >> >> Am 22.04.2016 um 15:02 schrieb Anthony: >>> Hello everyone, >>> >>> I had a power outage, so I had to reboot my box and my probe, but now >>> the LED button "WPS / RESET" lights is this normal? >>> Before it off extinct. >>> >>> thank you in advance >>> > From contact.anthoo at gmail.com Fri Apr 22 17:50:23 2016 From: contact.anthoo at gmail.com (Anthony) Date: Fri, 22 Apr 2016 17:50:23 +0200 Subject: [atlas] Led WPS / RESET In-Reply-To: <21db02c8-ebf9-8cb7-f1ac-932591391d73@gmx.net> References: <571A20E6.9030602@gmail.com> <662f9adf-63da-a1a9-480b-2d978c02a00b@gmx.net> <571A264F.7020008@gmail.com> <21db02c8-ebf9-8cb7-f1ac-932591391d73@gmx.net> Message-ID: <571A483F.3010901@gmail.com> Okay, thank you for accuracy :) Le 22/04/2016 15:37, Estelmann, Christian a ?crit : > Yes, as long as the 1st, 3rd and 4th LED is on and the 2nd LED off the > probe is connected and everything is working. The status of the 5th > LED doesn't matter in this case (it can be on, off, blinking...). > > Just ignore the LED for the cases in which the status is labelled as > "undetermined" in the table. > > Am 22.04.2016 um 15:25 schrieb Anthony: >> Thank you for the answer, I read the documentation, but I did not >> understand well. >> >> So if I understand correctly, it can happen that the LED is lit? But >> everything is ok anyway? >> >> Sorry for my English :( >> >> Le 22/04/2016 15:06, Estelmann, Christian a ?crit : >>> Hi, >>> >>> see >>> https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean >>> >>> >>> >>> When the probe is connected the LED 5 (WPS / Reset) can do >>> everything... >>> >>> Greetings, >>> Christian >>> >>> Am 22.04.2016 um 15:02 schrieb Anthony: >>>> Hello everyone, >>>> >>>> I had a power outage, so I had to reboot my box and my probe, but now >>>> the LED button "WPS / RESET" lights is this normal? >>>> Before it off extinct. >>>> >>>> thank you in advance >>>> >> From rgnr at riseup.net Fri Apr 22 19:33:43 2016 From: rgnr at riseup.net (rgnr at riseup.net) Date: Fri, 22 Apr 2016 19:33:43 +0200 Subject: [atlas] Probe not received Message-ID: Hey, as the subject says. It's been 4 weeks now and nothing has arrived. Any clues what to do? regards Bernd From mhi at ionescu.de Fri Apr 22 19:52:48 2016 From: mhi at ionescu.de (Michael Ionescu) Date: Fri, 22 Apr 2016 19:52:48 +0200 Subject: [atlas] Probe not received In-Reply-To: References: Message-ID: <60369D67-15B6-464A-B8BE-29D916DE91BF@ionescu.de> Don't worry, that's not that unusual. The email they send out when the probe is allocated to you is a bit on the optimistic side regarding the estimated time of arrival. On April 22, 2016 7:33:43 PM GMT+02:00, rgnr at riseup.net wrote: >Hey, > >as the subject says. It's been 4 weeks now and nothing has arrived. Any > >clues what to do? > >regards >Bernd -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jon.brewer at gmail.com Sat Apr 23 05:55:41 2016 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Sat, 23 Apr 2016 15:55:41 +1200 Subject: [atlas] Failure Rate on Atlas Probes Message-ID: Hi All, What's the known failure rate of Atlas probes, and the mean time before failure? At a guess 20% or more of the probes I've been working with have failed within their first year of deployment. Sometimes they come back with a power cycle, sometimes they don't. Regards, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Fri Apr 29 12:23:44 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 29 Apr 2016 12:23:44 +0200 Subject: [atlas] New on RIPE Labs: How Elasticsearch and Kibana Help us Analyse RIPE Atlas Data Logs In-Reply-To: References: Message-ID: Dear colleagues, RIPE Atlas backend applications run on more than 40 servers. Each day these machines can produce thousands of application logs of any kind of severity level. In order to be able to track down serious errors, warnings or even unusual behaviour, we decided some time ago to try Elasticsearch as a logging sink. In this article we will look at the design of such a system and describe how we can easily make sense from an ocean of logs: https://labs.ripe.net/Members/andreas_strikos/how-elasticsearch-and-kibana-help-us-analyse-ripe-atlas-data-logs?pk_campaign=labs&pk_kwd=list-atlas Kind regards, Mirjam Kuehne RIPE NCC From vobelic at gbit6.net Sat Apr 30 22:18:51 2016 From: vobelic at gbit6.net (Vladimir-M. Obelic) Date: Sat, 30 Apr 2016 22:18:51 +0200 Subject: [atlas] Atlas probe down and probe replacement Message-ID: After a power outage i'm not getting the probe up. It's not even trying DHCP. What is the procedure for a probe replacement? Thanks Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From alexander at neilson.net.nz Sat Apr 30 22:32:25 2016 From: alexander at neilson.net.nz (Alexander Neilson) Date: Sun, 1 May 2016 08:32:25 +1200 Subject: [atlas] Atlas probe down and probe replacement In-Reply-To: References: Message-ID: Have you tried booting it up without the USB stick attached to it? What are the lights showing as for the status of the device? Regards Alexander > On 1/05/2016, at 08:18, Vladimir-M. Obelic wrote: > > After a power outage i'm not getting the probe up. > It's not even trying DHCP. > > What is the procedure for a probe replacement? > > Thanks > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum > From vobelic at gbit6.net Sat Apr 30 22:58:47 2016 From: vobelic at gbit6.net (Vladimir-M. Obelic) Date: Sat, 30 Apr 2016 22:58:47 +0200 Subject: [atlas] Atlas probe down and probe replacement In-Reply-To: Message-ID: With the USB plugged in, i'm getting 1st and 2nd LED in permanent on state. With USB unplugged it actually did get IP over DHCP. LEDs blinking as described in the FAQ (Running from built-in flash). Not connecting to the grid tho... The USB seems ok when plugged in a PC, 3 partitions visible. What fs are we talking about, any chance fsck could help? Rgds, Vladimir Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From alexander at neilson.net.nz Sat Apr 30 23:05:12 2016 From: alexander at neilson.net.nz (Alexander Neilson) Date: Sun, 1 May 2016 09:05:12 +1200 Subject: [atlas] Atlas probe down and probe replacement In-Reply-To: References: Message-ID: <4746420E-CDDF-4C96-9D12-C0114B908FBE@neilson.net.nz> Sounds like it may be a bad / corrupted USB. Try a plain reformat of the drive. See if it takes and if you can write to it. Then boot the atlas probe without the stick and insert it. The probe should format it and load up and rejoin the network. You may have been hit by the dead USB stick issue. If the stick doesn't like something to throws a permanent death switch and makes itself read only. In that case if you put a new stick in of 3GB or more then it should format it and start working again fully. I had to do this recently with a probe. Regards Alexander > On 1/05/2016, at 08:58, Vladimir-M. Obelic wrote: > > With the USB plugged in, i'm getting 1st and 2nd LED in permanent on state. > With USB unplugged it actually did get IP over DHCP. LEDs blinking as described in the FAQ (Running from built-in flash). > Not connecting to the grid tho... > > The USB seems ok when plugged in a PC, 3 partitions visible. What fs are we talking about, any chance fsck could help? > > Rgds, > Vladimir > > > Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum >