From ljsong at biigroup.cn Tue May 9 10:03:07 2017 From: ljsong at biigroup.cn (=?gb2312?B?RGF2ZXkgU29uZyjLzsHWvaEp?=) Date: Tue, 9 May 2017 16:03:07 +0800 Subject: [atlas] Many timeout-failures for DNS over TCP Message-ID: <029401d2c89a$b1ee50f0$15caf2d0$@cn> Hi folks, I setup measurements for DNS queries over both TCP and UDP. I found the timeout and failures of TCP is far more than UDP. For example : DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes DNS over UDP: https://atlas.ripe.net/measurements/8552846/#!probes Is it normal ? I mean is there any special timeout routine/parameters of atlas probes from normal resolver? Best regards, Davey -------------- next part -------------- An HTML attachment was scrubbed... URL: From w.b.devries at utwente.nl Tue May 9 10:13:44 2017 From: w.b.devries at utwente.nl (w.b.devries at utwente.nl) Date: Tue, 9 May 2017 08:13:44 +0000 Subject: [atlas] Many timeout-failures for DNS over TCP In-Reply-To: <029401d2c89a$b1ee50f0$15caf2d0$@cn> References: <029401d2c89a$b1ee50f0$15caf2d0$@cn> Message-ID: <1494317566366.1661@utwente.nl> Hi Davey, There used to be a message on the atlas.ripe.net frontpage, I retrieved it from google cache: Due to an unfortunate bug in a recent probe firmware (version 4760), TCP based DNS measurements are not providing correct results. This affects all ongoing and one-off measurements. The issue also affected DNSMON measurements between 14-23 March. On 23 March we deployed a corrected firmware on RIPE Atlas anchors (version 4770), and in the near future we'll deploy it on regular probes as well. Our excuses for the inconvenience caused!? So any probe that is still on version 4760 will provide timeouts for TCP DNS lookups. Cheers, Wouter ________________________________ From: ripe-atlas on behalf of Davey Song(???) Sent: Tuesday, May 9, 2017 10:03 AM To: ripe-atlas at ripe.net Subject: [atlas] Many timeout-failures for DNS over TCP Hi folks, I setup measurements for DNS queries over both TCP and UDP. I found the timeout and failures of TCP is far more than UDP. For example : DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes DNS over UDP: https://atlas.ripe.net/measurements/8552846/#!probes Is it normal ? I mean is there any special timeout routine/parameters of atlas probes from normal resolver? Best regards, Davey -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at yoda.pw Tue May 9 10:33:28 2017 From: tom at yoda.pw (Tom) Date: Tue, 09 May 2017 08:33:28 +0000 Subject: [atlas] Many timeout-failures for DNS over TCP In-Reply-To: <1494317566366.1661@utwente.nl> References: <1494317566366.1661@utwente.nl> <029401d2c89a$b1ee50f0$15caf2d0$@cn> Message-ID: <73525547c1d02c762c265b0a01cd781c@bfb47388622b> For reference, it still appears on https://atlas.ripe.net/ (https://atlas.ripe.net/) for me - Tom May 9, 2017 9:14 AM, w.b.devries at utwente.nl (mailto:w.b.devries at utwente.nl) wrote: Hi Davey, There used to be a message on the atlas.ripe.net frontpage, I retrieved it from google cache: Due to an unfortunate bug in a recent probe firmware (version 4760), TCP based DNS measurements are not providing correct results. This affects all ongoing and one-off measurements. The issue also affected DNSMON measurements between 14-23 March. On 23 March we deployed a corrected firmware on RIPE Atlas anchors (version 4770), and in the near future we'll deploy it on regular probes as well. Our excuses for the inconvenience caused!? So any probe that is still on version 4760 will provide timeouts for TCP DNS lookups. Cheers, Wouter ------------------------------------ From: ripe-atlas on behalf of Davey Song($BAWNS7r(B) Sent: Tuesday, May 9, 2017 10:03 AM To: ripe-atlas at ripe.net (mailto:ripe-atlas at ripe.net) Subject: [atlas] Many timeout-failures for DNS over TCP Hi folks, I setup measurements for DNS queries over both TCP and UDP. I found the timeout and failures of TCP is far more than UDP. For example : DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes (https://atlas.ripe.net/measurements/8552847/#!probes) DNS over UDP: https://atlas.ripe.net/measurements/8552846/#!probes (https://atlas.ripe.net/measurements/8552846/#!probes) Is it normal ? I mean is there any special timeout routine/parameters of atlas probes from normal resolver? Best regards, Davey -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljsong at biigroup.cn Tue May 9 10:50:37 2017 From: ljsong at biigroup.cn (=?UTF-8?B?RGF2ZXkgU29uZyjlrovmnpflgaUp?=) Date: Tue, 9 May 2017 16:50:37 +0800 Subject: [atlas] =?utf-8?b?562U5aSNOiAgTWFueSB0aW1lb3V0LWZhaWx1cmVzIGZv?= =?utf-8?q?r_DNS_over_TCP?= In-Reply-To: <73525547c1d02c762c265b0a01cd781c@bfb47388622b> References: <1494317566366.1661@utwente.nl> <029401d2c89a$b1ee50f0$15caf2d0$@cn> <73525547c1d02c762c265b0a01cd781c@bfb47388622b> Message-ID: <02a401d2c8a1$55291010$ff7b3030$@cn> Thanks for the information. It seems to me that the comparison on failures between TCP and UDP make no sense at this moment. Davey ???: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] ?? Tom ????: 2017?5?9? 16:33 ???: ripe-atlas at ripe.net ??: Re: [atlas] Many timeout-failures for DNS over TCP For reference, it still appears on https://atlas.ripe.net/ for me - Tom May 9, 2017 9:14 AM, w.b.devries at utwente.nl wrote: Hi Davey, There used to be a message on the atlas.ripe.net frontpage, I retrieved it from google cache: Due to an unfortunate bug in a recent probe firmware (version 4760), TCP based DNS measurements are not providing correct results. This affects all ongoing and one-off measurements. The issue also affected DNSMON measurements between 14-23 March. On 23 March we deployed a corrected firmware on RIPE Atlas anchors (version 4770), and in the near future we'll deploy it on regular probes as well. Our excuses for the inconvenience caused!? So any probe that is still on version 4760 will provide timeouts for TCP DNS lookups. Cheers, Wouter _____ From: ripe-atlas on behalf of Davey Song($BAWNS7r(B) Sent: Tuesday, May 9, 2017 10:03 AM To: ripe-atlas at ripe.net Subject: [atlas] Many timeout-failures for DNS over TCP Hi folks, I setup measurements for DNS queries over both TCP and UDP. I found the timeout and failures of TCP is far more than UDP. For example : DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes DNS over UDP: https://atlas.ripe.net/measurements/8552846/#!probes Is it normal ? I mean is there any special timeout routine/parameters of atlas probes from normal resolver? Best regards, Davey -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcandela at ripe.net Wed May 10 15:55:59 2017 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 10 May 2017 15:55:59 +0200 Subject: [atlas] TraceMON follow up Message-ID: <41F097B5-361D-4BA1-9DBC-3411EF8084E1@ripe.net> As a follow up to my talk at RIPE74 about TraceMON, here a link with some live examples: https://massimo.ripe.net/tracemon/widget/ Ciao, Massimo -------------- next part -------------- An HTML attachment was scrubbed... URL: From philip.homburg at ripe.net Thu May 11 10:46:52 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 11 May 2017 10:46:52 +0200 Subject: [atlas] Many timeout-failures for DNS over TCP In-Reply-To: <029401d2c89a$b1ee50f0$15caf2d0$@cn> References: <029401d2c89a$b1ee50f0$15caf2d0$@cn> Message-ID: <4c236928-f20c-f1b2-ec49-1bb591c34920@ripe.net> On 2017/05/09 10:03 , Davey Song(???) wrote: > I setup measurements for DNS queries over both TCP and UDP. I found the > timeout and failures of TCP is far more than UDP. > DNS over TCP: https://atlas.ripe.net/measurements/8552847/#!probes Hi, Unfortunately, due to a bug, DNS over TCP measurements do not work in firmware 4760. I went over the results of this measurement. And the in most cases the probe was indeed still running 4760. Over time, probes upgrade 4770 and this issue will be fixed. There are a few probes that have a timeout but are running 4770. I created a TCP traceroute measurement using the same probes of measurement 8552847. https://atlas.ripe.net/measurements/8552847/#!probes In those remaining cases, the traceroute fails to complete. So for those probes there a network related issue. Philip From BECHA at ripe.net Thu May 11 11:55:47 2017 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 11 May 2017 11:55:47 +0200 Subject: [atlas] Results of the DNS Measurements hackathon - article now published on RIPE Labs In-Reply-To: References: Message-ID: <858113d8-e6b5-b05f-ca84-5335cb108d44@ripe.net> Dear all, in April we held a fifth hackathon. Altho the topic was DNS, most of the projects were using RIPE Atlas data. Therefore, I invite you to check out the hackathon results, follow the links to the code, and enjoy the photos that attempt to transfer some of the atmosphere.. https://labs.ripe.net/Members/becha/results-dns-measurements-hackathon Please do take part: - use the tools/SW and let us know your experiences with it - modify the code & publish it again on GitHub - join our next hackathon - as a host, sponsor, or participant (date & location & topic to be announced soon!) Let me know in person if you are interested; and otherwise, post your comments or questions on the list, greetings from RIPE74, Vesna From jm at poure.com Sat May 13 00:06:24 2017 From: jm at poure.com (Jean-Michel =?ISO-8859-1?Q?Pour=E9?=) Date: Sat, 13 May 2017 00:06:24 +0200 Subject: [atlas] Introducing blitzortung.org Network for Lightning and Thunderstorms in Real Time Message-ID: <1494626784.6955.2.camel@poure.com> Dear Friends from RIPE community, This is my first post on the forum. I would like to point out to the community the existence of a free community providing a network device for Lightning and Thunderstorms in Real Time: http://blitzortung.org The device works the same as a RIPE probe, except that it collects information about lightning via radio and delivers the information to a central network of computers for data processing. If you are network specialist hosting very expensive network devices, it might be interesting for you to participate in the effort to build a free community and host a Blitzordnung device in your premisses. All information can be found on http://blitzortung.org and BlitzOrdnung forum : http://en.blitzortung.org/forum.php BlitzOrdnung coverage is good in Europe and North America, but BlitzOrdnung needs more devices in Africa/South America/China and Russia. All help is welcome and may save you a lot of money in lightning protection. Kind regards, Kellogs From adavies at ripe.net Tue May 16 16:22:01 2017 From: adavies at ripe.net (Alun Davies) Date: Tue, 16 May 2017 16:22:01 +0200 Subject: [atlas] RIPE Atlas V1 Probe Issue Message-ID: Hello all, Due to an unfortunate bug in a recently released probe firmware (version 4760), a number of RIPE Atlas V1 probes are not currently able to connect to the network. The bug leads to excessive memory fragmentation which impacts that V1 probes because they have no MMU and only 8 MByte worth of memory. For reasons that are not yet clear, the issue has only affected well below half of the V1 probes. We are working on a new firmware that will correct this issue, but probes that will not connect will need to be returned to the RIPE NCC in order for the fix to be carried out. Once the new firmware is ready, users can either return their V1 probes to us to be fixed, or request a V3 probe instead. Thank you to Wilfred Woeber for reporting this and requesting an update on the current issue with the V1 probes. Cheers, Alun Davies RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2607 bytes Desc: not available URL: From adavies at ripe.net Wed May 17 12:40:16 2017 From: adavies at ripe.net (Alun Davies) Date: Wed, 17 May 2017 12:40:16 +0200 Subject: [atlas] RIPE Atlas V1 Probe Issue In-Reply-To: References: Message-ID: A few points of clarification are warranted following the previous mail. The firmware alluded to in the previous email was released in February 2017. Since then, approximately 100 RIPE Atlas V1 probes have disconnected - about 15% of the total number of V1 probes on the network. The fix that is currently in the making is expected to be released in a month or so. If at that time you have still been unable to reconnect your V1 probe, you can then return your probe to be fixed. Alternatively, you may apply for a V3 probe by following the usual process as described here: https://atlas.ripe.net/get-involved/become-a-host/ Cheers, Alun Davies RIPE NCC > On 16 May 2017, at 16:22, Alun Davies wrote: > > Hello all, > > Due to an unfortunate bug in a recently released probe firmware (version 4760), a number of RIPE Atlas V1 probes are not currently able to connect to the network. The bug leads to excessive memory fragmentation which impacts that V1 probes because they have no MMU and only 8 MByte worth of memory. > > For reasons that are not yet clear, the issue has only affected well below half of the V1 probes. We are working on a new firmware that will correct this issue, but probes that will not connect will need to be returned to the RIPE NCC in order for the fix to be carried out. Once the new firmware is ready, users can either return their V1 probes to us to be fixed, or request a V3 probe instead. > > Thank you to Wilfred Woeber for reporting this and requesting an update on the current issue with the V1 probes. > > Cheers, > 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 John_Brzozowski at comcast.com Wed May 17 12:46:55 2017 From: John_Brzozowski at comcast.com (Brzozowski, John) Date: Wed, 17 May 2017 10:46:55 +0000 Subject: [atlas] RIPE Atlas V1 Probe Issue In-Reply-To: References: , Message-ID: <4F0BE1BD-183E-4474-B068-43F3F8D8C151@Cable.Comcast.com> For the record, I think my probe was one of these. Initially I thought it was associated with some maintenance that I performed on my network. Turns out it was related to this thread. I reconnected the probe and several days later it successfully reconnected and seems to have remain connected. John +1-484-962-0060 On May 17, 2017, at 06:41, Alun Davies > wrote: A few points of clarification are warranted following the previous mail. The firmware alluded to in the previous email was released in February 2017. Since then, approximately 100 RIPE Atlas V1 probes have disconnected - about 15% of the total number of V1 probes on the network. The fix that is currently in the making is expected to be released in a month or so. If at that time you have still been unable to reconnect your V1 probe, you can then return your probe to be fixed. Alternatively, you may apply for a V3 probe by following the usual process as described here: https://atlas.ripe.net/get-involved/become-a-host/ Cheers, Alun Davies RIPE NCC On 16 May 2017, at 16:22, Alun Davies > wrote: Hello all, Due to an unfortunate bug in a recently released probe firmware (version 4760), a number of RIPE Atlas V1 probes are not currently able to connect to the network. The bug leads to excessive memory fragmentation which impacts that V1 probes because they have no MMU and only 8 MByte worth of memory. For reasons that are not yet clear, the issue has only affected well below half of the V1 probes. We are working on a new firmware that will correct this issue, but probes that will not connect will need to be returned to the RIPE NCC in order for the fix to be carried out. Once the new firmware is ready, users can either return their V1 probes to us to be fixed, or request a V3 probe instead. Thank you to Wilfred Woeber for reporting this and requesting an update on the current issue with the V1 probes. Cheers, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-atlas-probe-2010 at hayler.de Wed May 17 13:04:23 2017 From: ripe-atlas-probe-2010 at hayler.de (Michael Hayler) Date: Wed, 17 May 2017 13:04:23 +0200 Subject: [atlas] RIPE Atlas V1 Probe Issue In-Reply-To: References: Message-ID: <814ce9c5-2db7-c783-8ed9-f566e8cd9d70@hayler.de> Hi, my Probe was reported offline one week ago and of course that happened while I was on vacation :) >From a tcpdump on my gateway it seemed that the probe itself was doing nothing anymore (no active checks etc.) but it was still responding to my Nagios Ping Checks. After a switchport shut/no shut it did not even respond to arp/nd anymore. So I powercycled the probe after I was home again and since then it is online without any issues for 11 hours now. Am 17.05.2017 um 12:40 schrieb Alun Davies: > A few points of clarification are warranted following the previous mail. > > The firmware alluded to in the previous email was released in February > 2017. Since then, approximately 100 RIPE Atlas V1 probes have > disconnected - about 15% of the total number of V1 probes on the network. > > The fix that is currently in the making is expected to be released in a > month or so. If at that time you have still been unable to reconnect > your V1 probe, you can then return your probe to be fixed. > Alternatively, you may apply for a V3 probe by following the usual > process as described > here: https://atlas.ripe.net/get-involved/become-a-host/ > -- Best Regards Michael Hayler From dfk at ripe.net Thu May 18 15:52:12 2017 From: dfk at ripe.net (Daniel Karrenberg) Date: Thu, 18 May 2017 15:52:12 +0200 Subject: [atlas] RIPE Atlas V1 Probe Issue In-Reply-To: <814ce9c5-2db7-c783-8ed9-f566e8cd9d70@hayler.de> References: <814ce9c5-2db7-c783-8ed9-f566e8cd9d70@hayler.de> Message-ID: <84f74adf-6fad-6b4d-e666-ecd846b1aa84@ripe.net> On 17.05.17 13:04 , Michael Hayler wrote: > ... So I powercycled the probe after I was home again and since then it is > online without any issues for 11 hours now. That is identical to my observations with probes #7 and #8. After a power cycle they do re-connect after a while. So I am hopeful that they may be updated eventually to the special firmware that was mentioned. Still we should offer more recent hardware to those hosts of v1 probes who want it. Daniel From bortzmeyer at nic.fr Fri May 19 14:35:59 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 19 May 2017 14:35:59 +0200 Subject: [atlas] DNS and recursion Message-ID: <20170519123559.ae3h4dt4fgb5x5u4@nic.fr> API v1 had a field recursion_desired when performing DNS measurements. If I remember correctly (but I cannot find the reference right now), it worked only when querying a specific name server, and not when using the probe's own resolver, to avoid cache snooping. API v2 has instead a set_rd_bit. Documentation does not indicate its default value. Anyway, my experience with the API is that the RD (Recursion Desired) bit is always set, whether with 'set_rd_bit': False or with 'set_rd_bit': True, and independant of use_probe_resolver. I can understand this choice for privacy reasons (RFC 7626, section 2.3). But, in that case, the documentation should be fixed. Anything I missed? (Here, a request by a probe, the + after the Query ID - here, 52379 - means the RD bit is set 12:22:23.170304 IP (tos 0x0, ttl 64, id 2287, offset 0, flags [DF], proto UDP (17), length 65) 192.168.2.8.45955 > 212.27.40.240.53: [udp sum ok] 52379+ AAAA? uucp.bortzmeyer.org. (37) From camin at ripe.net Mon May 22 14:15:54 2017 From: camin at ripe.net (Chris Amin) Date: Mon, 22 May 2017 14:15:54 +0200 Subject: [atlas] DNS and recursion In-Reply-To: <20170519123559.ae3h4dt4fgb5x5u4@nic.fr> References: <20170519123559.ae3h4dt4fgb5x5u4@nic.fr> Message-ID: <234762d4-c14b-01c8-1631-e879b1437a3f@ripe.net> Hi Stephane, On 19/05/2017 14:35, Stephane Bortzmeyer wrote: > API v1 had a field recursion_desired when performing DNS > measurements. If I remember correctly (but I cannot find the reference > right now), it worked only when querying a specific name server, and > not when using the probe's own resolver, to avoid cache snooping. > > API v2 has instead a set_rd_bit. Documentation > > does not indicate its default value. You're right, the reference doesn't indicate a default value (we will fix that), but it should be "false", with the exception of when using the probe's own resolver as you mentioned above. This behaviour is still documented in the manual: https://atlas.ripe.net/docs/api/v2/manual/measurements/types/type_specific_attributes.html > Anyway, my experience with the API is that the RD (Recursion Desired) > bit is always set, whether with 'set_rd_bit': False or with > 'set_rd_bit': True, and independant of use_probe_resolver. > > I can understand this choice for privacy reasons (RFC 7626, section > 2.3). But, in that case, the documentation should be fixed. > > Anything I missed? > > (Here, a request by a probe, the + after the Query ID - here, 52379 - > means the RD bit is set > > 12:22:23.170304 IP (tos 0x0, ttl 64, id 2287, offset 0, flags [DF], proto UDP (17), length 65) > 192.168.2.8.45955 > 212.27.40.240.53: [udp sum ok] 52379+ AAAA? uucp.bortzmeyer.org. (37) It looks like this corresponds to measurement ID 8756383, which indeed has set_rd_bit set which is reflected in the answer found in the abuf. However, I notice that you also created a measurement #8756385 which does not have set_rd_bit to true in the metadata, nor is RD reflected in the results -- did you create this measurement in a different way? Regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stanish.stanishev at vivacom.bg Thu May 25 14:36:28 2017 From: stanish.stanishev at vivacom.bg (Stanish Stanishev) Date: Thu, 25 May 2017 14:36:28 +0200 Subject: [atlas] DNS measurement Message-ID: Hello, I am having troubles running a a DNS measurement against our DNS cache servers. I get Error: Timeout: 5000 every time I run such measurement. Please see measurement ID #8771668 for example. In this measurement I've selected the two anchors (ids 6262 and 6263) hosted by us (Vivacom) as the source and the target is one of our DNS cache servers - 212.39.90.42. There is no firewalls or other preventing our anchors from reaching the 212.39.90.42 and also the DNS cache server running on 212.39.90.42 is configured to serve queries from Anchors' IPs. What am I doing wrong ? Thanks, Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From bjorn at mork.no Thu May 25 15:34:45 2017 From: bjorn at mork.no (=?utf-8?Q?Bj=C3=B8rn_Mork?=) Date: Thu, 25 May 2017 15:34:45 +0200 Subject: [atlas] DNS measurement In-Reply-To: (Stanish Stanishev's message of "Thu, 25 May 2017 14:36:28 +0200") References: Message-ID: <87shjtoya2.fsf@miraculix.mork.no> Stanish Stanishev writes: > I am having troubles running a a DNS measurement against our DNS cache > servers. I get Error: Timeout: 5000 every time I run such measurement. > > Please see measurement ID #8771668 for example. > In this measurement I've selected the two anchors (ids 6262 and 6263) > hosted by us (Vivacom) as the source and the target is one of our DNS > cache servers - 212.39.90.42. There is no firewalls or other > preventing our anchors from reaching the 212.39.90.42 and also the DNS > cache server running on 212.39.90.42 is configured to serve queries > from Anchors' IPs. > > What am I doing wrong ? You forgot to check "recursion desired"? BTDT :-) Bj?rn From Stanish.Stanishev at vivacom.bg Thu May 25 17:06:51 2017 From: Stanish.Stanishev at vivacom.bg (Stanish Stanishev) Date: Thu, 25 May 2017 15:06:51 +0000 Subject: [atlas] DNS measurement In-Reply-To: <87shjtoya2.fsf@miraculix.mork.no> References: <87shjtoya2.fsf@miraculix.mork.no> Message-ID: Ah, Thank You So Much! Cheers :-) -----Original Message----- From: Bj?rn Mork [mailto:bjorn at mork.no] Sent: Thursday, May 25, 2017 4:35 PM To: Stanish Stanishev Cc: ripe-atlas at ripe.net Subject: Re: [atlas] DNS measurement Stanish Stanishev writes: > I am having troubles running a a DNS measurement against our DNS cache > servers. I get Error: Timeout: 5000 every time I run such measurement. > > Please see measurement ID #8771668 for example. > In this measurement I've selected the two anchors (ids 6262 and 6263) > hosted by us (Vivacom) as the source and the target is one of our DNS > cache servers - 212.39.90.42. There is no firewalls or other > preventing our anchors from reaching the 212.39.90.42 and also the DNS > cache server running on 212.39.90.42 is configured to serve queries > from Anchors' IPs. > > What am I doing wrong ? You forgot to check "recursion desired"? BTDT :-) Bj?rn From mkh at rqc.ru Fri May 26 13:51:49 2017 From: mkh at rqc.ru (Marat Khalili) Date: Fri, 26 May 2017 14:51:49 +0300 Subject: [atlas] Need host with very large ping times Message-ID: I have an interesting problem: I need some host that doesn't mind being pinged but with several seconds of RTT (that's thousands milliseconds; from Moscow, but it probably doesn't matter). Amazingly, I could not easily find one. I even tried to ping-scan IP ranges of Antarctica, but those hosts that responded did so in fraction of a second. Not much luck with North Korea (mostly down), Taiwan (internet is much better than it used to be) and several other suspect countries. (Though I'm not sure my tests are correct, since firewall processing of such long response times is one of the things I'm trying to find out.) Is it possible to somehow find one using RIPE ATLAS, preferably without ping-scanning whole internet? Would be especially great if it responded to other types of ping beside ICMP. -- With Best Regards, Marat Khalili From borjam at sarenet.es Fri May 26 13:54:38 2017 From: borjam at sarenet.es (Borja Marcos) Date: Fri, 26 May 2017 13:54:38 +0200 Subject: [atlas] Need host with very large ping times In-Reply-To: References: Message-ID: > On 26 May 2017, at 13:51, Marat Khalili wrote: > > I have an interesting problem: I need some host that doesn't mind being pinged but with several seconds of RTT (that's thousands milliseconds; from Moscow, but it probably doesn't matter). Amazingly, I could not easily find one. I even tried to ping-scan IP ranges of Antarctica, but those hosts that responded did so in fraction of a second. Not much luck with North Korea (mostly down), Taiwan (internet is much better than it used to be) and several other suspect countries. (Though I'm not sure my tests are correct, since firewall processing of such long response times is one of the things I'm trying to find out.) > > Is it possible to somehow find one using RIPE ATLAS, preferably without ping-scanning whole internet? Would be especially great if it responded to other types of ping beside ICMP. I haven?t tried such long delays, but FreeBSD?s dummynet allows you to create pipes with arbitrarily long delays, percentage of packet loss, etc Best regards, Borja. From annikaw at penguinfriends.org Fri May 26 13:57:59 2017 From: annikaw at penguinfriends.org (Annika Wickert) Date: Fri, 26 May 2017 13:57:59 +0200 Subject: [atlas] Need host with very large ping times In-Reply-To: References: Message-ID: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> You could try to test with this tool: https://github.com/tylertreat/comcast On 26.05.17 13:51, Marat Khalili wrote: > I have an interesting problem: I need some host that doesn't mind > being pinged but with several seconds of RTT (that's thousands > milliseconds; from Moscow, but it probably doesn't matter). Amazingly, > I could not easily find one. I even tried to ping-scan IP ranges of > Antarctica, but those hosts that responded did so in fraction of a > second. Not much luck with North Korea (mostly down), Taiwan (internet > is much better than it used to be) and several other suspect > countries. (Though I'm not sure my tests are correct, since firewall > processing of such long response times is one of the things I'm trying > to find out.) > > Is it possible to somehow find one using RIPE ATLAS, preferably > without ping-scanning whole internet? Would be especially great if it > responded to other types of ping beside ICMP. > > -- > > With Best Regards, > Marat Khalili > > From mkh at rqc.ru Fri May 26 14:17:53 2017 From: mkh at rqc.ru (Marat Khalili) Date: Fri, 26 May 2017 15:17:53 +0300 Subject: [atlas] Need host with very large ping times In-Reply-To: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> References: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> Message-ID: Annika, Borja, thank you for the suggestions. I'll consider purpose-building such host, but still hope to stumble upon existing one (some remote observatory on a satellite link probably...) -- With Best Regards, Marat Khalili On 26/05/17 14:57, Annika Wickert wrote: > You could try to test with this tool: > https://github.com/tylertreat/comcast > > On 26.05.17 13:51, Marat Khalili wrote: >> I have an interesting problem: I need some host that doesn't mind >> being pinged but with several seconds of RTT (that's thousands >> milliseconds; from Moscow, but it probably doesn't matter). >> Amazingly, I could not easily find one. I even tried to ping-scan IP >> ranges of Antarctica, but those hosts that responded did so in >> fraction of a second. Not much luck with North Korea (mostly down), >> Taiwan (internet is much better than it used to be) and several other >> suspect countries. (Though I'm not sure my tests are correct, since >> firewall processing of such long response times is one of the things >> I'm trying to find out.) >> >> Is it possible to somehow find one using RIPE ATLAS, preferably >> without ping-scanning whole internet? Would be especially great if it >> responded to other types of ping beside ICMP. >> >> -- >> >> With Best Regards, >> Marat Khalili >> >> > > From emile.aben at ripe.net Fri May 26 15:32:22 2017 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 26 May 2017 15:32:22 +0200 Subject: [atlas] Need host with very large ping times In-Reply-To: References: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> Message-ID: <47898a28-a3eb-ca96-b6bd-09fb1c0ab4bf@ripe.net> Hi Marat, there are big datasets of results of people that did already ICMP scans of the Internet, that contain timestamps, from which you could extract hosts with large RTTs. This is a scan from Univ. Michigan (as i understand it): https://censys.io/data/0-icmp-echo_request-full_ipv4 This research paper: http://conferences2.sigcomm.org/imc/2015/papers/p303.pdf describes how they found IP addresses with high RTTs (5% of IP address space that was probed had >5s RTT for 5% of the time). Maybe you can contact the authors if you are interested in this data? hope this helps, Emile Aben RIPE NCC On 26/05/17 14:17, Marat Khalili wrote: > Annika, Borja, thank you for the suggestions. I'll consider > purpose-building such host, but still hope to stumble upon existing one > (some remote observatory on a satellite link probably...) > > -- > > With Best Regards, > Marat Khalili > > On 26/05/17 14:57, Annika Wickert wrote: >> You could try to test with this tool: >> https://github.com/tylertreat/comcast >> >> On 26.05.17 13:51, Marat Khalili wrote: >>> I have an interesting problem: I need some host that doesn't mind >>> being pinged but with several seconds of RTT (that's thousands >>> milliseconds; from Moscow, but it probably doesn't matter). >>> Amazingly, I could not easily find one. I even tried to ping-scan IP >>> ranges of Antarctica, but those hosts that responded did so in >>> fraction of a second. Not much luck with North Korea (mostly down), >>> Taiwan (internet is much better than it used to be) and several other >>> suspect countries. (Though I'm not sure my tests are correct, since >>> firewall processing of such long response times is one of the things >>> I'm trying to find out.) >>> >>> Is it possible to somehow find one using RIPE ATLAS, preferably >>> without ping-scanning whole internet? Would be especially great if it >>> responded to other types of ping beside ICMP. >>> >>> -- >>> >>> With Best Regards, >>> Marat Khalili >>> >>> >> >> > > From mkh at rqc.ru Fri May 26 17:14:06 2017 From: mkh at rqc.ru (Marat Khalili) Date: Fri, 26 May 2017 18:14:06 +0300 Subject: [atlas] Need host with very large ping times In-Reply-To: <47898a28-a3eb-ca96-b6bd-09fb1c0ab4bf@ripe.net> References: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> <47898a28-a3eb-ca96-b6bd-09fb1c0ab4bf@ripe.net> Message-ID: Very interesting research indeed! Section "ASes most prone to RTTs greater than 1 second" contained enough information for me to find these hosts, no need to contact authors. Quest complete, thank you! -- With Best Regards, Marat Khalili On 26/05/17 16:32, Emile Aben wrote: > Hi Marat, > > there are big datasets of results of people that did already ICMP scans > of the Internet, that contain timestamps, from which you could extract > hosts with large RTTs. > This is a scan from Univ. Michigan (as i understand it): > https://censys.io/data/0-icmp-echo_request-full_ipv4 > > This research paper: > http://conferences2.sigcomm.org/imc/2015/papers/p303.pdf > describes how they found IP addresses with high RTTs (5% of IP address > space that was probed had >5s RTT for 5% of the time). Maybe you can > contact the authors if you are interested in this data? > > hope this helps, > Emile Aben > RIPE NCC > > On 26/05/17 14:17, Marat Khalili wrote: >> Annika, Borja, thank you for the suggestions. I'll consider >> purpose-building such host, but still hope to stumble upon existing one >> (some remote observatory on a satellite link probably...) >> >> -- >> >> With Best Regards, >> Marat Khalili >> >> On 26/05/17 14:57, Annika Wickert wrote: >>> You could try to test with this tool: >>> https://github.com/tylertreat/comcast >>> >>> On 26.05.17 13:51, Marat Khalili wrote: >>>> I have an interesting problem: I need some host that doesn't mind >>>> being pinged but with several seconds of RTT (that's thousands >>>> milliseconds; from Moscow, but it probably doesn't matter). >>>> Amazingly, I could not easily find one. I even tried to ping-scan IP >>>> ranges of Antarctica, but those hosts that responded did so in >>>> fraction of a second. Not much luck with North Korea (mostly down), >>>> Taiwan (internet is much better than it used to be) and several other >>>> suspect countries. (Though I'm not sure my tests are correct, since >>>> firewall processing of such long response times is one of the things >>>> I'm trying to find out.) >>>> >>>> Is it possible to somehow find one using RIPE ATLAS, preferably >>>> without ping-scanning whole internet? Would be especially great if it >>>> responded to other types of ping beside ICMP. >>>> >>>> -- >>>> >>>> With Best Regards, >>>> Marat Khalili >>>> >>>> >>> >> From rm at romanrm.net Fri May 26 18:42:54 2017 From: rm at romanrm.net (Roman Mamedov) Date: Fri, 26 May 2017 21:42:54 +0500 Subject: [atlas] Need host with very large ping times In-Reply-To: References: Message-ID: <20170526214254.6713843c@natsu> On Fri, 26 May 2017 14:51:49 +0300 Marat Khalili wrote: > I have an interesting problem: I need some host that doesn't mind being > pinged but with several seconds of RTT (that's thousands milliseconds; > from Moscow, but it probably doesn't matter). Just something to keep in mind, if they have such a terrible network connection, they probably would not appreciate being pinged (if you mean continuously or at any degree of regularity), chipping away at their miniscule network bandwidth in favor of some random person's unrelated research... -- With respect, Roman From jared at puck.nether.net Fri May 26 20:41:44 2017 From: jared at puck.nether.net (Jared Mauch) Date: Fri, 26 May 2017 14:41:44 -0400 Subject: [atlas] Need host with very large ping times In-Reply-To: <20170526214254.6713843c@natsu> References: <20170526214254.6713843c@natsu> Message-ID: <8AA91902-A0DD-421E-B8FE-93BB0D7110FA@puck.nether.net> > On May 26, 2017, at 12:42 PM, Roman Mamedov wrote: > > On Fri, 26 May 2017 14:51:49 +0300 > Marat Khalili wrote: > >> I have an interesting problem: I need some host that doesn't mind being >> pinged but with several seconds of RTT (that's thousands milliseconds; >> from Moscow, but it probably doesn't matter). > > Just something to keep in mind, if they have such a terrible network > connection, they probably would not appreciate being pinged (if you mean > continuously or at any degree of regularity), chipping away at their miniscule > network bandwidth in favor of some random person's unrelated research... My experience is it?s not always about the lack of connectivity, it?s about odd buffering behaviors of devices. The Juniper M40 would buffer an incredible amount of data on the FPC for a T1 speed link whereas a OC48 FPC had the same buffer sizes for much higher rates. Of course, this all assumes you know what you?re measuring, which is a critical part of it. - Jared From bortzmeyer at nic.fr Sat May 27 07:16:38 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 27 May 2017 07:16:38 +0200 Subject: [atlas] DNS and recursion In-Reply-To: <234762d4-c14b-01c8-1631-e879b1437a3f@ripe.net> References: <20170519123559.ae3h4dt4fgb5x5u4@nic.fr> <234762d4-c14b-01c8-1631-e879b1437a3f@ripe.net> Message-ID: <20170527051638.GA21769@laperouse.bortzmeyer.org> On Mon, May 22, 2017 at 02:15:54PM +0200, Chris Amin wrote a message of 89 lines which said: > This behaviour is still > documented in the manual: > https://atlas.ripe.net/docs/api/v2/manual/measurements/types/type_specific_attributes.html OK, I see, there was a problem in my tests, sorry. Indeed, if I set use_probe_resolver to false, *and* set_rd_bit to false, I get no recursion: 17:10:25.438994 IP (tos 0x0, ttl 64, id 16851, offset 0, flags [DF], proto UDP (17), length 79) 192.168.2.8.58886 > 80.67.169.12.53: [udp sum ok] 13066 A? hdsfdfsqgsqdfysq.bernardtapie.com. (51) (Measurement #8772374) If use_probe_resolver is true, I always have recursion enabled, set_rd_bit is indeed silently ignored. (Something that could be documented in ) From vaibhav.bajpai at tum.de Sun May 28 15:09:09 2017 From: vaibhav.bajpai at tum.de (Bajpai, Vaibhav) Date: Sun, 28 May 2017 13:09:09 +0000 Subject: [atlas] challenges with reproducibility Message-ID: <3e8e76e1-566a-4173-948c-8c4b0c9b6a2d@BADWLRZ-SWMBB01.ads.mwn.de> Dear RIPE Atlas / MAT WG -- sorry for cross-posting. A few of us wrote a paper discussing challenges with ?reproducibility? of research and certain steps we can take to initiate a cultural change. This paper will appear at the SIGCOMM reproducibility workshop [b]; the paper is now available online [a]. Thought to share it along: [a] http://vaibhavbajpai.com/documents/papers/proceedings/reproducibility-sigcomm-workshop-2017.pdf [b] http://conferences.sigcomm.org/sigcomm/2017/workshop-reproducibility.html -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany -------------------------- From borjam at sarenet.es Mon May 29 08:47:32 2017 From: borjam at sarenet.es (Borja Marcos) Date: Mon, 29 May 2017 08:47:32 +0200 Subject: [atlas] Need host with very large ping times In-Reply-To: References: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> Message-ID: > On 26 May 2017, at 14:17, Marat Khalili wrote: > > Annika, Borja, thank you for the suggestions. I'll consider purpose-building such host, but still hope to stumble upon existing one (some remote observatory on a satellite link probably?) An example creating a 20 second delay. # ipfw pipe 10 config delay 9999 Now we create a couple of firewall rules. I will give this ?royal treatment? to betweeen ?pinger? and ?pingee? # ipfw add 121 pipe 10 icmp from x.y.z.t to me # ipfw add 122 pipe 10 icmp from me to x.y.z.t (Adding delay to both the ping and the ping ack so that the maximum delay I can get is 20000 ms) And testing: 64 bytes from a.b.c.d: icmp_seq=259 ttl=60 time=20000.069 ms If you need it, give me the IP addresses from which you intend to do the tests and the delay you need and I can create a ping target on my test server in Amazon?s EC2. Cheers, Borja. From mkh at rqc.ru Mon May 29 09:21:43 2017 From: mkh at rqc.ru (Marat Khalili) Date: Mon, 29 May 2017 10:21:43 +0300 Subject: [atlas] Need host with very large ping times In-Reply-To: References: <20d93b77-08f6-0fa9-94a4-4a3a4a010b0e@penguinfriends.org> Message-ID: <1e49ace6-9192-e526-7bb8-7a1deef1f190@rqc.ru> Dear Borja, Thank you for your offer, but I already found out what I wanted for fixed source IP address and several seconds delays (that firewalls are ok with it). For "real" research much more would need to be done, but I don't have enough time and resources for it now. Just in case someone is interested in conducting this kind of research, IMO it would be interesting to open delay host to all internet and point ATLAS probes to it, then vary delay time and try to find out delays at which firewalls start to close connections prematurely. Then repeat it for TCP and (especially interesting) UDP, but AFAIU current probes can only send TCP/UDP test packets to anchors, therefore it would require coordination with ATLAS people. (I did not study literature, so maybe it has already been done recently.) -- With Best Regards, Marat Khalili On 29/05/17 09:47, Borja Marcos wrote: >> On 26 May 2017, at 14:17, Marat Khalili wrote: >> >> Annika, Borja, thank you for the suggestions. I'll consider purpose-building such host, but still hope to stumble upon existing one (some remote observatory on a satellite link probably?) > An example creating a 20 second delay. > > # ipfw pipe 10 config delay 9999 > > Now we create a couple of firewall rules. I will give this ?royal treatment? to betweeen ?pinger? and ?pingee? > > # ipfw add 121 pipe 10 icmp from x.y.z.t to me > # ipfw add 122 pipe 10 icmp from me to x.y.z.t > > (Adding delay to both the ping and the ping ack so that the maximum delay I can get is 20000 ms) > > > And testing: > > 64 bytes from a.b.c.d: icmp_seq=259 ttl=60 time=20000.069 ms > > > If you need it, give me the IP addresses from which you intend to do the tests and the delay you need and I can create a > ping target on my test server in Amazon?s EC2. > > > Cheers, > > > > > > Borja. > > > From bortzmeyer at nic.fr Mon May 29 13:41:45 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 29 May 2017 13:41:45 +0200 Subject: [atlas] TLS tests with login.live.com Message-ID: <20170529114145.zjy76xn52pt62w6h@nic.fr> TLS tests from the Atlas probes work for me, for every server... *but* login.live.com, for which I always get timeouts (it works with other TLS clients). Measurement #8775150 if someone has an idea... From bortzmeyer at nic.fr Mon May 29 13:53:35 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 29 May 2017 13:53:35 +0200 Subject: [atlas] TLS tests with login.live.com In-Reply-To: <20170529114145.zjy76xn52pt62w6h@nic.fr> References: <20170529114145.zjy76xn52pt62w6h@nic.fr> Message-ID: <20170529115335.zpswinmmx4opvh3a@nic.fr> On Mon, May 29, 2017 at 01:41:45PM +0200, Stephane Bortzmeyer wrote a message of 5 lines which said: > TLS tests from the Atlas probes work for me, for every server... *but* > login.live.com, for which I always get timeouts (it works with other > TLS clients). Could it be related to this error which is reported by many people on the socnets today? The Atlas probe checks the OCSP answer? From philip.homburg at ripe.net Mon May 29 13:58:13 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 29 May 2017 13:58:13 +0200 Subject: [atlas] TLS tests with login.live.com In-Reply-To: <20170529115335.zpswinmmx4opvh3a@nic.fr> References: <20170529114145.zjy76xn52pt62w6h@nic.fr> <20170529115335.zpswinmmx4opvh3a@nic.fr> Message-ID: <1cedd573-4bcf-c09b-e673-8a9720f11816@ripe.net> On 2017/05/29 13:53 , Stephane Bortzmeyer wrote: > On Mon, May 29, 2017 at 01:41:45PM +0200, > Stephane Bortzmeyer wrote > a message of 5 lines which said: > >> TLS tests from the Atlas probes work for me, for every server... *but* >> login.live.com, for which I always get timeouts (it works with other >> TLS clients). > > Could it be related to this error > which is > reported by many people on the socnets today? > > The Atlas probe checks the OCSP answer? Hi Stephane, No, the Atlas code is nowhere near advanced enough to do that. My guess is that the measurement code sends something the other side doesn't like and then the server responds with something the Atlas code doesn't understand. Philip From bortzmeyer at nic.fr Mon May 29 14:02:02 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 29 May 2017 14:02:02 +0200 Subject: [atlas] TLS tests with login.live.com In-Reply-To: <1cedd573-4bcf-c09b-e673-8a9720f11816@ripe.net> References: <20170529114145.zjy76xn52pt62w6h@nic.fr> <20170529115335.zpswinmmx4opvh3a@nic.fr> <1cedd573-4bcf-c09b-e673-8a9720f11816@ripe.net> Message-ID: <20170529120202.x6zljzeucpmnwdep@nic.fr> On Mon, May 29, 2017 at 01:58:13PM +0200, Philip Homburg wrote a message of 24 lines which said: > No, the Atlas code is nowhere near advanced enough to do that. OK, but the coincidence is funny :-) > My guess is that the measurement code sends something the other side > doesn't like and then the server responds with something the Atlas > code doesn't understand. Any way to debug it in more detail? From philip.homburg at ripe.net Mon May 29 14:04:40 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 29 May 2017 14:04:40 +0200 Subject: [atlas] TLS tests with login.live.com In-Reply-To: <20170529120202.x6zljzeucpmnwdep@nic.fr> References: <20170529114145.zjy76xn52pt62w6h@nic.fr> <20170529115335.zpswinmmx4opvh3a@nic.fr> <1cedd573-4bcf-c09b-e673-8a9720f11816@ripe.net> <20170529120202.x6zljzeucpmnwdep@nic.fr> Message-ID: On 2017/05/29 14:02 , Stephane Bortzmeyer wrote: >> My guess is that the measurement code sends something the other side >> doesn't like and then the server responds with something the Atlas >> code doesn't understand. > > Any way to debug it in more detail? I guess the first step would be look at the interaction in wireshark to see what the server is sending back. Note that at the moment, the probes do not include any SNI information. But a quick test suggests that that is not the cause of the problem. Philip From mike.oghia at gmail.com Tue May 30 14:23:26 2017 From: mike.oghia at gmail.com (Michael Oghia) Date: Tue, 30 May 2017 14:23:26 +0200 Subject: [atlas] Three improvement suggestions Message-ID: Dear all, I have three suggestions for how to improve the Atlas program: 1. Set up an automatic transfer system? That way, if someone accrues credits they would like to transfer, we can set it up to do so automatically once we hit 1,000,000 credits (think of it as similar to a bank's auto-pay system). 2. A system where, if someone needs extra credits, they can automatically request them to be deducted (with those who opt-in) from someone like myself with unused / extra credits. 3. Email notifications of when we have accrued 1,000,000 credits (my apologies if this is already a feature). I say this because I don't use my credits, so I don't want them to go to waste. It would be much more efficient if someone who needed them could access them any time (assuming I already gave permission for that (opted-in)). Let me know if anyone needs clarification about my suggestions. Best, -Michael __________________ Michael J. Oghia EuroDIG 2017 focal point (WS 11 ) Independent #netgov consultant & editor Belgrade, Serbia Skype: mikeoghia Twitter *|* LinkedIn -------------- next part -------------- An HTML attachment was scrubbed... URL: From neal at daringer.org Tue May 30 14:50:53 2017 From: neal at daringer.org (Neal Daringer) Date: Tue, 30 May 2017 08:50:53 -0400 Subject: [atlas] Three improvement suggestions In-Reply-To: References: Message-ID: not sure if this is appropriate for the list or not, but I definitely am in the same boat. I don't use my credits and would love for them to be put to use. On Tue, May 30, 2017 at 8:23 AM, Michael Oghia wrote: > Dear all, > > I have three suggestions for how to improve the Atlas program: > > 1. Set up an automatic transfer system? That way, if someone accrues > credits they would like to transfer, we can set it up to do so > automatically once we hit 1,000,000 credits (think of it as similar to a > bank's auto-pay system). > > 2. A system where, if someone needs extra credits, they can automatically > request them to be deducted (with those who opt-in) from someone like > myself with unused / extra credits. > > 3. Email notifications of when we have accrued 1,000,000 credits (my > apologies if this is already a feature). > > I say this because I don't use my credits, so I don't want them to go to > waste. It would be much more efficient if someone who needed them could > access them any time (assuming I already gave permission for that > (opted-in)). > > Let me know if anyone needs clarification about my suggestions. > > Best, > -Michael > __________________ > > Michael J. Oghia > EuroDIG 2017 focal point (WS 11 ) > Independent #netgov consultant & editor > > Belgrade, Serbia > Skype: mikeoghia > Twitter *|* LinkedIn > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kyriacos at sakkas.eu Tue May 30 14:55:47 2017 From: kyriacos at sakkas.eu (Kyriacos Sakkas) Date: Tue, 30 May 2017 15:55:47 +0300 Subject: [atlas] Three improvement suggestions In-Reply-To: References: Message-ID: <517d1edd-ab41-bcee-951b-53cb24793729@sakkas.eu> +1 on the idea in general, not likely to ever use most of my credits. Also we could make them into a virtual currency and a tradeable commodity, then we'll all be rich! Kyriacos On 30/05/2017 15:50, Neal Daringer wrote: > not sure if this is appropriate for the list or not, but I definitely > am in the same boat. I don't use my credits and would love for them to > be put to use. > > On Tue, May 30, 2017 at 8:23 AM, Michael Oghia > wrote: > > Dear all, > > I have three suggestions for how to improve the Atlas program: > > 1. Set up an automatic transfer system? That way, if someone > accrues credits they would like to transfer, we can set it up to > do so automatically once we hit 1,000,000 credits (think of it as > similar to a bank's auto-pay system). > > 2. A system where, if someone needs extra credits, they can > automatically request them to be deducted (with those who opt-in) > from someone like myself with unused / extra credits. > > 3. Email notifications of when we have accrued 1,000,000 credits > (my apologies if this is already a feature). > > I say this because I don't use my credits, so I don't want them to > go to waste. It would be much more efficient if someone who needed > them could access them any time (assuming I already gave > permission for that (opted-in)). > > Let me know if anyone needs clarification about my suggestions. > > Best, > -Michael > __________________ > > Michael J. Oghia > EuroDIG 2017 focal point (WS 11 > ) > Independent #netgov consultant & editor > > Belgrade, Serbia > Skype: mikeoghia > Twitter *|* LinkedIn > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared at puck.nether.net Tue May 30 14:56:48 2017 From: jared at puck.nether.net (Jared Mauch) Date: Tue, 30 May 2017 08:56:48 -0400 Subject: [atlas] Three improvement suggestions In-Reply-To: References: Message-ID: <94A68E8B-4142-4208-9E06-398FDB1A65C8@puck.nether.net> > On May 30, 2017, at 8:50 AM, Neal Daringer wrote: > > not sure if this is appropriate for the list or not, but I definitely am in the same boat. I don't use my credits and would love for them to be put to use. > > On Tue, May 30, 2017 at 8:23 AM, Michael Oghia wrote: > Dear all, > > I have three suggestions for how to improve the Atlas program: > > 1. Set up an automatic transfer system? That way, if someone accrues credits they would like to transfer, we can set it up to do so automatically once we hit 1,000,000 credits (think of it as similar to a bank's auto-pay system). > > 2. A system where, if someone needs extra credits, they can automatically request them to be deducted (with those who opt-in) from someone like myself with unused / extra credits. > > 3. Email notifications of when we have accrued 1,000,000 credits (my apologies if this is already a feature). > > I say this because I don't use my credits, so I don't want them to go to waste. It would be much more efficient if someone who needed them could access them any time (assuming I already gave permission for that (opted-in)). > > Let me know if anyone needs clarification about my suggestions. My problem is always finding someone to send credits to. You can share credits, but I don?t know who would want them. - jared From rm at romanrm.net Tue May 30 15:30:06 2017 From: rm at romanrm.net (Roman Mamedov) Date: Tue, 30 May 2017 18:30:06 +0500 Subject: [atlas] Three improvement suggestions In-Reply-To: <517d1edd-ab41-bcee-951b-53cb24793729@sakkas.eu> References: <517d1edd-ab41-bcee-951b-53cb24793729@sakkas.eu> Message-ID: <20170530183006.0dd2fa6d@natsu> On Tue, 30 May 2017 15:55:47 +0300 Kyriacos Sakkas wrote: > +1 on the idea in general, not likely to ever use most of my credits. > > Also we could make them into a virtual currency and a tradeable > commodity, then we'll all be rich! It would be nice to see a marketplace for credits, or at least the ability to trade them into RIPE merchandise (stickers, baseball hats, T-shirts[1]...?), so that regular participants could feel some thanks for running a probe over the years. But I guess the project does not include any budget for that. And with tons of people willing to give away their credits for free, there isn't any market for selling them either. [1] https://labs.ripe.net/Members/becha/tshirtback2.jpg/view -- With respect, Roman From kyriacos at sakkas.eu Tue May 30 16:49:24 2017 From: kyriacos at sakkas.eu (Kyriacos Sakkas) Date: Tue, 30 May 2017 17:49:24 +0300 Subject: [atlas] Three improvement suggestions In-Reply-To: <20170530183006.0dd2fa6d@natsu> References: <517d1edd-ab41-bcee-951b-53cb24793729@sakkas.eu> <20170530183006.0dd2fa6d@natsu> Message-ID: <1077cf07-a920-0e2f-9947-1134f982753d@sakkas.eu> On 30/05/2017 16:30, Roman Mamedov wrote: > On Tue, 30 May 2017 15:55:47 +0300 > Kyriacos Sakkas wrote: > >> +1 on the idea in general, not likely to ever use most of my credits. >> >> Also we could make them into a virtual currency and a tradeable >> commodity, then we'll all be rich! > It would be nice to see a marketplace for credits, or at least the ability to > trade them into RIPE merchandise (stickers, baseball hats, T-shirts[1]...?), so > that regular participants could feel some thanks for running a probe over the > years. But I guess the project does not include any budget for that. And with > tons of people willing to give away their credits for free, there isn't any > market for selling them either. > > [1] https://labs.ripe.net/Members/becha/tshirtback2.jpg/view > My plan is foiled once again :) From mike.oghia at gmail.com Tue May 30 17:23:34 2017 From: mike.oghia at gmail.com (Michael Oghia) Date: Tue, 30 May 2017 17:23:34 +0200 Subject: [atlas] Three improvement suggestions In-Reply-To: <1077cf07-a920-0e2f-9947-1134f982753d@sakkas.eu> References: <517d1edd-ab41-bcee-951b-53cb24793729@sakkas.eu> <20170530183006.0dd2fa6d@natsu> <1077cf07-a920-0e2f-9947-1134f982753d@sakkas.eu> Message-ID: Thank you all for the support for the idea. I'm not sure who would need to implement it (RIPE NCC I suppose?), but yes, I like the marketplace idea too. However, I'm happy to do it for free -- and making it easier for those who use the credits for measurements, for me, is plenty. I'll wait for a RIPE NCC staffer to respond as well. Best, -Michael On Tue, May 30, 2017 at 4:49 PM, Kyriacos Sakkas wrote: > On 30/05/2017 16:30, Roman Mamedov wrote: > >> On Tue, 30 May 2017 15:55:47 +0300 >> Kyriacos Sakkas wrote: >> >> +1 on the idea in general, not likely to ever use most of my credits. >>> >>> Also we could make them into a virtual currency and a tradeable >>> commodity, then we'll all be rich! >>> >> It would be nice to see a marketplace for credits, or at least the >> ability to >> trade them into RIPE merchandise (stickers, baseball hats, >> T-shirts[1]...?), so >> that regular participants could feel some thanks for running a probe over >> the >> years. But I guess the project does not include any budget for that. And >> with >> tons of people willing to give away their credits for free, there isn't >> any >> market for selling them either. >> >> [1] https://labs.ripe.net/Members/becha/tshirtback2.jpg/view >> >> My plan is foiled once again :) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hank at efes.iucc.ac.il Tue May 30 17:32:26 2017 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Tue, 30 May 2017 18:32:26 +0300 Subject: [atlas] Three improvement suggestions In-Reply-To: References: Message-ID: On 30/05/2017 15:23, Michael Oghia wrote: > Dear all, > > I have three suggestions for how to improve the Atlas program: > > 1. Set up an automatic transfer system? That way, if someone accrues > credits they would like to transfer, we can set it up to do so > automatically once we hit 1,000,000 credits (think of it as similar to > a bank's auto-pay system). Isn't the ATLAS "standing order" credit tab an answer for that? > > 2. A system where, if someone needs extra credits, they can > automatically request them to be deducted (with those who opt-in) from > someone like myself with unused / extra credits. If you trust the person you can in the meantime use the "Share Access" tab in the Credit system. Regards, Hank From robert at ripe.net Wed May 31 14:30:25 2017 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 31 May 2017 14:30:25 +0200 Subject: [atlas] Three improvement suggestions In-Reply-To: References: Message-ID: On 2017-05-30 14:23, Michael Oghia wrote: > Dear all, > > I have three suggestions for how to improve the Atlas program: > > 1. Set up an automatic transfer system? That way, if someone accrues > credits they would like to transfer, we can set it up to do so > automatically once we hit 1,000,000 credits (think of it as similar to a > bank's auto-pay system). > > 2. A system where, if someone needs extra credits, they can > automatically request them to be deducted (with those who opt-in) from > someone like myself with unused / extra credits. > > 3. Email notifications of when we have accrued 1,000,000 credits (my > apologies if this is already a feature). > > I say this because I don't use my credits, so I don't want them to go to > waste. It would be much more efficient if someone who needed them could > access them any time (assuming I already gave permission for that > (opted-in)). > > Let me know if anyone needs clarification about my suggestions. > > Best, > -Michael Hello, As Hank mentioned, the "standing order" is indeed the function to solve (1), and "share access" lets you authorise others to tap into your account mostly solving (2) within a trust realm. Even though we don't have email notifications about accumulated credits, there's an API to interact with the credit system, documented at https://atlas.ripe.net/docs/api/v2/reference/#!/api/Account_GET going a long way to self-build (3). The idea of a "credit marketplace" came up a few times before and so far it has mostly been handled by community interaction, i.e. users asking each other if in need or they have excess amounts. We could of course work on a more automated mechanism if this is widely considered to be a useful feature. The risk is this will evolve into a whole separate banking system, perhaps being a bigger undertaking than building RIPE Atlas itself :-) Regards, Robert Kisteleki RIPE NCC From mike.oghia at gmail.com Wed May 31 14:57:46 2017 From: mike.oghia at gmail.com (Michael Oghia) Date: Wed, 31 May 2017 14:57:46 +0200 Subject: [atlas] Three improvement suggestions In-Reply-To: References: Message-ID: Hi Robert, all: Thanks for addressing my questions. Indeed, "standing order" does solve my main question. Also, I visited the API link you sent, but honestly I have no idea how to use that information (I don't know any code). I meant that it would just be a simple email notification when we've hit a certain amount of credits (but then again, if it can do so automatically with standing order, then it's all fine). On further thought, I disagree with the credit marketplace system. I appreciate that this is a service we volunteer for and the measurements are also voluntary. With that said, though, I am sure there are many unused credits that those who run many measurements could use (especially if no one uses their credits). Could this be addressed somehow? Lastly, would anyone like to get around 1,000,000 credits from me every 5 weeks? I can set it up using the standing order process. Best, -Michael On Wed, May 31, 2017 at 2:30 PM, Robert Kisteleki wrote: > On 2017-05-30 14:23, Michael Oghia wrote: > > Dear all, > > > > I have three suggestions for how to improve the Atlas program: > > > > 1. Set up an automatic transfer system? That way, if someone accrues > > credits they would like to transfer, we can set it up to do so > > automatically once we hit 1,000,000 credits (think of it as similar to a > > bank's auto-pay system). > > > > 2. A system where, if someone needs extra credits, they can > > automatically request them to be deducted (with those who opt-in) from > > someone like myself with unused / extra credits. > > > > 3. Email notifications of when we have accrued 1,000,000 credits (my > > apologies if this is already a feature). > > > > I say this because I don't use my credits, so I don't want them to go to > > waste. It would be much more efficient if someone who needed them could > > access them any time (assuming I already gave permission for that > > (opted-in)). > > > > Let me know if anyone needs clarification about my suggestions. > > > > Best, > > -Michael > > Hello, > > As Hank mentioned, the "standing order" is indeed the function to solve > (1), and "share access" lets you authorise others to tap into your > account mostly solving (2) within a trust realm. > > Even though we don't have email notifications about accumulated credits, > there's an API to interact with the credit system, documented at > https://atlas.ripe.net/docs/api/v2/reference/#!/api/Account_GET going a > long way to self-build (3). > > The idea of a "credit marketplace" came up a few times before and so far > it has mostly been handled by community interaction, i.e. users asking > each other if in need or they have excess amounts. We could of course > work on a more automated mechanism if this is widely considered to be a > useful feature. The risk is this will evolve into a whole separate > banking system, perhaps being a bigger undertaking than building RIPE > Atlas itself :-) > > Regards, > Robert Kisteleki > RIPE NCC > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonesnco at gmail.com Wed May 31 16:07:52 2017 From: jonesnco at gmail.com (Dan Jones) Date: Wed, 31 May 2017 09:07:52 -0500 Subject: [atlas] Surplus RIPE Atlas credit offer Message-ID: I have a large pool of unused credits if anyone needs any transferred to their account. I likely won't be using them so they should go to a good cause. Dan Jones -------------- next part -------------- An HTML attachment was scrubbed... URL: