From budiwijaya at ipv6.or.id Mon Feb 2 06:10:40 2015 From: budiwijaya at ipv6.or.id (Budiwijaya) Date: Mon, 2 Feb 2015 12:10:40 +0700 Subject: [atlas] Web Werks (IN) has joined RIPE Atlas anchors In-Reply-To: References: Message-ID: Hi Guys, I'm from Wowrack[1], we have just applied to host probe on two locations, Indonesia and Seattle, I just read about RIPE Anchors, are the hardware need to be Soekris? We can host an anchor, but we only have an x86 systems, or if someone want to sponsors an anchor and host in our DC, we are very welcome. We can host anchor on two locations, Indonesia and Seattle. Thank you. Budiwijaya [1] http://wowrack.com, http://wowrack.co.id ? On Fri, Jan 30, 2015 at 9:11 PM, Michela Galante wrote: > 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 in-bom-as33480 and it is hosted by Web Werks in > Mumbai, India, and sponsored by APNIC. > > 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, > > RIPE Atlas Team > atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at danrl.de Fri Feb 6 12:06:45 2015 From: mail at danrl.de (Dan Luedtke) Date: Fri, 6 Feb 2015 12:06:45 +0100 Subject: [atlas] Bug? RIPE Atlas interface mixing up legacy IP addresses Message-ID: <7EE9FC46-BC33-4D7E-977E-994F109FADDE@danrl.de> Hi all, I encountered some odd behaviour today using the Atlas web interface. It mixed up the octets of a legacy IP address in a funny way. Is this a bug? The corresponding probe seems to be down now /0\ I made a screen cap to document it. It was reproducible, but I am not sure if I broke it or if it is a general bug. ?> http://youtu.be/Bhnyd9ogyNs Cheers Dan From mail at danrl.de Fri Feb 6 12:20:40 2015 From: mail at danrl.de (Dan Luedtke) Date: Fri, 6 Feb 2015 12:20:40 +0100 Subject: [atlas] Bug? RIPE Atlas interface mixing up legacy IP addresses In-Reply-To: <7EE9FC46-BC33-4D7E-977E-994F109FADDE@danrl.de> References: <7EE9FC46-BC33-4D7E-977E-994F109FADDE@danrl.de> Message-ID: <340C74C3-95BC-48FA-A786-2C396B8B3729@danrl.de> FYI: It came up after a while. It looks the config pushed to the probe is correct, even if the web interface shows otherwise. > On 06 Feb 2015, at 12:06, Dan Luedtke wrote: > > Hi all, > > I encountered some odd behaviour today using the Atlas web interface. It mixed up the octets of a legacy IP address in a funny way. Is this a bug? The corresponding probe seems to be down now /0\ > > I made a screen cap to document it. It was reproducible, but I am not sure if I broke it or if it is a general bug. > ?> http://youtu.be/Bhnyd9ogyNs > > Cheers > > Dan From dquinn at ripe.net Fri Feb 6 13:51:56 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Fri, 06 Feb 2015 13:51:56 +0100 Subject: [atlas] Bug? RIPE Atlas interface mixing up legacy IP addresses In-Reply-To: <340C74C3-95BC-48FA-A786-2C396B8B3729@danrl.de> References: <7EE9FC46-BC33-4D7E-977E-994F109FADDE@danrl.de> <340C74C3-95BC-48FA-A786-2C396B8B3729@danrl.de> Message-ID: <54D4B8EC.5070508@ripe.net> >From the looks of things, there's definitely a problem. I'll look into it and get back to you off-list. In the future though, please report these sorts of things to atlas at ripe.net (our bug tracker) so we don't pollute the list with bug reports. From BECHA at ripe.net Mon Feb 9 11:29:27 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Mon, 09 Feb 2015 11:29:27 +0100 Subject: [atlas] Fwd: SEE4/RIPE NCC Regional Meeting: Registration Open! In-Reply-To: <54C61511.8030500@ripe.net> References: <54C61511.8030500@ripe.net> Message-ID: <54D88C07.7030308@ripe.net> Dear RIPE Atlas users, do you want to share your experiences with using RIPE Atlas with the community on "Balkans"? Please submit your talks - and see you there! Regards, Vesna -------- Forwarded Message -------- Subject: SEE 4/RIPE NCC Regional Meeting: Registration Open! Date: Mon, 26 Jan 2015 11:21:05 +0100 From: SEE To: ripe-list at ripe.net Dear colleagues, The fourth RIPE NCC Regional Meeting/South East Europe Meeting (SEE 4) takes places in Belgrade at the Metropol Palace Hotel on 21-22 April 2015. Join us there! The SEE 4/RIPE NCC Regional Meeting is open to everyone and attendance is free of charge. You can register for this meeting at: http://www.ripe.net/see-4/registration This meeting will build on the success of past meetings, which took place in Dubrovnik, Skopje and Sofia. These meetings demonstrated how vibrant the Internet community in the region is, as well as the knowledge-sharing and network-building benefits to be gained from meeting as a community. The meeting will cover a wide range of topics, including: - IPv6 deployment - Managing IPv4 scarcity in operations - Commercial transactions of IPv4 addresses - Data centre technologies - Network and DNS operations - Internet governance and regulatory practices - Network and routing security - Content delivery - Internet peering and mobile data exchange - Efforts to establish IXPs in the region - Reports from existing IXPs - Regional success stories - Much, much more! Do you have expertise on some of these topics? An interesting case to share with your peers? Then please submit a presentation proposal here: https://www.ripe.net/ripe/meetings/regional-meetings/see-4/cfp Further information about the meeting can be found at: http://www.ripe.net/see4 See you there! Kind regards, Gergana -- Gergana Petrova Conference Coordinator RIPE Network Coordination Centre Singel 258, 1016 AB Amsterdam, The Netherlands T: +31 20 535 4444 www.ripe.net From hvjunk at gmail.com Thu Feb 12 07:37:06 2015 From: hvjunk at gmail.com (Hendrik Visage) Date: Thu, 12 Feb 2015 08:37:06 +0200 Subject: [atlas] MacOSX: probe add problems (create measurements) Message-ID: Goodday, I'm trying to add some new measurements, but the probe selection's "+New Set - Manual" and "+Reuse a set from an old Measurement" both just flash the screen, looks like it opens a drop down windows, and closes it before I could even blink my eyes. This was tested on the Firefox 35.0.1 as well as on Safari 7.0.3 on MacOSX 10.9.3. Hendrik From mcandela at ripe.net Thu Feb 12 10:40:53 2015 From: mcandela at ripe.net (Massimo Candela) Date: Thu, 12 Feb 2015 10:40:53 +0100 Subject: [atlas] MacOSX: probe add problems (create measurements) In-Reply-To: References: Message-ID: <965108B4-8FEE-4922-A16E-2005C76ECD95@ripe.net> Good morning, There was a library conflict that now we fixed. Explanation: we use some components from stat.ripe.net to show some insights about the data. This issue appeared when, after an update, also stat.ripe.net started loading a library we were already loading in Atlas causing a conflict. Thanks a lot for your email!! Feel free to contact us if you have any other issue/question. Cheers, Massimo Candela On 12 Feb 2015, at 07:37, Hendrik Visage wrote: > Goodday, > > I'm trying to add some new measurements, but the probe selection's > "+New Set - Manual" and "+Reuse a set from an old Measurement" both > just flash the screen, looks like it opens a drop down windows, and > closes it before I could even blink my eyes. > > This was tested on the Firefox 35.0.1 as well as on Safari 7.0.3 on > MacOSX 10.9.3. > > Hendrik > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2611 bytes Desc: not available URL: From astracha at ripe.net Thu Feb 12 16:17:29 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 12 Feb 2015 16:17:29 +0100 Subject: [atlas] Globalways AC (Stuttgart, Germany ) has joined RIPE Atlas Anchors Message-ID: <43C700B3-1EE6-4148-B6BB-4C6DE12622D4@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 de-str-as48918 and it is hosted by Globalways AC based in Stuttgart, 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, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From astracha at ripe.net Thu Feb 12 16:17:32 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 12 Feb 2015 16:17:32 +0100 Subject: [atlas] Globalways AC (Frankfurt, Germany ) has joined RIPE Atlas Anchors Message-ID: <7C4E8C94-3454-4CB0-BE46-ED22BB690735@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 de-fra-as48918 and it is hosted by Globalways AC based 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, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From astracha at ripe.net Thu Feb 12 16:17:36 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 12 Feb 2015 16:17:36 +0100 Subject: [atlas] Larsen Data ApS (Ballerup, Denmark ) has joined RIPE Atlas Anchors Message-ID: <045D046B-02FF-4702-8220-B11148CC0550@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 dk-blp-as197495 and it is hosted by Larsen Data ApS based in Ballerup, Denmark. 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, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From robert at ripe.net Fri Feb 13 12:05:16 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 13 Feb 2015 12:05:16 +0100 Subject: [atlas] problems creating measurements with old web interface In-Reply-To: <54C0C59E.1050301@pernau.at> References: <54BFA06C.5090305@pernau.at> <54BFA87C.9030709@ripe.net> <54C0C59E.1050301@pernau.at> Message-ID: <54DDDA6C.2060801@ripe.net> Hi, On 2015-01-22 10:40, Klaus Darilion wrote: >>> PS: IMO the new web interface is not very user friendly when choosing >>> the probes - eg I failed to select 100 probes word wide (how to do this >>> in the map)? It would be nice to have a textual alternative as my >>> browser gets incredibly slow when showing all the probes on the map. >> >> Indeed we realise that the map can be a bottleneck sometimes. We're looking >> at possibilities to remedy this. > > The old text-interface without map would be a remedy. Please do this > before removing the old GUI. > > Thanks > Klaus You may be interested to hear that this has been deployed -- you can now create probe selection specifications in the UI without the use of the interactive map. Regards, Robert From pvlaar at afilias.info Thu Feb 19 00:47:50 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 19 Feb 2015 00:47:50 +0100 Subject: [atlas] Sagan: 'Response' object has no attribute 'edns0' Message-ID: <54E524A6.30400@afilias.info> Hi all, I'm trying to do some basic DNS UDM result parsing using Sagan. I'd like to have an easy way to extract the NSID. I followed the instruction found here: https://www.ripe.net/ripe/mail/archives/ripe-atlas/2014-May/001475.html 'from ripe.atlas.sagan import Result result = Result("your-JSON-result-blob-here") print(result.responses[0].edns0.options[0].nsid)' That didn't work, as I get: AttributeError: 'Result' object has no attribute 'responses' So I figured I need to use a DnsResult, instead. I then have the following Python code: from ripe.atlas.sagan import DnsResult import json url = "https://atlas.ripe.net/api/v1/measurement-latest/1873691/" results = json.load(urllib.urlopen(url)) for probe in results: sagan_result = DnsResult(results[probe][0]) print(sagan_result.responses[0].edns0.options[0].nsid) This gives me: print(sagan_result.responses[0].edns0.options[0].nsid) AttributeError: 'Response' object has no attribute 'edns0' After some digging through the Sagan documentation, I found out that the way to do this should be: print(sagan_result.responses[0].abuf.edns0.options[0].nsid) This might be of help to others. ~paul From pvlaar at afilias.info Fri Feb 20 00:12:20 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Fri, 20 Feb 2015 00:12:20 +0100 Subject: [atlas] some probes not returning NSID Message-ID: <54E66DD4.2050004@afilias.info> Hi all, it appears that some probes never return NSID, when requested, while others do, for the same query. For example: https://atlas.ripe.net/measurements/1875836/#!general As you can see NSID is set to True. These are the raw results from the two probes, for a one-off DNS UDM: results = { u'6012': [{u'lts': 230, u'proto': u'UDP', u'from': u'193.0.19.108', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384037, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 6012, u'result': {u'abuf': u'OQGEAAABAAEAAAABA29yZwAABgABwAwABgABAAADhAAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2sAAAcIAAADhAAJOoAAAVGAAAApEAAAAAAAACUAAwAhbnMwMDBiLmFwcDcubnJ0MS5hZmlsaWFzLW5zdC5pbmZv', u'rt': 312.971, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 900, u'SERIAL': 2011382635, u'TYPE': u'SOA'}], u'ID': 14593, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 132}, u'src_addr': u'193.0.19.108', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}], u'10039': [{u'lts': 166, u'proto': u'UDP', u'from': u'96.237.232.254', u'msm_id': 1875836, u'af': 4, u'timestamp': 1424384040, u'fw': 4670, u'msm_name': u'Tdig', u'prb_id': 10039, u'result': {u'abuf': u'qxGAgAABAAEAAAABA29yZwAABgABwAwABgABAAAB3QAzAmEwA29yZwthZmlsaWFzLW5zdARpbmZvAANub2PAKHfjQ2UAAAcIAAADhAAJOoAAAVGAAAApD6AAAAAAAAA=', u'rt': 8.299, u'NSCOUNT': 0, u'QDCOUNT': 1, u'answers': [{u'RNAME': u'noc.afilias-nst.info.', u'NAME': u'org.', u'MNAME': u'a0.org.afilias-nst.info.', u'TTL': 477, u'SERIAL': 2011382629, u'TYPE': u'SOA'}], u'ID': 43793, u'ARCOUNT': 1, u'ANCOUNT': 1, u'size': 95}, u'src_addr': u'192.168.13.40', u'group_id': 1875836, u'type': u'dns', u'dst_addr': u'199.19.56.1'}] } Sagan tells me, for probe 6012, responses[0].abuf.raw_data is: {'HEADER': {'AA': True, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': False, 'Z': 0, 'ID': 14593}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 900, 'Serial': 2011382635, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [{'OptionCode': 3, 'OptionName': 'NSID', 'NSID': u'ns000b.app7.nrt1.afilias-nst.info', 'OptionLength': 33}], 'UDPsize': 4096, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is present. And for 10039: {'HEADER': {'AA': False, 'QR': True, 'AD': False, 'NSCOUNT': 0, 'QDCOUNT': 1, 'ANCOUNT': 1, 'TC': False, 'RD': False, 'ARCOUNT': 1, 'CD': False, 'ReturnCode': 'NOERROR', 'OpCode': 'QUERY', 'RA': True, 'Z': 0, 'ID': 43793}, 'AnswerSection': [{'Retry': 900, 'Name': u'org.', 'NegativeTtl': 86400, 'Refresh': 1800, 'MasterServerName': u'a0.org.afilias-nst.info.', 'Expire': 604800, 'MaintainerName': u'noc.afilias-nst.info.', 'TTL': 477, 'Serial': 2011382629, 'Type': 'SOA', 'Class': 'IN', 'RDlength': 51}], 'QuestionSection': [{'Qclass': 'IN', 'Qtype': 'SOA', 'Qname': u'org.'}], 'EDNS0': {'ExtendedReturnCode': 0, 'Option': [], 'UDPsize': 4000, 'Version': 0, 'Z': 0, 'Type': 'OPT', 'Name': u'.'}} NSID is missing. Why is this? I've tried increasing the payload size, this makes no difference. I get the same when I try for SOA . @ k.root-servers.net: Compare these outcomes: https://atlas.ripe.net/measurements/1875933/ https://atlas.ripe.net/measurements/1875926/ It appears to me that probe 10039 (or its network) has a problem of sorts, causing this. It would be great if faulty probes can be weeded out, if this is really the case. BTW, I am always getting "null" on the NSID field in the web interface, regardless of whether it lives in abuf, or not. This seems to be a bug. ~paul From BECHA at ripe.net Fri Feb 20 16:17:34 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Fri, 20 Feb 2015 16:17:34 +0100 Subject: [atlas] Brno University of Technology (CZ) has joined RIPE Atlas anchors Message-ID: <54E7500E.5000206@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called cz-brq-as197451 and is hosted by Brno University of Technology in Czech Republic. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, Vesna Manojlovic Measurements Community Building Team RIPE NCC From bortzmeyer at nic.fr Mon Feb 23 14:08:47 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 23 Feb 2015 14:08:47 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <54E66DD4.2050004@afilias.info> References: <54E66DD4.2050004@afilias.info> Message-ID: <20150223130847.GA15045@nic.fr> On Fri, Feb 20, 2015 at 12:12:20AM +0100, Paul Vlaar wrote a message of 88 lines which said: > It appears to me that probe 10039 (or its network) has a problem of > sorts, causing this. It would be great if faulty probes can be > weeded out, if this is really the case. Zealous middlebox, dropping the EDNS options it doesn't know? This is far more probable than a faulty probe. From listclient at sokolov.eu.org Mon Feb 23 15:22:20 2015 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Mon, 23 Feb 2015 10:22:20 -0400 Subject: [atlas] some probes not returning NSID In-Reply-To: <20150223130847.GA15045@nic.fr> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> Message-ID: <54EB379C.1050100@sokolov.eu.org> On 2015-02-23 at 09:08, Stephane Bortzmeyer wrote: > Zealous middlebox, dropping the EDNS options it doesn't know? This is > far more probable than a faulty probe. Which would be an interesting test result, too. BR Daniel AJ From f4w at echo.emu.st Mon Feb 23 17:23:02 2015 From: f4w at echo.emu.st (Mark Delany) Date: 23 Feb 2015 16:23:02 +0000 Subject: [atlas] some probes not returning NSID In-Reply-To: <54EB379C.1050100@sokolov.eu.org> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> Message-ID: <20150223162302.25737.qmail@f5-external.bushwire.net> On 23Feb15, Daniel AJ Sokolov allegedly wrote: > On 2015-02-23 at 09:08, Stephane Bortzmeyer wrote: > > Zealous middlebox, dropping the EDNS options it doesn't know? This is > > far more probable than a faulty probe. > > Which would be an interesting test result, too. Yes. This is an excellent thought for a feature request. Being able to add EDNS options to the query and test whether they make it there and back. MarkA at ISC has a similar set of tests which might be a useful guide. They also include the ability to send an "unknown" EDNS option and an "unknown" version I believe. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From philip.homburg at ripe.net Tue Feb 24 11:06:21 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 24 Feb 2015 11:06:21 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <20150223162302.25737.qmail@f5-external.bushwire.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> Message-ID: <54EC4D1D.2020507@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/23 17:23 , Mark Delany wrote: > On 23Feb15, Daniel AJ Sokolov allegedly wrote: >> On 2015-02-23 at 09:08, Stephane Bortzmeyer wrote: >>> Zealous middlebox, dropping the EDNS options it doesn't know? >>> This is far more probable than a faulty probe. >> >> Which would be an interesting test result, too. > > Yes. This is an excellent thought for a feature request. > > Being able to add EDNS options to the query and test whether they > make it there and back. MarkA at ISC has a similar set of tests which > might be a useful guide. They also include the ability to send an > "unknown" EDNS option and an "unknown" version I believe. Except for unknown EDNS options and unknown version, this is already possible. There is however no way to just include the EDNS option. Setting any parameter that requires the option pulls it in. So the easiest way to get the option included is to change the USB buffer size. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTsTR0ACgkQ23LKRM64egKIxQCfXEuz/2eXm3zUHsv8H4/naAj1 qSgAn2piu24acy38NfyY4OUInQhqRYPw =UrBM -----END PGP SIGNATURE----- From bortzmeyer at nic.fr Tue Feb 24 11:10:09 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 24 Feb 2015 11:10:09 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <20150223162302.25737.qmail@f5-external.bushwire.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> Message-ID: <20150224101009.GA29981@nic.fr> On Mon, Feb 23, 2015 at 04:23:02PM +0000, Mark Delany wrote a message of 36 lines which said: > They also include the ability to send an "unknown" EDNS option and > an "unknown" version I believe. Breaking the Internet with Atlas probes, "attribute 99"-style :-) From philip.homburg at ripe.net Tue Feb 24 11:12:50 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 24 Feb 2015 11:12:50 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <54EC4D1D.2020507@ripe.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> Message-ID: <54EC4EA2.1060105@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/24 11:06 , Philip Homburg wrote: > So the easiest way to get the option included is to change the USB > buffer size. Of course I meant UDP. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTsTqIACgkQ23LKRM64egIK1gCgubV63hDcL2Dh7odFPENR8tlR ujYAn1P037xhI1GUyi6UwiUCSRcik3dT =KSzw -----END PGP SIGNATURE----- From mir at ripe.net Tue Feb 24 11:20:24 2015 From: mir at ripe.net (Mirjam Kuehne) Date: Tue, 24 Feb 2015 11:20:24 +0100 Subject: [atlas] New on RIPE Labs: Stopping Support for Internet Explorer 8 on Windows XP in RIPE Atlas and RIPEstat In-Reply-To: <54EC4E97.1090405@ripe.net> References: <54EC4E97.1090405@ripe.net> Message-ID: <54EC5068.6090705@ripe.net> Dear colleagues, Microsoft ended support for Windows XP as of April 2014. We're about to change RIPE Atlas and RIPEstat to stop support for Internet Explorer 8 running on these systems. Please find some more information on RIPE Labs: https://labs.ripe.net/Members/kistel/stopping-support-for-internet-explorer-8-windows-xp-in-ripe-atlas-and-ripestat Kind regards, Mirjam Kuehne RIPE NCC From f4w at echo.emu.st Tue Feb 24 16:56:01 2015 From: f4w at echo.emu.st (Mark Delany) Date: 24 Feb 2015 15:56:01 +0000 Subject: [atlas] some probes not returning NSID In-Reply-To: <54EC4EA2.1060105@ripe.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> <54EC4EA2.1060105@ripe.net> Message-ID: <20150224155601.30640.qmail@f5-external.bushwire.net> > > So the easiest way to get the option included is to change the USB > > buffer size. Well, to get packet size option sure, but what about the others? For example when edns-client-subnet standardizes? Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From philip.homburg at ripe.net Tue Feb 24 17:11:50 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 24 Feb 2015 17:11:50 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <20150224155601.30640.qmail@f5-external.bushwire.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> <54EC4EA2.1060105@ripe.net> <20150224155601.30640.qmail@f5-external.bushwire.net> Message-ID: <54ECA2C6.5010207@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/24 16:56 , Mark Delany wrote: >>> So the easiest way to get the option included is to change the >>> USB buffer size. > > Well, to get packet size option sure, but what about the others? > For example when edns-client-subnet standardizes? When there is interest from the community then we can just add that option. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTsosYACgkQ23LKRM64egJpMwCfU3iZ5EJWBds2eRydE2XtQ4JV ExQAoLTLAX1gRZZEZ8/NVY085iwHfO8s =6z/f -----END PGP SIGNATURE----- From n5v at whiskey.emu.st Tue Feb 24 16:54:32 2015 From: n5v at whiskey.emu.st (Mark Delany) Date: 24 Feb 2015 15:54:32 +0000 Subject: [atlas] some probes not returning NSID In-Reply-To: <20150224101009.GA29981@nic.fr> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <20150224101009.GA29981@nic.fr> Message-ID: <20150224155432.30602.qmail@f5-external.bushwire.net> On 24Feb15, Stephane Bortzmeyer allegedly wrote: > On Mon, Feb 23, 2015 at 04:23:02PM +0000, > Mark Delany wrote > a message of 36 lines which said: > > > They also include the ability to send an "unknown" EDNS option and > > an "unknown" version I believe. > > Breaking the Internet with Atlas probes, "attribute 99"-style :-) Well, to be fair, the standards do define behavior in such cricumstances. The point of such tests is to determine non-compliance, not break the internet. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From f4w at echo.emu.st Tue Feb 24 17:14:23 2015 From: f4w at echo.emu.st (Mark Delany) Date: 24 Feb 2015 16:14:23 +0000 Subject: [atlas] some probes not returning NSID In-Reply-To: <54ECA2C6.5010207@ripe.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> <54EC4EA2.1060105@ripe.net> <20150224155601.30640.qmail@f5-external.bushwire.net> <54ECA2C6.5010207@ripe.net> Message-ID: <20150224161423.30729.qmail@f5-external.bushwire.net> > > Well, to get packet size option sure, but what about the others? > > For example when edns-client-subnet standardizes? > > When there is interest from the community then we can just add that > option. Color me intersted. Mark. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 213 bytes Desc: not available URL: From alan at clegg.com Tue Feb 24 18:23:26 2015 From: alan at clegg.com (Alan Clegg) Date: Tue, 24 Feb 2015 12:23:26 -0500 Subject: [atlas] some probes not returning NSID In-Reply-To: <20150224161423.30729.qmail@f5-external.bushwire.net> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> <54EC4EA2.1060105@ripe.net> <20150224155601.30640.qmail@f5-external.bushwire.net> <54ECA2C6.5010207@ripe.net> <20150224161423.30729.qmail@f5-external.bushwire.net> Message-ID: <54ECB38E.1060308@clegg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2/24/15 11:14 AM, Mark Delany wrote: >>> Well, to get packet size option sure, but what about the >>> others? For example when edns-client-subnet standardizes? >> >> When there is interest from the community then we can just add >> that option. > Color me intersted. I'm interested as well. (is there a better way to show interest than to spam the mailing list?) AlanC -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJU7LOOAAoJEOW2o5eiJADbPqYH/RCOz8aRHZeHp/eDWkp+FWTo NvDE5kDX8XGxMoTcw/vfWkleGbTVBimp3ryuZ0xn6fa9/0krFqFes3Gdxa5pJVgE ma1rxUmsNeeXIRI7Gdq137W8s23BHSQN8NU8NYs06QOkv4H+NL+2KamCzOmoRJPp EEZGRCJZR6+FKJKJDrscrxpv6++UBOC3DtzzLVfKsS7v/LsT1sjlV+fNiQR37aut /sL1f8izsxS/uY7GSSlghEPIWIyHHOnVPiCeTlc9ciDEk0UtDb4TcRMc5HZGi4ZP XPZdfvTedggNcKLtslHjcyZENCFxhxay9QbNYNXf+R4sJgCg4QZz9Mke1TcvluU= =YM43 -----END PGP SIGNATURE----- From philip.homburg at ripe.net Wed Feb 25 00:21:48 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 25 Feb 2015 00:21:48 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <54ECB38E.1060308@clegg.com> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> <54EC4EA2.1060105@ripe.net> <20150224155601.30640.qmail@f5-external.bushwire.net> <54ECA2C6.5010207@ripe.net> <20150224161423.30729.qmail@f5-external.bushwire.net> <54ECB38E.1060308@clegg.com> Message-ID: <54ED078C.3020708@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 2015/02/24 18:23 , Alan Clegg wrote: > On 2/24/15 11:14 AM, Mark Delany wrote: >>>> Well, to get packet size option sure, but what about the >>>> others? For example when edns-client-subnet standardizes? >>> >>> When there is interest from the community then we can just add >>> that option. > >> Color me intersted. > > I'm interested as well. (is there a better way to show interest > than to spam the mailing list?) Mailing MCB(Vesna). I'm curious what the measurement should do. Just measure propagation or does the contents matter as well? And how should in that case the prefix be set? And why Atlas? I assumed that this was an option between big resolvers, like Google's, and authoritative nameservers. Philip -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlTtB4wACgkQ23LKRM64egIZMQCeLeFaMnDb2M911ETCNWcKEFhr sVMAnRU9Yn5RXK81g/Fh8ue2S+TsYUsC =OC3T -----END PGP SIGNATURE----- From mwinter at noaccess.com Wed Feb 25 08:28:37 2015 From: mwinter at noaccess.com (Martin Winter) Date: Tue, 24 Feb 2015 23:28:37 -0800 (PST) Subject: [atlas] Proble locations (Changed because of Geo-IP) Message-ID: So I've noticed that (at least some) probes got the location automatically updated based on Geo IP. However, this is frequently fundamentially broken. One of my probe moved from San Jose, CA to somewhere in the middle of Texas. (Broken Geo-IP location for AT&T DSL users). (The example I talk about is proble #10770) Kind of sad... not sure how many had this happening. Specially as I took care to put the exact lat/lon in the User interface in the past. Now I can only reposition it by dragging on a map - and that seems to be broken as well (at least it fails to save when I try to correct this probes location on Chrome) I wonder how many and why there was a decision to change the location. I think the location were much better before they got force-changed. - Martin Winter From jas.grewal at booking.com Wed Feb 25 09:22:11 2015 From: jas.grewal at booking.com (Grewal, Jas) Date: Wed, 25 Feb 2015 08:22:11 +0000 Subject: [atlas] Proble locations (Changed because of Geo-IP) In-Reply-To: References: Message-ID: <3CFA17D2124B0843866AC0D0D10D3E2003CCF733@AMS4-EXMB-05.corpad.adbkng.com> Agreed, how about including this critical information in the description field to get around this, perhaps? -----Original Message----- From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Martin Winter Sent: 25 February 2015 07:29 To: ripe-atlas at ripe.net Subject: [atlas] Proble locations (Changed because of Geo-IP) So I've noticed that (at least some) probes got the location automatically updated based on Geo IP. However, this is frequently fundamentially broken. One of my probe moved from San Jose, CA to somewhere in the middle of Texas. (Broken Geo-IP location for AT&T DSL users). (The example I talk about is proble #10770) Kind of sad... not sure how many had this happening. Specially as I took care to put the exact lat/lon in the User interface in the past. Now I can only reposition it by dragging on a map - and that seems to be broken as well (at least it fails to save when I try to correct this probes location on Chrome) I wonder how many and why there was a decision to change the location. I think the location were much better before they got force-changed. - Martin Winter From mwinter at noaccess.com Wed Feb 25 10:10:30 2015 From: mwinter at noaccess.com (Martin Winter) Date: Wed, 25 Feb 2015 01:10:30 -0800 (PST) Subject: [atlas] Proble locations (Changed because of Geo-IP) In-Reply-To: <3CFA17D2124B0843866AC0D0D10D3E2003CCF733@AMS4-EXMB-05.corpad.adbkng.com> References: <3CFA17D2124B0843866AC0D0D10D3E2003CCF733@AMS4-EXMB-05.corpad.adbkng.com> Message-ID: I have actually the address in it. The earlier webpage had a way to enter Lat/Lon for probes (which I can't find anymore). I think a simple Geo-Lokup based on addresses in description would have done a much better job. But a field to enter lat/lon in it and take this as a preference (if entered) without going to overwrite it would be a good start. I mainly worry on whatever happend there in this process may have misplaced a lot of probes to the wrong location. Anyone else noticed that their probe moved to a new (wrong) location? - Martin On Wed, 25 Feb 2015, Grewal, Jas wrote: > Agreed, how about including this critical information in the description field to get around this, perhaps? > > -----Original Message----- > From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Martin Winter > Sent: 25 February 2015 07:29 > To: ripe-atlas at ripe.net > Subject: [atlas] Proble locations (Changed because of Geo-IP) > > So I've noticed that (at least some) probes got the location automatically updated based on Geo IP. > However, this is frequently fundamentially broken. One of my probe moved from San Jose, CA to somewhere in the middle of Texas. (Broken Geo-IP location for AT&T DSL users). > (The example I talk about is proble #10770) > > Kind of sad... not sure how many had this happening. Specially as I took care to put the exact lat/lon in the User interface in the past. > Now I can only reposition it by dragging on a map - and that seems to be broken as well (at least it fails to save when I try to correct this probes location on Chrome) > > I wonder how many and why there was a decision to change the location. I think the location were much better before they got force-changed. > > - Martin Winter > > > > From BECHA at ripe.net Wed Feb 25 10:38:13 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Wed, 25 Feb 2015 10:38:13 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <54ECB38E.1060308@clegg.com> References: <54E66DD4.2050004@afilias.info> <20150223130847.GA15045@nic.fr> <54EB379C.1050100@sokolov.eu.org> <20150223162302.25737.qmail@f5-external.bushwire.net> <54EC4D1D.2020507@ripe.net> <54EC4EA2.1060105@ripe.net> <20150224155601.30640.qmail@f5-external.bushwire.net> <54ECA2C6.5010207@ripe.net> <20150224161423.30729.qmail@f5-external.bushwire.net> <54ECB38E.1060308@clegg.com> Message-ID: <54ED9805.9050109@ripe.net> Dear Alan, all, On 24-feb.-15 18:23, Alan Clegg wrote: > (is there a better way to show interest than to spam the mailing list?) Yes and no ;-) I am listening (as a Community Builder) - on my private email address, twitter, Jabber, conferences... and the collected feature requests are published on the roadmap, every few months. However, the advantages of the public mailing list are: transparency and encouraging participation of others. We are considering introducing the public-facing "bug tracker", however, there are no concrete plans for that yet. This request is noted, and will be weighted against all the other ones, and prioritized compared with our general plans and available people. Thanks for your interest! Vesna https://atlas.ripe.net/get-involved/feedback/ http://roadmap.ripe.net/ripe-atlas/ From astracha at ripe.net Wed Feb 25 10:45:01 2015 From: astracha at ripe.net (Alastair Strachan) Date: Wed, 25 Feb 2015 10:45:01 +0100 Subject: [atlas] Delta Softmedia Ltd (Sofia, Bulgaria) has joined RIPE Atlas Anchors Message-ID: <1492D332-7823-478F-B065-33D4A74A3FD3@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 bg-sof-as197216 and it is hosted by Delta Softmedia Ltd in Sofia, Bulgaria. 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, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From astracha at ripe.net Wed Feb 25 10:45:03 2015 From: astracha at ripe.net (Alastair Strachan) Date: Wed, 25 Feb 2015 10:45:03 +0100 Subject: [atlas] =?utf-8?q?FastVPS_Eesti_OU_=28J=C3=B5hvi=2C_Estonia=29_ha?= =?utf-8?q?s_joined_RIPE_Atlas_Anchors?= Message-ID: <0CB650B0-777A-4819-AB90-88E97C6FCD4D@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 ee-jvi-as198068 and it is hosted by FastVPS Eesti OU in J?hvi, Estonia. 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, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From camin at ripe.net Wed Feb 25 10:53:12 2015 From: camin at ripe.net (Chris Amin) Date: Wed, 25 Feb 2015 10:53:12 +0100 Subject: [atlas] Fwd: Re: Proble locations (Changed because of Geo-IP) In-Reply-To: <54ED9904.3000500@ripe.net> References: <54ED9904.3000500@ripe.net> Message-ID: <54ED9B88.2040607@ripe.net> Dear Martin, I'm sorry for this, we recently made a change which keeps the location of those probes which are geolocated (i.e. *without* a manually set address) up to date. Previously such probes were geolocated once, and never again. It was never the intention to overwrite manually given locations. Unfortunately, it seems that a number of probes were erroneously marked as being automatically geolocated when in fact their owners had carefully provided a location. We are now looking at our logs to see how many probes might have been affected by this, and whether we can automatically revert the location in those cases. As for your point about not being able to enter the location, there is a text box above the map popup which should allow you to enter a textual address. If this isn't working for you, please let me know. Apologies once again. Kind regards, Chris Amin RIPE NCC On Wed, 25 Feb 2015 01:10:30 -0800 (PST), Martin Winter wrote: > I have actually the address in it. > The earlier webpage had a way to enter Lat/Lon for probes (which I can't > find anymore). > > I think a simple Geo-Lokup based on addresses in description would have > done a much better job. > But a field to enter lat/lon in it and take this as a preference (if > entered) without going to overwrite it would be a good start. > > I mainly worry on whatever happend there in this process may have > misplaced a lot of probes to the wrong location. > Anyone else noticed that their probe moved to a new (wrong) location? > > - Martin > > > On Wed, 25 Feb 2015, Grewal, Jas wrote: > >> Agreed, how about including this critical information in the >> description field to get around this, perhaps? >> >> -----Original Message----- >> From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of >> Martin Winter >> Sent: 25 February 2015 07:29 >> To: ripe-atlas at ripe.net >> Subject: [atlas] Proble locations (Changed because of Geo-IP) >> >> So I've noticed that (at least some) probes got the location >> automatically updated based on Geo IP. >> However, this is frequently fundamentially broken. One of my probe >> moved from San Jose, CA to somewhere in the middle of Texas. (Broken >> Geo-IP location for AT&T DSL users). >> (The example I talk about is proble #10770) >> >> Kind of sad... not sure how many had this happening. Specially as I >> took care to put the exact lat/lon in the User interface in the past. >> Now I can only reposition it by dragging on a map - and that seems to >> be broken as well (at least it fails to save when I try to correct >> this probes location on Chrome) >> >> I wonder how many and why there was a decision to change the location. >> I think the location were much better before they got force-changed. >> >> - Martin Winter >> >> >> >> > > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2713 bytes Desc: S/MIME Cryptographic Signature URL: From mwinter at noaccess.com Wed Feb 25 12:50:07 2015 From: mwinter at noaccess.com (Martin Winter) Date: Wed, 25 Feb 2015 03:50:07 -0800 (PST) Subject: [atlas] Fwd: Re: Proble locations (Changed because of Geo-IP) In-Reply-To: <54ED9B88.2040607@ripe.net> References: <54ED9904.3000500@ripe.net> <54ED9B88.2040607@ripe.net> Message-ID: Chris, On Wed, 25 Feb 2015, Chris Amin wrote: > Dear Martin, > > I'm sorry for this, we recently made a change which keeps the location > of those probes which are geolocated (i.e. *without* a manually set > address) up to date. Previously such probes were geolocated once, and > never again. It was never the intention to overwrite manually given > locations. > > Unfortunately, it seems that a number of probes were erroneously marked > as being automatically geolocated when in fact their owners had > carefully provided a location. We are now looking at our logs to see how > many probes might have been affected by this, and whether we can > automatically revert the location in those cases. Good. I mainly worry about all the probes where noone noticed the location change. > As for your point about not being able to enter the location, there is a > text box above the map popup which should allow you to enter a textual > address. If this isn't working for you, please let me know. Interesting.. never thought about clicking there, as it already showed the *correct* address in it. Beside of not being able to save, that seems to be an issue with Chrome (I've used Chrome 40.0.2214.115 on Mac OSX). Same issue with the textfield: It just says "saving..." below and never succeeds. Trying the same with Firefox worked correctly. - Martin > Apologies once again. > > Kind regards, > Chris Amin > RIPE NCC > > > On Wed, 25 Feb 2015 01:10:30 -0800 (PST), Martin Winter wrote: > >> I have actually the address in it. >> The earlier webpage had a way to enter Lat/Lon for probes (which I can't >> find anymore). >> >> I think a simple Geo-Lokup based on addresses in description would have >> done a much better job. >> But a field to enter lat/lon in it and take this as a preference (if >> entered) without going to overwrite it would be a good start. >> >> I mainly worry on whatever happend there in this process may have >> misplaced a lot of probes to the wrong location. >> Anyone else noticed that their probe moved to a new (wrong) location? >> >> - Martin >> >> >> On Wed, 25 Feb 2015, Grewal, Jas wrote: >> >>> Agreed, how about including this critical information in the >>> description field to get around this, perhaps? >>> >>> -----Original Message----- >>> From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of >>> Martin Winter >>> Sent: 25 February 2015 07:29 >>> To: ripe-atlas at ripe.net >>> Subject: [atlas] Proble locations (Changed because of Geo-IP) >>> >>> So I've noticed that (at least some) probes got the location >>> automatically updated based on Geo IP. >>> However, this is frequently fundamentially broken. One of my probe >>> moved from San Jose, CA to somewhere in the middle of Texas. (Broken >>> Geo-IP location for AT&T DSL users). >>> (The example I talk about is proble #10770) >>> >>> Kind of sad... not sure how many had this happening. Specially as I >>> took care to put the exact lat/lon in the User interface in the past. >>> Now I can only reposition it by dragging on a map - and that seems to >>> be broken as well (at least it fails to save when I try to correct >>> this probes location on Chrome) >>> >>> I wonder how many and why there was a decision to change the location. >>> I think the location were much better before they got force-changed. >>> >>> - Martin Winter >>> >>> >>> >>> >> >> >> >> >> > > > From dquinn at ripe.net Wed Feb 25 16:42:15 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Wed, 25 Feb 2015 16:42:15 +0100 Subject: [atlas] some probes not returning NSID In-Reply-To: <54E66DD4.2050004@afilias.info> References: <54E66DD4.2050004@afilias.info> Message-ID: <54EDED57.1020103@ripe.net> On 20/02/15 00:12, Paul Vlaar wrote: > BTW, I am always getting "null" on the NSID field in the web interface, > regardless of whether it lives in abuf, or not. This seems to be a bug. Hi all, I just thought that I'd mention that with Paul's help, I've managed to find and fix this issue and the changes were pushed out earlier today. From bortzmeyer at nic.fr Thu Feb 26 09:53:27 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 26 Feb 2015 09:53:27 +0100 Subject: [atlas] [ietf-secretariat@ietf.org: New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols] Message-ID: <20150226085327.GA28429@nic.fr> It could be interesting to use Atlas probes for such measurements, no? -------------- next part -------------- An embedded message was scrubbed... From: IETF Secretariat Subject: New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols Date: Wed, 25 Feb 2015 10:25:49 -0800 Size: 8214 URL: From pierky at pierky.com Thu Feb 26 12:27:23 2015 From: pierky at pierky.com (Pier Carlo Chiodi) Date: Thu, 26 Feb 2015 12:27:23 +0100 Subject: [atlas] [ietf-secretariat@ietf.org: New Non-WG Mailing List: hops -- Measuring deployability of new transport protocols] In-Reply-To: <20150226085327.GA28429@nic.fr> References: <20150226085327.GA28429@nic.fr> Message-ID: On 2015-02-26 09:53, Stephane Bortzmeyer wrote: > It could be interesting to use Atlas probes for such measurements, no? ... > The objective > is to determine a set of measurements that can be made as a side > effect of the normal operation of the networking stack, and a > reporting format that provides some visibility into the scope and > nature of middlebox impact while addressing end-user privacy and > business confidentiality concerns. Just to stay on the subject: https://labs.ripe.net/Members/julien_colmonts/tracebox-a-nice-tool-to-detect-middleboxes -- Pier Carlo Chiodi http://pierky.com From pvlaar at afilias.info Thu Feb 26 17:43:02 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Thu, 26 Feb 2015 10:43:02 -0600 Subject: [atlas] some probes not returning NSID In-Reply-To: <54EDED57.1020103@ripe.net> References: <54E66DD4.2050004@afilias.info> <54EDED57.1020103@ripe.net> Message-ID: <54EF4D16.4050909@afilias.info> On 25/2/15 9:42 AM, Daniel Quinn wrote: > Hi all, I just thought that I'd mention that with Paul's help, I've > managed to find and fix this issue and the changes were pushed out > earlier today. I can confirm that I see NSID results in the web interface now. Thanks Daniel, ~paul -- Paul Vlaar DNS Infrastructure Group Afilias e-mail: pvlaar at afilias.info phone: +1-416-673-4078 -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-02-26 at 10.38.57 AM.png Type: image/png Size: 64590 bytes Desc: not available URL: From astracha at ripe.net Fri Feb 27 08:19:13 2015 From: astracha at ripe.net (Alastair Strachan) Date: Fri, 27 Feb 2015 08:19:13 +0100 Subject: [atlas] University of Twente (Enschede, The Netherlands) has joined RIPE Atlas Anchors Message-ID: <6D679F77-A79A-4EE4-94DE-94F35D114364@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 nl-ens-as1133 and it is hosted by University of Twente in Enschede, The Netherlands 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, RIPE Atlas Team -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: