From robert at ripe.net Fri May 2 14:52:17 2014 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 02 May 2014 14:52:17 +0200 Subject: [atlas] Internal issues this morning Message-ID: <53639501.1080600@ripe.net> Dear All, This morning we had internal difficulties in the system, which caused a slowly responding system in general, and in some cases failures when trying to get to data or scheduling new measurements. System operations are now back to normal. We have identified the root cause for the issue and will implement mitigations for it. Sorry for the inconvenience this may have caused, Robert Kisteleki RIPE NCC From mgalante at ripe.net Mon May 5 10:10:09 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 5 May 2014 10:10:09 +0200 Subject: [atlas] =?iso-8859-1?q?_Universit=E9_catholique_de_Louvain_=28BE?= =?iso-8859-1?q?=29_has_joined_RIPE_Atlas_anchors?= Message-ID: <0AFB8B07-3281-4F80-91CF-935DC347982F@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 be-lln-as2611 and it is hosted by the Universit? catholique de Louvain in Louvain-la-Neuve, Belgium. Congratulations to the Universit? catholique de Louvain! This is the first anchor in Belgium! 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 ivom at rijwind.be Mon May 5 15:15:52 2014 From: ivom at rijwind.be (Ivo van den Maagdenberg) Date: Mon, 05 May 2014 15:15:52 +0200 Subject: [atlas] Change of emailaddress/loginname for atlas Message-ID: <53678F08.4010703@rijwind.be> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi people, The login to ripe-atlas is tied to an email adres, I'd like to change that very address. How is a change of emailaddress/loginname organised? I can't seem to find the way under https://atlas.ripe.net/my-atlas/ The FAQ https://atlas.ripe.net/about/faq/ doesn't mention it neither. Kind regards, Ivo -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTZ48IAAoJEO8w8Dsjf0uUd0MH/3s9DQ/P4GLBs+Z+EbC++S7Z lxzfBgsF46CEsZjJTGG1KlFcuXGS1OUnCm6SrhMUAGOmHBZ/9jIlYtn7yWkc9uaL ZtMUFQ0x7ViDr7GY6HFWiGtbnO8Oi/Trh5DSHVOKFKpyeXgvK85L6nMesBkVKWmF A/i8f1KuTNB8bTAcNEeX5a3MsPzIOvI5k2Xq6HavuTUyWsxVlLUL3NSrc8Oba07d 6JleHQvjJl6UO6GNT0v8HhZaMlxLZ2ACzKm4sYvBJzrqJZ4KphFUvvulrYz3xKa9 YUTEFaBywwWFY/8mqsUS01asuMv6LeTRTGwZu++FAlETbFiqEElURo5dbEKiqRM= =FWOv -----END PGP SIGNATURE----- From robert at ripe.net Mon May 5 15:53:19 2014 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 05 May 2014 15:53:19 +0200 Subject: [atlas] Change of emailaddress/loginname for atlas In-Reply-To: <53678F08.4010703@rijwind.be> References: <53678F08.4010703@rijwind.be> Message-ID: <536797CF.8030404@ripe.net> Hello, On 2014.05.05. 15:15, Ivo van den Maagdenberg wrote: > Hi people, > > The login to ripe-atlas is tied to an email adres, I'd like to change > that very address. How is a change of emailaddress/loginname organised? > I can't seem to find the way under https://atlas.ripe.net/my-atlas/ Almost correct: the RIPE Atlas logins are tied to RIPE NCC Access credentials, RIPE Atlas is just accessing data stored in that. It's possible to change your email address in Access What you should do is: 1. Go to https://access.ripe.net/ and log in if needed 2. Change your email 3. Log out and in again -- to be sure 4. Visit RIPE Atlas Once you do this, the changes should be recognised. Hope this helps, Robert > The FAQ https://atlas.ripe.net/about/faq/ doesn't mention it neither. > > Kind regards, Ivo > > From BECHA at ripe.net Fri May 9 11:32:11 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 09 May 2014 11:32:11 +0200 Subject: [atlas] Feature you asked for: "latest results" API Message-ID: <536CA09B.1000900@ripe.net> Dear RIPE Atlas community, last week we enabled a new feature that quite a few people had an interest in: an API that lets you get up to 10 most recent results of any measurement: https://atlas.ripe.net/docs/measurement-latest-api/ We wrote an article with more details: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-results-api-and-parsing-library From the article: "This new feature could come in useful in a number of different situations, such as: - Creating a widget for a website that monitors a specific result in near real time, such as ping results from 100 probes around the world toward your own website - Monitoring your network by setting up an alert based on the average measurement result from the past hour - Staying aware of a major network event, such as an Internet outage in a certain region - DNS monitoring of your own domain, with configurable measurements using 10 RIPE Atlas anchors - Prototyping a script using RIPE Atlas data" Please let us know if you find other creative uses for this new API! If you develop custom code for configuring the results of this API, please share it at the GitHub RIPE Atlas Community repository: https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib We would love to hear your success stories! Regards, Vesna From mgalante at ripe.net Fri May 9 14:27:20 2014 From: mgalante at ripe.net (Michela Galante) Date: Fri, 9 May 2014 14:27:20 +0200 Subject: [atlas] DENIC eG (DE) 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 de-fra-as8763 and it is hosted by DENIC eG in Frankfurt, Germany. 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 dquinn at ripe.net Mon May 12 12:10:01 2014 From: dquinn at ripe.net (dquinn) Date: Mon, 12 May 2014 12:10:01 +0200 Subject: [atlas] Introducing: the new result parsing library (Sagan) Message-ID: Hi everyone, in advance of the RIPE Meeting, I thought I'd let you all know about the new parsing library we've developed for use against measurement results. This was mentioned in a recent RIPE Labs article[1] but I thought it worth detailing here for those of you who aren't avid Labs followers. The idea is that you run every result you get through this handy Python library and out comes programmer-friendly Python objects. It supports the various changes in result format over time, and even does some of the heavy lifting for you like calculating ping median rtt, parsing the DNS abuf, or counting the traceroute hops. The project code is published on GitHub[2], and pull requests are welcome. Installation can be done via Pypi[3], and documentation is included in the module and available online[4] as well If you have any questions feel free to post to the list and one of us will see what we can do for you. [1] RIPE Labs article: https://labs.ripe.net/Members/suzanne_taylor_muzzin/ripe-atlas-latest-results-api-and-parsing-library [2] Project: https://github.com/RIPE-NCC/ripe.atlas.sagan [3] Pypi: https://pypi.python.org/pypi/ripe.atlas.sagan/ [4] Documentation: https://atlas.ripe.net/docs/sagan/ From BECHA at ripe.net Wed May 14 11:45:24 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 14 May 2014 11:45:24 +0200 Subject: [atlas] RIPE Atlas use cases and more In-Reply-To: <84E84DC2-C90D-4790-A63C-9AF46C88E044@ripe.net> References: <84E84DC2-C90D-4790-A63C-9AF46C88E044@ripe.net> Message-ID: <53733B34.2090402@ripe.net> Dear colleagues, There have been a lot of great examples recently of how RIPE Atlas can be used to investigate network events, troubleshoot problems, explore how the Internet behaves, and more. Some of the topics include: - Investigating customer complaints about slow servers - Comparing TCP and UDP Response Times of DNS Root Servers - Discovering Path MTU black holes on the Internet We?ve collected all of these user experiences, analyses, papers and presentations in one place on RIPE Labs, in order to make it easy to discover how others are making use of the RIPE Atlas network - and maybe spark some ideas about how you can, too. https://labs.ripe.net/atlas/user-experiences If you have your own story about how you?ve used RIPE Atlas, we want to hear from you! Please get in touch with us at atlas at ripe.net , or on this list. Kind regards, Vesna Manojlovic Measurements Community Building RIPE NCC From dgabad at gmail.com Wed May 14 15:47:45 2014 From: dgabad at gmail.com (Daniel Gomez) Date: Wed, 14 May 2014 15:47:45 +0200 Subject: [atlas] Atlas API and IPv6 Message-ID: Hi All, Could it be that the API at atlas-ui.ripe.net is since last night not ipv6 reachable? We are not sure if it was before, but we had to change today the DNS Name to the ipv4, in order for the requests to work. Thanks in advance, Daniel El 14/05/2014 11:45, "Vesna Manojlovic" escribi?: > Dear colleagues, > > There have been a lot of great examples recently of how RIPE Atlas can be > used to investigate network events, troubleshoot problems, explore how the > Internet behaves, and more. Some of the topics include: > > - Investigating customer complaints about slow servers > - Comparing TCP and UDP Response Times of DNS Root Servers > - Discovering Path MTU black holes on the Internet > > We?ve collected all of these user experiences, analyses, papers and > presentations in one place on RIPE Labs, in order to make it easy to > discover how others are making use of the RIPE Atlas network - and maybe > spark some ideas about how you can, too. > > https://labs.ripe.net/atlas/user-experiences > > If you have your own story about how you?ve used RIPE Atlas, we want to > hear from you! Please get in touch with us at atlas at ripe.net , > or on this list. > > Kind regards, > > Vesna Manojlovic > Measurements Community Building > RIPE NCC > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed May 14 16:37:45 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 14 May 2014 16:37:45 +0200 Subject: [atlas] Atlas API and IPv6 In-Reply-To: References: Message-ID: <53737FB9.2090706@ripe.net> Hello, We're not aware of any changes on our end, and according to the system itself (since it can measure itself :-) it's reachable over IPv6. (Also note: we recommend using the https://atlas.ripe.net/ name, other aliases may result in certificate name mismatch errors.) Regards, Robert On 2014.05.14. 15:47, Daniel Gomez wrote: > Hi All, > > Could it be that the API at atlas-ui.ripe.net is > since last night not ipv6 reachable? > > We are not sure if it was before, but we had to change today the DNS Name to > the ipv4, in order for the requests to work. > > Thanks in advance, > > Daniel > > El 14/05/2014 11:45, "Vesna Manojlovic" > escribi?: > > Dear colleagues, > > There have been a lot of great examples recently of how RIPE Atlas can > be used to investigate network events, troubleshoot problems, explore > how the Internet behaves, and more. Some of the topics include: > > - Investigating customer complaints about slow servers > - Comparing TCP and UDP Response Times of DNS Root Servers > - Discovering Path MTU black holes on the Internet > > We?ve collected all of these user experiences, analyses, papers and > presentations in one place on RIPE Labs, in order to make it easy to > discover how others are making use of the RIPE Atlas network - and maybe > spark some ideas about how you can, too. > > https://labs.ripe.net/atlas/__user-experiences > > > If you have your own story about how you?ve used RIPE Atlas, we want to > hear from you! Please get in touch with us at atlas at ripe.net > , > or on this list. > > Kind regards, > > Vesna Manojlovic > Measurements Community Building > RIPE NCC > > > > From jared at puck.nether.net Sat May 17 19:03:00 2014 From: jared at puck.nether.net (Jared Mauch) Date: Sat, 17 May 2014 13:03:00 -0400 Subject: [atlas] Some UDM comments Message-ID: I'm working on creating some measurements and haven't quite moved into using the API yet and wanted to provide some feedback: 1) When creating a UDM, when it's scheduled but not yet assigned to probe(s), it would be nice to be able to increase the # of probes. 2) When creating a UDM and specifying source ASN, you can't type in that box and must use the pull-down. Related to #1, if you increase probes to (eg: 5) it resets to 1 after you select the ASN. 3) When stopping a UDM that is set for ongoing/no-end, it would be nice to have a 'stop now' vs having to pick the next 15 minute interval. In theory the system could auto-populate this. 4) I do like the probes/map/seismograph view, is it possible to provide a direct-link to these public UDMs without logging-in? (I haven't looked closely so there may be a way to do this). Trying to not need to fetch the data and generate my own graphs... 5) If I see a probe that is behaving poorly, eg: UDM 1665566 Probe# 3925, should I be providing feedback on this to others? I'm working on a Nx(N-1) measurement of these ASNs to determine which have persistent congestion that can be measured via RIPE Atlas if that is of interest to others. 174 209 701 1239 1299 2828 2914 3320 3257 3356 3491 3561 5511 6453 6461 7018 Those interested in this, I will be able to send you a list of UDMs to look at which are public. - Jared From tim at haitabu.net Sat May 17 19:12:13 2014 From: tim at haitabu.net (Tim Kleefass) Date: Sat, 17 May 2014 19:12:13 +0200 Subject: [atlas] Some UDM comments In-Reply-To: References: Message-ID: <5377986D.3070904@haitabu.net> On 17.05.2014 7:03 PM, Jared Mauch wrote: > 4) I do like the probes/map/seismograph view, is it possible to > provide a direct-link to these public UDMs without logging-in? (I > haven't looked closely so there may be a way to do this). Trying to > not need to fetch the data and generate my own graphs... I would be interested in having this, too! Cheers, Tim From f4w at echo.emu.st Sat May 17 20:24:16 2014 From: f4w at echo.emu.st (Mark Delany) Date: 17 May 2014 18:24:16 +0000 Subject: [atlas] Taking the fuzz our of client cache results Message-ID: <20140517182416.3733.qmail@f5-external.bushwire.net> Hi. I've been running some DNS queries using the probe caches with a view to understanding the latency between the probe cache and the authoritative that I'm interested in. The problem is that there is a fair degree of uncertainty in these measurements because the cache may have to first resolve higher level names in the hierarchy and there is no way of knowing whether the cache had to do this or not. If my query is for www.example.com, it's quite possible that the cache has to first resolve example.com prior to sending the final query for www. This means the measurement may include the cost of getting an answer from .com *and* getting the answer from example.com... sometimes. Depending on how popular example.com is and what other clients are doing with the cache. I'm wondering if there is a way in which we can eliminate this fuzziness? The most obvious way to do this is to ensure the cache is pre-primed with every answer up to, but not including the target name. If we assume the measurement request includes a new "prime cache" flag, then in the presence of that flag the probe could first run a query for something like: cacheprime.example.com substituting the first label with some other value. Alternatively it could first run an NS query for example.com A third alternative is that the creator of the measurement could nominate the priming query as they will have the knowledge needed to get it right. A forth alternative is that the probe could run the query twice - with a nominated delay that is known to exceed the TTL of the target query. In all cases, as soon as the priming query is complete, the probe then runs the target query with a high degree of confidence that the cache only needs to make one round trip to the authoritative server. There is still a small probability that the results will be fuzzy for a variety of reasons, multiple cache choices, anycast caches, super-busy caches, multiple probes using the same cache, but that probability will be very low. Also, a pre-primed query would presumably cost twice as many credits since it's really running two queries. Do others think a primed cache query is of use? And, are there ways of achieving this already? Mark. From philip.homburg at ripe.net Sat May 17 20:59:09 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Sat, 17 May 2014 20:59:09 +0200 Subject: [atlas] Taking the fuzz our of client cache results In-Reply-To: <20140517182416.3733.qmail@f5-external.bushwire.net> References: <20140517182416.3733.qmail@f5-external.bushwire.net> Message-ID: <5377B17D.8050204@ripe.net> Hi Mark, On 2014/05/17 20:24 , Mark Delany wrote: > Also, a pre-primed query would presumably cost twice as many credits since > it's really running two queries. > > Do others think a primed cache query is of use? And, are there ways of > achieving this already? I'm just focusing on what is already there. If you are using oneoffs, then just running two oneoffs a minute apart should do what you want. If you want a periodic measurement then we have an (apparently undocumented) option to prefix the query with the probe's ID and the current time. This should also give the desired effect. Philip From f4w at echo.emu.st Sat May 17 21:57:29 2014 From: f4w at echo.emu.st (Mark Delany) Date: 17 May 2014 19:57:29 +0000 Subject: [atlas] Taking the fuzz our of client cache results In-Reply-To: <5377B17D.8050204@ripe.net> References: <20140517182416.3733.qmail@f5-external.bushwire.net> <5377B17D.8050204@ripe.net> Message-ID: <20140517195729.4028.qmail@f5-external.bushwire.net> On 17May14, Philip Homburg allegedly wrote: > If you want a periodic measurement then we have an (apparently > undocumented) option to prefix the query with the probe's ID and the > current time. This should also give the desired effect. It helps a little wrt probes sharing caches, but it doesn't help with the timing being distorted by the cache having to fetch parent records. For example, the cache having to ask .com to get example.com name server details. Even if parents have long TTLs (e.g. they come out of a TLD) there is no guarantee that the parent records haven't been evicted due to caching pressure. And yes, periodic is what I should have clarified. Mark. From dquinn at ripe.net Mon May 19 12:22:55 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Mon, 19 May 2014 12:22:55 +0200 Subject: [atlas] Some UDM comments In-Reply-To: References: Message-ID: <5379DB7F.80802@ripe.net> I'll answer the ones I can. > 2) When creating a UDM and specifying source ASN, you can't type in that box and must use the pull-down. Related to #1, if you increase probes to (eg: 5) it resets to 1 after you select the ASN. We're currently working on a complete rewrite of the interface for UDM creation that will include all sorts of nifty things like autocompleting ASNs, so we've got you covered here. > 3) When stopping a UDM that is set for ongoing/no-end, it would be nice to have a 'stop now' vs having to pick the next 15 minute interval. In theory the system could auto-populate this. Currently the only way to do this is to find your measurement in the list of measurements, right-click and select "Stop". In the new version you'll be able to stop a measurement on its detail page as well. > 4) I do like the probes/map/seismograph view, is it possible to provide a direct-link to these public UDMs without logging-in? (I haven't looked closely so there may be a way to do this). Trying to not need to fetch the data and generate my own graphs... Direct-linking is currently available through a convoluted URL structure that I'd rather not share publicly for fear that it will fall into common usage. The new pages (due out in the next few months) will follow the typical structure of /measurements/MEASUREMENT_ID/#tab-name, but that's not out yet. If you really can't wait for the new pages, email me off-list and I'll hook you up with the weird way we currently handle deep linking. From robert at ripe.net Mon May 19 15:01:36 2014 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 19 May 2014 15:01:36 +0200 Subject: [atlas] Some UDM comments In-Reply-To: References: Message-ID: <537A00B0.9010606@ripe.net> Hi, > I'm working on creating some measurements and haven't quite moved into using the API yet and wanted to provide some feedback: Thanks, it's always appreciated! > 1) When creating a UDM, when it's scheduled but not yet assigned to probe(s), it would be nice to be able to increase the # of probes. This is somewhat tricky, because the answer is: it depends. If you schedule a measurement to be started in the future, then you can always just cancel the original one and schedule a new one. One can also change the set of probes for already running measurements, Although we don't recommend it because it can be very confusing when you interpret the results. > 5) If I see a probe that is behaving poorly, eg: UDM 1665566 Probe# 3925, should I be providing feedback on this to others? I believe that such bits of information could be useful. But, since they are one-to-one messages, it's probably not so useful to do them on this list :-) Would there be a need for an in-Atlas messaging service? If so, what should it allow / prevent? We have been thinking about such a thing before, but I would not want to pre-empt a useful discussion by exposing too much of our own ideas :-) Cheers, Robert From mgalante at ripe.net Mon May 19 16:01:11 2014 From: mgalante at ripe.net (Michela Galante) Date: Mon, 19 May 2014 16:01:11 +0200 Subject: [atlas] NTT Communications (US) joined RIPE Atlas anchors Message-ID: <2708892A-2FB8-4FA8-9278-86E90C7645A8@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 us-dal-as2914 and it is hosted by NTT Communications in Dallas, United States. 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 jared at puck.nether.net Mon May 19 16:05:50 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 19 May 2014 10:05:50 -0400 Subject: [atlas] Some UDM comments In-Reply-To: <5379DB7F.80802@ripe.net> References: <5379DB7F.80802@ripe.net> Message-ID: <3B0CC0EA-A68E-4280-BAF2-45C06979B828@puck.nether.net> On May 19, 2014, at 6:22 AM, Daniel Quinn wrote: > Direct-linking is currently available through a convoluted URL structure > that I'd rather not share publicly for fear that it will fall into > common usage. The new pages (due out in the next few months) will > follow the typical structure of /measurements/MEASUREMENT_ID/#tab-name, > but that's not out yet. > > If you really can't wait for the new pages, email me off-list and I'll > hook you up with the weird way we currently handle deep linking. Sure. Looking at this measurement: # 1665566 - 209->701 It seems to show that Qwest/Centurylink -> UUNet/VZ is ?congested? and seeing queueing delay at some points of the day. Same for this one: # 1665596 - 701->2914 I?m going to go finish creating these measurements later today or tomorrow (time permitting). The general idea is something like: http://www.internetpulse.net/ But with atlas probes. - Jared From jared at puck.nether.net Mon May 19 19:12:45 2014 From: jared at puck.nether.net (Jared Mauch) Date: Mon, 19 May 2014 13:12:45 -0400 Subject: [atlas] high volume IPs/anycasted? Message-ID: <545C9324-2D76-4DC8-A78C-680B2FC66D01@puck.nether.net> I have a few IPs on our network that are anycasted that I'd like to see the "9 limit" increased for, is there a proper way to do this? - Jared From klaus.mailinglists at pernau.at Tue May 20 11:32:39 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 20 May 2014 11:32:39 +0200 Subject: [atlas] Problems with DNS measurements and NSID Message-ID: <537B2137.3030206@pernau.at> Hi! Whatever I try I fail to get the nameserver id. See measurement: https://atlas.ripe.net/api/v1/measurement/1666014/ But there is no NSID in the results: https://atlas.ripe.net/api/v1/measurement/1666014/result/ Am I doing something wrong, or is there a bug? Thanks Klaus From antony at ripe.net Tue May 20 12:52:11 2014 From: antony at ripe.net (Antony Antony) Date: Tue, 20 May 2014 12:52:11 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B2137.3030206@pernau.at> References: <537B2137.3030206@pernau.at> Message-ID: <20140520105211.GA20550@puppy.ripe.net> Hi, NSID is in the result, abuf. I see it when I decode the abuf string. To decode abuf string you may use a Python script or so. https://github.com/RIPE-Atlas-Community/RIPE-Atlas-data-analysis "NSID": "tld-berlin-fra1", "OptionLength": 15 If you are using the above script better to download it as txt wget -O 1666014.txt 'https://atlas.ripe.net/api/v1/measurement/1666014/result/?format=txt' cat 1666014.txt | ./scripts/decode_abuf.py -dall -antony On Tue, May 20, 2014 at 11:32:39AM +0200, Klaus Darilion wrote: > Hi! > > Whatever I try I fail to get the nameserver id. See measurement: > https://atlas.ripe.net/api/v1/measurement/1666014/ > > But there is no NSID in the results: > https://atlas.ripe.net/api/v1/measurement/1666014/result/ > > Am I doing something wrong, or is there a bug? > > Thanks > Klaus > > From mgalante at ripe.net Tue May 20 14:15:10 2014 From: mgalante at ripe.net (Michela Galante) Date: Tue, 20 May 2014 14:15:10 +0200 Subject: [atlas] NTT Communications (US, Miami) has joined RIPE Atlas anchors Message-ID: <38B2453E-ED96-499E-81E7-4887E4EDA51E@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 us-mia-as2914 and it is hosted by NTT Communications in Miami, United States. Congratulations to NTT Communications for their second anchor online! 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 klaus.mailinglists at pernau.at Tue May 20 15:24:17 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 20 May 2014 15:24:17 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <20140520105211.GA20550@puppy.ripe.net> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> Message-ID: <537B5781.1040401@pernau.at> Thanks for the hint. Feature Request: Make NSID available in the results (without the need to parse the whole DNS packet). regards Klaus On 20.05.2014 12:52, Antony Antony wrote: > Hi, > NSID is in the result, abuf. I see it when I decode the abuf string. > To decode abuf string you may use a Python script or so. > > https://github.com/RIPE-Atlas-Community/RIPE-Atlas-data-analysis > > "NSID": "tld-berlin-fra1", "OptionLength": 15 > > If you are using the above script better to download it as txt > > wget -O 1666014.txt 'https://atlas.ripe.net/api/v1/measurement/1666014/result/?format=txt' > cat 1666014.txt | ./scripts/decode_abuf.py -dall > > -antony > > > > On Tue, May 20, 2014 at 11:32:39AM +0200, Klaus Darilion wrote: >> Hi! >> >> Whatever I try I fail to get the nameserver id. See measurement: >> https://atlas.ripe.net/api/v1/measurement/1666014/ >> >> But there is no NSID in the results: >> https://atlas.ripe.net/api/v1/measurement/1666014/result/ >> >> Am I doing something wrong, or is there a bug? >> >> Thanks >> Klaus >> >> From dquinn at ripe.net Tue May 20 15:43:33 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 20 May 2014 15:43:33 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B5781.1040401@pernau.at> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> Message-ID: <537B5C05.70005@ripe.net> > Feature Request: Make NSID available in the results (without the need to parse the whole DNS packet) In case you're using Python, you should know that if you use the new parsing library[1] the work of parsing the DNS packet and getting the NSID out is done for you: from ripe.atlas.sagan import Result result = Result("your-JSON-result-blob-here") print(result.responses[0].edns0.options[0].nsid) [1] https://github.com/RIPE-NCC/ripe.atlas.sagan/ From klaus.mailinglists at pernau.at Tue May 20 17:08:47 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 20 May 2014 17:08:47 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B5C05.70005@ripe.net> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> Message-ID: <537B6FFF.3070207@pernau.at> Hi Daniel! On 20.05.2014 15:43, Daniel Quinn wrote: >> Feature Request: Make NSID available in the results (without the need to parse the whole DNS packet) > > In case you're using Python, you should know that if you use the new > parsing library[1] the work of parsing the DNS packet and getting the > NSID out is done for you: Actually I tried it today but failed obviously due to my lack of Python. It would be great if you could add an example to the README e.g. with full result parsing: - load the json file from disk - loop over every result (json list) - print some value > from ripe.atlas.sagan import Result > result = Result("your-JSON-result-blob-here") > print(result.responses[0].edns0.options[0].nsid) Why do I have to use the responses[0] object? Can there be multiple responses with different nsids? Thanks Klaus From dquinn at ripe.net Tue May 20 17:47:26 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 20 May 2014 17:47:26 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B6FFF.3070207@pernau.at> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> Message-ID: <537B790E.5070606@ripe.net> On Tue 20 May 2014 17:08:47 CEST, Klaus Darilion wrote: Hi Daniel! Hi! Actually I tried it today but failed obviously due to my lack of Python. It would be great if you could add an example to the README e.g. with full result parsing: * load the json file from disk * loop over every result (json list) * print some value The full documentation already has a few examples that should be enough to get you going (I?ve just added some more), but here?s a breakdown of what you?re wanting: |from ripe.atlas.sagan import Result my_results_file = "/path/to/file.txt" with open(my_results_file) as results: for result in results.readlines(): parsed_result = Result.get(result) print(parsed_result.origin) | Once you have a |parsed_result|, you have access to all of the properties of that result, which are defined in the full documentation . Why do I have to use the responses[0] object? Can there be multiple responses with different nsids? In some cases, DNS results /can/ contain multiple responses. In an effort to maintain consistency for all DNS results, we opted to treat all DNS results as if they contain a list of responses ? even if that list is of only one response. This makes it easier to write scripts that make use of the object, since you always have a consistent data type in |parsed_result.responses|. I hope that helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at johnbond.org Tue May 20 18:17:05 2014 From: mail at johnbond.org (john) Date: Tue, 20 May 2014 18:17:05 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B790E.5070606@ripe.net> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> Message-ID: <537B8001.5060805@johnbond.org> Hi Daniel, On 20/05/14 17:47, Daniel Quinn wrote: > On Tue 20 May 2014 17:08:47 CEST, Klaus Darilion wrote: > In some cases, DNS results /can/ contain multiple responses. In an > effort to maintain consistency for all DNS results, we opted to treat > all DNS results as if they contain a list of responses ? even if that > list is of only one response. This makes it easier to write scripts that > make use of the object, since you always have a consistent data type in > |parsed_result.responses|. I was actually wondering about this myself. What DNS packet would contain multiple responses, considering that the response object relates to the message(s)[1] and not the individual sections. The RFC doesn't explicitly state that a transaction will only contain one message however I can't think of a situation one would send multiple messages. I suspect it is invalid and suspect or would break some implementations one where to try. Thanks John [1]http://tools.ietf.org/html/rfc1035#section-4 From dquinn at ripe.net Tue May 20 18:23:07 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 20 May 2014 18:23:07 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B8001.5060805@johnbond.org> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> <537B8001.5060805@johnbond.org> Message-ID: <537B816B.50900@ripe.net> Maybe there's some confusion here, but this multiple response business is all related to the introduction of `resultset` in firmware 4610: https://atlas.ripe.net/docs/data_struct/#v4610_dns When this firmware was introduced it became possible that instead of there being a single "result" property, a "resultset" property would exist containing a list of responses. Rather than have the library act differently for older firmware results, I opted to have a consistent behaviour. As to why this change was introduced in the first place, if there's interest I can ask Philip to respond to the list tomorrow when he's in since this is more of a question of probe behaviour rather than the parser library. From mail at johnbond.org Tue May 20 18:36:48 2014 From: mail at johnbond.org (john) Date: Tue, 20 May 2014 18:36:48 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B816B.50900@ripe.net> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> <537B8001.5060805@johnbond.org> <537B816B.50900@ripe.net> Message-ID: <537B84A0.8050000@johnbond.org> On 20/05/14 18:23, Daniel Quinn wrote: > Maybe there's some confusion here, but this multiple response business > is all related to the introduction of `resultset` in firmware 4610: > > https://atlas.ripe.net/docs/data_struct/#v4610_dns > > When this firmware was introduced it became possible that instead of > there being a single "result" property, a "resultset" property would > exist containing a list of responses. Rather than have the library act > differently for older firmware results, I opted to have a consistent > behaviour. As to why this change was introduced in the first place, if > there's interest I can ask Philip to respond to the list tomorrow when > he's in since this is more of a question of probe behaviour rather than > the parser library. > Hi Daniel, OK, I guess it might be to support retrying the query on a failure but I would be keen to get confirmation from Philip. Thanks John From philip.homburg at ripe.net Tue May 20 19:29:15 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 20 May 2014 19:29:15 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B84A0.8050000@johnbond.org> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> <537B8001.5060805@johnbond.org> <537B816B.50900@ripe.net> <537B84A0.8050000@johnbond.org> Message-ID: <537B90EB.5040900@ripe.net> On 2014/05/20 18:36 , john wrote: > On 20/05/14 18:23, Daniel Quinn wrote: >> Maybe there's some confusion here, but this multiple response business >> is all related to the introduction of `resultset` in firmware 4610: >> >> https://atlas.ripe.net/docs/data_struct/#v4610_dns >> > OK, I guess it might be to support retrying the query on a failure but I > would be keen to get confirmation from Philip. The 'normal' mode for DNS queries is that they get sent to one server. So you would get one reply each time the measurement is performed. The exception is when the measurement is to query the probe's local DNS resolvers. In that case, up to three resolvers are queried and you can get as many replies. In the past, each replies would be an independent Atlas result. However, our storage back-end cannot really handle that. So the code was changed that all three replies are grouped into a single Atlas result. Hence, in general, an Atlas DNS result can contain multiple DNS replies. But only if you select the 'use the probe's local resolvers' option. Philip From mail at johnbond.org Wed May 21 00:21:18 2014 From: mail at johnbond.org (john) Date: Wed, 21 May 2014 00:21:18 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B90EB.5040900@ripe.net> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> <537B8001.5060805@johnbond.org> <537B816B.50900@ripe.net> <537B84A0.8050000@johnbond.org> <537B90EB.5040900@ripe.net> Message-ID: <537BD55E.2020600@johnbond.org> On 20/05/14 19:29, Philip Homburg wrote: > The 'normal' mode for DNS queries is that they get sent to one server. > So you would get one reply each time the measurement is performed. > > The exception is when the measurement is to query the probe's local DNS > resolvers. In that case, up to three resolvers are queried and you can > get as many replies. > > In the past, each replies would be an independent Atlas result. However, > our storage back-end cannot really handle that. So the code was changed > that all three replies are grouped into a single Atlas result. > > Hence, in general, an Atlas DNS result can contain multiple DNS replies. > But only if you select the 'use the probe's local resolvers' option. Thanks for the clarification Philip. good to know. From Ondrej.Caletka at cesnet.cz Wed May 21 09:26:59 2014 From: Ondrej.Caletka at cesnet.cz (=?ISO-8859-2?Q?Ond=F8ej_Caletka?=) Date: Wed, 21 May 2014 09:26:59 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection Message-ID: <537C5543.3050203@cesnet.cz> Hello list, I just observed strange behaviour of one Atlas probe. It was unable to connect to the control server from a corporate network. I suspect that some IDS/IPS appliance detects and drops probe attempt to use port 443 for non-TLS traffic*. I've tested it by trying to SSH to control server from within that network and it failed. However, normal SSH to port 22 works fine. It would be nice if the probe would be able to try more ways to reach the control server, eg. first attempt on port 443, second on port 22, third on some arbitrary high port number. I know that it would be better to put the probe in front of the firewall/IPS, but this is much more complicated in many corporate networks. *) At least it doesn't do MitM on HTTPs traffic. I've checked that too. Cheers, Ond?ej Caletka -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From robert at ripe.net Wed May 21 09:48:09 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 21 May 2014 09:48:09 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537C5543.3050203@cesnet.cz> References: <537C5543.3050203@cesnet.cz> Message-ID: <537C5A39.5050004@ripe.net> On 2014.05.21. 9:26, Ond?ej Caletka wrote: > Hello list, > > I just observed strange behaviour of one Atlas probe. It was unable to > connect to the control server from a corporate network. I suspect that > some IDS/IPS appliance detects and drops probe attempt to use port 443 > for non-TLS traffic*. I've tested it by trying to SSH to control server > from within that network and it failed. However, normal SSH to port 22 > works fine. > > It would be nice if the probe would be able to try more ways to reach > the control server, eg. first attempt on port 443, second on port 22, > third on some arbitrary high port number. I know that it would be better > to put the probe in front of the firewall/IPS, but this is much more > complicated in many corporate networks. > > *) At least it doesn't do MitM on HTTPs traffic. I've checked that too. > > Cheers, > Ond?ej Caletka Hello, The probe and the infrastructure it connects to are doing mutual authentication (every actor has its own key pair for that) over SSH, meaning that if there's an appliance meddling with the traffic, the connection will fail. That's of course by design. We *could* try to fall back to other ports, but reality is that in the vast majority of the cases 443 works fine (*), and where it doesn't, other ports would very likely be blocked as well. It's difficult to justify the added complexity for the marginal benefit. Regards, Robert (*) As far as we know... We are aware of cases where it doesn't. From klaus.mailinglists at pernau.at Wed May 21 10:07:04 2014 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Wed, 21 May 2014 10:07:04 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537B790E.5070606@ripe.net> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> Message-ID: <537C5EA8.2050409@pernau.at> Hi Daniel! Thanks. Meanwhile I managed to iterate over the JSON list and print the nsid: import json from ripe.atlas.sagan import DnsResult f=open("dns-from-de-anycast.json","r") data = f.read() jdata = json.loads(data) for d in jdata: print d result = DnsResult.get(d) print(result.responses[0].edns0.options[0].nsid) print "" But the problem is if there was an error during the measurement (eg timeout), then my script terminates: {u'from': u'84.132.219.105', u'msm_id': 1666006, u'timestamp': 1400570732, u'fw': 4610, u'proto': u'UDP', u'af': 4, u'msm_name': u'Tdig', u'prb_id': 2960, u'error': {u'timeout': 5000}, u'src_addr': u'192.168.179.20', u'group_id': 1666005, u'type': u'dns', u'dst_addr': u'194.0.25.16'} Traceback (most recent call last): File "json-file.py", line 11, in print(result.responses[0].edns0.options[0].nsid) IndexError: list index out of range What is the suggested way to find out if a result is valid and exists? Thanks Klaus On 20.05.2014 17:47, Daniel Quinn wrote: > On Tue 20 May 2014 17:08:47 CEST, Klaus Darilion wrote: > > Hi Daniel! > > Hi! > > Actually I tried it today but failed obviously due to my lack of Python. > It would be great if you could add an example to the README e.g. with > full result parsing: > > * load the json file from disk > * loop over every result (json list) > * print some value > > The full documentation already has a few examples > that should be enough to > get you going (I?ve just added some more), but here?s a breakdown of > what you?re wanting: > > |from ripe.atlas.sagan import Result > > my_results_file = "/path/to/file.txt" > with open(my_results_file) as results: > for result in results.readlines(): > parsed_result = Result.get(result) > print(parsed_result.origin) > | > > Once you have a |parsed_result|, you have access to all of the > properties of that result, which are defined in the full documentation > . > > Why do I have to use the responses[0] object? Can there be multiple > responses with different nsids? > > In some cases, DNS results /can/ contain multiple responses. In an > effort to maintain consistency for all DNS results, we opted to treat > all DNS results as if they contain a list of responses ? even if that > list is of only one response. This makes it easier to write scripts that > make use of the object, since you always have a consistent data type in > |parsed_result.responses|. > > I hope that helps! > From dquinn at ripe.net Wed May 21 12:12:09 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 21 May 2014 12:12:09 +0200 Subject: [atlas] Problems with DNS measurements and NSID In-Reply-To: <537C5EA8.2050409@pernau.at> References: <537B2137.3030206@pernau.at> <20140520105211.GA20550@puppy.ripe.net> <537B5781.1040401@pernau.at> <537B5C05.70005@ripe.net> <537B6FFF.3070207@pernau.at> <537B790E.5070606@ripe.net> <537C5EA8.2050409@pernau.at> Message-ID: <537C7BF9.2000504@ripe.net> On 21/05/14 10:07, Klaus Darilion wrote: Thanks. Meanwhile I managed to iterate over the JSON list and print the nsid: ? But the problem is if there was an error during the measurement (eg timeout), then my script terminates: ? What is the suggested way to find out if a result is valid and exists? First of all, i should say thanks for working with us on this. The trouble with a parsing library is that it?s supposed to be able to handle all of the edge cases, but finding them independently is quite difficult. When you post examples to the list of result blobs that act in unexpected ways, this really helps in polishing the parser and making it more intuitive. Given that, and other comments from John regarding error handling for DNS results, I?ve added a little more code to better handle errors, so if you update Sagan to 0.1.12 (or just |git pull|), and re-run your code you?ll find that |result.is_error| is now set to |True| in your case. Additionally, if you pass |on_error=Result.ERROR_FAIL| to the parsing argument, it?ll explode with a |ResultParseError| which you can handle any way you please. So given your example, you could do something like: | result = DnsResult(d) if not result.is_error: # Do stuff | However, there?s likely cases where you might see results that /aren?t/ errors, but still don?t have any responses, or where |edns0.options| is an empty list. Unfortunately, you have to write your code to account for these, since they?re perfectly valid parsings: | result = DnsResult(d) if not result.is_error: for response in responses: if response.edns0: for option in response.edns0.options: print(option.nsid) | Note that I?m not really checking that much here, just looping over (potentially empty) lists. This keeps your code free of checks, and will make sure that it accounts for cases where the number of responses is > 1 or the number of edns0 options is > 1. But please, if you find another result blob that isn?t performing the way you?d expect, please feel free to post it here or send it to atlas-bugs at ripe.net so we can look into it and make sure that Sagan has complete coverage. -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.karrenberg at ripe.net Wed May 21 13:45:04 2014 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Wed, 21 May 2014 13:45:04 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537C5A39.5050004@ripe.net> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> Message-ID: <537C91C0.8090409@ripe.net> On 21.05.14 9:48 , Robert Kisteleki wrote: > On 2014.05.21. 9:26, Ond?ej Caletka wrote: >> Hello list, >> >> I just observed strange behaviour of one Atlas probe. It was unable to >> connect to the control server from a corporate network. I suspect that >> some IDS/IPS appliance detects and drops probe attempt to use port 443 >> for non-TLS traffic*. I've tested it by trying to SSH to control server >> from within that network and it failed. However, normal SSH to port 22 >> works fine. >> >> It would be nice if the probe would be able to try more ways to reach >> the control server, eg. first attempt on port 443, second on port 22, >> third on some arbitrary high port number. I know that it would be better >> to put the probe in front of the firewall/IPS, but this is much more >> complicated in many corporate networks. >> >> *) At least it doesn't do MitM on HTTPs traffic. I've checked that too. >> >> Cheers, >> Ond?ej Caletka > > Hello, > > The probe and the infrastructure it connects to are doing mutual > authentication (every actor has its own key pair for that) over SSH, meaning > that if there's an appliance meddling with the traffic, the connection will > fail. That's of course by design. > > We *could* try to fall back to other ports, but reality is that in the vast > majority of the cases 443 works fine (*), and where it doesn't, other ports > would very likely be blocked as well. It's difficult to justify the added > complexity for the marginal benefit. > > Regards, > Robert > > (*) As far as we know... We are aware of cases where it doesn't. It seems to me that just trying port 22 if no contact can be made on 443 should be added to the requested features list. The reason being that probes could then work in places where policy allows 22. However I agree that the priority should be low considering the small number of cases this would fix and the likelihood that measurements would be affected by middle boxes as well. Daniel From Woeber at CC.UniVie.ac.at Wed May 21 15:09:08 2014 From: Woeber at CC.UniVie.ac.at (Wilfried Woeber) Date: Wed, 21 May 2014 15:09:08 +0200 Subject: [atlas] a thought about public probe page... Message-ID: <537CA574.2030500@CC.UniVie.ac.at> I've got a small comments regarding the probes' overviw page at https://atlas.ripe.net/probes/ - for the country filter, top right, could the list of countries be sorted? Thanks, low prio :-) Wilfried. From Ondrej.Caletka at cesnet.cz Wed May 21 16:37:58 2014 From: Ondrej.Caletka at cesnet.cz (=?ISO-8859-2?Q?Ond=F8ej_Caletka?=) Date: Wed, 21 May 2014 16:37:58 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537C91C0.8090409@ripe.net> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> Message-ID: <537CBA46.4080800@cesnet.cz> Dne 21.5.2014 13:45, Daniel Karrenberg napsal(a): > It seems to me that just trying port 22 if no contact can be made on 443 > should be added to the requested features list. The reason being that > probes could then work in places where policy allows 22. However I agree > that the priority should be low considering the small number of cases > this would fix and the likelihood that measurements would be affected by > middle boxes as well. I agree completely. The only question is, what are atlas probes supposed to measure, Internet infrastructure or "eyeball" perspective of the Internet? From what I see, the objective is somewhere in the middle with probes installed both in datacentres (measuring infrastructure) as well as at users homes (measuring eyeballs). If measuring the users experience is legitimate use case, then it shouldn't be problem to have some middleboxes on the way. -- Ond?ej -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From philip.homburg at ripe.net Wed May 21 16:58:36 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 21 May 2014 16:58:36 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CBA46.4080800@cesnet.cz> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> Message-ID: <537CBF1C.1040300@ripe.net> On 2014/05/21 16:37 , Ond?ej Caletka wrote: > Dne 21.5.2014 13:45, Daniel Karrenberg napsal(a): >> It seems to me that just trying port 22 if no contact can be made on 443 >> should be added to the requested features list. The reason being that >> probes could then work in places where policy allows 22. However I agree >> that the priority should be low considering the small number of cases >> this would fix and the likelihood that measurements would be affected by >> middle boxes as well. > > I agree completely. The only question is, what are atlas probes supposed > to measure, Internet infrastructure or "eyeball" perspective of the > Internet? From what I see, the objective is somewhere in the middle with > probes installed both in datacentres (measuring infrastructure) as well > as at users homes (measuring eyeballs). > If measuring the users experience is legitimate use case, then it > shouldn't be problem to have some middleboxes on the way. My experience is that probes at users' homes just work. There are a few gotchas but most work. Probes that cause trouble are usually where somebody explicitly tried to configure something in the network, firewalls, etc. I'm curious what this firewall is trying to do. If it allows unrestricted outbound connectivity over ssh, but not ssh on port 443. What is that rule trying to protect? Philip From Ondrej.Caletka at cesnet.cz Wed May 21 17:10:15 2014 From: Ondrej.Caletka at cesnet.cz (=?ISO-8859-2?Q?Ond=F8ej_Caletka?=) Date: Wed, 21 May 2014 17:10:15 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CBF1C.1040300@ripe.net> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> <537CBF1C.1040300@ripe.net> Message-ID: <537CC1D7.6020104@cesnet.cz> Dne 21.5.2014 16:58, Philip Homburg napsal(a): > I'm curious what this firewall is trying to do. If it allows > unrestricted outbound connectivity over ssh, but not ssh on port 443. > What is that rule trying to protect? I don't think anyone ever knows. It's like with the DNS inspection modules for Cisco not allowing UDP/53 packets bigger than 512 bytes (effectively killing EDNS0 and DNSSEC) but allowing unrestricted traffic on any other UDP port :) -- Ond?ej -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5563 bytes Desc: Elektronicky podpis S/MIME URL: From mail at johnbond.org Wed May 21 17:13:13 2014 From: mail at johnbond.org (john) Date: Wed, 21 May 2014 17:13:13 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CBF1C.1040300@ripe.net> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> <537CBF1C.1040300@ripe.net> Message-ID: <537CC289.30107@johnbond.org> On 21/05/14 16:58, Philip Homburg wrote: > I'm curious what this firewall is trying to do. If it allows > unrestricted outbound connectivity over ssh, but not ssh on port 443. > What is that rule trying to protect? Its trying to prevent exactly this. A lot of exploits/malware dial home using the same assumption you do. i.e. 443 will be open. however most of the don't use ssl. With this in mind many IDS will drop anything talking on 443 that isn't ssl/tls. They also do the same protocol analysis on other ports so trying port 80 in this case is also likely to be drooped, as the traffic is not http. From philip.homburg at ripe.net Wed May 21 17:20:01 2014 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 21 May 2014 17:20:01 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CC289.30107@johnbond.org> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> <537CBF1C.1040300@ripe.net> <537CC289.30107@johnbond.org> Message-ID: <537CC421.8090705@ripe.net> On 2014/05/21 17:13 , john wrote: > On 21/05/14 16:58, Philip Homburg wrote: >> I'm curious what this firewall is trying to do. If it allows >> unrestricted outbound connectivity over ssh, but not ssh on port 443. >> What is that rule trying to protect? > Its trying to prevent exactly this. A lot of exploits/malware dial home > using the same assumption you do. i.e. 443 will be open. however most > of the don't use ssl. With this in mind many IDS will drop anything > talking on 443 that isn't ssl/tls. They also do the same protocol > analysis on other ports so trying port 80 in this case is also likely to > be drooped, as the traffic is not http. But in those setups, port 22 is usually closed. And if you really want to prevent malware from dialing home, you would have to close all other ports as well. Typically, I find port 22 closed and then port 443 wide open. So the availability of port 22 is what surprises me. Philip From mail at johnbond.org Wed May 21 17:37:44 2014 From: mail at johnbond.org (john) Date: Wed, 21 May 2014 17:37:44 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CC421.8090705@ripe.net> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> <537CBF1C.1040300@ripe.net> <537CC289.30107@johnbond.org> <537CC421.8090705@ripe.net> Message-ID: <537CC848.8050206@johnbond.org> On 21/05/14 17:20, Philip Homburg wrote: > On 2014/05/21 17:13 , john wrote: >> On 21/05/14 16:58, Philip Homburg wrote: >>> I'm curious what this firewall is trying to do. If it allows >>> unrestricted outbound connectivity over ssh, but not ssh on port 443. >>> What is that rule trying to protect? >> Its trying to prevent exactly this. A lot of exploits/malware dial home >> using the same assumption you do. i.e. 443 will be open. however most >> of the don't use ssl. With this in mind many IDS will drop anything >> talking on 443 that isn't ssl/tls. They also do the same protocol >> analysis on other ports so trying port 80 in this case is also likely to >> be drooped, as the traffic is not http. > > But in those setups, port 22 is usually closed. And if you really want > to prevent malware from dialing home, you would have to close all other > ports as well. > > Typically, I find port 22 closed and then port 443 wide open. So the > availability of port 22 is what surprises me. I agree i suspect if one has gone to this much trouble then high ports will also be closed and port 22 will be restricted to know hosts/subnets From robert at ripe.net Wed May 21 18:28:37 2014 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 21 May 2014 18:28:37 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CC848.8050206@johnbond.org> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> <537CBF1C.1040300@ripe.net> <537CC289.30107@johnbond.org> <537CC421.8090705@ripe.net> <537CC848.8050206@johnbond.org> Message-ID: <537CD435.8070701@ripe.net> On 2014.05.21. 17:37, john wrote: > On 21/05/14 17:20, Philip Homburg wrote: >> On 2014/05/21 17:13 , john wrote: >>> On 21/05/14 16:58, Philip Homburg wrote: >>>> I'm curious what this firewall is trying to do. If it allows >>>> unrestricted outbound connectivity over ssh, but not ssh on port 443. >>>> What is that rule trying to protect? >>> Its trying to prevent exactly this. A lot of exploits/malware dial home >>> using the same assumption you do. i.e. 443 will be open. however most >>> of the don't use ssl. With this in mind many IDS will drop anything >>> talking on 443 that isn't ssl/tls. They also do the same protocol >>> analysis on other ports so trying port 80 in this case is also likely to >>> be drooped, as the traffic is not http. >> >> But in those setups, port 22 is usually closed. And if you really want >> to prevent malware from dialing home, you would have to close all other >> ports as well. >> >> Typically, I find port 22 closed and then port 443 wide open. So the >> availability of port 22 is what surprises me. > I agree i suspect if one has gone to this much trouble then high ports > will also be closed and port 22 will be restricted to know hosts/subnets Which brings us back to the original point: if 443 is closed / filtered, the chances are that so is 22. (As it's almost always an explicit user action to fiddle with these.) We can spend resources researching how often this happens, what we can do about it, implementing fallback mechanisms and workarounds, use different ports or even protocols. But at the end of the day, we'd likely save only a fraction of the struggling probes. Robert From daniel at karrenberg.net Wed May 21 18:10:40 2014 From: daniel at karrenberg.net (Daniel Karrenberg) Date: Wed, 21 May 2014 18:10:40 +0200 Subject: [atlas] Probe cannot connect from behind IDS/IPS with HTTPS inspection In-Reply-To: <537CBF1C.1040300@ripe.net> References: <537C5543.3050203@cesnet.cz> <537C5A39.5050004@ripe.net> <537C91C0.8090409@ripe.net> <537CBA46.4080800@cesnet.cz> <537CBF1C.1040300@ripe.net> Message-ID: <537CD000.5050203@karrenberg.net> On 21.05.14 16:58 , Philip Homburg wrote: > ... > > I'm curious what this firewall is trying to do. If it allows > unrestricted outbound connectivity over ssh, but not ssh on port 443. > What is that rule trying to protect? That is all an interesting discussion but not all that useful. Our decision to use 443 comes from our experience/expectation that 443 is more permeable than 22. However the protocol we are running "belongs" on 22 and it is somewhat silly to not use that port when it is in fact usable. So I think it is a reasonable request to use 22 when available. Again: the relative priority of this is another question that depends on the number of cases where 22 works and 443 does not. Currently I would not expect this to happen often. But that may change as middle box silliness increases. So I suggest again to put it on the list of requests with low priority. Daniel From mail at johnbond.org Thu May 22 22:53:18 2014 From: mail at johnbond.org (john) Date: Thu, 22 May 2014 22:53:18 +0200 Subject: [atlas] Atlas Latest Message-ID: <537E63BE.3010503@johnbond.org> Hi, I have been playing with the latest API over the past few days and it seems like there may be a cache in place. Is this the case? if so how long is it? Thanks John From dquinn at ripe.net Fri May 23 12:14:38 2014 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 23 May 2014 12:14:38 +0200 Subject: [atlas] Atlas Latest In-Reply-To: <537E63BE.3010503@johnbond.org> References: <537E63BE.3010503@johnbond.org> Message-ID: <537F1F8E.5010107@ripe.net> I'd remembered putting a cache on it, but couldn't remember the value 'till I checked just now: it's set to 1hour which is admittedly awfully high. I can drop it down to 5min, but I'd hate to go lower than that. From mail at johnbond.org Fri May 23 12:25:02 2014 From: mail at johnbond.org (john) Date: Fri, 23 May 2014 12:25:02 +0200 Subject: [atlas] Atlas Latest In-Reply-To: <537F1F8E.5010107@ripe.net> References: <537E63BE.3010503@johnbond.org> <537F1F8E.5010107@ripe.net> Message-ID: <537F21FE.7010807@johnbond.org> On 23/05/14 12:14, Daniel Quinn wrote: > I'd remembered putting a cache on it, but couldn't remember the value > 'till I checked just now: it's set to 1hour which is admittedly awfully > high. I can drop it down to 5min, but I'd hate to go lower than that. Hi Daniel, 5 minutes would be fine for my use. Thanks John From BECHA at ripe.net Mon May 26 14:25:00 2014 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 26 May 2014 14:25:00 +0200 Subject: [atlas] RIPE Atlas use case on RIPE Labs: Evaluating new IXP peers Message-ID: <5383329C.3070605@ripe.net> Dear colleagues, in this article Daniel Gomez explain how RIPE Atlas helped to evaluate new synaix's peering partners within an Internet Exchange Point and how this helped to improve customer services. Please find more details on RIPE Labs: https://labs.ripe.net/Members/daniel_gomez/basic-evaluation-of-new-ixp-peering-partners-with-ripe-atlas-and-zabbix Kind regards, Vesna Manojlovic RIPE NCC From bortzmeyer at nic.fr Mon May 26 16:50:27 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 26 May 2014 16:50:27 +0200 Subject: [atlas] Introducing: the new result parsing library (Sagan) In-Reply-To: References: Message-ID: <20140526145027.GA5652@nic.fr> On Mon, May 12, 2014 at 12:10:01PM +0200, dquinn wrote a message of 28 lines which said: > The idea is that you run every result you get through this handy > Python library and out comes programmer-friendly Python objects. It > supports the various changes in result format over time, and even > does some of the heavy lifting for you like calculating ping median > rtt, parsing the DNS abuf, or counting the traceroute hops. Unfortunately, it seems it have been made for brains brighter than mine. I tried the following script: import sys from ripe.atlas.sagan import PingResult if len(sys.argv) <= 1: raise Exception("Usage: %s filename ..." % sys.argv[0]) for filename in sys.argv[1:]: results = open(filename).read() result = PingResult(results) print filename print result.rtt_median print "" And I give it the result of a measurement (#1666654 if you want to check): Traceback (most recent call last): File "sagan-ping.py", line 19, in result = PingResult(results) File "/usr/local/lib/python2.7/dist-packages/ripe.atlas.sagan-0.1.14-py2.7.egg/ripe/atlas/sagan/ping.py", line 54, in __init__ Result.__init__(self, data, **kwargs) File "/usr/local/lib/python2.7/dist-packages/ripe.atlas.sagan-0.1.14-py2.7.egg/ripe/atlas/sagan/base.py", line 118, in __init__ "measurement: {raw_data}".format(raw_data=self.raw_data)) ripe.atlas.sagan.base.ResultParseError: This does not look like a RIPE Atlas measurement: [{u'af': 6, u'prb_id': 10031, u'result': [{u'rtt': 56.194}, {u'rtt': 54.074}, {u'rtt': 54.47}], u'ttl': 54, u'avg': 54.9126666667, u'size': 48, u'from': u'2a01:1e8:e13f:0:a2f3:c1ff:fec4:5fab', u'proto': u'ICMP', u'timestamp': 1401114806, u'dup': 0, u'type': u'ping', u'sent': 3, u'msm_id': 1666654, u'fw': 4610, u'max': 56.194, u'step': None, u'src_addr': u'2a01:1e8:e13f:0:a2f3:c1ff:fec4:5fab', u'rcvd': 3, u'msm_name': u'Ping', u'lts': 16, u'dst_name': u'2001:4b98:dc0:41:216:3eff:fece:1902', u'min': 54.074, u'group_id': 1666654, u'dst_addr': u'2001:4b98:dc0 [...] The JSON file (attached) does seem correct. I also tried with pre-parsing: for filename in sys.argv[1:]: results = json.loads(open(filename).read()) result = PingResult(results) print filename and got the same result. From bortzmeyer at nic.fr Mon May 26 17:35:46 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 26 May 2014 17:35:46 +0200 Subject: [atlas] Introducing: the new result parsing library (Sagan) In-Reply-To: <538359FB.9070408@ripe.net> References: <20140526145027.GA5652@nic.fr> <538359FB.9070408@ripe.net> Message-ID: <20140526153546.GA10482@nic.fr> On Mon, May 26, 2014 at 05:12:59PM +0200, Daniel Quinn wrote a message of 141 lines which said: > The key is to remember that you need to break up that Great Big File > into separate result blobs, either by looping over a fragmented > file's lines, or by parsing the whole JSON file into memory first > and parsing out each result. OK, thanks, it works now. From daniel.quinn at ripe.net Mon May 26 17:12:59 2014 From: daniel.quinn at ripe.net (Daniel Quinn) Date: Mon, 26 May 2014 17:12:59 +0200 Subject: [atlas] Introducing: the new result parsing library (Sagan) In-Reply-To: <20140526145027.GA5652@nic.fr> References: <20140526145027.GA5652@nic.fr> Message-ID: <538359FB.9070408@ripe.net> On 26/05/14 16:50, Stephane Bortzmeyer wrote: import sys from ripe.atlas.sagan import PingResult if len(sys.argv) <= 1: raise Exception("Usage: %s filename ..." % sys.argv[0]) for filename in sys.argv[1:]: results = open(filename).read() result = PingResult(results) print filename print result.rtt_median print "" The thing to remember is that this is a /result/ parser, not a /result*s*/ parser. In other words, you have to pass each result individually into Sagan for parsing and it will in turn return a Python object for that single result. Your code here takes /the entire file/, multiple results in a JSON list, and dumps it into Sagan, which explodes because you're passing multiple results. Generally, this is bad practise since it's entirely possible that your one file could be bigger than a few GB, which would definitely crash your system if you tried to load the entire file into memory. Instead, I suggest the following: |for filename in sys.argv[1:]: with open(filename) as my_results: for result in json.loads(my_results): result = Result.get(result) print(result.rtt_median) | or skip the manual JSON parsing by using the fragmented file format (|?format=txt|): | for filename in sys.argv[1:]: with open(filename) as my_results: for result in my_results.readlines(): result = Result.get(result) print(result.rtt_median) | The key is to remember that you need to break up that Great Big File into separate result blobs, either by looping over a fragmented file's lines, or by parsing the whole JSON file into memory first and parsing out each result. That step is up to you. Sagan only takes over once you've got a single result to work with. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roussillat at gmail.com Tue May 27 09:50:28 2014 From: roussillat at gmail.com (Vincent Roussillat) Date: Tue, 27 May 2014 09:50:28 +0200 Subject: [atlas] Unable to connect my probe Message-ID: Hello I've received my probe #16969 yesterday, registered it and tried to connect it behind my Orange Livebox here in France. It doesn't succeed to get connected and even doesn't get an IP from the DHCP server of my box (which delivers IP address to my other devices). I have tried this morning to connect it to another Internet access, at work and this failed too. Led #4 remains blinking. I can see in MyAtlas interface that the probe got connected just after the first boot, as I can see to request to DNS servers logged in the interface. May be, an upgrade began and got interrupted, leaving the probe in a strange state, I don't know... Anyway, what should I do now ? Request another probe ? Send this one back to the RIPE ? If so, where should I send it ? Regards. From robert at ripe.net Tue May 27 10:02:45 2014 From: robert at ripe.net (Robert Kisteleki) Date: Tue, 27 May 2014 10:02:45 +0200 Subject: [atlas] Unable to connect my probe In-Reply-To: References: Message-ID: <538446A5.8090102@ripe.net> Hello, In general, for issues like this please write to the ticketised customer services address atlas at ripe.net instead of this public list. We'll contact you privately about the details of this specific issue. Regards, Robert On 2014.05.27. 9:50, Vincent Roussillat wrote: > Hello > > I've received my probe #16969 yesterday, registered it and tried to > connect it behind my Orange Livebox here in France. > It doesn't succeed to get connected and even doesn't get an IP from > the DHCP server of my box (which delivers IP address to my other > devices). > I have tried this morning to connect it to another Internet access, at > work and this failed too. > Led #4 remains blinking. > > I can see in MyAtlas interface that the probe got connected just after > the first boot, as I can see to request to DNS servers logged in the > interface. > May be, an upgrade began and got interrupted, leaving the probe in a > strange state, I don't know... > > Anyway, what should I do now ? Request another probe ? Send this one > back to the RIPE ? > If so, where should I send it ? > > Regards. > > From bortzmeyer at nic.fr Tue May 27 17:32:40 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 27 May 2014 17:32:40 +0200 Subject: [atlas] Feature you asked for: "latest results" API In-Reply-To: <536CA09B.1000900@ripe.net> References: <536CA09B.1000900@ripe.net> Message-ID: <20140527153239.GB8799@nic.fr> On Fri, May 09, 2014 at 11:32:11AM +0200, Vesna Manojlovic wrote a message of 42 lines which said: > last week we enabled a new feature that quite a few people had an > interest in: an API that lets you get up to 10 most recent results > of any measurement: The Python package RIPEAtlas has been updated to use this new feature: measurement = RIPEAtlas.Measurement(data=None, id=int(sys.argv[1])) results = measurement.results(latest=1) for result in results: From calderm at usc.edu Wed May 28 07:48:13 2014 From: calderm at usc.edu (Matt Calder) Date: Tue, 27 May 2014 22:48:13 -0700 Subject: [atlas] Measurement creation tools and library Message-ID: Hi, I'm announcing a set of Python-based command-line tools/library for measurement creation available at https://github.com/USC-NSL/ripe-atlas. Since the focus is heavily on assisting measurement creation, I think that it should compliment Sagan nicely. It has been slowly under development for a while now but still has plenty of room to grow in supporting all of the options for different measurement types. Thanks, Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Wed May 28 11:43:45 2014 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 28 May 2014 11:43:45 +0200 Subject: [atlas] Measurement creation tools and library In-Reply-To: References: Message-ID: <20140528094345.GA13198@nic.fr> On Tue, May 27, 2014 at 10:48:13PM -0700, Matt Calder wrote a message of 31 lines which said: > I'm announcing a set of Python-based command-line tools/library for > measurement creation available at > https://github.com/USC-NSL/ripe-atlas. Cool. Could you summarize in what way they are different from the tools existing at specially the RIPEAtlas module? From mgalante at ripe.net Wed May 28 13:39:26 2014 From: mgalante at ripe.net (Michela Galante) Date: Wed, 28 May 2014 13:39:26 +0200 Subject: [atlas] Bogal AB (SE) 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 se-got-as50168 and it is hosted by Bogal AB in Gothenburg, Sweden. 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 gilles.pion at gmail.com Wed May 28 22:03:07 2014 From: gilles.pion at gmail.com (Gilles Pion) Date: Wed, 28 May 2014 22:03:07 +0200 Subject: [atlas] Where is "My probe" tab? Message-ID: Hello, Just received my probe today, Registered it, plugged it, all leds seem correct. I've followed the instruction on page https://atlas.ripe.net/get-involved/become-a-host/ where one can read: "Once we see that your probe is connected to the RIPE Atlas infrastructure, you'll be able to see it listed on the Public Probes page and, when you are logged in to the RIPE Atlas website, it will appear under the "My Probes" tab on that page. But, although logged on the web site I'm unable to find this "My Probes" tab on the "Public Probes" page Could someone help? -- Gilles From the.lists at mgm51.com Wed May 28 22:33:43 2014 From: the.lists at mgm51.com (Mike.) Date: Wed, 28 May 2014 16:33:43 -0400 Subject: [atlas] Where is "My probe" tab? In-Reply-To: References: Message-ID: <201405281633430457.018FD3CA@smtp.24cl.home> On 5/28/2014 at 10:03 PM Gilles Pion wrote: |Hello, | |Just received my probe today, | |Registered it, plugged it, all leds seem correct. | |I've followed the instruction on page |https://atlas.ripe.net/get-involved/become-a-host/ where one can read: | |"Once we see that your probe is connected to the RIPE Atlas |infrastructure, you'll be able to see it listed on the Public Probes |page and, when you are logged in to the RIPE Atlas website, it will |appear under the "My Probes" tab on that page. | |But, although logged on the web site I'm unable to find this "My |Probes" tab on the "Public Probes" page | |Could someone help? ============= Once you log in, just to the left of the Logout menu item you should see a menu item that contains "My Atlas: nnn" with your name in the place of the nnn. Hover on that menu item, and a menu drops down. >From that drop down menu, select "Probes". You should then go to a page that has two tabs: My Probes and Public Probes. Click on My Probes. From gilles.pion at gmail.com Wed May 28 22:37:11 2014 From: gilles.pion at gmail.com (Gilles Pion) Date: Wed, 28 May 2014 22:37:11 +0200 Subject: [atlas] Where is "My probe" tab? In-Reply-To: <201405281633430457.018FD3CA@smtp.24cl.home> References: <201405281633430457.018FD3CA@smtp.24cl.home> Message-ID: 2014-05-28 22:33 GMT+02:00 Mike. : > Once you log in, just to the left of the Logout menu item you should > see a menu item that contains "My Atlas: nnn" with your name in the > place of the nnn. > > Hover on that menu item, and a menu drops down. > > From that drop down menu, select "Probes". > > You should then go to a page that has two tabs: My Probes and Public > Probes. > > Click on My Probes. Now I have the two tabs, but a few minutes sooner I only had the "Public Probes" tab I guess my probe was not fully initialized and connected. Seem to be fixed. -- Gilles