- ripe-atlas - mailman.ripe.net

Questions with regard to the measurement status and running time
by Jerome Mao 20 Oct '23

20 Oct '23

Hi RIPE Atlas Team and Community, I would like to know more about the status of measurements - I have scheduled a one-off ping measurement which utilized 15 anchors. I polled the measurement status and results from my local desktop to the restful API through cousteau Python lib. The results were returned to me in less than a minute, but it took around 13 minutes for the measurement to transition from "ongoing" to "stopped." On the other side, the time delta between the "requested start time" and "requested stop time" on the RIPE Atlas portal is 9 minutes. My questions are: 1. Why is the measurement "ongoing" even if the results have already been made available? 2. What is the meaning of the "requested start time" and "requested stop time" on the RIPE Atlas portal? 3. Will a one-off measurement release one slot from the measurement rate limit once its result becomes available even if it’s still in "ongoing" state? Thanks! Best, Jerome

3 3

HE "Supertraceroute" exposes ATLAS traceroute functionality to the public
by me＠natha.info 19 Oct '23

19 Oct '23

Hi all, As mentioned by Lukas, NLNOG Ring is also used in the "supertraceroute" project from HE. The NLNOG Board just published a statement regarding this on the NLNOG mailing list: http://mailman.nlnog.net/pipermail/nlnog/2023-October/003099.html Kind regards, Nathalie Trenaman (also on the NLNOG Board)

2 1

HE "Supertraceroute" exposes ATLAS traceroute functionality to the public
by Lukas Tribus 19 Oct '23

19 Oct '23

Hello, FYI HE's new "supertraceroute" exposes ATLAS traceroute functionality to the public: https://bgp.he.net/traceroute/ Other sources are (NLNOG) RING nodes and other projects. Interesting approach, not sure if I should be happy about this, but I guess HE is paying for it with Atlas credits. Lukas

2 1

NTP empty results ('result': [{'x': '*'}])
by Giovane C. M. Moura 12 Oct '23

12 Oct '23

Hi folks, I am getting some NTP results in the following format: 'result': [{'x': '*'}], Does anyone know waht is this supposed to mean? is it like the measurement did not run? See blob below: {'fw': 5080, 'mver': '2.6.2', 'lts': 20, 'dst_name': '186.155.28.147', 'dst_addr': '186.155.28.147', 'src_addr': '10.10.31.19', 'proto': 'UDP', 'af': 4, 'result': [{'x': '*'}], 'msm_id': 47867316, 'prb_id': 33745, 'timestamp': 1671799154, 'msm_name': 'Ntp', 'from': '85.238.41.3', 'type': 'ntp', 'group_id': 47867316, 'stored_timestamp': 1671799249}] thanks, /giovane

2 1

New measurement form is now live (and default)
by Stephen Suess 12 Oct '23

12 Oct '23

Hello Atlas Community, We have just pushed the release version of the new measurement form (that was formerly in beta) to production. It is now the default (and lives at the same url as the old form) and the old one has been renamed legacy and will remain available for a few weeks in the menu and linked from the new form. Please check it out and let us know if you find any issues. We really appreciate the feedback given by the community during the beta, it helped us evolve and improve the form significantly. You can find the new form at https://atlas.ripe.net/measurements/form/ Thanks! Stephen RIPE Atlas UI

1 0

Changes to RIPE Atlas API keys
by Robert Kisteleki 04 Oct '23

04 Oct '23

Dear RIPE Atlas users, We'd like to update you on some upcoming changes regarding API keys in RIPE Atlas. TL;DR nothing changes regarding how you can use your API keys in the short term - as long as you're actually using them. However, we'll change how unused or forgotten keys are handled as well as remove the less secure in-URL use of them. At the moment RIPE Atlas users can query their existing API keys via the UI and API, including the possibility to retrieve old keys. In order to improve the security of how we handle these, we'll introduce the following changes in October 2023: * The listing (retrieval) of keys will only reveal parts of the keys (enough to identify them) in the API as well as in the UI. * We'll add the ability to "regenerate" an API key, which will replace the secret UUID of the key while keeping exactly the same permissions. * Unused API keys will automatically be frozen after 1 year of not being used. Active keys (i.e. the ones that have been used at least once) will not be frozen. You still have the ability to save your keys until these changes are done and, as written above, you will be able to regenerate them later. We'll notify this list when the changes are about to be done. In addition, in order to further increase the security of our system, in the long run we'll make changes about how these API keys are communicated to the API: * At the moment the API accepts these either in HTTP headers ("Authorization" header) or in the URL (?key=xyz), although the Authorization header version has been documented as the preferred version for some time. * We'll deprecate and remove the ability to use the URL form in about a year (around October 2024). * We plan to send further reminders about this change over time, as well as reaching out to heavy users of the to-be-removed format. Regards, Robert Kisteleki RIPE Atlas team

1 1

RIPE Atlas Quarterly Planning Q4 2023
by Robert Kisteleki 04 Oct '23

04 Oct '23

Dear colleagues, We have published our next quarterly plans for RIPE Atlas on our website: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue discussing the five proposals for changing the RIPE Atlas behaviour and working on renewing the big data backend. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki Principal Engineer RIPE NCC

1 0

Changes to RIPE Atlas API auth status codes on 2 Oct
by Chris Amin 02 Oct '23

02 Oct '23

Dear colleagues, Currently the RIPE Atlas REST API (https://atlas.ripe.net/api/v2/) returns a 403 Forbidden status code in two cases: * When a request requires authentication but the user has not provided any credentials, or has provided incorrect credentials * When a user has authenticated correctly, but they or their API key lacks the permissions needed for a particular request Distinguishing between these two cases is important because in the first case the client can potentially get access by authenticating, and in the second case there is no point in retrying authentication with the same credentials. In order to enable this distinction, and to generally conform to web standards and best practices, on Monday, 2nd October we will change the REST API so that a completely unauthenticated request will receive a response with a 401 Unauthorized status code. The 403 Forbidden status code will still be returned for users and API keys that are authenticated but lack the necessary permissions for the request. As a temporary migration measure, the API will keep the same behaviour (always return 403) if either: * The "Referer" header contains "RIPE Atlas Tools" and a version string <= 3.1.1, or * An "X-Compat" header is set and contains the string "auth-2022" This temporary measure is guaranteed to work for the rest of 2022, after which it will be removed and the API will always make the 401/403 distinction. Kind regards, Chris Amin RIPE Atlas team

2 4

Will probes catch up?
by Ernst J. Oud 21 Sep '23

21 Sep '23

Hi, Some of my probes, all on different providers, (for instance: https://atlas.ripe.net/probes/1005104/#tab-builtins) have not catched up after the recent disruption. Will this happen automatically? They are connected, streaming results are ok., so I guess I don’t need to restart them? Regards, Ernst J. Oud

2 1

Atlas fully down..
by Ernst J. Oud 20 Sep '23

20 Sep '23

Considering the fact that all of Atlas is completely down for more than 24 hrs., I find the silence a bit deafening. No status updates, nothing. Weird. Not up to RIPE standards. Regards, Ernst J. Oud

7 16