- ripe-atlas - mailman.ripe.net

Streaming API, endTime parameter is ignored
by Roberto Nunziato 10 Feb '17

10 Feb '17

Hello everybody, I am an Italian student and I am working with the RIPE Atlas Streaming API. I am trying to replay events that have happened in the past, so I am using the optional parameter endTime in the code below. Now, the stream starts at the specified time but it never ends. Am I doing anything wrong? Is this a bug? var socket = io(“https://atlas-stream.ripe.net <https://atlas-stream.ripe.net/>:443” , {path: “/stream/socket.io <http://socket.io/>”}); startTime = 1486256400 //05-02-17 h: 01:00GMT endTime = 1486258200 //05-02-17 h: 01:30GMT socket.emit(“atlas_subscribe”, {stream_type: “result”, startTime: startTime, endTime: endTime, msm: 1962548}); Best, Roberto Nunziato

2 3

New on RIPE Labs: Campaign to Sponsor 15 RIPE Atlas Anchors
by Mirjam Kuehne 31 Jan '17

31 Jan '17

Dear colleagues, The RIPE NCC is pleased to announce that we will be sponsoring 15 new RIPE Atlas anchors in 2017. This article provides details about the campaign and introduces the criteria that will be used to decide which applicants will receive sponsorship: https://labs.ripe.net/Members/alun_davies/campaign-to-sponsor-15-ripe-atlas… Kind regards, Mirjam Kuhne RIPE NCC

1 0

Reporting incorrect locations
by Marty Strong 30 Jan '17

30 Jan '17

Hi RIPE Atlas folks, Is there somewhere we can go to report a suspected incorrect location of an Atlas probe? This probe: https://atlas.ripe.net/probes/16578/ Is marked as in China, but is clearly in Australia. I couldn’t see anywhere I should report this. Marty

2 3

high v6 user-base, less atlas probes
by Bajpai, Vaibhav 28 Jan '17

28 Jan '17

Hello, -- sorry for cross-posting Here is a list of top 20 countries that have a large v6 user-base [*] but are underrepresented by RIPE Atlas due to less number of deployed dual-stacked probes. Consider hosting a dual-stacked probe in these regions to help remove the region-based bias that v6 studies using RIPE Atlas may otherwise have: Full paper available here: http://goo.gl/hWGveA (§4) +----+------------+-----------| | CC | v6 Users | v6 Probes | |-----+----+------------+-----------| | 01 | BE | 56.48 % | 2.82 % | | 02 | LU | 35.23 % | 0.61 % | | 03 | GR | 33.66 % | 1.39 % | | 04 | CH | 33.48 % | 3.82 % | | 05 | PT | 29.01 % | 0.74 % | | 06 | IN | 22.25 % | 0.09 % | | 07 | US | 33.00 % | 13.21 % | | 08 | DE | 40.07 % | 21.25 % | | 09 | EC | 18.76 % | 0.04 % | | 10 | JP | 19.69 % | 1.35 % | | 11 | GB | 24.63 % | 7.00 % | | 12 | EE | 16.55 % | 0.26 % | | 13 | CA | 17.83 % | 1.91 % | | 14 | FI | 16.68 % | 1.39 % | | 15 | MY | 14.90 % | 0.13 % | | 16 | IE | 13.22 % | 0.87 % | | 17 | NO | 14.02 % | 1.83 % | | 18 | BR | 12.56 % | 0.83 % | | 19 | AU | 12.76 % | 1.09 % | |-----+----+------------+-----------| [*] The estimation of number of IPv6 users is taken from APNIC dataset: http://labs.apnic.net/dists/v6dcc.html -- Vaibhav -------------------------- Vaibhav Bajpai www.vaibhavbajpai.com Postdoctoral Researcher TU Munich, Germany --------------------------

1 0

RIPE Atlas Interface Hackathon, 21-22 May, Copenhagen
by Vesna Manojlovic 23 Jan '17

23 Jan '17

Dear colleagues, Calling all front-end developers, UI designers, network operators and other enthusiastic coders! The next RIPE Atlas hackathon takes place 21-22 May in Copenhagen, the weekend before the RIPE 72 Meeting. We're looking for creative thinkers to help us develop new interfaces for RIPE Atlas. All source code developed during the hackathon will be publicly licensed and available on GitHub, and will be free for the entire community to use. -------------------- How to Apply -------------------- Interested? Learn more and apply online today! https://atlas.ripe.net/hackathon/Interface/?pk_campaign=hackathon&pk_kwd=li… *The application deadline is 23 March* Please note that we are unfortunately unable to provide travel or accommodation funding. We look forward to seeing you there! Regards, Vesna and the RIPE Atlas Team

1 4

RIPE Atlas v1 APIs have been decommissioned
by Robert Kisteleki 20 Jan '17

20 Jan '17

Dear All, As we've been announcing it for a while now (see https://www.ripe.net/ripe/mail/archives/ripe-atlas/2016-September/003017.ht… and https://www.ripe.net/ripe/mail/archives/ripe-atlas/2017-January/003128.html), the v1 APIs were to be decommissioned by the end of last year / early this year. This step actually happened on Wednesday this week (18 January, around 14h CET). This means that queries to these APIs give 404s (for GETs) and 405s (for other methods, which we may change to 404 instead). This is also the cause for the issues Stéphane was experiencing. Full documentation on the v2 APIs and other features are available at https://atlas.ripe.net/docs/ Apologies for not sending this mail already on Wednesday. Regards, Robert Kisteleki RIPE NCC

1 0

traceroute measurement with abnormally small RTT
by Wenqin SHAO 19 Jan '17

19 Jan '17

Dear list, I recently found a ‘weird’ traceroute measurement record in the sense that: with paris id set, it has different IP addresses for a given hop; after it reached the destination, it tried one more hop; the final hop reported abnormally small RTT. I’d appreciate your views on how this happened. Here is how to identify the measurement in question: (the concerned record is as well provided at the end the mail) from ripe.atlas.cousteau import AtlasResultsRequest filters = dict(msm_id=5010, probe_ids=[10460], start=1482177890, stop=1482177900) _, results = AtlasResultsRequest(**filters).create() It’s a IPv4 traceroute measurement toward DNS b root, 192.228.79.201. What you’ll see is: starting from hop 14, the 3 measurements for the same hop come from different IP address: hop 14: 184.105.80.202, 72.52.92.122 hop 15: 72.52.92.122, 216.218.223.28 hop 16: 216.218.223.28, 130.152.181.189 hop 17: 130.152.181.189, 206.117.5.22 hop 18: 206.117.5.22, 192.228.79.201 hop 19: 192.228.79.201 My first doubt is with Paris traceroute is it still possible that response IP can change due to LB mechanism on the returning path? At hop 18, the traceroute actually already reached the destination, but it continued to perform the hop 19, why? At hop 19, there is one measurement from 192.228.79.201 reporting abnormally small RTT of 0.449ms. How come? Can that happen to other measurements as well, under what circumstances? The above listed neighbouring hops always share one IP address, which makes it seem like a data formatting issue. Is there a known bug? Thanks in advance for your attention. Best regards, wenqin Here below the measurement in question: ==== [ { "lts":-1, "size":40, "from":"176.227.133.141", "dst_name":"192.228.79.201", "fw":4740, "proto":"UDP", "af":4, "msm_name":"Traceroute", "prb_id":10460, "result":[ { "result":[ { "rtt":0.533, "ttl":255, "from":"192.168.1.1", "size":28 }, { "rtt":0.418, "ttl":255, "from":"192.168.1.1", "size":28 }, { "rtt":0.405, "ttl":255, "from":"192.168.1.1", "size":28 } ], "hop":1 }, { "result":[ { "x":"*" }, { "x":"*" }, { "x":"*" } ], "hop":2 }, { "result":[ { "rtt":677.27, "ttl":253, "from":"10.130.162.13", "size":28 }, { "rtt":660.216, "ttl":253, "from":"10.130.162.13", "size":28 }, { "rtt":709.112, "ttl":253, "from":"10.130.162.13", "size":28 } ], "hop":3 }, { "result":[ { "rtt":666.445, "ttl":252, "from":"10.130.162.250", "size":28 }, { "rtt":995.219, "ttl":252, "from":"10.130.162.250", "size":28 }, { "rtt":668.192, "ttl":252, "from":"10.130.162.250", "size":28 } ], "hop":4 }, { "result":[ { "rtt":681.02, "ttl":250, "from":"10.130.162.82", "size":28 }, { "rtt":652.502, "ttl":250, "from":"10.130.162.82", "size":28 }, { "rtt":673.857, "ttl":250, "from":"10.130.162.82", "size":28 } ], "hop":5 }, { "result":[ { "rtt":685.088, "ttl":250, "from":"88.202.127.129", "size":28 }, { "rtt":665.164, "ttl":250, "from":"88.202.127.129", "size":28 }, { "rtt":657.344, "ttl":250, "from":"88.202.127.129", "size":28 } ], "hop":6 }, { "result":[ { "rtt":669.097, "ttl":249, "from":"88.202.127.121", "size":28 }, { "rtt":743.974, "ttl":249, "from":"88.202.127.121", "size":28 }, { "rtt":637.311, "ttl":249, "from":"88.202.127.121", "size":28 } ], "hop":7 }, { "result":[ { "ttl":243, "rtt":692.425, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 }, { "ttl":243, "rtt":659.768, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 }, { "ttl":243, "rtt":698.084, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":439171 } ], "class":1 } ] }, "from":"88.202.127.6", "size":140 } ], "hop":8 }, { "result":[ { "ttl":247, "rtt":684.096, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 }, { "ttl":247, "rtt":685.871, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 }, { "ttl":247, "rtt":736.12, "icmpext":{ "rfc4884":0, "version":2, "obj":[ { "type":1, "mpls":[ { "s":1, "ttl":1, "exp":0, "label":311104 } ], "class":1 } ] }, "from":"10.130.2.42", "size":140 } ], "hop":9 }, { "result":[ { "rtt":675.198, "ttl":246, "from":"10.130.1.201", "size":28 }, { "rtt":671.127, "ttl":246, "from":"10.130.1.201", "size":28 }, { "rtt":683.236, "ttl":246, "from":"10.130.1.201", "size":28 } ], "hop":10 }, { "result":[ { "rtt":736.688, "ttl":54, "from":"37.49.236.10", "size":28 }, { "rtt":697.844, "ttl":54, "from":"37.49.236.10", "size":28 }, { "rtt":818.184, "ttl":54, "from":"37.49.236.10", "size":28 } ], "hop":11 }, { "result":[ { "rtt":992.33, "ttl":53, "from":"184.105.213.173", "size":28 }, { "rtt":920.759, "ttl":53, "from":"184.105.213.173", "size":28 }, { "rtt":966.019, "ttl":53, "from":"184.105.213.173", "size":28 } ], "hop":12 }, { "result":[ { "x":"*" }, { "rtt":428.86, "ttl":52, "from":"184.105.80.202", "size":28 }, { "rtt":372.607, "ttl":52, "from":"184.105.80.202", "size":28 } ], "hop":13 }, { "result":[ { "rtt":448.726, "ttl":52, "from":"184.105.80.202", "size":28 }, { "rtt":427.897, "ttl":51, "from":"72.52.92.122", "size":28 }, { "rtt":550.12, "ttl":51, "from":"72.52.92.122", "size":28 } ], "hop":14 }, { "result":[ { "rtt":422.308, "ttl":51, "from":"72.52.92.122", "size":28 }, { "rtt":447.841, "ttl":241, "from":"216.218.223.28", "size":68 }, { "rtt":339.084, "ttl":241, "from":"216.218.223.28", "size":68 } ], "hop":15 }, { "result":[ { "rtt":470.177, "ttl":241, "from":"216.218.223.28", "size":68 }, { "rtt":338.323, "ttl":241, "from":"130.152.181.189", "size":68 }, { "rtt":482.44, "ttl":241, "from":"130.152.181.189", "size":68 } ], "hop":16 }, { "result":[ { "rtt":359.104, "ttl":241, "from":"130.152.181.189", "size":68 }, { "rtt":630.604, "ttl":48, "from":"206.117.5.22", "size":68 }, { "rtt":195.704, "ttl":48, "from":"206.117.5.22", "size":68 } ], "hop":17 }, { "result":[ { "rtt":759.236, "ttl":48, "from":"206.117.5.22", "size":68 }, { "rtt":369.954, "ttl":48, "from":"192.228.79.201", "size":68 }, { "rtt":431.369, "ttl":48, "from":"192.228.79.201", "size":68 } ], "hop":18 }, { "result":[ { "rtt":397.795, "ttl":48, "from":"192.228.79.201", "size":68 }, { "x":"*" }, { "ttl":48, "rtt":0.449, "ittl":2, "from":"192.228.79.201", "size":68 } ], "hop":19 } ], "timestamp":1482177892, "src_addr":"192.168.1.115", "paris_id":15, "endtime":1482177928, "type":"traceroute", "dst_addr":"192.228.79.201", "msm_id":5010 } ]

2 1

Atlas API down?
by Stephane Bortzmeyer 18 Jan '17

18 Jan '17

RIPEAtlas.RequestSubmissionError: Status 405, reason "{"error":{"status":405,"code":104,"detail":"Method \"POST\" not allowed.","title":"Method Not Allowed"}}" Just when I wanted to investigate pool.ntp.org failure :-(

1 0

Surplus RIPE Atlas credits
by Michael Oghia 13 Jan '17

13 Jan '17

Hi everyone, I host a probe but do not create measurements. As such, I have a large surplus of unused credits. Is anyone in need of credits and would like for me to transfer them? Best, -Michael __________________ Michael J. Oghia iGmena <http://igmena.org/> communications manager Independent #netgov consultant & editor Belgrade, Serbia Skype: mikeoghia Twitter <https://www.twitter.com/MikeOghia> *|* LinkedIn <https://www.linkedin.com/in/mikeoghia>

7 13

Maximum daily spending boundaries?
by Sebastian Castro 12 Jan '17

12 Jan '17

Hi: While scheduling a few one-off measurements, I'm constantly hitting the "Maximum daily spending" limit, however I don't have any ongoing measurements and just a handful of one-off measurements going at a expense of ~5000 credits each. When is the daily spending is reset? Midnight in some time zone? Something different? This case seems to be a race condition or something like that, as few measurements attempts actually go through, while the rest is rejected. A consistent behavior seems to be "from here no other measurement will succeed" Cheers! -- Sebastian Castro Technical Research Manager NZRS Ltd. desk: +64 4 495 2337 mobile: +64 21 400535

2 1