From robert at ripe.net Fri Dec 1 10:45:08 2017 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 1 Dec 2017 10:45:08 +0100 Subject: [atlas] Effect of "Resolve on Probe"-option In-Reply-To: <531ABB2A-F7CD-4482-A3F7-9C8EF9C5E0DF@timwattenberg.de> References: <531ABB2A-F7CD-4482-A3F7-9C8EF9C5E0DF@timwattenberg.de> Message-ID: On 2017-11-30 20:27, Tim Wattenberg wrote: > Hi everyone, > > I think I don?t quite understand the effect of the ?Resolve on Probe? option when creating a measurement. The form says it forces the probe to do DNS resolution, the API reference says that it indicates that a name should be resolved (using DNS) on the probe otherwise it will be resolved on the RIPE Atlas servers. > > Could someone explain what this means for example if I have a simple measurement for querying the A record of a given domain via the probe?s resolvers? > > Thanks, Tim Hi, When you measure something given with a DNS name and leave this option to its default settings, then the DNS resolution happens once, in the infrastructure (somewhere in Amsterdam, NL), and the probes are told to measure towards the resolved *IP*. This is more efficient, prevents DNS errors on the edges, but only works if DNS can only give one answer. If you turn on "resolve on probe", then the probes get to measure the *name* you entered, and do the DNS resolution themselves every single time they measure. This has a somewhat higher chance of failure, but it's needed if the resolved IP depends on the location of the vantage point. Hope this helps, Robert From benc at hawaga.org.uk Fri Dec 1 12:05:45 2017 From: benc at hawaga.org.uk (Ben Clifford) Date: Fri, 1 Dec 2017 11:05:45 +0000 (UTC) Subject: [atlas] map distinction between "no data yet" and "timeout" Message-ID: I was just trying to get a map view for a nameserver that appeared to not be responding to people in some geographical areas. I fired off a measurement across a load of probes and get a map back. In my particular case, the result I'm looking for is whether a response came back from the target server at all. But the map doesn't distinguish between probes that haven't measured yet, and probes that have attempted a measurement but timed out, as far as I can tell. -- From mail at timwattenberg.de Fri Dec 1 15:44:22 2017 From: mail at timwattenberg.de (Tim Wattenberg) Date: Fri, 1 Dec 2017 15:44:22 +0100 Subject: [atlas] Effect of "Resolve on Probe"-option In-Reply-To: References: <531ABB2A-F7CD-4482-A3F7-9C8EF9C5E0DF@timwattenberg.de> Message-ID: Robert, thanks for your explanations. I now do understand this for all measurements exept for those of type DNS. DNS measurements with a central resolver somehow seem not that useful to me. Am I missing the use case here? Context: I want to measure the consistency of DNS records or how they are seen inside the probes networks. In my measurement I activated the option to use the probes resolver(s) and left the option to resolve on the probe deactivated. Does this simulate the scenario of a client asking its local DNS resolver (e.g. assigned by DHCP)? Thanks, Tim Tim Wattenberg mail at timwattenberg.de +49 1578 8248731 2017-12-01 10:45 GMT+01:00 Robert Kisteleki : > > On 2017-11-30 20:27, Tim Wattenberg wrote: > > Hi everyone, > > > > I think I don?t quite understand the effect of the ?Resolve on Probe? > option when creating a measurement. The form says it forces the probe to do > DNS resolution, the API reference says that it indicates that a name should > be resolved (using DNS) on the probe otherwise it will be resolved on the > RIPE Atlas servers. > > > > Could someone explain what this means for example if I have a simple > measurement for querying the A record of a given domain via the probe?s > resolvers? > > > > Thanks, Tim > > Hi, > > When you measure something given with a DNS name and leave this option > to its default settings, then the DNS resolution happens once, in the > infrastructure (somewhere in Amsterdam, NL), and the probes are told to > measure towards the resolved *IP*. This is more efficient, prevents DNS > errors on the edges, but only works if DNS can only give one answer. > > If you turn on "resolve on probe", then the probes get to measure the > *name* you entered, and do the DNS resolution themselves every single > time they measure. This has a somewhat higher chance of failure, but > it's needed if the resolved IP depends on the location of the vantage > point. > > Hope this helps, > Robert > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jordi.palet at consulintel.es Sat Dec 2 10:41:52 2017 From: jordi.palet at consulintel.es (JORDI PALET MARTINEZ) Date: Sat, 02 Dec 2017 10:41:52 +0100 Subject: [atlas] ULA detected by probe? Message-ID: <6EF94BB7-B960-4629-9FA1-0E8F00EC825A@consulintel.es> Hi, I?ve two probes in two networks, with exactly the same config in both routers (which are the same, using LEDE). ULA is NOT configured in the router and no other device in the network can see the ULA. However, one of the probes, shows the TAG ?IPv6 ULA? And Addresses fd3f:4830:fd21:0:220:4aff:febf:ffaf/64 2001:?. How is that possible and how to clean up it? Regards, Jordi ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.consulintel.es The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it. From bortzmeyer at nic.fr Sun Dec 3 17:36:46 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sun, 3 Dec 2017 17:36:46 +0100 Subject: [atlas] Effect of "Resolve on Probe"-option In-Reply-To: References: <531ABB2A-F7CD-4482-A3F7-9C8EF9C5E0DF@timwattenberg.de> Message-ID: <20171203163646.qe75cz2zt34hqkni@sources.org> On Fri, Dec 01, 2017 at 03:44:22PM +0100, Tim Wattenberg wrote a message of 123 lines which said: > In my measurement I activated the option to use the probes > resolver(s) and left the option to resolve on the probe deactivated. The documentation appears misleading here, for the specific case of DNS. For DNS measurements: 'use_probe_resolver': True means using the probe's resolver(s), typically obtained through DHCP 'use_probe_resolver': False means you have to indicate a name server (resolver or authoritative) as a target. Atlas rejects 'use_probe_resolver': False if you did not specify a target: Status 400, reason "{"error":{"status":400,"errors":[{"source":{"pointer":"/definitions/0"},"detail":"`target` cannot be null if `use_probe_resolver` is not specified"}],"code":102,"detail":"There was a problem with your request","title":"Bad Request"}}" 'resolve_on_probe' seems ignored. Examples with atlas-resolve: 1) Use the probe's resolver(s): % atlas-resolve -r 5 -v thepiratebay.org {'definitions': [{'protocol': 'UDP', 'description': 'DNS resolution of thepiratebay.org', 'af': 4, 'query_argument': 'thepiratebay.org', 'query_type': 'A', 'query_class': 'IN', 'set_rd_bit': True, 'type': 'dns', 'use_probe_resolver': True}], 'is_oneoff': True, 'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-resolves-a-correctly', 'system-resolves-aaaa-correctly', 'system-ipv4-works']}}]} Measurement #10397465 for thepiratebay.org/A uses 5 probes [104.27.216.28 104.27.217.28] : 4 occurrences [213.46.185.10] : 1 occurrences Test #10397465 done at 2017-12-03T16:18:22Z 2) Use an external server (here, Quad9, option -e): % atlas-resolve -r 5 -v -e 9.9.9.9 thepiratebay.org {'definitions': [{'protocol': 'UDP', 'description': 'DNS resolution of thepiratebay.org via nameserver 9.9.9.9', 'af': 4, 'query_argument': 'thepiratebay.org', 'query_type': 'A', 'query_class': 'IN', 'target': '9.9.9.9', 'set_rd_bit': True, 'type': 'dns', 'use_probe_resolver': False}], 'is_oneoff': True, 'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-ipv4-works']}}]} Measurement #10397471 for thepiratebay.org/A uses 5 probes Nameserver 9.9.9.9 [104.27.216.28 104.27.217.28] : 5 occurrences Test #10397471 done at 2017-12-03T16:19:41Z In the case 1), measurement #10397465, the "dst_addr" field will indicate the address of the resolver: % wget -q -O - https://atlas.ripe.net/api/v2/measurements/10397465/results/ | jq "map(.resultset) | flatten(1) | map(.dst_addr)" [ "172.29.253.203", "172.29.254.203", "80.58.61.250", "80.58.61.254", "62.179.104.196", "213.46.228.196", "217.11.217.3", "217.11.217.13", "192.168.10.2", "208.67.222.222" ] In the case 2), measurement #10397471: % wget -q -O - https://atlas.ripe.net/api/v2/measurements/10397471/results/ | jq "map(.dst_addr)" [ "9.9.9.9", "9.9.9.9", "9.9.9.9", "9.9.9.9", "9.9.9.9" ] From philip.homburg at ripe.net Mon Dec 4 12:13:48 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 4 Dec 2017 12:13:48 +0100 Subject: [atlas] Effect of "Resolve on Probe"-option In-Reply-To: <20171203163646.qe75cz2zt34hqkni@sources.org> References: <531ABB2A-F7CD-4482-A3F7-9C8EF9C5E0DF@timwattenberg.de> <20171203163646.qe75cz2zt34hqkni@sources.org> Message-ID: <4bd582f2-bcbd-c935-f4be-8c10703b650d@ripe.net> On 2017/12/03 17:36 , Stephane Bortzmeyer wrote: > Atlas rejects 'use_probe_resolver': False if you did not specify a > target: > > Status 400, reason "{"error":{"status":400,"errors":[{"source":{"pointer":"/definitions/0"},"detail":"`target` cannot be null if `use_probe_resolver` is not specified"}],"code":102,"detail":"There was a problem with your request","title":"Bad Request"}}" > > 'resolve_on_probe' seems ignored. > > 2) Use an external server (here, Quad9, option -e): > > % atlas-resolve -r 5 -v -e 9.9.9.9 thepiratebay.org > {'definitions': [{'protocol': 'UDP', 'description': 'DNS resolution of thepiratebay.org via nameserver 9.9.9.9', 'af': 4, 'query_argument': 'thepiratebay.org', 'query_type': 'A', 'query_class': 'IN', 'target': '9.9.9.9', 'set_rd_bit': True, 'type': 'dns', 'use_probe_resolver': False}], 'is_oneoff': True, 'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 'tags': {'include': ['system-ipv4-works']}}]} > Measurement #10397471 for thepiratebay.org/A uses 5 probes > Nameserver 9.9.9.9 > [104.27.216.28 104.27.217.28] : 5 occurrences > Test #10397471 done at 2017-12-03T16:19:41Z It may be worth pointing out that resolve_on_probe has effect if two conditions are met: 1) use_probe_resolver is false 2) the measurement target is a dns name (as opposed to an IP address literal) In your quad-9 example, the target is a literal, so resolve_on_probe has no effect. The following DNS measurement uses resolve_on_probe: https://atlas.ripe.net/measurements/10404214/ Here is an example measurement result: {"af":4,"dst_addr":"193.0.9.7","from":"73.34.225.118","fw":4780,"group_id":10404214,"lts":38,"msm_id":10404214,"msm_name":"Tdig","name":"manus.authdns.ripe.net","prb_id":21675,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":0,"ID":55944,"NSCOUNT":0,"QDCOUNT":1,"abuf":"2oiEAAABAAEAAAAAA3d3dwRyaXBlA25ldAAAAQABwAwAAQABAABUYAAEwQAGiw==","rt":131.954,"size":46},"src_addr":"192.168.29.154","stored_timestamp":1512385062,"timestamp":1512385044,"type":"dns"} The probe reports that it resolved 'name' manus.authdns.ripe.net to 'dst_addr' 193.0.9.7 Philip From klaus.mailinglists at pernau.at Tue Dec 5 23:01:20 2017 From: klaus.mailinglists at pernau.at (Klaus Darilion) Date: Tue, 5 Dec 2017 23:01:20 +0100 Subject: [atlas] Problem with new Openipmap Message-ID: <6a18a1ee-a6c3-898d-8623-57ad23c4ae86@pernau.at> Hi! I just noticed the new interface of Openipmap. Nice, but unfortunately not as useful as the old one: 1. clicking on the graph does not show the trace 2. it does not show 50 traces as the last one (I need plenty of traceroutes for network optimization, not only 10) 3. there should be a possibillity to mark a location as wrong. E.g. see https://atlas.ripe.net/measurements/10418213/#!openipmap Openipmap display Warsaw as target where all this traces terminate in New York as this IP address is an Anycast IP address and therefore it must no be mapped to a single location. hence, for Anycast IPs there should be feature to mark the IP as Anycast. Then the final target is usually the location of the IP address before. regards Klaus From listclient at sokolov.eu.org Tue Dec 5 23:13:49 2017 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Tue, 05 Dec 2017 14:13:49 -0800 Subject: [atlas] Problem with new Openipmap In-Reply-To: <6a18a1ee-a6c3-898d-8623-57ad23c4ae86@pernau.at> References: <6a18a1ee-a6c3-898d-8623-57ad23c4ae86@pernau.at> Message-ID: He makes good points. I think there should be at 100 traces, not just 10. That's just to small a sample. BR Daniel AJ On 5 December 2017 14:01:20 GMT-08:00, Klaus Darilion wrote: >Hi! > >I just noticed the new interface of Openipmap. Nice, but unfortunately >not as useful as the old one: > >1. clicking on the graph does not show the trace >2. it does not show 50 traces as the last one (I need plenty of >traceroutes for network optimization, not only 10) >3. there should be a possibillity to mark a location as wrong. > >E.g. see https://atlas.ripe.net/measurements/10418213/#!openipmap > >Openipmap display Warsaw as target where all this traces terminate in >New York as this IP address is an Anycast IP address and therefore it >must no be mapped to a single location. > >hence, for Anycast IPs there should be feature to mark the IP as >Anycast. Then the final target is usually the location of the IP >address >before. > >regards >Klaus Sent from mobile phone. Please excuse my brevity. From mcandela at ripe.net Wed Dec 6 10:22:07 2017 From: mcandela at ripe.net (Massimo Candela) Date: Wed, 6 Dec 2017 10:22:07 +0100 Subject: [atlas] Problem with new Openipmap In-Reply-To: <6a18a1ee-a6c3-898d-8623-57ad23c4ae86@pernau.at> References: <6a18a1ee-a6c3-898d-8623-57ad23c4ae86@pernau.at> Message-ID: <36DA731E-2681-4A2E-8EAC-FC100137EC54@ripe.net> Hello Klaus, First of all thanks for your feedback. > On 5 Dec 2017, at 23:01, Klaus Darilion wrote: > > Hi! > > I just noticed the new interface of Openipmap. Nice, but unfortunately > not as useful as the old one: > > 1. clicking on the graph does not show the trace It shows them on the left column. Do you mean in a classic CLI format? > 2. it does not show 50 traces as the last one (I need plenty of > traceroutes for network optimization, not only 10) The new version does a series of additional data enrichment, so on this release we tried to save on browsers resources. We will increase this number soon. > 3. there should be a possibillity to mark a location as wrong. > > E.g. see https://atlas.ripe.net/measurements/10418213/#!openipmap > > Openipmap display Warsaw as target where all this traces terminate in > New York as this IP address is an Anycast IP address and therefore it > must no be mapped to a single location. > > hence, for Anycast IPs there should be feature to mark the IP as > Anycast. Then the final target is usually the location of the IP address > before. As announced at the RIPE meeting, we are working on anycast support right now! Thank you very much for letting us know what you think we should prioritise. Ciao, Massimo > > regards > Klaus > > From philip.homburg at ripe.net Wed Dec 6 11:24:11 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 6 Dec 2017 11:24:11 +0100 Subject: [atlas] ULA detected by probe? In-Reply-To: <6EF94BB7-B960-4629-9FA1-0E8F00EC825A@consulintel.es> References: <6EF94BB7-B960-4629-9FA1-0E8F00EC825A@consulintel.es> Message-ID: <2ac00e35-c5af-b8b8-8bb4-44621a91696b@ripe.net> Hi Jordi, On 2017/12/02 10:41 , JORDI PALET MARTINEZ wrote: > And > Addresses fd3f:4830:fd21:0:220:4aff:febf:ffaf/64 > 2001:?. I'm not aware of any case where an Atlas probe created an IPv6 ULA out of thin air. Addresses are either statically configured or derived from a prefix in a router advertisement. So most likely the probe picked it up from an RA. Your probe is now up for 27 days. So that's the time period where the probe could have received the RA. If the lifetime in the RA is infinite, then the prefix will essentially stay there forever, or until another RA modifies the lifetime. > How is that possible and how to clean up it? The easiest way to get rid of it is to powercycle the probe. Philip From mir at ripe.net Fri Dec 8 14:06:57 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 8 Dec 2017 14:06:57 +0100 Subject: [atlas] New on RIPE Labs: Measuring Network Behaviour with RIPE Atlas Message-ID: Dear colleagues, In this article Marcel Flores and Stephen McQuistin describe how they used RIPE Atlas to understand the network behaviours their end-users are experiencing: https://labs.ripe.net/Members/verizon_digital/seeing-the-world-with-ripe-atlas Kind regards, Mirjam K?hne RIPE NCC From camin at ripe.net Wed Dec 13 11:32:54 2017 From: camin at ripe.net (Chris Amin) Date: Wed, 13 Dec 2017 11:32:54 +0100 Subject: [atlas] Missing servers in DNSMON Message-ID: <5186b906-f01a-5c00-9ea6-c30f4f1708d2@ripe.net> Dear colleagues, It was recently brought to our attention that a small number of name servers were not being included in the visualisations on DNSMON. This issue has now been fixed, but you may notice a gap between mid-September and mid-December when visualising large time ranges for the affected servers. Apologies for any confusion or inconvenience caused. The affected zones and nameservers are: hk. - 203.119.87.218 xn--j6w193g. - 203.119.87.218 il. - 128.139.35.5 il. - 194.146.106.122 il. - 2001:67c:1010:31::53 mx. - 2001:13c7:7000::1 pl. - 2001:1a68:0:17::238 pl. - 2001:a10:121:1::156 pl. - 2a00:4120:8000:2::186 Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From mir at ripe.net Tue Dec 19 12:19:45 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 19 Dec 2017 12:19:45 +0100 Subject: [atlas] Second Part of RIPE Atlas as IoT Devices - The RIPE Atlas Architecture In-Reply-To: <023b76e2-9634-25de-048c-c341c37e3b7f@ripe.net> References: <023b76e2-9634-25de-048c-c341c37e3b7f@ripe.net> Message-ID: <33526be1-5e6d-1c57-9ee2-f67634003fd3@ripe.net> Dear colleagues, Here is the second part of the story about RIPE Atlas as IoT Devices. This time we we give some insights into the overall architecture of the RIPE Atlas network and how we manage secure communication with our probe flock. https://labs.ripe.net/Members/kistel/ripe-atlas-architecture-how-we-manage-our-probes Kind regards, Mirjam K?hne RIPE NCC From listclient at sokolov.eu.org Wed Dec 20 08:21:08 2017 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Tue, 19 Dec 2017 23:21:08 -0800 Subject: [atlas] Probe disconnects every 2 hours Message-ID: <25075b35-0917-8f25-90c3-c5babf3f5684@sokolov.eu.org> Hello, the logs for my probe (version 1) show that is has been disconnecting very regularly every 2 hours. The uptimes are always +/- 1 hour 50 minutes, followed by a disconnect period of 5, 8, or 11 minutes. Out of my last 25 connects, 20 are like that. 3 have double the uptime (about 3 hours and 50 minutes), only one has almost 24 hours, and the current one is 6 hours and counting. The disconnects there were, again, 5, 8, or 11 minutes. However, I to not notice similar disconnects as a user of the same network. I sometimes listen to online streams for more then 2 hours without interruption. I work on my computer for more than 2 hours and don't notice these interruptions of my internet access. It's all IPv4; no IPv6 here. The controller is ctr-fnc01. What could be the cause of these log entries? BR Daniel AJ From philip.homburg at ripe.net Wed Dec 20 13:48:22 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 20 Dec 2017 13:48:22 +0100 Subject: [atlas] Probe disconnects every 2 hours In-Reply-To: <25075b35-0917-8f25-90c3-c5babf3f5684@sokolov.eu.org> References: <25075b35-0917-8f25-90c3-c5babf3f5684@sokolov.eu.org> Message-ID: <60c472c1-eb57-1371-5782-1e7454d62e98@ripe.net> Hi, Maybe you can mention your probe ID. That makes it easier to figure out what is going on. Philip From empirical_bayesian at ieee.org Wed Dec 20 17:09:48 2017 From: empirical_bayesian at ieee.org (Jan Galkowski) Date: Wed, 20 Dec 2017 11:09:48 -0500 Subject: [atlas] Any recommendations on how I can get ATLAS admins to reset my two-step verification? In-Reply-To: References: Message-ID: <1513786188.3409683.1211348136.5D5FCB09@webmail.messagingengine.com> Hi I have an ATLAS probe, long connected with a lot of credits. I have a RIPE NCC account, where the email and passcode are both recognized. Unfortunately, I apparently also have two-step verification set up. I don't recall doing that, but, then, it's probably my memory is at fault. And I do not know where, if anywhere, I put the notes for the 32 bit "emergency" code. The guidance at the site is to reach out to the ATLAS administrations in this situation for, I presume a reset. I have looked for additional information, and opened tickets. Unfortunately, the link to the FAQ describing this security facility is "404", and the tickets have gone acknowledged by the ticketing system, but not responded to. My interest is keen, because I was hoping to get some measurements research done by the start of the New Year. Alas. I have things I can do towards this, but has anyone else been in a similar situation? Advice? Thanks very much, Merry Newtonmas, and best wishes for the New Year. - Jan Galkowski, Westwood, MA. From jterbeest at ripe.net Wed Dec 20 20:36:03 2017 From: jterbeest at ripe.net (Johan ter Beest) Date: Wed, 20 Dec 2017 20:36:03 +0100 Subject: [atlas] Any recommendations on how I can get ATLAS admins to reset my two-step verification? In-Reply-To: <1513786188.3409683.1211348136.5D5FCB09@webmail.messagingengine.com> References: <1513786188.3409683.1211348136.5D5FCB09@webmail.messagingengine.com> Message-ID: Hi Jan, On 20/12/2017 17:09, Jan Galkowski wrote: > Hi > > I have an ATLAS probe, long connected with a lot of credits. > > I have a RIPE NCC account, where the email and passcode are both recognized. > > Unfortunately, I apparently also have two-step verification set up. I don't recall doing that, but, then, it's probably my memory is at fault. And I do not know where, if anywhere, I put the notes for the 32 bit "emergency" code. I've turned your 2FA off so you should be able to log in again. > > The guidance at the site is to reach out to the ATLAS administrations in this situation for, I presume a reset. I have looked for additional information, and opened tickets. Unfortunately, the link to the FAQ describing this security facility is "404", and the tickets have gone acknowledged by the ticketing system, but not responded to. I'm sorry about that, I will go check why your tickets were never responded to. Normally you would get a repsonse within 24-48 hours at most. > > My interest is keen, because I was hoping to get some measurements research done by the start of the New Year. Alas. I have things I can do towards this, but has anyone else been in a similar situation? Advice? > > Thanks very much, Merry Newtonmas, and best wishes for the New Year. Happy holidays to you too and thank you for using RIPE Atlas :) Kind regards, Johan ter Beest RIPE Atlas Team > > - Jan Galkowski, Westwood, MA. > > > From jterbeest at ripe.net Wed Dec 20 20:37:26 2017 From: jterbeest at ripe.net (Johan ter Beest) Date: Wed, 20 Dec 2017 20:37:26 +0100 Subject: [atlas] Any recommendations on how I can get ATLAS admins to reset my two-step verification? In-Reply-To: References: <1513786188.3409683.1211348136.5D5FCB09@webmail.messagingengine.com> Message-ID: Hi Jan, If you still have problems with your account, please email me directly. I didn't want to say that on the list as otherwise people might email me directly instead of going through our Customer Service department ;) Cheers, Johan On 20/12/2017 20:36, Johan ter Beest wrote: > Hi Jan, > > > On 20/12/2017 17:09, Jan Galkowski wrote: >> Hi >> >> I have an ATLAS probe, long connected with a lot of credits. >> >> I have a RIPE NCC account, where the email and passcode are both >> recognized. >> >> Unfortunately, I apparently also have two-step verification set up.? >> I don't recall doing that, but, then, it's probably my memory is at >> fault.? And I do not know where, if anywhere, I put the notes for the >> 32 bit "emergency" code. > > I've turned your 2FA off so you should be able to log in again. >> >> The guidance at the site is to reach out to the ATLAS administrations >> in this situation for, I presume a reset.? I have looked for >> additional information, and opened tickets. Unfortunately, the link >> to the FAQ describing this security facility is "404", and the >> tickets have gone acknowledged by the ticketing system, but not >> responded to. > > I'm sorry about that, I will go check why your tickets were never > responded to. Normally you would get a repsonse within 24-48 hours at > most. >> >> My interest is keen, because I was hoping to get some measurements >> research done by the start of the New Year. Alas. I have things I can >> do towards this, but has anyone else been in a similar situation?? >> Advice? >> >> Thanks very much, Merry Newtonmas, and best wishes for the New Year. > Happy holidays to you too and thank you for using RIPE Atlas :) > > Kind regards, > > Johan ter Beest > RIPE Atlas Team >> >> ? - Jan Galkowski, Westwood, MA. >> >> >> > > > From listclient at sokolov.eu.org Wed Dec 20 20:41:34 2017 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Wed, 20 Dec 2017 11:41:34 -0800 Subject: [atlas] Probe disconnects every 2 hours In-Reply-To: <60c472c1-eb57-1371-5782-1e7454d62e98@ripe.net> References: <25075b35-0917-8f25-90c3-c5babf3f5684@sokolov.eu.org> <60c472c1-eb57-1371-5782-1e7454d62e98@ripe.net> Message-ID: <09954504-f4b0-2ebc-08b5-03b240097715@sokolov.eu.org> On 2017-12-20 at 04:48 AM, Philip Homburg wrote: > Hi, > > Maybe you can mention your probe ID. That makes it easier to figure out > what is going on. > > Philip > It is 1118. Daniel AJ From philip.homburg at ripe.net Thu Dec 21 11:55:17 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 21 Dec 2017 11:55:17 +0100 Subject: [atlas] Probe disconnects every 2 hours In-Reply-To: <09954504-f4b0-2ebc-08b5-03b240097715@sokolov.eu.org> References: <25075b35-0917-8f25-90c3-c5babf3f5684@sokolov.eu.org> <60c472c1-eb57-1371-5782-1e7454d62e98@ripe.net> <09954504-f4b0-2ebc-08b5-03b240097715@sokolov.eu.org> Message-ID: On 2017/12/20 20:41 , Daniel AJ Sokolov wrote: > It is 1118. Your probe seems to reboot every two hours. V1 probes suffer from memory fragmentation, so when the ssh connection breaks, they often reboot. However I cannot find anything related to that in the logs. A reboot can be caused by a power failure. Do you have anything that might be causing that? Alternatively, there may be a software bug that triggers the reboot. Other V1 probes that connect to the same controller seem fine. So either you probe gets a specific measurement that triggers a bug, or there is a power issue. How is the probe powered? Philip From mir at ripe.net Thu Dec 21 12:00:40 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Thu, 21 Dec 2017 12:00:40 +0100 Subject: [atlas] New on RIPE Labs: Plan of Action for RIPE Atlas Anchor VMs Message-ID: <9f0b7339-af21-6ddc-d20a-d95427a2147a@ripe.net> Dear colleagues, Members of the RIPE Atlas community have asked us to implement RIPE Atlas vantage points as Virtual Machines (VMs). In order to address these requests, we came up with a plan of action: https://labs.ripe.net/Members/kistel/plan-of-action-for-ripe-atlas-anchor-vms Kind regards, Mirjam K?hne RIPE NCC From colinj at mx5.org.uk Thu Dec 21 12:03:59 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 21 Dec 2017 11:03:59 +0000 Subject: [atlas] New on RIPE Labs: Plan of Action for RIPE Atlas Anchor VMs In-Reply-To: <9f0b7339-af21-6ddc-d20a-d95427a2147a@ripe.net> References: <9f0b7339-af21-6ddc-d20a-d95427a2147a@ripe.net> Message-ID: <53B5EC08-528D-456F-939A-899D4F6575A7@mx5.org.uk> Happy to help with vm work as well if needed as I was one asking for VM probe functionality. Colin > On 21 Dec 2017, at 11:00, Mirjam Kuehne wrote: > > Dear colleagues, > > Members of the RIPE Atlas community have asked us to implement RIPE > Atlas vantage points as Virtual Machines (VMs). In order to address > these requests, we came up with a plan of action: > > https://labs.ripe.net/Members/kistel/plan-of-action-for-ripe-atlas-anchor-vms > > Kind regards, > Mirjam K?hne > RIPE NCC > From jared at puck.nether.net Thu Dec 21 12:48:57 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 21 Dec 2017 06:48:57 -0500 Subject: [atlas] New on RIPE Labs: Plan of Action for RIPE Atlas Anchor VMs In-Reply-To: <53B5EC08-528D-456F-939A-899D4F6575A7@mx5.org.uk> References: <9f0b7339-af21-6ddc-d20a-d95427a2147a@ripe.net> <53B5EC08-528D-456F-939A-899D4F6575A7@mx5.org.uk> Message-ID: <2BD4744B-BB0C-4A5D-AC01-F74F5776C661@puck.nether.net> Similarly happy to help. - Jared > On Dec 21, 2017, at 6:03 AM, Colin Johnston wrote: > > Happy to help with vm work as well if needed as I was one asking for VM probe functionality. > > Colin > > >> On 21 Dec 2017, at 11:00, Mirjam Kuehne wrote: >> >> Dear colleagues, >> >> Members of the RIPE Atlas community have asked us to implement RIPE >> Atlas vantage points as Virtual Machines (VMs). In order to address >> these requests, we came up with a plan of action: >> >> https://labs.ripe.net/Members/kistel/plan-of-action-for-ripe-atlas-anchor-vms >> >> Kind regards, >> Mirjam K?hne >> RIPE NCC >> > From bryan at digitalocean.com Wed Dec 27 18:05:04 2017 From: bryan at digitalocean.com (Bryan Socha) Date: Wed, 27 Dec 2017 12:05:04 -0500 Subject: [atlas] New on RIPE Labs: Plan of Action for RIPE Atlas Anchor VMs In-Reply-To: <2BD4744B-BB0C-4A5D-AC01-F74F5776C661@puck.nether.net> References: <9f0b7339-af21-6ddc-d20a-d95427a2147a@ripe.net> <53B5EC08-528D-456F-939A-899D4F6575A7@mx5.org.uk> <2BD4744B-BB0C-4A5D-AC01-F74F5776C661@puck.nether.net> Message-ID: Also happy to help and really happy to see this. Bryan Socha Network Engineer bryan at digitalocean.com ------------------------------ We're Hiring! | @digitalocean On Thu, Dec 21, 2017 at 6:48 AM, Jared Mauch wrote: > Similarly happy to help. > > - Jared > > > On Dec 21, 2017, at 6:03 AM, Colin Johnston wrote: > > > > Happy to help with vm work as well if needed as I was one asking for VM > probe functionality. > > > > Colin > > > > > >> On 21 Dec 2017, at 11:00, Mirjam Kuehne wrote: > >> > >> Dear colleagues, > >> > >> Members of the RIPE Atlas community have asked us to implement RIPE > >> Atlas vantage points as Virtual Machines (VMs). In order to address > >> these requests, we came up with a plan of action: > >> > >> https://labs.ripe.net/Members/kistel/plan-of-action-for- > ripe-atlas-anchor-vms > >> > >> Kind regards, > >> Mirjam K?hne > >> RIPE NCC > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From afshar.milad89 at gmail.com Sat Dec 30 12:23:05 2017 From: afshar.milad89 at gmail.com (Milad Afshari) Date: Sat, 30 Dec 2017 14:53:05 +0330 Subject: [atlas] RIPE Atlas CLI Message-ID: Hi Dear Colleagues; I hope you are doing well; I have an issue with creating a measurement using " --include-tag" option,As far as I check the syntax is correct but it doesn't work.Please let me know if you have any idea. cmd: *a) - ripe-atlas measure ping --from-country ir --target 79.127.127.1 --include-tag system-ipv4-works* *b) ripe-atlas measure ping --from-country ir --target 79.127.127.1 --include-tag=system-ipv4-works* Error: *ripe-atlas measure: error: argument --include-tag: "system-ipv4-works" does not appear to be valid.* Regards Milad -------------- next part -------------- An HTML attachment was scrubbed... URL: From wings_spread at hotmail.fr Fri Dec 29 12:36:24 2017 From: wings_spread at hotmail.fr (Walid Ben Ali) Date: Fri, 29 Dec 2017 11:36:24 +0000 Subject: [atlas] Probe didn't get static IP address Message-ID: Dear ripe Atlas support, My probe ID 26099 didn't reconize the static IP adress. Knowing that it worked for days. Today I just tried to know if it is a network problem or a probe issu, I just conenct it into DHCP and the probe works., I also pluged my Laptop to the netwok with the static IP address (in order to know if it is a network issu) and also the network ork perfectly, I even surfed on the RIPE NCC web site without any pb. So please RIPE Atlas support, could you bring me some help? I returned back the probe to the nework, the static specified IP is kept, (with the DNS and submask and so on), but the probe didn't work. Looking for your support Many thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: