From rm at romanrm.net Mon Apr 7 13:45:52 2014 From: rm at romanrm.net (Roman Mamedov) Date: Mon, 7 Apr 2014 17:45:52 +0600 Subject: [atlas] Probe IPs are public? Message-ID: <20140407174552.48754f93@natsu> Hello, I was under impression RIPE tries to somewhat anonymize probe information that's displayed publicly, e.g. only showing the probe IP address information down to the subnet or AS level on the maps, providing the option to use "Obfuscated DNS entry", etc. But on the public stats pages e.g. here: https://stat.ripe.net/widget/atlas-probes#w.resource=DE (+ "switch to table view") I am able to see both IPv4 and IPv6 addresses of many or most probes without even having to log-in; is that intended? Also what is the point of choosing to use the Obfuscated DNS option if the probe IPs are available in the clear anyway. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From gordslater at gmail.com Mon Apr 7 20:01:02 2014 From: gordslater at gmail.com (Gord Slater) Date: Mon, 7 Apr 2014 19:01:02 +0100 Subject: [atlas] Probe IPs are public? In-Reply-To: <20140407174552.48754f93@natsu> References: <20140407174552.48754f93@natsu> Message-ID: On 7 April 2014 12:45, Roman Mamedov wrote: > > But on the public stats pages e.g. here: > https://stat.ripe.net/widget/atlas-probes#w.resource=DE (+ "switch to > table view") > I am able to see both IPv4 and IPv6 addresses of many or most probes > without > even having to log-in; is that intended? My own probe isn't show in the table for the UK, so maybe it's based on a probe-holder's option somewhere? That may be wrong though, becuase y probe was down yesterday for maintenance window, though is up now, just not for 24h yet. I could be very wrong, just a hunch. Gord -- sent via Gmail web interface, so please excuse my gross neglect of Netiquette -------------- next part -------------- An HTML attachment was scrubbed... URL: From christian.teuschel at ripe.net Mon Apr 7 21:31:52 2014 From: christian.teuschel at ripe.net (Christian Teuschel) Date: Mon, 07 Apr 2014 21:31:52 +0200 Subject: [atlas] Probe IPs are public? In-Reply-To: <20140407174552.48754f93@natsu> References: <20140407174552.48754f93@natsu> Message-ID: <5342FD28.8060706@ripe.net> Hi Roman, On 07/04/14 13:45, Roman Mamedov wrote: > Hello, > > I was under impression RIPE tries to somewhat anonymize probe information > that's displayed publicly, e.g. only showing the probe IP address information > down to the subnet or AS level on the maps, providing the option to use > "Obfuscated DNS entry", etc. > Indeed, that is true for private probes as well as their measurements. > But on the public stats pages e.g. here: > https://stat.ripe.net/widget/atlas-probes#w.resource=DE (+ "switch to table view") > I am able to see both IPv4 and IPv6 addresses of many or most probes without > even having to log-in; is that intended? Also what is the point of choosing to > use the Obfuscated DNS option if the probe IPs are available in the clear > anyway. > For a private probe you will only see the probe's ID and the ASN but not the IP address. Best regards, Christian Teuschel -------------- next part -------------- A non-text attachment was scrubbed... Name: christian_teuschel.vcf Type: text/x-vcard Size: 342 bytes Desc: not available URL: From dgabad at gmail.com Tue Apr 8 11:12:33 2014 From: dgabad at gmail.com (Daniel Gomez) Date: Tue, 8 Apr 2014 11:12:33 +0200 Subject: [atlas] Using ripe data results on publications? Message-ID: Good Morning everyone, What is the policy about using ripe atlas results on articles and publications? We know atlas is a great infrastructure to perform measurements, but we can find on them , i.e. traceroute, private IPs from atlas hosts networks. I know there is a lot of people on this list concerned about making public some information. Are atlas results open to share and so the probes information? Greetings, Daniel Gomez -------------- next part -------------- An HTML attachment was scrubbed... URL: From BECHA at ripe.net Tue Apr 8 16:06:21 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 08 Apr 2014 16:06:21 +0200 Subject: [atlas] Probe IPs are public? In-Reply-To: <20140407174552.48754f93@natsu> References: <20140407174552.48754f93@natsu> Message-ID: <5344025D.7060708@ripe.net> Dear Roman, all, On 07-apr.-14 13:45, Roman Mamedov wrote: > Hello, > > I was under impression RIPE tries to somewhat anonymize probe information > that's displayed publicly, e.g. only showing the probe IP address information > down to the subnet or AS level on the maps, providing the option to use > "Obfuscated DNS entry", etc. > > But on the public stats pages e.g. here: > https://stat.ripe.net/widget/atlas-probes#w.resource=DE (+ "switch to table view") > I am able to see both IPv4 and IPv6 addresses of many or most probes without > even having to log-in; is that intended? > As my colleague pointed out already, we display all network-related information about public probes (with the exception of personal data of the probe host). Hosts can choose to not mark their probe public, however, this does not make the probe "private", nor does it hide all the networking-related information in the measurement results involving that probe. You can find out what is the difference between the data presented about public and not-public probes in this RIPE Labs article: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public > Also what is the point of choosing to use the Obfuscated DNS option > if the probe IPs are available in the clear anyway. These are two different use cases, and different levels of trying to hide your probe data. Obfuscated DNS is used if you do not want the hostname for the probe to be generated by us, based on the probe-ID, and therefore predictable, even if you do not mark your probe as public. But, indeed, IP address of the probe will be visible *in the measurements results* even if the probe is not marked public. The only difference is that the probes not marked public will not be _listed_ in our tolls - both RIPE Atlas web interfaces, and RIPEstat. We still encourage users to keep the defaults (public), since the goal of the RIPE Atlas is to share measurements results, for the benefit of the whole community. We are working on producing more documentation based on the above article, and based on the results of the discussion with the community, as summarized in the massages to this & MAT-wg mailing lists: https://www.ripe.net/ripe/mail/archives/mat-wg/2014-March/000436.html https://www.ripe.net/ripe/mail/archives/ripe-atlas/2014-March/001359.html Please let me know if you have any further questions. Regards, Vesna From BECHA at ripe.net Tue Apr 8 16:20:39 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 08 Apr 2014 16:20:39 +0200 Subject: [atlas] Using ripe data results on publications? In-Reply-To: References: Message-ID: <534405B7.7010709@ripe.net> Dear Daniel, On 08-apr.-14 11:12, Daniel Gomez wrote: > Good Morning everyone, > > What is the policy about using ripe atlas results on articles and > publications? > Anyone is free to use the data provided by RIPE Atlas, if the data is either marked "public" by the users, or obtainable as part of network information returned by measurements results. (see below) If you and other researchers or operators are using RIPE Atlas data in articles or publications, RIPE NCC would appreciate if you acknowledge the source as RIPE Atlas, including the link to atlas.ripe.net . We can provide you with a boilerplate text, if needed. > We know atlas is a great infrastructure to perform measurements, but we > can find on them , i.e. traceroute, private IPs from atlas hosts > networks. I know there is a lot of people on this list concerned about > making public some information. > > Are atlas results open to share and so the probes information? There was an extensive discussion on this topic with the community of RIPE Atlas users, and others interested in measurements and tools, in the previous months. Results of that discussion are for now documented in the RIPE Labs article and a reply to the mailing lists: https://labs.ripe.net/Members/becha/proposing-making-ripe-atlas-data-more-public https://www.ripe.net/ripe/mail/archives/mat-wg/2014-March/000436.html https://www.ripe.net/ripe/mail/archives/ripe-atlas/2014-March/001359.html In short: - goal of RIPE Atlas is to provide measurements data for the RIPE NCC members, RIPE Atlas users, network operators, researchers and general public (global Internet community). - RIPE NCC strongly encourages publication of measurement data - users of RIPE Atlas have a possibility to mark their probes and measurements *not* public - RIPE NCC provides documentation that clearly states what information about probe network details and measurements results are visible, and to whom. - users personal details are always kept private. I hope this answers your question, and otherwise, please let me know how can I be of help. Regards, Vesna Manojlovic From phw at nymity.ch Fri Apr 11 07:51:15 2014 From: phw at nymity.ch (Philipp Winter) Date: Thu, 10 Apr 2014 23:51:15 -0600 Subject: [atlas] "Invalid group id" for Restful API? Message-ID: <20140411055115.GA23089@nymity.ch> I'm trying to create a measurement using Atlas' Restful API [1]. Before that, I created an API key for measurement creation. Using my API key, when executing the simple example shown in [1], the server tells me: > {"error": {"code": 104, "message": "group: Invalid group id"}} I get the same error code with different JSON-formatted queries. Any ideas what's going on here? [1] https://atlas.ripe.net/docs/measurement-creation-api/ Cheers, Philipp From collin at averysmallbird.com Fri Apr 11 08:05:21 2014 From: collin at averysmallbird.com (Collin Anderson) Date: Fri, 11 Apr 2014 02:05:21 -0400 Subject: [atlas] "Invalid group id" for Restful API? In-Reply-To: <20140411055115.GA23089@nymity.ch> References: <20140411055115.GA23089@nymity.ch> Message-ID: I have also actually started to receive the same error Thursday using scripts that worked the day before, as well as even attempting the "My First Measurement" query on the documentation. On Fri, Apr 11, 2014 at 1:51 AM, Philipp Winter wrote: > I'm trying to create a measurement using Atlas' Restful API [1]. Before > that, > I created an API key for measurement creation. Using my API key, when > executing the simple example shown in [1], the server tells me: > > > {"error": {"code": 104, "message": "group: Invalid group id"}} > > I get the same error code with different JSON-formatted queries. Any ideas > what's going on here? > > [1] https://atlas.ripe.net/docs/measurement-creation-api/ > > Cheers, > Philipp > > -- *Collin David Anderson* averysmallbird.com | @cda | Washington, D.C. -------------- next part -------------- An HTML attachment was scrubbed... URL: From v.bajpai at jacobs-university.de Fri Apr 11 09:44:25 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 11 Apr 2014 07:44:25 +0000 Subject: [atlas] "Invalid group id" for Restful API? In-Reply-To: References: <20140411055115.GA23089@nymity.ch> Message-ID: <884B41F9-EBBF-4711-8F89-837ADA21745B@jacobs-university.de> On 11 Apr 2014, at 08:05, Collin Anderson wrote: > I have also actually started to receive the same error Thursday using > scripts that worked the day before, as well as even attempting the ?My > First Measurement" query on the documentation. Same issue here. Although, I can confirm that the API was working on Wednesday April 9, 2014. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dquinn at ripe.net Fri Apr 11 11:29:50 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 11 Apr 2014 10:29:50 +0100 Subject: [atlas] "Invalid group id" for Restful API? In-Reply-To: <884B41F9-EBBF-4711-8F89-837ADA21745B@jacobs-university.de> References: <20140411055115.GA23089@nymity.ch> <884B41F9-EBBF-4711-8F89-837ADA21745B@jacobs-university.de> Message-ID: <5347B60E.8060403@ripe.net> Sorry everyone, this was a bug that I introduced into the API yesterday and have (hopefully) addressed as of this morning. If anyone sees this happen again, feel free to drop a line to atlas at ripe.net and someone will fix it quick. From v.bajpai at jacobs-university.de Fri Apr 11 11:33:57 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Fri, 11 Apr 2014 09:33:57 +0000 Subject: [atlas] "Invalid group id" for Restful API? In-Reply-To: <5347B60E.8060403@ripe.net> References: <20140411055115.GA23089@nymity.ch> <884B41F9-EBBF-4711-8F89-837ADA21745B@jacobs-university.de> <5347B60E.8060403@ripe.net> Message-ID: <89116838-8642-41CC-9453-E0AD25AC2508@jacobs-university.de> On 11 Apr 2014, at 11:29, Daniel Quinn wrote: > Sorry everyone, this was a bug that I introduced into the API yesterday > and have (hopefully) addressed as of this morning. If anyone sees this > happen again, feel free to drop a line to atlas at ripe.net and someone > will fix it quick. I can confirm that it?s working now. Thank you for a quick action on this Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From royaen at cs.unm.edu Mon Apr 14 11:48:47 2014 From: royaen at cs.unm.edu (Roya Ensafi) Date: Mon, 14 Apr 2014 03:48:47 -0600 Subject: [atlas] Related to Rip Atlas Credit System Message-ID: Hi all, Considering RIPE Atlas credit system, ping and tracerout unit cost calculations are tricky. It closely depends on number of packets in train and size of the packets. Based on [1], predicted cost of a traceroute measurement with sent packet size of 2040 and 3 as number of packets (detail arguments are bellow) should be 10*3*(int(2040/1500)+1) = 90 (refer to [1]). However, predicted cost calculated by RIPE server is 120. After looking at available JavaScript, we couldn't find the predicted cost calculation. It sounds like calculation happens on server side and then the the value is returned. Is it possible to check the server code i.e. is the cost function calculation on server side publicly available? Thanks, Roya Enasfi [1]: https://atlas.ripe.net/docs/credits Details for a traceroute measurement : (Per result: 120.0 credits, Estimated total cost: 120 credits) Arguments: (Interval: 900 seconds, Resolve on probe: No, First hop: 1, #packets: 3, Don't fragment: True, Max hops: 32, Tcp: True,Paris: 16, Timeout resp.(ms): 4000, Port: 80, Size: 2040) From mgalante at ripe.net Mon Apr 14 14:11:54 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 14 Apr 2014 15:11:54 +0300 Subject: [atlas] APNIC (AU) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called au-bne-as4608 and it is hosted by APNIC in Brisbane, Australia. This is the second anchor hosted by an RIR on behalf of the RIPE NCC. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From vnaumov at ripe.net Mon Apr 14 14:51:52 2014 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 14 Apr 2014 14:51:52 +0200 Subject: [atlas] Related to Rip Atlas Credit System In-Reply-To: References: Message-ID: <534BD9E8.2010903@ripe.net> Hi Roya, I cannot reproduce your values 10*3*(int(2040/1500)+1) equals 60 but not 90. One-off measurement result costs twice more than recurring one. In this case you get 120. I just found that it is not covered in the docs. Sorry and thanks for pointing! Victor Naumov On 4/14/14, 11:48 AM, Roya Ensafi wrote: > Hi all, > > Considering RIPE Atlas credit system, ping and tracerout unit cost > calculations are tricky. It closely depends on number of packets in > train and size of the packets. Based on [1], predicted cost of a > traceroute measurement with sent packet size of 2040 and 3 as number > of packets (detail arguments are bellow) should be > 10*3*(int(2040/1500)+1) = 90 (refer to [1]). However, predicted cost > calculated by RIPE server is 120. After looking at available > JavaScript, we couldn't find the predicted cost calculation. It sounds > like calculation happens on server side and then the the value is > returned. Is it possible to check the server code i.e. is the cost > function calculation on server side publicly available? > > Thanks, > Roya Enasfi > > [1]: https://atlas.ripe.net/docs/credits > > Details for a traceroute measurement : (Per result: 120.0 credits, > Estimated total cost: 120 credits) > Arguments: (Interval: 900 seconds, Resolve on probe: No, First hop: 1, > #packets: 3, Don't fragment: True, Max hops: 32, Tcp: True,Paris: 16, > Timeout resp.(ms): 4000, Port: 80, Size: 2040) > From v.bajpai at jacobs-university.de Tue Apr 15 14:38:51 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 15 Apr 2014 12:38:51 +0000 Subject: [atlas] v2 in anchorv2 Message-ID: <668CEB69-79E6-435F-A52E-2F3389409CF1@jacobs-university.de> Hello, We have a RIPE atlas anchor question. Can you please tell us the reason for using v2 in anchorv2? We went to [2], but that doesn?t exist. We also searched but couldn?t find documentation on this. [1] http://anchorv2.ripe.net [2] http://anchorv1.ripe.net PS: We understand what RIPE atlas anchors do :-) Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From cpetrie at ripe.net Tue Apr 15 14:57:17 2014 From: cpetrie at ripe.net (Colin Petrie) Date: Tue, 15 Apr 2014 14:57:17 +0200 Subject: [atlas] v2 in anchorv2 In-Reply-To: <668CEB69-79E6-435F-A52E-2F3389409CF1@jacobs-university.de> References: <668CEB69-79E6-435F-A52E-2F3389409CF1@jacobs-university.de> Message-ID: <534D2CAD.7000008@ripe.net> Hi, On 15/04/14 14:38, Bajpai, Vaibhav wrote: > We have a RIPE atlas anchor question. Can you please tell us the > reason for using v2 in anchorv2? We went to [2], but that doesn?t exist. > We also searched but couldn?t find documentation on this. The V2 anchors are the current production versions of the Anchor (Soekris hardware), whereas the V1 anchors are the boxes (Dell PowerEdge servers) that existed during the pilot phase of the Anchor service (technically, probe IDs 6001 - 6017) We put the V2 site up to identify the boxes in case someone finds them and doesn't know what they are (there are similar probev1, probev2, probev3 sites as well) - the URL is printed on the front panel of the V2 anchors. The only reasons that there is no V1 anchor site is because: 1) The V1 anchors were part of the initial pilot, before the anchor service went into production. 2) The V1 anchors are just Dell PowerEdge servers that don't look any different from any other Dell PowerEdge. 3) The V1 anchors do not have a URL printed on them, to point anyone to a V1 website :-) Hope this clarifies! Regards, Colin -- Colin Petrie Systems Engineer RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 881 bytes Desc: OpenPGP digital signature URL: From v.bajpai at jacobs-university.de Wed Apr 16 13:41:16 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Wed, 16 Apr 2014 11:41:16 +0000 Subject: [atlas] one-off traceroute and interval parameter Message-ID: <0FCDD87D-F221-490B-BBB7-D9F76EF4571E@jacobs-university.de> Hello, Traceroute UDMs include an interval parameter. If I provision a one-off traceroute UDM via the GUI wizard, the interval field should get disabled no? Once the measurement is completed, the general information tab for the UDM now shows the interval for a one-off measurement as 900s. PS: We understand the interval parameter may have made no difference to the actual measurement. This is more of a bug report for visual side of things. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From v.bajpai at jacobs-university.de Mon Apr 21 12:38:27 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Mon, 21 Apr 2014 10:38:27 +0000 Subject: [atlas] network coverage and probe API Message-ID: Hello, The network coverage page [1] shows around 10K+ registered probes. However, if I call the probe API [2], the total_count field shows 8K probes. Probe objects also have is_public field, so I assume the API counts both public and private probes. There is also a status field, so I assume the API counts connected, disconnected and abandoned probes as well. What am I missing? [1] https://atlas.ripe.net/results/maps/network-coverage [2] https://atlas.ripe.net/api/v1/probe Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dquinn at ripe.net Tue Apr 22 10:59:33 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 22 Apr 2014 09:59:33 +0100 Subject: [atlas] network coverage and probe API In-Reply-To: References: Message-ID: <53562F75.9080405@ripe.net> On Mon 21 Apr 2014 11:38:27 BST, Bajpai, Vaibhav wrote: > What am I missing? I think it's just how you're reading the chart, which is probably more a failing of the chart than your perception of it. The yellow bars on the chart represent the *registered users*, while the blue bars represent the *active probes*. As you can see the active probes appear to be just over 5000, which makes sense as this only counts the probes online at the time the chart was generated. It's on my list to clean up that chart, and break up the bars into sub-groups rather than stacked like they are now, but until then I hope this explanation will suffice. From v.bajpai at jacobs-university.de Tue Apr 22 11:16:55 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 22 Apr 2014 09:16:55 +0000 Subject: [atlas] network coverage and probe API In-Reply-To: <53562F75.9080405@ripe.net> References: <53562F75.9080405@ripe.net> Message-ID: Hello Daniel, On 22 Apr 2014, at 10:59, Daniel Quinn wrote: > On Mon 21 Apr 2014 11:38:27 BST, Bajpai, Vaibhav wrote: >> What am I missing? > > I think it's just how you're reading the chart, which is probably more > a failing of the chart than your perception of it. The yellow bars on > the chart represent the *registered users*, Who are registered users? - who have registered a RIPE account via? https://access.ripe.net - who registered to receive a probe irrespective of whether it?s online? > while the blue bars represent the *active probes*. As you can see the > active probes appear to be just over 5000, which makes sense as this > only counts the probes online at the time the chart was generated. Yep, this syncs with the API. However, the geographical distribution plot uses the term, ?connected probes?, but the stacked plot below uses the term ?active probes?. What is the difference between connected and active probes? > It's on my list to clean up that chart, and break up the bars into > sub-groups rather than stacked like they are now, but until then I hope > this explanation will suffice. It would be nice to have an associated table with hard numbers. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dquinn at ripe.net Tue Apr 22 12:02:41 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 22 Apr 2014 11:02:41 +0100 Subject: [atlas] network coverage and probe API In-Reply-To: References: <53562F75.9080405@ripe.net> Message-ID: <53563E41.8080507@ripe.net> On Tue 22 Apr 2014 10:16:55 BST, Bajpai, Vaibhav wrote: > Who are registered users? > - who have registered a RIPE account via? https://access.ripe.net > - who registered to receive a probe irrespective of whether it?s online? A registered user, in the context of RIPE Atlas is a user who has registered a RIPE account via https://access.ripe.net/ AND has visited the Atlas site at lease once while they're logged in. > However, the geographical distribution plot uses the term, ?connected probes?, > but the stacked plot below uses the term ?active probes?. > What is the difference between connected and active probes? Yeah that was just poor choice of names at the time that that page was created. I've since brought them in line so now they both say "connected probes". If you do a refresh on the coverage page you'll see :-) From v.bajpai at jacobs-university.de Tue Apr 22 14:03:15 2014 From: v.bajpai at jacobs-university.de (Bajpai, Vaibhav) Date: Tue, 22 Apr 2014 12:03:15 +0000 Subject: [atlas] network coverage and probe API In-Reply-To: <53563E41.8080507@ripe.net> References: <53562F75.9080405@ripe.net> <53563E41.8080507@ripe.net> Message-ID: <9D66D89C-D238-4678-A91A-3000BFD23DF3@jacobs-university.de> On 22 Apr 2014, at 12:02, Daniel Quinn wrote: > On Tue 22 Apr 2014 10:16:55 BST, Bajpai, Vaibhav wrote: >> Who are registered users? >> - who have registered a RIPE account via? https://access.ripe.net >> - who registered to receive a probe irrespective of whether it?s online? > > A registered user, in the context of RIPE Atlas is a user who has > registered a RIPE account via https://access.ripe.net/ AND has visited > the Atlas site at lease once while they're logged in. Aha! This definition is difficult to guess. It would be nice to have ^ description on the network coverage webpage. >> However, the geographical distribution plot uses the term, ?connected probes?, >> but the stacked plot below uses the term ?active probes?. >> What is the difference between connected and active probes? > > Yeah that was just poor choice of names at the time that that page was > created. I've since brought them in line so now they both say > "connected probes". If you do a refresh on the coverage page you'll > see :-) Thanks for a quick action on this. Best, Vaibhav ----------------------------------------------------- Vaibhav Bajpai Research I, Room 86 Computer Networks and Distributed Systems (CNDS) Lab School of Engineering and Sciences Jacobs University Bremen, Germany www.vaibhavbajpai.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 496 bytes Desc: Message signed with OpenPGP using GPGMail URL: From colinj at mx5.org.uk Tue Apr 22 14:21:16 2014 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 22 Apr 2014 13:21:16 +0100 Subject: [atlas] home probe now active again In-Reply-To: <9D66D89C-D238-4678-A91A-3000BFD23DF3@jacobs-university.de> References: <53562F75.9080405@ripe.net> <53563E41.8080507@ripe.net> <9D66D89C-D238-4678-A91A-3000BFD23DF3@jacobs-university.de> Message-ID: <3FDE178F-CBBE-46AD-BF68-7453EC84F31E@mx5.org.uk> Dear all at RIPE, hope you all had a good easter break. I moved home after Xmas and finally managed to get FTTC for home internet. I have plugged probe back in and I think working again How does one check it is alive and working again ? probe id 2317 Does it take a few days for ripe status pages to update themselves ? Colin From inigo at infornografia.net Tue Apr 22 14:55:36 2014 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Tue, 22 Apr 2014 14:55:36 +0200 Subject: [atlas] home probe now active again In-Reply-To: <3FDE178F-CBBE-46AD-BF68-7453EC84F31E@mx5.org.uk> References: <53562F75.9080405@ripe.net> <53563E41.8080507@ripe.net> <9D66D89C-D238-4678-A91A-3000BFD23DF3@jacobs-university.de> <3FDE178F-CBBE-46AD-BF68-7453EC84F31E@mx5.org.uk> Message-ID: On Tue, Apr 22, 2014 at 2:21 PM, Colin Johnston wrote: > Dear all at RIPE, hope you all had a good easter break. > > I moved home after Xmas and finally managed to get FTTC for home internet. > > I have plugged probe back in and I think working again > > How does one check it is alive and working again ? > > probe id 2317 You could use the Probe API [1]: https://atlas.ripe.net/api/v1/probe/2317/?format=json returns: { "address_v4": "86.153.136.154", "address_v6": null, "asn_v4": 2856, "asn_v6": null, "country_code": "GB", "id": 2317, "is_anchor": false, "is_public": true, "latitude": 53.4805, "longitude": -2.2525, "prefix_v4": "86.128.0.0/11", "prefix_v6": null, "status": 1, "status_name": "Connected", "status_since": 1398169190 } You should also be able to log in to your Atlas pages and see the status of your probes. HTH, [1] https://atlas.ripe.net/docs/rest/#probe > Does it take a few days for ripe status pages to update themselves ? > > > Colin > > -- "If you want to go fast, go alone. If you want to go far, go together." From BECHA at ripe.net Wed Apr 23 09:45:46 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 23 Apr 2014 09:45:46 +0200 Subject: [atlas] home probe now active again In-Reply-To: <3FDE178F-CBBE-46AD-BF68-7453EC84F31E@mx5.org.uk> References: <53562F75.9080405@ripe.net> <53563E41.8080507@ripe.net> <9D66D89C-D238-4678-A91A-3000BFD23DF3@jacobs-university.de> <3FDE178F-CBBE-46AD-BF68-7453EC84F31E@mx5.org.uk> Message-ID: <53576FAA.7020402@ripe.net> Hi, in addition to what Inigo said... On 22-apr.-14 14:21, Colin Johnston wrote: > Dear all at RIPE, hope you all had a good easter break. > > I moved home after Xmas and finally managed to get FTTC for home internet. > > I have plugged probe back in and I think working again > > How does one check it is alive and working again ? > > probe id 2317 > ... your probe page is here: https://atlas.ripe.net/probes/2317/ > Does it take a few days for ripe status pages to update themselves ? > normally it should not... It says here that your probe was up last for 19 hours. That would mean it got activated y'day at 5am Can you please check this page to see if all is ok? Thank you for taking part in RIPE Atlas! Regards, Vesna > > Colin > > > From cobusv at gmail.com Thu Apr 24 21:51:01 2014 From: cobusv at gmail.com (Cobus Viljoen) Date: Thu, 24 Apr 2014 21:51:01 +0200 Subject: [atlas] V3 Probes Message-ID: Hi Guys, wonder if anyone can tell me where i'm going wrong. but i have received these probes and i cant seem to get them working. they have been registered, but leaving them connected just doesn't show up on the site under my probes. they are getting ip's via dhcp and have access to the internet so i cant really see why they are not showing up any advise would be greatly appreciated Cobus. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Fri Apr 25 09:59:49 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 25 Apr 2014 09:59:49 +0200 Subject: [atlas] V3 Probes In-Reply-To: References: Message-ID: <535A15F5.1090504@ripe.net> On 2014.04.24. 21:51, Cobus Viljoen wrote: > Hi Guys, > > wonder if anyone can tell me where i'm going wrong. but i have received > these probes and i cant seem to get them working. > > they have been registered, but leaving them connected just doesn't show up > on the site under my probes. > > they are getting ip's via dhcp and have access to the internet so i cant > really see why they are not showing up > > any advise would be greatly appreciated > > Cobus. Hello, Generally speaking, as long as they get a working IP(v4) address using DHCP, and the Internet connection is unfiltered (NATs are OK), they should be fine. We verify each and every one of them before shipping, so the chance of being dead on arrival is very small. Please let us know the probe IDs in a mail to atlas at ripe.net and we can check if we see any life signs on our end. Regards, Robert From mgalante at ripe.net Mon Apr 28 13:59:15 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 28 Apr 2014 13:59:15 +0200 Subject: [atlas] SuperNetwork (CZ) has joined RIPE Atlas anchors Message-ID: <8D812D1F-F134-40AE-81FB-65531DA01203@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called cz-prg-as39392 and it is hosted by SuperNetwork in Prague, Czech Republic. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From mgalante at ripe.net Tue Apr 29 14:11:07 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 29 Apr 2014 14:11:07 +0200 Subject: [atlas] ADP (FR) has joined RIPE Atlas anchors Message-ID: Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called fr-tin-as196670 and it is hosted by ADP in Pantin, France. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Measurements Community Building Team RIPE NCC mcb at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: