From mm at 42com.com Mon Feb 1 09:50:26 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Mon, 1 Feb 2016 09:50:26 +0100 Subject: [atlas] Probe uptime? Message-ID: <56AF1C52.9010405@42com.com> Hi, i suspect that there is a problem with my atlas probe, sometimes it is just gone / offline for ~10 minutes (more or less) although there is clearly no issue on the network. Other checks and monitoring works fine at the same time and shows about 100% uptime... I am not sure how to investigate, is there any chance to check the uptime of the probe and not just connection time? Maybe the device is hanging or rebooting? Internet Address Controller Connected (UTC) Connected for Disconnected (UTC) Disconnected for xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-06 17:03:27 5d 22h 40m 2016-01-12 15:44:09 0h 5m xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-01 00:29:44 5d 16h 16m 2016-01-06 16:46:33 0h 16m xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 23:47:35 0h 38m 2016-01-01 00:25:40 0h 4m xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:59:18 0h 41m 2015-12-31 23:40:32 0h 7m xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:35:12 0h 20m 2015-12-31 22:56:08 0h 3m Best Regards Max M. From mm at 42com.com Mon Feb 1 11:29:47 2016 From: mm at 42com.com (=?UTF-8?Q?Max_M=c3=bchlbronner?=) Date: Mon, 1 Feb 2016 11:29:47 +0100 Subject: [atlas] Probe uptime? In-Reply-To: <56AF1C52.9010405@42com.com> References: <56AF1C52.9010405@42com.com> Message-ID: <56AF339B.4080701@42com.com> Even worse: Internet Address Controller Connected (UTC) Connected for Disconnected (UTC) Disconnected for 1xx.xxx.xxx.xx ctr-ams07, NL 2016-01-31 08:48:48 1d 1h 38m Still Connected 1xx.xxx.xxx.xx ctr-nue19, DE 2016-01-29 05:07:31 2d 1h 24m 2016-01-31 06:32:02 2h 16m Could it be a problem of the ripe "controllers"? E.g.if they are offline my probe also has a downtime , how fast do they failover to another Controller?? (Why was it offline for 2hours, until it switched to another one) Best Regards Max M. On 01.02.2016 09:50, Max M?hlbronner wrote: > Hi, > > i suspect that there is a problem with my atlas probe, sometimes it is > just gone / offline for ~10 minutes (more or less) although there is > clearly no issue on the network. Other checks and monitoring works > fine at the same time and shows about 100% uptime... > > I am not sure how to investigate, is there any chance to check the > uptime of the probe and not just connection time? Maybe the device is > hanging or rebooting? > > > Internet Address Controller Connected (UTC) Connected > for Disconnected (UTC) Disconnected for > xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-06 17:03:27 5d 22h > 40m 2016-01-12 15:44:09 0h 5m > xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-01 00:29:44 5d 16h > 16m 2016-01-06 16:46:33 0h 16m > xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 23:47:35 0h 38m > 2016-01-01 00:25:40 0h 4m > xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:59:18 0h 41m > 2015-12-31 23:40:32 0h 7m > xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:35:12 0h 20m > 2015-12-31 22:56:08 0h 3m > > > Best Regards > > > Max M. > From vnaumov at ripe.net Mon Feb 1 12:04:53 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 1 Feb 2016 12:04:53 +0100 Subject: [atlas] Probe uptime? In-Reply-To: <56AF339B.4080701@42com.com> References: <56AF1C52.9010405@42com.com> <56AF339B.4080701@42com.com> Message-ID: <56AF3BD5.20701@ripe.net> Hi Max, ctr-nue19 was rebooted around 11 o'clock UTC because it was not responding. The logic is following: If a controller doesn't send heartbeats for more than 2 hours it is excluded from the list of available controllers. The algorithm that assigns a probe to a controller tries to assign probes the controller it was connected last time. So your case your probe needed to migrate to another controller (ctr-ams07) after 2 hours of trying to connect to the last controller. It is not necessarily a downtime. It is stated here int the report as the disconnection time. During that time your probes does measurements but it doesn't sent results to controller. We are introducing the probe uptime metrics, but it is still in the making and not exposed to users yet and not included into the billing. WBR /vty On 2/1/16 11:29 AM, Max M?hlbronner wrote: > > Even worse: > > > Internet Address Controller Connected (UTC) Connected > for Disconnected (UTC) Disconnected for > 1xx.xxx.xxx.xx ctr-ams07, NL 2016-01-31 08:48:48 1d 1h > 38m Still Connected > 1xx.xxx.xxx.xx ctr-nue19, DE 2016-01-29 05:07:31 2d 1h > 24m 2016-01-31 06:32:02 2h 16m > > > Could it be a problem of the ripe "controllers"? E.g.if they are > offline my probe also has a downtime , how fast do they failover to > another Controller?? (Why was it offline for 2hours, until it switched > to another one) > > > Best Regards > > Max M. > > On 01.02.2016 09:50, Max M?hlbronner wrote: >> Hi, >> >> i suspect that there is a problem with my atlas probe, sometimes it >> is just gone / offline for ~10 minutes (more or less) although there >> is clearly no issue on the network. Other checks and monitoring works >> fine at the same time and shows about 100% uptime... >> >> I am not sure how to investigate, is there any chance to check the >> uptime of the probe and not just connection time? Maybe the device is >> hanging or rebooting? >> >> >> Internet Address Controller Connected (UTC) Connected >> for Disconnected (UTC) Disconnected for >> xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-06 17:03:27 5d 22h >> 40m 2016-01-12 15:44:09 0h 5m >> xxx.xxx.xxx.xx ctr-nue19, DE 2016-01-01 00:29:44 5d 16h >> 16m 2016-01-06 16:46:33 0h 16m >> xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 23:47:35 0h 38m >> 2016-01-01 00:25:40 0h 4m >> xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:59:18 0h 41m >> 2015-12-31 23:40:32 0h 7m >> xxx.xxx.xxx.xx ctr-nue19, DE 2015-12-31 22:35:12 0h 20m >> 2015-12-31 22:56:08 0h 3m >> >> >> Best Regards >> >> >> Max M. >> > > > From wenqin.shao at telecom-paristech.fr Wed Feb 3 11:07:57 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Wed, 3 Feb 2016 11:07:57 +0100 Subject: [atlas] API (v1) querying probes by ID Message-ID: <10824442-81B8-4DDA-991D-814D4DD7D345@telecom-paristech.fr> Dear list, I have the impression that querying probes by ID returns unexpected results. An example is: https://atlas.ripe.net/api/v1/probe/?id=1 As a result, I get the entire probe list: "meta": { "total_count": 16973, "use_iso_time": false, "next": "/api/v1/probe/?id=1&limit=100&offset=100", "limit": 100, "offset": 0, "previous": null }, And ID 1 is an valid ID, which corresponds to the first entry of results: "id": 1, "type": "Probe", "is_public": false, "first_connected": "2010-10-29T15:53:03Z", "last_connected": "2016-02-03T10:02:28.407276Z", "is_anchor": false, "address_v4": null, "address_v6": null, "asn_v4": 3265, "asn_v6": 3265, "country_code": "NL", "prefix_v4": "212.238.0.0/16", "prefix_v6": "2001:980::/29", Regards, wenqin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed Feb 3 11:11:36 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 3 Feb 2016 11:11:36 +0100 Subject: [atlas] API (v1) querying probes by ID In-Reply-To: <10824442-81B8-4DDA-991D-814D4DD7D345@telecom-paristech.fr> References: <10824442-81B8-4DDA-991D-814D4DD7D345@telecom-paristech.fr> Message-ID: <20160203101136.GA32116@nic.fr> On Wed, Feb 03, 2016 at 11:07:57AM +0100, Wenqin SHAO wrote a message of 98 lines which said: > An example is: > https://atlas.ripe.net/api/v1/probe/?id=1 I use the URL and it seems to work. From wenqin.shao at telecom-paristech.fr Wed Feb 3 11:34:18 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Wed, 3 Feb 2016 11:34:18 +0100 Subject: [atlas] API (v1) querying probes by ID In-Reply-To: <20160203101136.GA32116@nic.fr> References: <10824442-81B8-4DDA-991D-814D4DD7D345@telecom-paristech.fr> <20160203101136.GA32116@nic.fr> Message-ID: Indeed! What if I?d like to select a list of probes, how should I compose the query in this fashion? Many thanks. Wenqin > On 03 Feb 2016, at 11:11, Stephane Bortzmeyer wrote: > > On Wed, Feb 03, 2016 at 11:07:57AM +0100, > Wenqin SHAO wrote > a message of 98 lines which said: > >> An example is: >> https://atlas.ripe.net/api/v1/probe/?id=1 > > I use the URL and it seems to > work. From jdenhertog at ripe.net Wed Feb 3 11:35:39 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Wed, 3 Feb 2016 11:35:39 +0100 Subject: [atlas] API (v1) querying probes by ID In-Reply-To: References: <10824442-81B8-4DDA-991D-814D4DD7D345@telecom-paristech.fr> <20160203101136.GA32116@nic.fr> Message-ID: Wenqin, You could user the ?id__in= query-parameter in you query, like: https://atlas.ripe.net/api/v1/probe/?id__in=1,11,66 You are right BTW that ?id= is a documented feature, that is now working as advertised (although also completely useless). greetings, Jasper den Hertog Software Engineer RIPE NCC > On 03 Feb 2016, at 11:34, Wenqin SHAO wrote: > > Indeed! > What if I?d like to select a list of probes, how should I compose the query in this fashion? > Many thanks. > > Wenqin >> On 03 Feb 2016, at 11:11, Stephane Bortzmeyer wrote: >> >> On Wed, Feb 03, 2016 at 11:07:57AM +0100, >> Wenqin SHAO wrote >> a message of 98 lines which said: >> >>> An example is: >>> https://atlas.ripe.net/api/v1/probe/?id=1 >> >> I use the URL and it seems to >> work. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From wenqin.shao at telecom-paristech.fr Wed Feb 3 11:40:40 2016 From: wenqin.shao at telecom-paristech.fr (Wenqin SHAO) Date: Wed, 3 Feb 2016 11:40:40 +0100 Subject: [atlas] API (v1) querying probes by ID In-Reply-To: References: <10824442-81B8-4DDA-991D-814D4DD7D345@telecom-paristech.fr> <20160203101136.GA32116@nic.fr> Message-ID: Jasper, Thank you a lot for your quick response as usual. Regards, wenqin > On 03 Feb 2016, at 11:35, Jasper den Hertog wrote: > > Wenqin, > > You could user the ?id__in= query-parameter in you query, like: > > https://atlas.ripe.net/api/v1/probe/?id__in=1,11,66 > > You are right BTW that ?id= is a documented feature, that is now working as advertised (although also completely useless). > > greetings, > > Jasper den Hertog > Software Engineer > RIPE NCC > >> On 03 Feb 2016, at 11:34, Wenqin SHAO > wrote: >> >> Indeed! >> What if I?d like to select a list of probes, how should I compose the query in this fashion? >> Many thanks. >> >> Wenqin >>> On 03 Feb 2016, at 11:11, Stephane Bortzmeyer > wrote: >>> >>> On Wed, Feb 03, 2016 at 11:07:57AM +0100, >>> Wenqin SHAO > wrote >>> a message of 98 lines which said: >>> >>>> An example is: >>>> https://atlas.ripe.net/api/v1/probe/?id=1 >>> >>> I use the URL > and it seems to >>> work. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Thu Feb 4 15:42:20 2016 From: robert at ripe.net (Robert Kisteleki) Date: Thu, 4 Feb 2016 15:42:20 +0100 Subject: [atlas] Revamped RIPE Atlas website launched today Message-ID: <56B3634C.7060301@ripe.net> Dear all, We?re excited to announce that a revamped RIPE Atlas website launches today, so you can expect to see some changes when you visit atlas.ripe.net. We know that it can take some time to get used to change, but we think the new site is a big improvement over the old one and that you?ll find it quicker and easier to access the information you want. Some of the main features include proper landing pages for each section with quick links to the most relevant information, a restructured menu that includes a few new sections, including ?Measurements, Maps and Tools?, ?Probes and Anchors? and ?Resources?, an improved dashboard overview of all of your probes and measurements under ?My Atlas?, and faster data tables that you can now search. You can learn more about the revamped site and the reasons behind the change in this RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/the-revamped-ripe-atlas-website Take some to look around and let us know what you think. We hope you?ll like what you see. Of course, we?ve done our best to ensure that all links are working properly, but if you happen to spot anything that looks wrong or broken, please let us know at atlas at ripe.net. Regards, Robert From gil at magisto.com Tue Feb 9 11:13:09 2016 From: gil at magisto.com (Gil Bahat) Date: Tue, 9 Feb 2016 12:13:09 +0200 Subject: [atlas] Feature request - externalize packet loss in ping measurement UI Message-ID: Hi, looking at the JSON data, there is a field for the amount of received packets vs the requested, but at the measurement UI it is not reflected. it'd be great if this can be displayed (e.g. 'x% packet loss' as one of the columns). Regards, Gil Bahat, Director of Online Operations, Magisto Ltd. -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Tue Feb 9 12:29:34 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 9 Feb 2016 12:29:34 +0100 Subject: [atlas] List of my measurements via API In-Reply-To: References: Message-ID: <56B9CD9E.6010100@ripe.net> Hi Luke, On 28-jan.-16 10:47, Luke Overend wrote: > Hi all, > > I have searched the docs and tried everything I can think of but I > cannot get a list of my measurements via the API. It's here: https://atlas.ripe.net/docs/rest/ (search for "mine") > Can anyone provide me details on how to do this? It works like this: https://atlas.ripe.net/api/v1/measurement/?mine=true > If it is not currently possible how do I go about requesting the feature? You did the right thing :) If you try this out, and want some modifications, please write to the list again, or reply to me directly. Cheers, Vesna > > Thanks > > Luke Overend > -------------------------------------- > CloudFlare - AS13335 > Network Engineer > luke at cloudflare.com > +442038136383 > +447795328022 > > http://www.peeringdb.com/view.php?asn=13335 From annikaw at penguinfriends.org Wed Feb 10 14:18:33 2016 From: annikaw at penguinfriends.org (Annika Wickert) Date: Wed, 10 Feb 2016 14:18:33 +0100 Subject: [atlas] Feature request - externalize packet loss in ping measurement UI In-Reply-To: References: Message-ID: <56BB38A9.6010109@penguinfriends.org> +1 would be really cool. It's also a feature I miss. On 09/02/16 11:13, Gil Bahat wrote: > Hi, > > looking at the JSON data, there is a field for the amount of received > packets vs the requested, but at the measurement UI it is not > reflected. it'd be great if this can be displayed (e.g. 'x% packet > loss' as one of the columns). > > Regards, > > Gil Bahat, > Director of Online Operations, > Magisto Ltd. From me at anuragbhatia.com Wed Feb 10 20:56:02 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 11 Feb 2016 01:26:02 +0530 Subject: [atlas] Triggering traces from probes in specific cities Message-ID: Hello everyone, I was looking at possible command line tool to trigger traces from Atlas from given city or that area. The closest I can see is RIPE Atlas Tools - https://github.com/RIPE-NCC/ripe-atlas-tools but these let to only put source country or region. 1. Is anyone aware of how one can trigger traces via CLI from specific cities? *(I would love to do trace from a nearby city if specific city does not have Atlas coverage)* 2. In the Ripe Atlas Tools I see in documentation it refers to an argument "[--paris paris]". Is anyone aware of what does it mean? It seems to be asking for an integer value. Thanks in advance! -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From astrikos at ripe.net Wed Feb 10 21:32:44 2016 From: astrikos at ripe.net (Andreas Strikos) Date: Wed, 10 Feb 2016 21:32:44 +0100 Subject: [atlas] Triggering traces from probes in specific cities In-Reply-To: References: Message-ID: <56BB9E6C.6010904@ripe.net> Hi Anurag, you can do what you want with RIPE Atlas Tools in two steps. First get a list of probes that are around a city like: |ripe-atlas probes --location Amsterdam --ids-only --radius 20 | If you do: |ripe-atlas probes -h | you can see some explanation of the options. And then get the above list and pass it as a comma separated list to the measure command like: |ripe-atlas measure traceroute --from-probes 1,2,3,4 your_target | --paris is the paris traceroute option. It should be an integer from 0 to 64 as stated in the RIPE Atlas website documentation. I hope that helps! Regards, Andreas On 10/02/16 20:56, Anurag Bhatia wrote: > Hello everyone, > > > > > > I was looking at possible command line tool to trigger traces from > Atlas from given city or that area. > > > The closest I can see is RIPE Atlas Tools - > https://github.com/RIPE-NCC/ripe-atlas-tools but these let to only put > source country or region. > > > 1. Is anyone aware of how one can trigger traces via CLI from > specific cities? /(I would love to do trace from a nearby city if > specific city does not have Atlas coverage)/ > 2. In the Ripe Atlas Tools I see in documentation it refers to an > argument "[--paris paris]". Is anyone aware of what does it mean? > It seems to be asking for an integer value. > > > > > > Thanks in advance! > > -- > > > Anurag Bhatia > anuragbhatia.com ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at anuragbhatia.com Wed Feb 10 21:41:51 2016 From: me at anuragbhatia.com (Anurag Bhatia) Date: Thu, 11 Feb 2016 02:11:51 +0530 Subject: [atlas] Triggering traces from probes in specific cities In-Reply-To: <56BB9E6C.6010904@ripe.net> References: <56BB9E6C.6010904@ripe.net> Message-ID: Oh wow! Did not notice that existed. This is exactly what I was looking for! Thanks Andreas. On Thu, Feb 11, 2016 at 2:02 AM, Andreas Strikos wrote: > Hi Anurag, > > you can do what you want with RIPE Atlas Tools in two steps. > > First get a list of probes that are around a city like: > > ripe-atlas probes --location Amsterdam --ids-only --radius 20 > > If you do: > > ripe-atlas probes -h > > you can see some explanation of the options. > > And then get the above list and pass it as a comma separated list to the > measure command like: > > ripe-atlas measure traceroute --from-probes 1,2,3,4 your_target > > --paris is the paris traceroute option. It should be an integer from 0 to > 64 as stated in the RIPE Atlas website documentation. > > > I hope that helps! > > Regards, > Andreas > > On 10/02/16 20:56, Anurag Bhatia wrote: > > Hello everyone, > > > > > > I was looking at possible command line tool to trigger traces from Atlas > from given city or that area. > > > The closest I can see is RIPE Atlas Tools - > > https://github.com/RIPE-NCC/ripe-atlas-tools but these let to only put > source country or region. > > > > 1. Is anyone aware of how one can trigger traces via CLI from specific > cities? *(I would love to do trace from a nearby city if specific city > does not have Atlas coverage)* > 2. In the Ripe Atlas Tools I see in documentation it refers to an > argument "[--paris paris]". Is anyone aware of what does it mean? It seems > to be asking for an integer value. > > > > > > Thanks in advance! > > -- > > > Anurag Bhatia > anuragbhatia.com > > ? > -- Anurag Bhatia anuragbhatia.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From c.rauterberg at stud.uni-goettingen.de Fri Feb 12 08:20:51 2016 From: c.rauterberg at stud.uni-goettingen.de (Christoph Rauterberg) Date: Fri, 12 Feb 2016 16:20:51 +0900 Subject: [atlas] Detecting additional information from the probes Message-ID: <56BD87D3.4090208@stud.uni-goettingen.de> Ahoi everyone, I am currently trying to asses the behaviour of DNS queries between clients and authentication servers - and I would love to trace some DNS pakets between the probes and my server. I was wondering, if there is some way to get the information about the Authentication Bit of DNSSEC specified in the DNS query headers. A.f.a.i.k., the probes do something similiar/do a /dig/ lookup. /dig/ does provide information about the DNSSEC-section - and furthermore it has a very handy /+trace/ option. Can anyone maybe tell me, if there are possibilities to access the AUTH bith or even something like a trace function via the probes? Or should I open a feature request for that? Help much appreciated! :-) Best regards, Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Fri Feb 12 10:06:21 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 12 Feb 2016 10:06:21 +0100 Subject: [atlas] Detecting additional information from the probes In-Reply-To: <56BD87D3.4090208@stud.uni-goettingen.de> References: <56BD87D3.4090208@stud.uni-goettingen.de> Message-ID: <20160212090621.GA28095@nic.fr> On Fri, Feb 12, 2016 at 04:20:51PM +0900, Christoph Rauterberg wrote a message of 60 lines which said: > I was wondering, if there is some way to get the information about > the Authentication Bit of DNSSEC specified in the DNS query headers. You mean the reply? > A.f.a.i.k., the probes do something similiar/do a /dig/ lookup. No. The probes have a DNS client. dig is a DNS client. That's all the similarity. > Can anyone maybe tell me, if there are possibilities to access the AUTH > bith It is accessible (the full response is in the "abuf" field, you just have to decode it, example in Python: answer = result['abuf'] + "==" content = base64.b64decode(answer) msg = dns.message.from_wire(content) if msg.flags & dns.flags.AD: print "Authentic" From bortzmeyer at nic.fr Fri Feb 12 10:19:14 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 12 Feb 2016 10:19:14 +0100 Subject: [atlas] Detecting additional information from the probes In-Reply-To: <20160212090621.GA28095@nic.fr> References: <56BD87D3.4090208@stud.uni-goettingen.de> <20160212090621.GA28095@nic.fr> Message-ID: <20160212091914.GA29773@nic.fr> On Fri, Feb 12, 2016 at 10:06:21AM +0100, Stephane Bortzmeyer wrote a message of 25 lines which said: > It is accessible (the full response is in the "abuf" field, you just > have to decode it, example in Python: I forgot to add that it requires setting the DO bit in the query . In Python: data["definitions"][0]["do"] = True From mostafa.shahdadi at gmail.com Sat Feb 13 13:24:54 2016 From: mostafa.shahdadi at gmail.com (mostafa shahdadi) Date: Sat, 13 Feb 2016 15:54:54 +0330 Subject: [atlas] can help me increase speed Message-ID: % This is the RIPE Database query service. % The objects are in RPSL format. % % The RIPE Database is subject to Terms and Conditions. % See http://www.ripe.net/db/support/db-terms-conditions.pdf % Note: this output has been filtered. % To receive output for a database update, use the "-B" flag. % Information related to '2.189.88.0 - 2.189.95.255' % Abuse contact for '2.189.88.0 - 2.189.95.255' is 'R.javidi at tci.ir' inetnum: 2.189.88.0 - 2.189.95.255 netname: DABCO descr: Dadeh Pardazan Avaye Bandar Company country: IR admin-c: PA8248-RIPE tech-c: PA8248-RIPE status: ASSIGNED PA mnt-by: AS12880-MNT created: 2015-05-25T06:22:46Z last-modified: 2015-05-25T06:31:59Z source: RIPE # Filtered person: POURIYA ARGHASH address: No 2,first Floor,Daryanavard Building,Delgosha Conjunction, address: Emam Khomeyni Street,Bandar Abbas,Hormozgan,Iran phone: +98 761 222 54 90 fax-no: +98 761 222 54 90 nic-hdl: PA8248-RIPE mnt-by: AS12880-MNT created: 2015-05-25T06:31:59Z last-modified: 2015-05-25T06:31:59Z source: RIPE # Filtered % Information related to '2.189.0.0/16AS12880' route: 2.189.0.0/16 descr: Information Technology Company (ITC) origin: AS12880 mnt-by: AS12880-MNT mnt-routes: mohsenrahimimaintainer created: 2011-07-13T14:32:16Z last-modified: 2015-03-04T10:05:36Z source: RIPE # Filtered % This query was served by the RIPE Database Query Service version 1.85.1 (DB-1) Sent from my iPad From bortzmeyer at nic.fr Sat Feb 13 21:38:01 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 13 Feb 2016 21:38:01 +0100 Subject: [atlas] can help me increase speed In-Reply-To: References: Message-ID: <20160213203801.GA347@nic.fr> On Sat, Feb 13, 2016 at 03:54:54PM +0330, mostafa shahdadi wrote a message of 52 lines which said: > inetnum: 2.189.88.0 - 2.189.95.255 > netname: DABCO > descr: Dadeh Pardazan Avaye Bandar Company > country: IR Can you explain what the problem is and what you expect from us? PS : I find no RIPE Atlas probe in 2.189.88.0/21, alas. From c.rauterberg at stud.uni-goettingen.de Mon Feb 15 06:59:52 2016 From: c.rauterberg at stud.uni-goettingen.de (Christoph Rauterberg) Date: Mon, 15 Feb 2016 14:59:52 +0900 Subject: [atlas] Detecting additional information from the probes In-Reply-To: <20160212091914.GA29773@nic.fr> References: <56BD87D3.4090208@stud.uni-goettingen.de> <20160212090621.GA28095@nic.fr> <20160212091914.GA29773@nic.fr> Message-ID: <56C16958.9020604@stud.uni-goettingen.de> Coolio, I was overreading the DO-Bit. Together with the Sagan-Interface for Python, I can now get to work, Thanks for the quick reply! :-) On 12.02.2016 18:19, Stephane Bortzmeyer wrote: > On Fri, Feb 12, 2016 at 10:06:21AM +0100, > Stephane Bortzmeyer wrote > a message of 25 lines which said: > >> It is accessible (the full response is in the "abuf" field, you just >> have to decode it, example in Python: > I forgot to add that it requires setting the DO bit in the query > . In Python: > > data["definitions"][0]["do"] = True From sarah.wassermann at student.ulg.ac.be Tue Feb 16 19:29:38 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Tue, 16 Feb 2016 19:29:38 +0100 (CET) Subject: [atlas] probe tagged as "system: Firewall problem suspected" Message-ID: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> Hi, I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. Anybody knows how to fix this? (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( Thanks! Sarah From magicsata at gmail.com Wed Feb 17 10:21:07 2016 From: magicsata at gmail.com (Alistair Mackenzie) Date: Wed, 17 Feb 2016 09:21:07 +0000 Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> References: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> Message-ID: I've found that moving the probe between networks can cause this. Mine took almost 48 hours to return to normal operations. Please email me off list with your Atlas email address and I can transfer you some credits for your research :) On 16 February 2016 at 18:29, wrote: > Hi, > > I have (once again) problems with my probe (probeID: 24102). This time, it > got tagged as "system: Firewall problem suspected". The strange thing is > that I did not touch anything on my router when this happened and did not > change any other configuration... > This probe is located in Luxembourg. I now brought it to Belgium and > plugged it into the router I have here. Nothing changed. Furthermore, here > in Belgium, its 3rd light is slowly blinking, which let's suppose that it > gets tuck in the network-testing phase. > > Anybody knows how to fix this? > > (I already had some problems with that probe ("system: Hardware problem > suspected") but I could solve them thanks to a hint given by a user.) > > My worst problem is that, due to this issue, we have difficulties earning > enough credits for our research... So I would be really happy if this > problem could be solved easily :( > > Thanks! > > Sarah > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Wed Feb 17 10:53:02 2016 From: vnaumov at ripe.net (Viktor Naumov) Date: Wed, 17 Feb 2016 10:53:02 +0100 Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> References: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> Message-ID: <56C442FE.3090304@ripe.net> Hi Sarah, The tagging is done by heuristic that analyzes the probe connection attempts, SOS, timing between them and some other attributes like messages about flash drive. It has to have a quite large window for looking into data and it can take up to a few days for addressing a probe to a special controller if needed and resetting tags. In your case I see that it was disconnected at 2016-02-12 12:26:09. Up till this time your probe had no problem connecting regservers and controllers (tcp/443). After that time I see only SOS (DNS (tcp|udp)/53). That suggests the network problem with the highest probability - DNS is open but tcp/443 is closed. The lowest probability has the hardware problem (flash drive) in this case. Please use the tag as a suggestion where to begin your local diagnostics. If the network is good you can try to reinit the flash drive. wbr /vty On 2/16/16 7:29 PM, sarah.wassermann at student.ulg.ac.be wrote: > Hi, > > I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... > This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. > > Anybody knows how to fix this? > > (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) > > My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( > > Thanks! > > Sarah > From jdenhertog at ripe.net Wed Feb 17 14:54:37 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Wed, 17 Feb 2016 14:54:37 +0100 Subject: [atlas] Querying your own measurements In-Reply-To: <56A76277.7050606@ripe.net> References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> Message-ID: Hi Sebastian, Hi List, I would like to inform you that we?ve created an API endpoint with a key= query parameter on the (stil in progress) v2 API. You can get a listing of your own measurements if you include a key - with sufficient permissions - that was created by you: https://atlas.ripe.net/api/v2/measurements/my/?key= The key has to to have either ?create measurement? or ?download results of measurements? permissions. The listing will return ALL measurements belonging to the user who created the given key, not only the measurements created with that key. The resource https://atlas.ripe.net/api/v2/measurements/my/ also gives a listing of you measurements if you?re logged in and will replace the ?mine=true query parameter. The query parameter will be deprecated in v2. greetings, Jasper > On 2016-01-26 0:41, Sebastian Castro wrote: >> Hi: >> >> I'm currently testing the API to get a list of my own measurements. The >> API here reports >> >> ----------- >> Querying for Your Own Measurements >> >> In order to limit the results to your measurements only, just add a >> mine=true argument. For example: >> >> /api/v1/measurement/?mine=true >> Note that this only works if you're logged in, otherwise the result is >> the same as for any unauthenticated user. >> ----------- >> >> This seems to imply you need to manage a session within your code to get >> your own measurements, which I think violates the principle of a REST >> API. If you have the API key that provides you with access, shouldn't be >> reasonable to run the call as >> >> /api/v1/measurement/?mine=true&key=API_KEY >> >> and get a list of your own measurements? >> >> Thoughts? Am I reading the documentation in the wrong way? >> >> Thanks in advance > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From sarah.wassermann at student.ulg.ac.be Thu Feb 18 01:07:00 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Thu, 18 Feb 2016 01:07:00 +0100 (CET) Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <56C442FE.3090304@ripe.net> Message-ID: <1827467820.1518765.1455754020068.JavaMail.root@student.ulg.ac.be> Hi Viktor, The network looks good. The last time I had a problem with my probe, the flash drive was the guilty one. So, as you suggested, I will reinit the flash drive and see how it goes. I will keep you updated. Thanks for the hints! Sarah ----- Mail original ----- De: "Viktor Naumov" ?: "sarah wassermann" Cc: ripe-atlas at ripe.net Envoy?: Mercredi 17 F?vrier 2016 10:53:02 Objet: Re: [atlas] probe tagged as "system: Firewall problem suspected" Hi Sarah, The tagging is done by heuristic that analyzes the probe connection attempts, SOS, timing between them and some other attributes like messages about flash drive. It has to have a quite large window for looking into data and it can take up to a few days for addressing a probe to a special controller if needed and resetting tags. In your case I see that it was disconnected at 2016-02-12 12:26:09. Up till this time your probe had no problem connecting regservers and controllers (tcp/443). After that time I see only SOS (DNS (tcp|udp)/53). That suggests the network problem with the highest probability - DNS is open but tcp/443 is closed. The lowest probability has the hardware problem (flash drive) in this case. Please use the tag as a suggestion where to begin your local diagnostics. If the network is good you can try to reinit the flash drive. wbr /vty On 2/16/16 7:29 PM, sarah.wassermann at student.ulg.ac.be wrote: > Hi, > > I have (once again) problems with my probe (probeID: 24102). This time, it got tagged as "system: Firewall problem suspected". The strange thing is that I did not touch anything on my router when this happened and did not change any other configuration... > This probe is located in Luxembourg. I now brought it to Belgium and plugged it into the router I have here. Nothing changed. Furthermore, here in Belgium, its 3rd light is slowly blinking, which let's suppose that it gets tuck in the network-testing phase. > > Anybody knows how to fix this? > > (I already had some problems with that probe ("system: Hardware problem suspected") but I could solve them thanks to a hint given by a user.) > > My worst problem is that, due to this issue, we have difficulties earning enough credits for our research... So I would be really happy if this problem could be solved easily :( > > Thanks! > > Sarah > From mgalante at ripe.net Thu Feb 18 11:52:22 2016 From: mgalante at ripe.net (Michela Galante) Date: Thu, 18 Feb 2016 11:52:22 +0100 Subject: [atlas] Thirteen new RIPE Atlas anchors have joined the community Message-ID: <33080DFD-62C9-4D40-B1D1-8ED5E610FF64@ripe.net> Dear RIPE Atlas users, 13 new RIPE Atlas anchors have been activated during the last month and a half bringing the total number to 177. - id-jkt-as10208, hosted by PT. Millenium Internetindo in Jakarta, Indonesia and sponsored by APNIC. - ar-bue-as4270, hosted by ARIU in Buenos Aires, Argentina and sponsored by LACNIC. - de-nue-as60574, hosted by net-manager UG in Nuremberg, Germany. - uk-boh-as196745, hosted by Datacenta Hosting in Bournemouth, United Kingdom. - at-vie-as30971, hosted by nic.at in Vienna, Austria. - uk-lon-as6908, hosted by Six Degrees Group in London, United Kingdom. - nl-utc-as1103, second anchor hosted by SURFnet, in Utrecht, Netherlands. - Two anchors hosted by INX-ZA/Internet Service Providers' Association of South Africa: za-jnb-as37474 in Johannesburg and za-umr-as37668 in Umhlanga, South Africa. - ru-led-as43317, hosted by Fishnet Communications in Saint Petersburg, Russia. - nl-dro-as12414, hosted by Solcon Internetdiensten N.V. in Dronten, Netherlands - de-drs-as42699, hosted by managedhosting.de GmbH in Dresden, Germany. - fo-hyv-as15389, hosted by P/F Telefonverkid in Hoyvik, Faroe Islands. The map of all anchor locations is available at: https://atlas.ripe.net/anchors/map/ You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ And here are the logos and links to hosting companies: https://atlas.ripe.net/get-involved/community/#!tab-anchor-sponsors We are still accepting new applications from organisations interested in hosting a RIPE Atlas anchor. 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 more organisations that want to host a RIPE Atlas anchor but don?t have the necessary funding. To learn more about sponsoring an anchor, please contact us at mcb at ripe.net To apply for your own RIPE Atlas anchor: https://atlas.ripe.net/get-involved/become-an-anchor-host/ For any other questions, please contact us at atlas at ripe.net Regards, Michela Galante Measurements Community Building RIPE NCC From BECHA at ripe.net Thu Feb 18 15:35:11 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 18 Feb 2016 15:35:11 +0100 Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> References: <757190819.997328.1455647378364.JavaMail.root@student.ulg.ac.be> Message-ID: <56C5D69F.7070908@ripe.net> Hi Sarah, all, On 16-feb.-16 19:29, sarah.wassermann at student.ulg.ac.be wrote: > (I already had some problems with that probe ("system: Hardware > problem suspected") but I could solve them thanks to a hint given by > a user.) Thanks for keeping your probe alive - it will help increase the coverage in Belgium, and enable other users to ask for the measurements from Belgian point of view! > My worst problem is that, due to this issue, we have difficulties > earning enough credits for our research... We will reply to your message off-the-list about extra credits. Usually, we are quite generous when it comes to supporting students & researchers with credits to spend when producing papers. Regards, Vesna From hank at efes.iucc.ac.il Thu Feb 18 21:51:03 2016 From: hank at efes.iucc.ac.il (Hank Nussbacher) Date: Thu, 18 Feb 2016 22:51:03 +0200 Subject: [atlas] Querying your own measurements In-Reply-To: References: <56A6B292.6080508@nzrs.net.nz> <56A76277.7050606@ripe.net> Message-ID: <56C62EB7.6070709@efes.iucc.ac.il> On 17/02/2016 15:54, Jasper den Hertog wrote: Thanks. Can this documentation update be included in: https://atlas.ripe.net/docs/rest/ Under the last topic of "Querying for Your Own Measurements" Thanks, Hank > Hi Sebastian, Hi List, > > I would like to inform you that we?ve created an API endpoint with a > key= query parameter on the (stil in progress) v2 API. > > You can get a listing of your own measurements if you include a key - > with sufficient permissions - that was created by you: > > https://atlas.ripe.net/api/v2/measurements/my/?key= > > The key has to to have either ?create measurement? or ?download > results of measurements? permissions. The listing will return ALL > measurements belonging to the user who created the given key, not only > the measurements created with that key. > > The resource > > https://atlas.ripe.net/api/v2/measurements/my/ > > also gives a listing of you measurements if you?re logged in and will > replace the ?mine=true query parameter. The query parameter will be > deprecated in v2. > > greetings, > > Jasper > >> On 2016-01-26 0:41, Sebastian Castro wrote: >>> Hi: >>> >>> I'm currently testing the API to get a list of my own measurements. The >>> API here reports >>> >>> ----------- >>> Querying for Your Own Measurements >>> >>> In order to limit the results to your measurements only, just add a >>> mine=true argument. For example: >>> >>> /api/v1/measurement/?mine=true >>> Note that this only works if you're logged in, otherwise the result is >>> the same as for any unauthenticated user. >>> ----------- >>> >>> This seems to imply you need to manage a session within your code to get >>> your own measurements, which I think violates the principle of a REST >>> API. If you have the API key that provides you with access, shouldn't be >>> reasonable to run the call as >>> >>> /api/v1/measurement/?mine=true&key=API_KEY >>> >>> and get a list of your own measurements? >>> >>> Thoughts? Am I reading the documentation in the wrong way? >>> >>> Thanks in advance >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sarah.wassermann at student.ulg.ac.be Sun Feb 21 02:07:08 2016 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Sun, 21 Feb 2016 02:07:08 +0100 (CET) Subject: [atlas] probe tagged as "system: Firewall problem suspected" In-Reply-To: <56C5D69F.7070908@ripe.net> Message-ID: <2139862577.1311359.1456016828914.JavaMail.root@student.ulg.ac.be> Thank you Vesna, someone from the RIPE team contacted me to help me out! Sarah ----- Mail original ----- De: "Vesna Manojlovic" ?: "sarah wassermann" , ripe-atlas at ripe.net Envoy?: Jeudi 18 F?vrier 2016 15:35:11 Objet: Re: [atlas] probe tagged as "system: Firewall problem suspected" Hi Sarah, all, On 16-feb.-16 19:29, sarah.wassermann at student.ulg.ac.be wrote: > (I already had some problems with that probe ("system: Hardware > problem suspected") but I could solve them thanks to a hint given by > a user.) Thanks for keeping your probe alive - it will help increase the coverage in Belgium, and enable other users to ask for the measurements from Belgian point of view! > My worst problem is that, due to this issue, we have difficulties > earning enough credits for our research... We will reply to your message off-the-list about extra credits. Usually, we are quite generous when it comes to supporting students & researchers with credits to spend when producing papers. Regards, Vesna From bortzmeyer at nic.fr Mon Feb 22 11:08:20 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 22 Feb 2016 11:08:20 +0100 Subject: [atlas] Implementing structured error reports ("Problem Details for HTTP APIs")? Message-ID: <20160222100820.GA28287@nic.fr> Hello, IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem Details for HTTP APIs" which standardize structured error reports (in JSON) to add machine-readable information to HTTP error codes. Would it be a good idea to convert current Atlas reports ({"error":{"status":400,"code":104,"detail":"__all__: Your selected prefix is not covered by our network.","title":"Bad Request"}}) to the new and standard format? From robert at ripe.net Mon Feb 22 12:03:18 2016 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 22 Feb 2016 12:03:18 +0100 Subject: [atlas] Implementing structured error reports ("Problem Details for HTTP APIs")? In-Reply-To: <20160222100820.GA28287@nic.fr> References: <20160222100820.GA28287@nic.fr> Message-ID: <56CAEAF6.80504@ripe.net> On 2016-02-22 11:08, Stephane Bortzmeyer wrote: > Hello, > > IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem > Details for HTTP APIs" which standardize structured error reports (in > JSON) to add machine-readable information to HTTP error codes. > > Would it be a good idea to convert current Atlas reports > ({"error":{"status":400,"code":104,"detail":"__all__: Your selected > prefix is not covered by our network.","title":"Bad Request"}}) to the > new and standard format? Thanks for the heads up! We'll look at this, most likely when it actually becomes an RFC :) Regards, Robert From jdenhertog at ripe.net Mon Feb 22 12:07:18 2016 From: jdenhertog at ripe.net (Jasper den Hertog) Date: Mon, 22 Feb 2016 12:07:18 +0100 Subject: [atlas] Implementing structured error reports ("Problem Details for HTTP APIs")? In-Reply-To: <56CAEAF6.80504@ripe.net> References: <20160222100820.GA28287@nic.fr> <56CAEAF6.80504@ripe.net> Message-ID: The 'new and standard' way of structuring API requests and output is here, that I/We am/are trying to adhere to is here: http://jsonapi.org/ For errors especially: http://jsonapi.org/format/#errors greetings, Jasper > On 22 Feb 2016, at 12:03, Robert Kisteleki wrote: > > On 2016-02-22 11:08, Stephane Bortzmeyer wrote: >> Hello, >> >> IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem >> Details for HTTP APIs" which standardize structured error reports (in >> JSON) to add machine-readable information to HTTP error codes. >> >> Would it be a good idea to convert current Atlas reports >> ({"error":{"status":400,"code":104,"detail":"__all__: Your selected >> prefix is not covered by our network.","title":"Bad Request"}}) to the >> new and standard format? > > Thanks for the heads up! We'll look at this, most likely when it actually > becomes an RFC :) > > Regards, > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2619 bytes Desc: not available URL: From bortzmeyer at nic.fr Mon Feb 22 12:10:58 2016 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 22 Feb 2016 12:10:58 +0100 Subject: [atlas] Implementing structured error reports ("Problem Details for HTTP APIs")? In-Reply-To: References: <20160222100820.GA28287@nic.fr> <56CAEAF6.80504@ripe.net> Message-ID: <20160222111058.GA6331@nic.fr> On Mon, Feb 22, 2016 at 12:07:18PM +0100, Jasper den Hertog wrote a message of 142 lines which said: > The 'new and standard' way of structuring API requests and output is > here, that I/We am/are trying to adhere to is here: I don't know if it was mentioned at the IETF during the discussion before the approval of draft-ietf-appsawg-http-problem but it is annoying there are two standards... [Insert mandatory xkcd picture on standards.] From BECHA at ripe.net Thu Feb 25 15:57:01 2016 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 25 Feb 2016 15:57:01 +0100 Subject: [atlas] RIPE Atlas Interface Hackathon, 21-22 May, Copenhagen Message-ID: <56CF163D.5040104@ripe.net> Dear colleagues, Calling all front-end developers, UI designers, network operators and other enthusiastic coders! The next RIPE Atlas hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=list-atlas *The application deadline is 23 March* Please note that we are unfortunately unable to provide travel or accommodation funding. We look forward to seeing you there! Regards, Vesna and the RIPE Atlas Team From gboonie at gmail.com Mon Feb 29 16:12:06 2016 From: gboonie at gmail.com (dave) Date: Mon, 29 Feb 2016 16:12:06 +0100 Subject: [atlas] Ping option DF Message-ID: Hi, It seems atlas sends out ping with fragmentation allowed. Why is there no option to enable DF? Thanks, Dave. From philip.homburg at ripe.net Mon Feb 29 16:21:01 2016 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 29 Feb 2016 16:21:01 +0100 Subject: [atlas] Ping option DF In-Reply-To: References: Message-ID: <56D461DD.1050103@ripe.net> On 2016/02/29 16:12 , dave wrote: > It seems atlas sends out ping with fragmentation allowed. Why is there no option to enable DF? Hi Dave, As far as I know, there never was a request for such an option. Note that traceroute does have this option and if you the set the start hop high enough, it almost behaves like ping. If you have a use case that needs this to be in ping, then please let us know. Philip