From Ondrej.Caletka at cesnet.cz Wed Nov 2 15:18:16 2016 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Wed, 2 Nov 2016 15:18:16 +0100 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> Message-ID: <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> Dne 6.9.2016 v 15:32 Tim Bruijnzeels napsal(a): > Dear colleagues, > > In compliance with data protection rules and the desire to maintain a ?clean? database, we plan to remove unreferenced objects from the RIPE Database. We have recently been working on an improved implementation, and we are now ready to re-start the process. > > In order to be eligible for deletion, objects must have no incoming references (or be a person-maintainer or role-maintainer pair) and must have had no incoming references from any aut-num, domain, inet(6)num, route(6), as-set, filter-set, inet-rtr, peering-set, route-set, rtr-set, as-block, key-cert or irt object during the last 90 days. Hello Tim, hello RIPE Atlas team, I just found out that my RIPE Atlas Anchor contact role object CAAO-RIPE has been cleaned from the RIPE database. This object is registered as a RIPE Atlas Anchor contact in the RIPE Atlas systems. Could you perhaps somehow undelete such role object? Would it be possible to prevent such clean up in the future? Best regards, Ond?ej Caletka CESNET -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5600 bytes Desc: Elektronicky podpis S/MIME URL: From lists at ohlmeier.org Wed Nov 2 18:46:15 2016 From: lists at ohlmeier.org (Nils Ohlmeier) Date: Wed, 2 Nov 2016 10:46:15 -0700 Subject: [atlas] Probe reconnecting problem Message-ID: <4b46fb2c-5591-ccbb-c6dc-24640f5b2629@ohlmeier.org> Hello, is there any known problem around probes reconnecting after the uplink connectivity got lost? My probe was offline for several days even though my local network worked fine. I'm assuming that the uplink was dead for some time. And I waited a few days to see if the probe would recover by itself, but eventually gave up and power cycled it. Is there anything I could do to debug such a problem in case it should happen again? Cheers Nils From jon.brewer at gmail.com Wed Nov 2 22:49:04 2016 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Thu, 3 Nov 2016 10:49:04 +1300 Subject: [atlas] Fwd: Your RIPE Atlas Probe (ID: 24870) is not connected to our network In-Reply-To: <20161030074103.24655.76200@janus.atlas.ripe.net> References: <20161030074103.24655.76200@janus.atlas.ripe.net> Message-ID: Hi Team, It'd be great if you could change the tone of the alert messages below. Admit some fault. Ask for help. The majority of disconnects I've seen have been due to device failure, nothing to do with " everything is set up correctly on your side" and messages like this do nothing to encourage me or the networks I've convinced to host probes to help fix the problems. It really hurts that I've lost so many probes that took so much effort to get installed - and these messages don't help. Thanks, Jon ---------- Forwarded message ---------- From: RIPE Atlas Date: 30 October 2016 at 20:41 Subject: Your RIPE Atlas Probe (ID: 24870) is not connected to our network To: jon.brewer at gmail.com Dear RIPE Atlas probe host, Thank you for participating in RIPE Atlas! This is the second reminder that your probe () is not connected to our infrastructure and has been disconnected since 2016-10-09 05:44 UTC. Could you please check whether everything is set up correctly on your side? You may be able to find more information about the possible cause of the problem here: https://atlas.ripe.net/probes//#!tab-status If you believe everything is correctly set up and your probe is still reported as disconnected after 24 hours when you log in at https://atlas.ripe.net, please contact us at atlas at ripe.net Best regards, RIPE Atlas Team ********** You are receiving this message because you applied for or were given a RIPE Atlas probe. We will only send messages when your probe becomes disconnected for an extended period of time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe at brite.cz Thu Nov 3 09:55:22 2016 From: ripe at brite.cz (ripe at brite.cz) Date: Thu, 03 Nov 2016 09:55:22 +0100 Subject: [atlas] =?utf-8?q?Do_you_have_any_Probe_version_2_=5BLantronix_XP?= =?utf-8?q?ort=5D_available_for_distribution=3F?= Message-ID: <20161103095522.F48ABCB6@centrum.cz> Hi team, I will have the opportunity to install a probe on very remote place. Due to limited space in the place of installation, and also very limited reachability in case of USB failure, I would like to install only the previous version of probe, without USB flash drive. Do you have one or two Probes [not based on TP Link router] available? Thank you Jiri From robert at ripe.net Thu Nov 3 11:29:46 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 3 Nov 2016 11:29:46 +0100 Subject: [atlas] Do you have any Probe version 2 [Lantronix XPort] available for distribution? In-Reply-To: <20161103095522.F48ABCB6@centrum.cz> References: <20161103095522.F48ABCB6@centrum.cz> Message-ID: On 2016-11-03 9:55, ripe at brite.cz wrote: > Hi team, > > I will have the opportunity to install a probe on very remote place. Due to limited space in the place of installation, and also very limited reachability in case of USB failure, I would like to install only the previous version of probe, without USB flash drive. > > Do you have one or two Probes [not based on TP Link router] available? > > > Thank you > > > Jiri Hi, We do have some. I suggest you contact Lia (via atlas at ripe.net). Cheers, Robert From robert at ripe.net Thu Nov 3 11:30:45 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 3 Nov 2016 11:30:45 +0100 Subject: [atlas] Probe reconnecting problem In-Reply-To: <4b46fb2c-5591-ccbb-c6dc-24640f5b2629@ohlmeier.org> References: <4b46fb2c-5591-ccbb-c6dc-24640f5b2629@ohlmeier.org> Message-ID: On 2016-11-02 18:46, Nils Ohlmeier wrote: > Hello, > > is there any known problem around probes reconnecting after the uplink > connectivity got lost? > > My probe was offline for several days even though my local network > worked fine. I'm assuming that the uplink was dead for some time. And I > waited a few days to see if the probe would recover by itself, but > eventually gave up and power cycled it. > Is there anything I could do to debug such a problem in case it should > happen again? > > Cheers > Nils Hi, If you share your probe id with us (either here or privately) we can check what's in our logs, perhaps that will explain this. Regards, Robert From tim at ripe.net Thu Nov 3 15:42:09 2016 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 3 Nov 2016 15:42:09 +0100 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> Message-ID: Hi Ond?ej To be fair we did not consider this use case in our implementation. However, as a quick fix: you can recreate your objects and they will not be deleted for the next 90 days. In the meantime I want to take the opportunity to review the process for preventing deletion of objects. There (still) is an official process for this, but as you can see it's somewhat more complicated than it needs to be - at least imho: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/white-pages/view So, I would suggest that you actually don't try to follow that procedure for the time being, and I can keep you posted on the developments. I am confident that we can work something out with 90 days - but although I have an alternative in mind I will need to discuss it with various parties - including probably the db-wg before we can implement. I hope this helps. Kind regards, Tim Bruijnzeels > On 02 Nov 2016, at 15:18, Ond?ej Caletka wrote: > > Dne 6.9.2016 v 15:32 Tim Bruijnzeels napsal(a): >> Dear colleagues, >> >> In compliance with data protection rules and the desire to maintain a ?clean? database, we plan to remove unreferenced objects from the RIPE Database. We have recently been working on an improved implementation, and we are now ready to re-start the process. >> >> In order to be eligible for deletion, objects must have no incoming references (or be a person-maintainer or role-maintainer pair) and must have had no incoming references from any aut-num, domain, inet(6)num, route(6), as-set, filter-set, inet-rtr, peering-set, route-set, rtr-set, as-block, key-cert or irt object during the last 90 days. > > Hello Tim, hello RIPE Atlas team, > > I just found out that my RIPE Atlas Anchor contact role object CAAO-RIPE > has been cleaned from the RIPE database. This object is registered as a > RIPE Atlas Anchor contact in the RIPE Atlas systems. > > Could you perhaps somehow undelete such role object? Would it be > possible to prevent such clean up in the future? > > Best regards, > Ond?ej Caletka > CESNET > > From colinj at mx5.org.uk Thu Nov 3 16:05:29 2016 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 3 Nov 2016 15:05:29 +0000 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> Message-ID: <54D7802C-AD42-4B29-9065-C7D91BF8DBDB@mx5.org.uk> Hi Tim, on the subject of ripe contact role object info update How do I update update my role object for the phone number when a locked object ? nic-hdl: CJ570-RIPE created: 2006-09-18T14:37:05Z last-modified: 2016-04-07T07:05:31Z mnt-by: RIPE-NCC-LOCKED-MNT source: RIPE Colin > On 3 Nov 2016, at 14:42, Tim Bruijnzeels wrote: > > Hi Ond?ej > > To be fair we did not consider this use case in our implementation. However, as a quick fix: you can recreate your objects and they will not be deleted for the next 90 days. > > In the meantime I want to take the opportunity to review the process for preventing deletion of objects. There (still) is an official process for this, but as you can see it's somewhat more complicated than it needs to be - at least imho: > https://www.ripe.net/manage-ips-and-asns/db/support/documentation/white-pages/view > > So, I would suggest that you actually don't try to follow that procedure for the time being, and I can keep you posted on the developments. I am confident that we can work something out with 90 days - but although I have an alternative in mind I will need to discuss it with various parties - including probably the db-wg before we can implement. > > I hope this helps. Kind regards, > > Tim Bruijnzeels > > > > > > >> On 02 Nov 2016, at 15:18, Ond?ej Caletka wrote: >> >> Dne 6.9.2016 v 15:32 Tim Bruijnzeels napsal(a): >>> Dear colleagues, >>> >>> In compliance with data protection rules and the desire to maintain a ?clean? database, we plan to remove unreferenced objects from the RIPE Database. We have recently been working on an improved implementation, and we are now ready to re-start the process. >>> >>> In order to be eligible for deletion, objects must have no incoming references (or be a person-maintainer or role-maintainer pair) and must have had no incoming references from any aut-num, domain, inet(6)num, route(6), as-set, filter-set, inet-rtr, peering-set, route-set, rtr-set, as-block, key-cert or irt object during the last 90 days. >> >> Hello Tim, hello RIPE Atlas team, >> >> I just found out that my RIPE Atlas Anchor contact role object CAAO-RIPE >> has been cleaned from the RIPE database. This object is registered as a >> RIPE Atlas Anchor contact in the RIPE Atlas systems. >> >> Could you perhaps somehow undelete such role object? Would it be >> possible to prevent such clean up in the future? >> >> Best regards, >> Ond?ej Caletka >> CESNET >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Ondrej.Caletka at cesnet.cz Thu Nov 3 16:11:39 2016 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Thu, 3 Nov 2016 16:11:39 +0100 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: <3299E824-1A46-4EBC-8860-2AC9AE9271FE@ripe.net> References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> <3299E824-1A46-4EBC-8860-2AC9AE9271FE@ripe.net> Message-ID: Dne 3.11.2016 v 16:09 Tim Bruijnzeels napsal(a): > I discussed with the team and we can actually undelete your object CAAO-RIPE for you. > Thank you! I just tried to recreate it, however it turned out the the CAAO-RIPE nic-hdl cannot be used anymore. -- Ond?ej -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5600 bytes Desc: Elektronicky podpis S/MIME URL: From tim at ripe.net Thu Nov 3 16:09:29 2016 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 3 Nov 2016 16:09:29 +0100 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> Message-ID: <3299E824-1A46-4EBC-8860-2AC9AE9271FE@ripe.net> Hi Ond?ej > On 03 Nov 2016, at 15:42, Tim Bruijnzeels wrote: > > However, as a quick fix: you can recreate your objects and they will not be deleted for the next 90 days. I discussed with the team and we can actually undelete your object CAAO-RIPE for you. Cheers Tim From Ondrej.Caletka at cesnet.cz Thu Nov 3 16:17:28 2016 From: Ondrej.Caletka at cesnet.cz (=?UTF-8?Q?Ond=c5=99ej_Caletka?=) Date: Thu, 3 Nov 2016 16:17:28 +0100 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> Message-ID: <77b33c2e-aa04-c5b8-9fc7-ccec9e044204@cesnet.cz> Dear colleagues, sorry for the noise, this message was meant for the Atlas team, not the the mailing list. -- Ond?ej Caletka CESNET -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5600 bytes Desc: Elektronicky podpis S/MIME URL: From tim at ripe.net Thu Nov 3 17:26:21 2016 From: tim at ripe.net (Tim Bruijnzeels) Date: Thu, 3 Nov 2016 17:26:21 +0100 Subject: [atlas] Atlas Anchor contact role accidentally cleaned (Was: Clean-up of unreferenced objects in the RIPE Database) In-Reply-To: <54D7802C-AD42-4B29-9065-C7D91BF8DBDB@mx5.org.uk> References: <972305C0-8CBC-4833-B5B6-3D252EAD433D@ripe.net> <97f54f3f-0d23-2d83-f33c-fc4a24bcf8ab@cesnet.cz> <54D7802C-AD42-4B29-9065-C7D91BF8DBDB@mx5.org.uk> Message-ID: Hi Colin, This PERSON object was locked because it was unmaintained. We cannot, as a matter of principle, unlock unmaintained person objects: this can introduce a risk that we are liable for hijack of these objects by people other than their original owner - who can then change details while people referencing this object are unaware. To get around this please just create a new PERSON object instead, and ask people referencing CJ570-RIPE to update their reference. Once all references are removed the old object will be cleaned up automatically (after 90 days). If the maintainers of objects are unwilling to remove their references to CJ570-RIPE, then we do have a process in place that you can use to ask us to delete the object for you: https://www.ripe.net/manage-ips-and-asns/db/support/documentation/removal-of-personal-data I am sorry that this is somewhat formal, but considering the liabilities that can follow from not doing this properly, I see no other option than to ask you to go through this. Kind regards, Tim Bruijnzeels > On 03 Nov 2016, at 16:05, Colin Johnston wrote: > > Hi Tim, on the subject of ripe contact role object info update > How do I update update my role object for the phone number when a locked object ? > ? nic-hdl: CJ570-RIPE > ? created: 2006-09-18T14:37:05Z > ? last-modified: 2016-04-07T07:05:31Z > ? mnt-by: RIPE-NCC-LOCKED-MNT > ? source: RIPE > > > Colin > >> On 3 Nov 2016, at 14:42, Tim Bruijnzeels wrote: >> >> Hi Ond?ej >> >> To be fair we did not consider this use case in our implementation. However, as a quick fix: you can recreate your objects and they will not be deleted for the next 90 days. >> >> In the meantime I want to take the opportunity to review the process for preventing deletion of objects. There (still) is an official process for this, but as you can see it's somewhat more complicated than it needs to be - at least imho: >> https://www.ripe.net/manage-ips-and-asns/db/support/documentation/white-pages/view >> >> So, I would suggest that you actually don't try to follow that procedure for the time being, and I can keep you posted on the developments. I am confident that we can work something out with 90 days - but although I have an alternative in mind I will need to discuss it with various parties - including probably the db-wg before we can implement. >> >> I hope this helps. Kind regards, >> >> Tim Bruijnzeels >> >> >> >> >> >> >>> On 02 Nov 2016, at 15:18, Ond?ej Caletka wrote: >>> >>> Dne 6.9.2016 v 15:32 Tim Bruijnzeels napsal(a): >>>> Dear colleagues, >>>> >>>> In compliance with data protection rules and the desire to maintain a ?clean? database, we plan to remove unreferenced objects from the RIPE Database. We have recently been working on an improved implementation, and we are now ready to re-start the process. >>>> >>>> In order to be eligible for deletion, objects must have no incoming references (or be a person-maintainer or role-maintainer pair) and must have had no incoming references from any aut-num, domain, inet(6)num, route(6), as-set, filter-set, inet-rtr, peering-set, route-set, rtr-set, as-block, key-cert or irt object during the last 90 days. >>> >>> Hello Tim, hello RIPE Atlas team, >>> >>> I just found out that my RIPE Atlas Anchor contact role object CAAO-RIPE >>> has been cleaned from the RIPE database. This object is registered as a >>> RIPE Atlas Anchor contact in the RIPE Atlas systems. >>> >>> Could you perhaps somehow undelete such role object? Would it be >>> possible to prevent such clean up in the future? >>> >>> Best regards, >>> Ond?ej Caletka >>> CESNET >>> >>> >> >> > From cs at fnx.li Sat Nov 5 11:11:27 2016 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Sat, 5 Nov 2016 11:11:27 +0100 Subject: [atlas] Probe marked as offline, but it's online... In-Reply-To: <4af68c817553ff233b4362bfe433b46f@fnx.li> References: <4af68c817553ff233b4362bfe433b46f@fnx.li> Message-ID: <328a96fb-5548-fd6c-f3f1-44deb26765e6@fnx.li> btw: The USB drive (Verbatim) is READ-ONLY after 432 days... The replacement should be at minimum 4 GB, right? I'll buy a new one in the next few days. But nothing from SanDisk/Verbatim! :P -- With kind regards, Christian Schr?tter From gboonie at gmail.com Sun Nov 6 15:06:35 2016 From: gboonie at gmail.com (gboonie) Date: Sun, 6 Nov 2016 15:06:35 +0100 Subject: [atlas] Probe not taking UDMs for months but no issue reported Message-ID: <11442464-0f5c-4250-5682-132c3bd96406@gmail.com> Hi, My probe 24434 had an issue without me being aware because there was no notification. But even if there was, it was hard to detect. The only reason I found out was because I looked at a long running measurement that did not return data. On the other side, the built in measurements seemed fine. So first though was that something prevented the probe to perform DNS tests to the network's resolvers. I've attached a laptop to the connection but all worked fine. So rebooted the probe and found that the USB storage went to read-only. But why does it only detect this after a reboot? This probably means that the probe probably only checks at startup what the status is of the USB key. The other thing that is odd is that the probe kept earning credits. Here is a graph with the proof that it did stop taking UDMs early august. *My request: Please improve the probe's detection of issues. I do not mind replacing a USB dongle at all but I do find it annoying that the probes can be in this state where it is not down but also not taking any UDMs.* Thanks, Dave Proud owner of 3 probes. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: jcmoabkhkkbkbjmo.png Type: image/png Size: 24407 bytes Desc: not available URL: From vnaumov at ripe.net Mon Nov 7 08:20:26 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 7 Nov 2016 08:20:26 +0100 Subject: [atlas] Probe marked as offline, but it's online... In-Reply-To: <328a96fb-5548-fd6c-f3f1-44deb26765e6@fnx.li> References: <4af68c817553ff233b4362bfe433b46f@fnx.li> <328a96fb-5548-fd6c-f3f1-44deb26765e6@fnx.li> Message-ID: Hi Christian, Thank you for keeping it going! min 4GB is correct. /vty On 11/5/16 11:11 AM, Christian Schr?tter wrote: > btw: The USB drive (Verbatim) is READ-ONLY after 432 days... > > The replacement should be at minimum 4 GB, right? I'll buy a new one in > the next few days. But nothing from SanDisk/Verbatim! :P > From robert at ripe.net Mon Nov 7 11:56:55 2016 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 7 Nov 2016 11:56:55 +0100 Subject: [atlas] Ethical considerations Message-ID: Dear All, As mentioned in my RIPE Atlas update during the RIPE 73 MAT working group, we'd like to draw RIPE Atlas users? attention to relevant ethical considerations. We've just published a RIPE Labs article about this: https://labs.ripe.net/Members/kistel/ethics-of-ripe-atlas-measurements/ Regards, Robert Kisteleki RIPE NCC From adavies at ripe.net Mon Nov 7 14:31:03 2016 From: adavies at ripe.net (Alun Davies) Date: Mon, 7 Nov 2016 14:31:03 +0100 Subject: [atlas] Emails Regarding Probe Connection Issues Message-ID: Dear members of the RIPE Atlas community, It was recently called to our attention that certain emails we send out to RIPE Atlas probe hosts, concerning probe connection issues, have been somewhat abrupt in their tone. We are working to address the issue. While we devote a great deal of effort to ensuring that any correspondence we send out is both informative in content and appropriate in tone, we greatly appreciate feedback whenever it is felt that such goals have not been met. We would like to take this opportunity to once again thank all RIPE Atlas probe hosts for their ongoing participation. Best regards, Alun Davies (RIPE NCC) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2607 bytes Desc: not available URL: From mike.oghia at gmail.com Mon Nov 7 14:46:51 2016 From: mike.oghia at gmail.com (Michael Oghia) Date: Mon, 7 Nov 2016 14:46:51 +0100 Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: References: Message-ID: Hi Alun, Thank you very much for addressing this. Best, -Michael __________________ Michael J. Oghia iGmena communications manager 2016 ISOC IGF returning ambassador Independent #netgov consultant & editor Belgrade, Serbia Skype: mikeoghia Twitter *|* LinkedIn On Mon, Nov 7, 2016 at 2:31 PM, Alun Davies wrote: > Dear members of the RIPE Atlas community, > > It was recently called to our attention that certain emails we send out to > RIPE Atlas probe hosts, concerning probe connection issues, have been > somewhat abrupt in their tone. We are working to address the issue. > > While we devote a great deal of effort to ensuring that any correspondence > we send out is both informative in content and appropriate in tone, we > greatly appreciate feedback whenever it is felt that such goals have not > been met. > > We would like to take this opportunity to once again thank all RIPE Atlas > probe hosts for their ongoing participation. > > Best regards, > > Alun Davies (RIPE NCC) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From probe at garf.de Mon Nov 7 15:13:51 2016 From: probe at garf.de (Wolfgang Tremmel) Date: Mon, 7 Nov 2016 15:13:51 +0100 Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: References: Message-ID: Hello, > On 7 Nov 2016, at 14:31 , Alun Davies wrote: > > It was recently called to our attention that certain emails we send out to RIPE Atlas probe hosts, concerning probe connection issues, have been somewhat abrupt in their tone. We are working to address the issue the messages are fine. They should contain the facts (which they are) and not much else. No need to include humble apologies or other phrasing. They should fit into an iphone screen. Everything else is not necessary. I think everybody is aware that they are sent by a robot, and not by a human being. best regards Wolfgang From randy at psg.com Tue Nov 8 09:03:15 2016 From: randy at psg.com (Randy Bush) Date: Tue, 08 Nov 2016 17:03:15 +0900 Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: References: Message-ID: > It was recently called to our attention that certain emails we send > out to RIPE Atlas probe hosts, concerning probe connection issues, > have been somewhat abrupt in their tone. We are working to address the > issue. the mind boggles From nigel at titley.com Tue Nov 8 23:42:50 2016 From: nigel at titley.com (Nigel Titley) Date: Tue, 8 Nov 2016 22:42:50 +0000 Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: References: Message-ID: <6f5a227a-9304-3db0-ae94-59b19e5da5d2@titley.com> On 08/11/16 08:03, Randy Bush wrote: >> It was recently called to our attention that certain emails we send >> out to RIPE Atlas probe hosts, concerning probe connection issues, >> have been somewhat abrupt in their tone. We are working to address the >> issue. > > the mind boggles > Randy, have you never had the one that says "Oh for goodness sake... plug the USB plug into a USB socket and the ethernet into the other end... it's not that difficult. No, no, no! Not that way!" Seriously, though, I think we all know it comes from a robot. I doubt that anyone has been offended. But I thank Alun for his delicacy and consideration. Nigel From randy at psg.com Wed Nov 9 02:11:12 2016 From: randy at psg.com (Randy Bush) Date: Wed, 09 Nov 2016 10:11:12 +0900 Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: <6f5a227a-9304-3db0-ae94-59b19e5da5d2@titley.com> References: <6f5a227a-9304-3db0-ae94-59b19e5da5d2@titley.com> Message-ID: >>> It was recently called to our attention that certain emails we send >>> out to RIPE Atlas probe hosts, concerning probe connection issues, >>> have been somewhat abrupt in their tone. We are working to address the >>> issue. >> >> the mind boggles >> > Randy, have you never had the one that says "Oh for goodness sake... > plug the USB plug into a USB socket and the ethernet into the other > end... it's not that difficult. No, no, no! Not that way!" nope. but it would not bother me in the least. it would worry me if it told me to put the bleeping floppy in the drive. randy From mkh at rqc.ru Thu Nov 10 13:22:36 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 10 Nov 2016 15:22:36 +0300 Subject: [atlas] Latencymon widget: It is not possible to retrieve measurement information for this ID Message-ID: <7a6702d8-428c-6ba6-a12c-5c38ec462706@rqc.ru> Latenchmon widget stopped working for me this morning with the message "It is not possible to retrieve measurement information for this ID". Same error displays for sample widget code from documentation : > | >
| Has something changed in API, or are these just temporary problems server-side? -- With Best Regards, Marat Khalili -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Nov 10 13:35:06 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 10 Nov 2016 13:35:06 +0100 Subject: [atlas] Latencymon widget: It is not possible to retrieve measurement information for this ID In-Reply-To: <7a6702d8-428c-6ba6-a12c-5c38ec462706@rqc.ru> References: <7a6702d8-428c-6ba6-a12c-5c38ec462706@rqc.ru> Message-ID: Hello, Thank you for the report, we'll look into this right away. Regards, Robert On 2016-11-10 13:22, Marat Khalili wrote: > Latenchmon widget stopped working for me this morning with the message "It > is not possible to retrieve measurement information for this ID". Same error > displays for sample widget code from documentation > : > >> | >>
| > > > Has something changed in API, or are these just temporary problems server-side? > > > -- > > With Best Regards, > Marat Khalili From camin at ripe.net Thu Nov 10 14:21:14 2016 From: camin at ripe.net (Chris Amin) Date: Thu, 10 Nov 2016 14:21:14 +0100 Subject: [atlas] Latencymon widget: It is not possible to retrieve measurement information for this ID In-Reply-To: References: <7a6702d8-428c-6ba6-a12c-5c38ec462706@rqc.ru> Message-ID: <28ac6bcb-198f-33e6-af68-5b25770e0ff2@ripe.net> Dear Marat and list, This issue has now been fixed. Embedding the latencymon widget should now work as usual. Apologies for any inconvenience caused. Note: there is a chance that the previous version of the widget is cached in your browser. If the problem persists then you can try a "hard" refresh, or clearing your browser's cache. Regards, Chris On 10/11/2016 13:35, Robert Kisteleki wrote: > Hello, > > Thank you for the report, we'll look into this right away. > > Regards, > Robert > > > On 2016-11-10 13:22, Marat Khalili wrote: >> Latenchmon widget stopped working for me this morning with the message "It >> is not possible to retrieve measurement information for this ID". Same error >> displays for sample widget code from documentation >> : >> >>> | >>>
| >> >> >> Has something changed in API, or are these just temporary problems server-side? >> >> >> -- >> >> With Best Regards, >> Marat Khalili > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From mkh at rqc.ru Thu Nov 10 15:00:27 2016 From: mkh at rqc.ru (Marat Khalili) Date: Thu, 10 Nov 2016 17:00:27 +0300 Subject: [atlas] Latencymon widget: It is not possible to retrieve measurement information for this ID In-Reply-To: <28ac6bcb-198f-33e6-af68-5b25770e0ff2@ripe.net> References: <7a6702d8-428c-6ba6-a12c-5c38ec462706@rqc.ru> <28ac6bcb-198f-33e6-af68-5b25770e0ff2@ripe.net> Message-ID: <564730ec-408d-6abe-1c17-bd8e687bb0b4@rqc.ru> I can confirm that it works. Thank you! -- With Best Regards, Marat Khalili On 10/11/16 16:21, Chris Amin wrote: > Dear Marat and list, > > This issue has now been fixed. Embedding the latencymon widget should > now work as usual. Apologies for any inconvenience caused. > > Note: there is a chance that the previous version of the widget is > cached in your browser. If the problem persists then you can try a > "hard" refresh, or clearing your browser's cache. > > Regards, > Chris > > On 10/11/2016 13:35, Robert Kisteleki wrote: >> Hello, >> >> Thank you for the report, we'll look into this right away. >> >> Regards, >> Robert >> >> >> On 2016-11-10 13:22, Marat Khalili wrote: >>> Latenchmon widget stopped working for me this morning with the message "It >>> is not possible to retrieve measurement information for this ID". Same error >>> displays for sample widget code from documentation >>> : >>> >>>> | >>>>
| >>> >>> Has something changed in API, or are these just temporary problems server-side? >>> >>> >>> -- >>> >>> With Best Regards, >>> Marat Khalili >> >> > From cs at fnx.li Thu Nov 10 20:53:55 2016 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Thu, 10 Nov 2016 20:53:55 +0100 Subject: [atlas] Probe marked as offline, but it's online... In-Reply-To: References: <4af68c817553ff233b4362bfe433b46f@fnx.li> <328a96fb-5548-fd6c-f3f1-44deb26765e6@fnx.li> Message-ID: <3284a9a5-02c0-0d94-9f87-58276749b26f@fnx.li> Replaced with an old ?SDHC-card (8 GB) and a small ?-cardreader. The real replacement usb-stick will arrive in the next few weeks with my next Amazon order... -- With kind regards, Christian Schr?tter From mir at ripe.net Fri Nov 11 15:34:33 2016 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 11 Nov 2016 15:34:33 +0100 Subject: [atlas] New on RIPE Labs: Changes to RIPE Atlas API Keys Message-ID: Dear colleagues, We?ve made some changes to RIPE Atlas API Keys with the aim of improving the experience of RIPE Atlas users. The changes are designed to boost transparency and efficiency in the way users are able to manage their API Keys. Please find more details on RIPE Labs: https://labs.ripe.net/Members/alun_davies/changes-to-ripe-atlas-api-keys Kind regards, Mirjam Kuehne RIPE NCC From ripe-atlas at stderr.dk Thu Nov 17 03:02:52 2016 From: ripe-atlas at stderr.dk (Povl Ole Haarlev Olsen) Date: Thu, 17 Nov 2016 03:02:52 +0100 (CET) Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: References: Message-ID: On Mon, 7 Nov 2016, Alun Davies wrote: > It was recently called to our attention that certain emails we send out > to RIPE Atlas probe hosts, concerning probe connection issues, have been > somewhat abrupt in their tone. We are working to address the issue. > > While we devote a great deal of effort to ensuring that any > correspondence we send out is both informative in content and > appropriate in tone, we greatly appreciate feedback whenever it is felt > that such goals have not been met. Are you still working on this issue? I got one of the new emails earlier today, but it was a bit less informative than the previous emails: [- Quote -] Subject: Probe is disconnected () ... Your probe has been disconnected from the RIPE Atlas infrastructure since . ... [- End quote -] It looks like there's something wrong with the template system you're using. -- Povl Ole From camin at ripe.net Thu Nov 17 14:39:48 2016 From: camin at ripe.net (Chris Amin) Date: Thu, 17 Nov 2016 14:39:48 +0100 Subject: [atlas] Emails Regarding Probe Connection Issues In-Reply-To: References: Message-ID: <46a6692b-d5ac-294d-3c99-3494f4b9d8cf@ripe.net> Dear Povl Ole, Thank you for pointing this out. This was caused by an unrelated issue with the templating system, which has now been resolved. My apologies for the incomplete email. Regards, Chris Amin RIPE NCC On 17/11/2016 03:02, Povl Ole Haarlev Olsen wrote: > Are you still working on this issue? > > I got one of the new emails earlier today, but it was a bit less > informative than the previous emails: > > [- Quote -] > Subject: Probe is disconnected () > > ... > > Your probe has been disconnected from the RIPE Atlas infrastructure > since . > > ... > [- End quote -] > > It looks like there's something wrong with the template system you're > using. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From robert at ripe.net Fri Nov 18 13:39:38 2016 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 18 Nov 2016 13:39:38 +0100 Subject: [atlas] RIPE Atlas and nagios status-checks Message-ID: Dear All, The following message may be of interest to you if you're using Nagios (or variations like icinga) to query RIPE Atlas for status-checks. Yesterday morning our operations team made a change to the service configuration such that atlas.ripe.net only answers queries if they have proper Host: headers set. This is arguably a good operational practice, so we'd like to enforce it. However, one of the users running said nagios checks noticed that this causes 403 answers instead of the expected behaviour. We concluded that this is because the check_http plugin doesn't always set the Host: header. According to our statistics in total 12 users are affected, and since we could not foresee this problem, we temporarily reverted our configuration to the old settings. The fix on the client side is easy: one needs to add "-H atlas.ripe.net" parameter (or a similar change depending on forks and versions) to the checks. We'd like to ask our user to apply this change in the next two weeks in order to send well-formatted requests to our service. Thank you, Robert Kisteleki RIPE NCC From mgalante at ripe.net Thu Nov 24 16:26:17 2016 From: mgalante at ripe.net (Michela Galante) Date: Thu, 24 Nov 2016 16:26:17 +0100 Subject: [atlas] Fifteen new RIPE Atlas anchors have joined the community Message-ID: <0EE1D00C-8289-41A9-8689-F49E35D624EB@ripe.net> Dear colleagues, Fifteen new RIPE Atlas anchors have been activated since our last announcement in September, bringing the total number to 231: - us-bos-as26167, hosted by Markley Group in Boston, United States (IPv4-only anchor) - us-pct-as88, hosted by Princeton University in Princeton, United States (IPv4-only anchor) - tz-dar-as327844, hosted by Tanzania ISP Association in Dar es Salaam, Tanzania and ke-nbo-as37578, hosted by TESPOK in Nairobi, Kenya. These are the first two of five anchors that ISOC will sponsor. - dk-aal-as9158 and dk-cph-as9158, hosted by Telenor Denmark A/S in Aalborg and Copenhagen, Denmark - au-syd-as135150, hosted by bet365 in Sydney, Australia - ca-wnp-as16395, hosted by asn16395 in Winnipeg, Canada - us-ljl-as195, hosted by Center for Applied Internet Data Analysis (CAIDA) at the University of California, San Diego in La Jolla, United States - nz-akl-as38064, hosted by NZ Registry Services in Auckland, New Zealand - us-bos-as111, hosted by the Boston University in Boston, United States - kw-kwi-as42961, hosted by Zain Kuwait in Kuwait City, Kuwait - nl-ede-as12859-client, hosted by HCC in Ede, Netherlands - it-rom-as24796, hosted by NaMeX Consortium in Rome, Italy - us-fcn-as32934, hosted by Facebook in Forest City, United States. You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas anchors online: https://atlas.ripe.net/anchors/list/ Interested in hosting a RIPE Atlas anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ We are particularly interested in deploying anchors in the Middle East, Western Asia, Latin America and Africa in order to add more geographical diversity to the measurement data. There are several organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, or for any other questions, please contact us at atlas at ripe.net And don?t forget to let us know if you?re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From folkert at vanheusden.com Fri Nov 25 13:27:11 2016 From: folkert at vanheusden.com (folkert) Date: Fri, 25 Nov 2016 13:27:11 +0100 Subject: [atlas] tp-link probev3 tl-mr3020 Message-ID: <20161125122711.GE7877@belle.intranet.vanheusden.com> Hi, I have one of those tp-link probes, a v3 it looks like. Now when I got it, I was warned to put it on a 1A powersource. Now that is a bit of a problem so I started to measure its power usage to verify if I could maybe run it on a smaller power supply. What I measure is 0.14A upto 0.23A - that should easily be powered by a 0.5A power supply I think. As I'm not an electronics expert I'm now writing this message for confirmation: am I right about the power usage? Or ar there situations where it would be using a lot more power? Thank you, Folkert van Heusden -- ---------------------------------------------------------------------- Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com From philip.homburg at ripe.net Fri Nov 25 14:01:03 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Fri, 25 Nov 2016 14:01:03 +0100 Subject: [atlas] tp-link probev3 tl-mr3020 In-Reply-To: <20161125122711.GE7877@belle.intranet.vanheusden.com> References: <20161125122711.GE7877@belle.intranet.vanheusden.com> Message-ID: <40ee4bf3-e3bc-d4c4-0c35-03c0d0fa8bcb@ripe.net> On 2016/11/25 13:27 , folkert wrote: > I have one of those tp-link probes, a v3 it looks like. > Now when I got it, I was warned to put it on a 1A powersource. Now that > is a bit of a problem so I started to measure its power usage to verify > if I could maybe run it on a smaller power supply. > What I measure is 0.14A upto 0.23A - that should easily be powered by a > 0.5A power supply I think. > As I'm not an electronics expert I'm now writing this message for > confirmation: am I right about the power usage? Or ar there situations > where it would be using a lot more power? The actual TP-Link is not very sensitive to voltage changes. You can run it close to 3 volts and it will still work. On the other hand, the first USB sticks that we used (from SanDisk) are very sensitive to low voltage, and will often not show up if there is too much voltage drop somewhere (either in the power supply or in the cable). However, the main problem at the moment is filesystem corruption and USB sticks dying. There is no hard evidence as to what causes this. So to be on the safe side, it is best to use a good power supply. Typically, you can't tell from the outside whether something is well designed or not. And most people use unlabeled cheap versions, both for power supplies and cables. So it seems best to err on the side of caution and recommend slightly higher specs. In the end, if it works, fine. If you find USB sticks dying, then it worth looking if there is anything that can be changed. Philip From dragos.codita at telekom.ro Fri Nov 25 14:08:51 2016 From: dragos.codita at telekom.ro (CODITA, Dragos Gabriel) Date: Fri, 25 Nov 2016 13:08:51 +0000 Subject: [atlas] tp-link probev3 tl-mr3020 In-Reply-To: <20161125122711.GE7877@belle.intranet.vanheusden.com> References: <20161125122711.GE7877@belle.intranet.vanheusden.com> Message-ID: <5c0e8eb9-ed17-425c-6868-75a5790f141e@telekom.ro> I run mine on a standard USB port of a VDSL modem. Nothing fancy. It works since three months ago, except power outages, never had problems. On 11/25/2016 2:27 PM, folkert wrote: > Hi, > > I have one of those tp-link probes, a v3 it looks like. > Now when I got it, I was warned to put it on a 1A powersource. Now that > is a bit of a problem so I started to measure its power usage to verify > if I could maybe run it on a smaller power supply. > What I measure is 0.14A upto 0.23A - that should easily be powered by a > 0.5A power supply I think. > As I'm not an electronics expert I'm now writing this message for > confirmation: am I right about the power usage? Or ar there situations > where it would be using a lot more power? > > > Thank you, > > Folkert van Heusden >