- 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

One-off measurements stopped after 5-6 minutes without results
by Gerdriaan Mulder 20 Sep '23

20 Sep '23

Hi list, A few hours ago (around 15:00Z), I launched some one-off measurements[1][2][3] on the platform for a select number of probes (based on ASN and region). The target in all three cases was 2a02:1807:1020:700::1 (no hostname, purely the address). Although the number of requested and participating probes varied a bit, it seems none of the measurements yielded any results. At the time I didn't look at recent posts on this mailing list, nor was I aware of this ongoing incident[4] on the Atlas backend. It seems like that incident might be the cause of the (current) unavailability of these results. It would be great if anyone can confirm that (viewing results of) user-defined measurements are affected as well. Aside, I suppose the following messages on "My RIPE Atlas Dashboard" are also caused by the mentioned incident[4]? --->8--- 2023-09-18 16:40 UTC Your probe #11nnn was automatically untagged as "system: Resolves AAAA Correctly" 2023-09-18 16:40 UTC Your probe #11nnn was automatically untagged as "system: Resolves A Correctly" 2023-09-18 16:20 UTC Your probe #11nnn was automatically untagged as "system: IPv6 Works" 2023-09-18 16:20 UTC Your probe #11nnn was automatically untagged as "system: IPv4 Works" ---8<--- Perhaps the incident page[4] can include a few lines of the current (estimated) impact, as well. Best regards, Gerdriaan Mulder [1] https://atlas.ripe.net/frames/measurements/60161706/ (default IPv6 traceroute) [2] https://atlas.ripe.net/frames/measurements/60162230/ (IPv6 traceroute, paris=0) [3] https://atlas.ripe.net/frames/measurements/60162753/ (default IPv6 ping) [4] https://status.ripe.net/incidents/wfd7qywz3v68

3 4

Issues with Atlas back-end
by Ernst J. Oud 19 Sep '23

19 Sep '23

Hi, From September 18th there is an issue with the Atlas back-end, already 9 hours delay. Built-ins show data until around 14:00 UTC. It is now midnight. I am confused, the status page (https://status.ripe.net/) at the bottom says: “Resolved - The backend team could restore the service level and with that issues in RIPEstat stopped as well. Sep 18, 15:11 UTC” It clearly is not resolved. On the top of that status page it says: “Investigating - We are experiencing issues with the RIPE Atlas backend and currently are investigating this issue. Sep 18, 2023 - 14:07 UTC” So what is the status? Regards, Ernst J. Oud

2 1

New Atlas Measurement Creation Form (BETA)
by Stephen Suess 18 Sep '23

18 Sep '23

Hello Atlas fans, As part of our ongoing User Interface renewal activity we've been working on a redesign of the measurement creation form. Today, we're excited to announce the release of this new form in beta, and we would love your feedback and suggestions as we continue to develop it. Notable improvements include: - A simplified and cleaner user interface. - Client-side functionality, eliminating the need for external libraries, websites, or APIs (except for cost calculations and final submit). - Enhanced performance. - Mobile-friendly design. - Clearer probe selection information. - Presentation of API specification with and without the cURL command. You can find the new form at https://atlas.ripe.net/mform or in the menu under "Measurements -> Create Measurement (BETA)". Your input and feedback is highly appreciated, you can reply to this message or directly to me or in the forum at https://forum.ripe.net/t/new-measurement-form-beta/678 Thanks! Stephen RIPE Atlas UI

1 0

Built-ins tab in Atlas web interface does not respond
by Ernst J. Oud 11 Sep '23

11 Sep '23

Hi, In the web interface clicking the tab “Built-ins” does not work, it shows “loading” and nothing happens. Tried different browsers. Regards, Ernst J. Oud

2 3

Fwd: Questions with regard to the measurement status and running time
by Ernst J. Oud 08 Sep '23

08 Sep '23

> From: "Ernst J. Oud" <ernstoud(a)gmail.com> > Date: 7 September 2023 at 20:46:53 CEST > To: Jerome Mao <jxm959(a)case.edu> > Subject: Re: [atlas] Questions with regard to the measurement status and running time > > My 0.02 euro; did you get the results of all 15 probes in that short period? I use Magellan to get results and after a minute sometimes not all results are in. Magellan has two options in the latest version; a timeout to stop streaming results after for instance 30 seconds or stop after a specified number of results have been received. > > I believe probes get instructions from controllers and ofcourse they don’t receive those all at the same time. Also probes might be busy I guess doing their default measurements (every 4 minutes). So it might take a while, I have seen results coming in after a couple of minutes. > > Not sure the above is correct, just my thoughts. > > Regards, > > Ernst J. Oud

2 1

Verdien 3.0.3
by Ernst J. Oud 07 Sep '23

07 Sep '23

Hi, @Chris Amin: Yes, commit c999953, version 3.0.3 completely solves this. My gratitude is larger than the losses Mr. Musk is making now that Twitter is going down the drain :-) Thanks! Regards, Ernst J. Oud

5 4

Probe issues - now recovered
by Nigel Metheringham 04 Sep '23

04 Sep '23

Probe Id 22680 This v3 probe started playing up a couple of months back but I had not had a chance to properly investigate until this weekend. Symptoms were that it disconnected and reconnected every minute or so - my August availability report was nearly 14K lines long! Packet trace showed that it was connecting to the RIPE atlas hosts on port 433 (but talking ssh), and after a minute or so was sent a FIN from the RIPE end. Tried a few things without success, so replaced the USB stick this morning, and so far (only a few hours in) that appears to have fixed the issue... The replaced USB stick was the original I got with the hardware something over 8 years back. Nigel.

2 1

Link-Local ICMP messages for Atlas probe
by Daryl Morse 03 Sep '23

03 Sep '23

I used WireShark on the WAN interface and I can confirm that the messages are all ping requests. Further, I can confirm that all of the addresses have been mangled. They are logged as fe80:5::, but the correct addresses are fe80::. I created a bug report. -----Original Message----- From: Michel Stam <mstam(a)ripe.net> Hi Daryl, Can't say I've seen it before, can the firewall be a bit too strict? I read ICMP messages, but I don't see this in the log you post. Do you have any idea what sort of ICMP messages? Regards, Michel

2 1

Link-Local ICMP messages for Atlas probe
by Daryl Morse 18 Aug '23

18 Aug '23

I've been hosting an Atlas probe since February 2019. I have native dual-stack gigabit fibre internet service and my router is pfSense. Recently, I noticed that there are hundreds of messages in the log of the router like the following: Aug 12 22:38:54 kernel cannot forward src fe80:5::1cce:5fff:fe02:61b6, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 22:36:06 kernel cannot forward src fe80:5::e65d:370f:fc45:b5ba, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 22:11:31 kernel cannot forward src fe80:5::3c01:20ff:fee5:f601, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 17:45:08 kernel cannot forward src fe80:5::2a0:a50f:fcdb:db7c, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 15:47:09 kernel cannot forward src fe80:5::2a0:a50f:fcb9:c28e, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 08:13:04 kernel cannot forward src fe80:5::2a0:a50f:fc8a:8134, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 06:55:33 kernel cannot forward src fe80:5::bac2:530f:fc39:164a, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 03:39:05 kernel cannot forward src fe80:5::2a0:a50f:fc8a:85c0, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 01:17:54 kernel cannot forward src fe80:5::e6fc:820f:fcea:2016, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 12 00:55:09 kernel cannot forward src fe80:5::ee9e:cd0f:fc0d:79d4, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 15:47:11 kernel cannot forward src fe80:5::4271:830f:fce5:7fa, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 15:25:42 kernel cannot forward src fe80:5::bac2:530f:fcd4:fdd2, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 07:33:53 kernel cannot forward src fe80:5::cd08:c204:cc63:2d32, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 06:17:19 kernel cannot forward src fe80:5::fe33:420f:fcdc:5932, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 11 04:49:00 kernel cannot forward src fe80:5::7e25:860f:fc44:6742, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 22:41:25 kernel cannot forward src fe80:5::9ca0:15ff:fe87:842e, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 14:38:59 kernel cannot forward src fe80:5::c80a:daff:fe92:b8b7, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 10:55:07 kernel cannot forward src fe80:5::2a0:a50f:fc8a:6ea0, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 08:57:19 kernel cannot forward src fe80:5::46aa:500f:fceb:ad66, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 05:47:09 kernel cannot forward src fe80:5::b68a:5f0f:fcb2:1040, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 03:24:58 kernel cannot forward src fe80:5::2a0:a50f:fcb6:5ea2, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 03:08:55 kernel cannot forward src fe80:5::2a0:a50f:fc90:9d4, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 00:17:07 kernel cannot forward src fe80:5::e65d:370f:fc44:15ba, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 Aug 10 00:07:07 kernel cannot forward src fe80:5::2a0:a50f:fcb7:7c, dst 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1 The messages occur in groups of three, spaced a few seconds apart. All of the messages start with fe80:5. Even if I strip off the "5", none of them seem to convert into MAC addresses, so I can't use that to figure out what type of device is pinging the probe. There are no entries in the NDP table corresponding to these messages. I have no idea how long this has been happening. I only noticed it when I was setting up a new server to host pfsense. My probe is RIPE-Atlas-Probe-52209. I'm interested to know if anyone else has experienced this.

5 9

repeating v2 probe usb failure
by Randy Bush 16 Aug '23

16 Aug '23

probe 25898 had a usb failure. i did the unplug usb, power cycle, wait, replug usb. it worked for most of a day and then failed again. rinse repeat. oops, this last time, it has yet to return. can i just order a usb off the net and replace it? or do i just replace the unit? randy

5 6

Probe with ever changing upstreams/ASs?
by Carsten Schiefner 04 Aug '23

04 Aug '23

All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C.

3 3

System tag
by Ernst J. Oud 04 Aug '23

04 Aug '23

I noticed that the system tag “IPv4 stable 1d” is gone from my probe at: https://atlas.ripe.net/probes/1005104/ I use that tag as a criteria to select active orobes for measurements. But I noticed that my own probe was not included in my measurements. Which is weird since my probe has been online for 2.5 days (normally it is more stable, but my ISP had a small downtime). So my question is what triggers this tag? The tag is self explanatory but what does “stable” mean? Regards, Ernst J. Oud

3 3

Re: [atlas] Probe with ever changing upstreams/ASs?
by Ponikierski, Grzegorz 03 Aug '23

03 Aug '23

+ripe-atlas Regards, Grzegorz From: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Date: Thursday, 3 August 2023 at 17:49 To: Carsten Schiefner <carsten(a)schiefner.de> Subject: Re: [atlas] Probe with ever changing upstreams/ASs? Hi! It depends on use case. For me, such probe would be fine for one-off measurements but for continuous measurements I would filter out such probe to avoid noise in data. However, when I looked on freifunk.net map I noticed that this network span across Germany, Switzerland, and Austria so even for one-off measurements usage of such probe is questionable because I never know where remote end of the tunnel is. If I understand correctly it can jump from country to country every day. In other words, such probe would be tricky to handle and user will have to be aware how such probe behave to properly handle data generated by it. Probably new system tag would be needed to mark such exotic probe. Regards, Grzegorz From: Carsten Schiefner <carsten(a)schiefner.de> Date: Thursday, 3 August 2023 at 15:07 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Probe with ever changing upstreams/ASs? All - I wonder whether this is a good idea or rather a really bad one... I have a free port on a Freifunk router where I could plug in a RIPE Atlas probe. Freifunk is a community where you - amongst other things - can offer a bit of your bandwidth to "the world". This connectivity sharing however is set up as a tunnel to various ISPs (for-profit companies and non-profit associations) as these would enjoy the "provider privilege": that in short is not to be held accountable for e.g. copy right infringements etc. ("Störerhaftung"). Anyhow: as part of this tunnel setup, the other end of the tunnel changes every 24 to 48 hours - and so does the upstream and therefore also the AS of the upstream provider. And now I am asking myself: a probe with ever changing upstreams/ASs - shall such an addition to the RIPE Atlas network be considered a fault or a feature? Any comments, anybody? Cheers, -C. -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at…<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

1 0

Requesting Credits for Research
by Alex Gamero-Garrido 29 Jul '23

29 Jul '23

Hi folks, My name is Alexander Gamero-Garrido and I'm a 5th year PhD student at CAIDA, UC San Diego. We're soon launching a large traceroute campaign for research and could use your generous donation of credits. We'll need about 150 million credits, but any partial amount that gets us closer to that goal is welcome and greatly appreciated. My account is agamerog at eng.ucsd.edu Thank you, Alex -- *Alex Gamero-Garrido* *PhD Student, Computer Science* Web: cseweb.ucsd.edu/~agamerog Center for Applied Internet Data Analysis (CAIDA) San Diego Supercomputer Center UC San Diego Pronouns: He/Him/His <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> I'm using Inbox When Ready <https://inboxwhenready.org/?utm_campaign=signature&utm_medium=email&utm_sou…> to protect my focus.

13 15

Re: [atlas] RIPE Atlas Virtual Anchor Registration for DCS1 (sg-sin-as37989)
by Sanjeev Gupta 28 Jul '23

28 Jul '23

Hi, I am trying to install the virtual anchor of the ISO. Unfortunately, my experience with Unix went directly from Sun to Debian in the late 90s, so I am not sure of the intricacies of RHEL anaconda What (and in what format) do I answer here: 1. IPv4 address: 203.123.48.20 2. IPv4 Netmask: I tried 255.255.255.224, which it seemed not to like, so I tried /27, and then 27. 3. IPv4 gateway: 203.123.48.6 4. IPv6 address: 2405:fc00::20 (it keeps failing, should I enclose this in [] )? 5. IPv4 Netmask: I tried /64, and then 64 6. IPv4 gateway: 2405:fc00::6 Now it fails with: <snip>freedektop.NetworkManager.Settings.Connection.MissingPropert: ipv4.addresses: this propery cannot be empty for 'method=manual' And how do I backspace in the installer? Neither BKSP nor ^H seem to work. Thanks, -- Sanjeev Gupta +65 98551208 http://www.linkedin.com/in/ghane On Thu, 27 Jul 2023 at 22:22, RIPE Atlas <no-reply(a)ripe.net> wrote: > Dear Sanjeev Gupta, > > Thank you for registering the technical information for your RIPE Atlas > virtual anchor! > > Your FQDN is: sg-sin-as37989.anchors.atlas.ripe.net > > You will need now to setup the Virtual Machine according to these > instructions: (https://atlas.ripe.net/docs/anchor-installation-vm/). > > It is important that once you have setup the virtual machine, you log in > to your RIPE Atlas account, go to the "My Atlas" menu and then "Anchors", > and check the boxes “Software is installed” and "Anchor is connected to the > network" so we are notified and can begin the tests. Please note that your > anchor will not be fully activated until we have finished these internal > tests. > > We will notify you once we have finished testing and your virtual anchor > is ready to use. > > If you have any questions, please do not hesitate to contact us at > atlas(a)ripe.net > > You registered the following details: > > IPv4 address: 203.123.48.20 > IPv4 ASN: 37989 > > IPv6 address: 2405:fc00::20 > IPv6 ASN: 37989 > > Kind regards, > > RIPE Atlas Team >

2 1

Easy way to view DNS results?
by Micha Bailey 27 Jul '23

27 Jul '23

Hi, I’m wondering if I’m missing something - I ran a DNS measurement with 110 probes, and the results are in, but the site UI seems to only show the result status and time elapsed until response, but not the results themselves. Looking at the JSON from the result endpoint I’m seeing that it seems to return the raw binary response - is there a particular reason it can’t be parsed and displayed in a more human-readable format? I know there are libraries and tools that do result parsing, but being on mobile at the moment (and often) means those are somewhat less accessible as far as I’m aware.

6 6

Re: [atlas] DoH and DoT measurements
by Ponikierski, Grzegorz 26 Jul '23

26 Jul '23

Indeed “tls” flag seems to work. Thanks! After first try with DoT providers like one.one.one.one or dns.google I have additional question. When exactly FQDN from “target” is resolved to IP? Is RIPE Atlas resolve domain to IP only once during measurements creation or is each probe resolve domain to IP individually? It’s important details for me because I will work with FQDN that will resolve do different IP depending on user location so if it is resolved only once by RIPE Atlas system then probes will be using sub-optimal IPs to run tests. Regards, Grzegorz From: Michel Stam <mstam(a)ripe.net> Date: Wednesday, 26 July 2023 at 17:13 To: "Ponikierski, Grzegorz" <gponikie(a)akamai.com> Subject: Re: [atlas] DoH and DoT measurements Hey Grzegorz, It’s a bit hidden, but in the measurement definition I think the key ’tis’ needs to be set to the boolean value ’true’. That should enable DNS over TLS. Cheers, Michel On 26 Jul 2023, at 17:09, Ponikierski, Grzegorz <gponikie(a)akamai.com> wrote: I have reviewed API Manual and Reference but I don’t see anything about DoH or DoT. Maybe I have overlooked something? Regards, Grzegorz From: Michel Stam <mstam(a)ripe.net<mailto:mstam@ripe.net>> Date: Wednesday, 26 July 2023 at 15:30 To: "Ponikierski, Grzegorz" <gponikie(a)akamai.com<mailto:gponikie@akamai.com>> Cc: "ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net>" <ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net>> Subject: Re: [atlas] DoH and DoT measurements Hello Gzzegorz, If I saw correctly DNS over TLS should be possible. Some initial steps have been taken to implement DNS over HTTP(S) but such is not available yet. You will probably have to use the API to schedule one, though RIPE Atlas docs | RIPE Atlas Documentation | Docs<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNO…> atlas.ripe.net<https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNO…> <image001.png><https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNO…> Hope this helps, Regards, Michel On 26 Jul 2023, at 15:09, Ponikierski, Grzegorz via ripe-atlas <ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net>> wrote: Hi! Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE Atlas? Regards, Grzegorz -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://lists.ripe.net/mailman/listinfo/ripe-atlas<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

2 2

DoH and DoT measurements
by Ponikierski, Grzegorz 26 Jul '23

26 Jul '23

Hi! Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE Atlas? Regards, Grzegorz

2 2

Issues downloading large result files
by Ana 21 Jul '23

21 Jul '23

Hi everyone, I'm seeing something very strange when trying to download the result files for some large measurements. The download is a different size each time (sometimes 1.4GB, then 3.2GB, then back to 1 GB again) and checking the end of the file I can always see it's not complete as it stops in the middle of a measurement, closing brackets aren't there etc. I guess this is because of the size of the file, not sure if there's some sort of limit on RIPE Atlas? If anyone here has seen anything like this or has any advice on how to fully download the result that would be much appreciated! Thank you, Ana

3 2

Re: [atlas] RIPE Atlas Virtual Anchor Registration for Angola Cables (ao-lad-as37468)
by Inacio Jose 17 Jul '23

17 Jul '23

1 0

Looking for RIPE Atlas credits
by Ioana Alexandrina Livadariu 17 Jul '23

17 Jul '23

Hello all, My name is Ioana Livadariu and I am a researcher at SimulaMet in Norway working on IP geolocation. I want to run a measurement campaign over RIPE Atlas which requires about 1M RIPE Atlas credits. If anybody can help me by sharing credits I would appreciate it a lot! My email for transfer is: ioana(at)simula.no Thank you, Ioana Livadariu

3 2

Credit request
by Ana Custura 13 Jul '23

13 Jul '23

Hi everyone, I would like to schedule some experiments to look at the prevalence and types of load-balancing in v4 and v6 networks. Running traceroutes with 32 paris repetitions on many probes unfortunately burns very quickly through credits. If you have some to spare and can donate to my account it would be much appreciated! Thank you, Ana

10 10

RIPE87: CfP, RACI & Fellowship Grants
by Vesna Manojlovic 13 Jul '23

13 Jul '23

Dear colleagues, RIPE 87 will be held in Rome, from 29 November to 2 December 2023: https://ripe87.ripe.net/ ----------- CFP ----------- Please propose a talk or a workshop at https://ripe87.ripe.net/cfp/ RIPE 87 will be a hybrid meeting, so both in-person and remote presentations are encouraged and will be accepted. ----------- Travel Grants ----------- The RIPE NCC is accepting applications for RIPE Fellowship and academics: travel grants are available for selected candidates. *The application deadline is Tuesday, 11 September 2023.* ----------- RACI ----------- RIPE Academic Cooperation Initiative (RACI) is supporting talented academics in the field of Internet technology. Successful applicants receive complimentary tickets, accommodation and travel to the meetings and the opportunity to present their research. To apply, submit a short abstract and draft slides via: https://www.ripe.net/participate/forms/apply/raci-application-form-2023/ More information: https://www.ripe.net/raci Subscribe to the RACI list: https://www.ripe.net/raci/mailing-list ----------- RIPE Fellowship ----------- Having participants with diverse backgrounds, expertise, opinions and experiences enriches the RIPE community. With the RIPE Fellowship, we aim to create opportunities for individuals from underrepresented regions, minority backgrounds, or others who would otherwise be unable to attend without funding, to participate in the RIPE Meetings. The RIPE Fellowship covers the cost of a meeting ticket, travel and accommodation for successful candidates in the RIPE NCC service region. Apply: https://www.ripe.net/participate/forms/apply/ripe-87-fellowship/ More information: https://www.ripe.net/fellowship ----------- We encourage our long-standing community members to share this announcement with others who could benefit from these opportunities. ----------- Warm regards, Vesna Manojlovic -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 1

Re: [atlas] Your Probe shipped
by Inacio Jose 11 Jul '23

11 Jul '23

2 1

credit transfer - 2 issues
by Paul Emmons 11 Jul '23

11 Jul '23

Hello all. First off, does the standing order for transferring credits form work? I have tried it a few times with no success on chrome and firefox. I submit it and nothing happens. And I can't seem to get a transfer done via a curl method - just get a invalid method response. A sample of the code we were trying is: curl -H "Content-Type: application/json" -H "Accept: application/json" -X POST -d '{ "amount":"1999999" , "recipient":"paul@somedomain" }' https://atlas.ripe.net/api/v2/credits/transfer/?key=a-real-key Thanks Paul

2 1

Accuracy of “Consumption Delay”
by Ernst J. Oud 01 Jul '23

01 Jul '23

L.S. To feed to the discussion… currently the “Consumption Delay” indicator is green while results of a new measurement still take a long time (half an hour or more) to be reported fully in the web interface. So this indicator cannot be fully relied on it seems. Met vriendelijke groet / Regards, Ernst J. Oud

1 0

Delays in backend…
by Ernst J. Oud 01 Jul '23

01 Jul '23

Hi, Measurements stream fine in Magellan, but results only show up in the web interface after - in extreme cases - hours. The RIPE status info says: Resolved This incident has been resolved. Posted 1 day ago. Jun 29, 2023 - 10:11 UTC Investigating We are experiencing issues with the RIPE Atlas backend and currently are investigating this issue. Posted 1 day ago. Jun 29, 2023 - 08:55 UTC But clearly this has not been resolved! Regards, Ernst J. Oud

2 3

RIPE Atlas Quarterly Planning Q3 2023
by Robert Kisteleki 28 Jun '23

28 Jun '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 start 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 RIPE NCC

1 0

Magellan
by Ernst J. Oud 26 Jun '23

26 Jun '23

Hi, Perhaps someone can help me. I use Magellan to create a measurement using connected probes on AS15435. First I search for probes using Magellan and then I supply the ID’s returned of those probes reported as “connected” when creating the measurement. I don’t want to wait for the stream to time-out so I use the “stream-limit” parameter, equal to the number of supplied connected probes. So when that number of connected probes have supplied data the streaming is complete. However, it appears that probes are reported as connected by Magellan but do not supply data when specified for a measurement, for instance probe 2565. That probe is Reported by Magellan as connected but when I use it in a measurement it does not supply data. Thus streaming will only time-out and does not stop not when spevified connected probes have supplied data. Apparantly “connected” does not imply “can be used in a measurement”. How can I supply probe ID’s in a “create measurement” command using Magellan knowing for sure that these probes will supply data? Regards, Ernst J. Oud

2 2

Recovered probe v3
by Renny Leal 26 Jun '23

26 Jun '23

Hi folks I’ve recovered one V3 probe but sadly the person who got it flashed the tp-link original firmware to the device. Is there any way to get the ripe atlas firmware back to it? Thanks in advance Enviado desde Correo<https://go.microsoft.com/fwlink/?LinkId=550986> para Windows

2 1

Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation
by Endre Szabo 21 Jun '23

21 Jun '23

Hi folks, I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? --Endre ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- From: RIPE Atlas <no-reply(a)ripe.net> Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Date: Tue, 20 Jun 2023 13:01:05 -0000 Dear Endre Szabo, We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. https://www.youtube.com/watch?v=BGj1MDIclDQ 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: RIPE NCC P.O. Box 10096 1001 EB Amsterdam The Netherlands ===== RIPE NCC Days Sofia, Bulgaria And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out – register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-s… . We look forward to seeing you there! ===== Thank you for continuing to support RIPE Atlas. Best regards, The RIPE Atlas Team ----- End forwarded message -----

2 2

Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation
by Endre Szabo 20 Jun '23

20 Jun '23

Hi folks, I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? --Endre ----- Forwarded message from RIPE Atlas <no-reply(a)ripe.net> ----- From: RIPE Atlas <no-reply(a)ripe.net> Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Date: Tue, 20 Jun 2023 13:01:05 -0000 Dear Endre Szabo, We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. https://www.youtube.com/watch?v=BGj1MDIclDQ 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: RIPE NCC P.O. Box 10096 1001 EB Amsterdam The Netherlands ===== RIPE NCC Days Sofia, Bulgaria And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out – register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-s… . We look forward to seeing you there! ===== Thank you for continuing to support RIPE Atlas. Best regards, The RIPE Atlas Team ----- End forwarded message -----

1 1

Can <contact@streamyard.com> please be unsubscribed?
by Carsten Schiefner 17 Jun '23

17 Jun '23

To whom it may concern… Thank you, -C.

3 2

Vergessen Sie nicht Ihre StreamYard-Einladung!
by StreamYard 17 Jun '23

17 Jun '23

StreamYard Inc. ( https://u7212249.ct.sendgrid.net/ls/click?upn=Ef-2BTvyZXeR9MIWcIdAYELFJPNYC… )

1 0

Sie wurden zu StreamYard eingeladen
by StreamYard 10 Jun '23

10 Jun '23

StreamYard Inc. ( https://u7212249.ct.sendgrid.net/ls/click?upn=Ef-2BTvyZXeR9MIWcIdAYELFJPNYC… )

1 0

upgrading an original soft probe
by Randy Bush 08 Jun '23

08 Jun '23

i have a probe, 1000004, on a deb 10 vm that was installed in the rotterdam hackathon. the detritus looks as if it was built using a deb install of atlasswprobe-5000-1.deb. two days ago, it stopped working in some way; i have not pursued, figuring i was dealing with an antique. is there a path to make it current? randy

4 9

Re: [atlas] credit request
by Michael Rabinovich 06 Jun '23

06 Jun '23

Many thanks! As I mentioned, I did get all the credits requested, but I am grateful to have them as it will allow us extra flexibility to do some exploratory measurements. Cheers, —Misha > On Jun 4, 2023, at 6:53 PM, DeuZa <proton(a)deuza.net> wrote: > > Sent 181 000 000 credits > > Sent from Proton Mail for iOS > > > Le mer. 24 mai 2023 à 17:29, Michael Rabinovich <michael.rabinovich(a)case.edu <mailto:Le mer. 24 mai 2023 %C3%A0 17:29, Michael Rabinovich <<a href=>> a écrit : >> >> Folks, >> >> As I posted couple months ago, we deployed and made available the instrumentation for longitudinal comparison of the performance implications of DNS resolver platforms, including ISP-provided and some influential publicly available resolvers ( https://dns-web-portal.netlify.app/). This work — and Nick Kernan’s MS thesis — was enabled by a generous donation of credits several years ago from the RIPE Atlas community — thanks a lot! Now to keep this measurement going requires ~20M credits per month. I’d like to assemble ~250M credits so we could keep this service up for a year. By then we should be able to see if it’s proved to be valued by the community and whether and how to keep it going beyond this time horizon. Would you please donate to my account what you can? >> >> Many thanks in advance! >> —Misha > <publicKey - proton(a)deuza.net - 0x714FB45F.asc>

1 0

credit request
by Michael Rabinovich 25 May '23

25 May '23

Folks, As I posted couple months ago, we deployed and made available the instrumentation for longitudinal comparison of the performance implications of DNS resolver platforms, including ISP-provided and some influential publicly available resolvers ( https://dns-web-portal.netlify.app/). This work — and Nick Kernan’s MS thesis — was enabled by a generous donation of credits several years ago from the RIPE Atlas community — thanks a lot! Now to keep this measurement going requires ~20M credits per month. I’d like to assemble ~250M credits so we could keep this service up for a year. By then we should be able to see if it’s proved to be valued by the community and whether and how to keep it going beyond this time horizon. Would you please donate to my account what you can? Many thanks in advance! —Misha

9 15

Probe DHCPv6 support
by Aleksi Pirttimaa 19 May '23

19 May '23

Hi! I recently received my v4 probe and I'm very happy with it. But unfortunately it doesn't support DHCPv6. I present a practical reason for implementing a DHCPv6 client on the probe. You see, my ISP doesn't send router advertisements with the prefix for stateless autoconfiguration set, and instead DHCPv6 must be used. I believe their decision could have something to do with the fact that the regulating body here requires ISP's to prevent IP address spoofing in consumer plans. And to meet that requirement my ISP may be using a feature similar to Cisco's IP source guard, where switch ports and/or mac addresses are passively associated to leased ip's or prefixes, breaking SLAAC. Unfortunately they hate letting consumers talk with their engineers so it's difficult to speculate this further. For now, I've put a stateful firewall appliance in front of the probe which provides SLAAC, it works just fine. Do you think a DHCPv6 client should be implemented?

8 13

Measurement suggestions for new deployments.
by Gerardo Huerta Robles 18 May '23

18 May '23

Hello all, I'm a newbie with RIPE ATLAS Probes, We are currently working on deploying a new Probe network in Nicaragua as the first step for a measurement project. The second step will be to capture statistics of traffic to the internet, but we are not clear what kind of targets are the most relevant for internet statistics. I would like to ask you for suggestions of targets, what kind of public servers are relevant for user internet traffic? We are thinking of DNS servers like 8.8.8.8 or some public HTTP web pages like the government or social media like Facebook, youtube and so on. But what do you think? Do you have some advice? The project is intended to obtain the first statistics about internet traffic and make it public using RIPE Probes and schedule measurements. If you have some advice please let me know, Thank you. Regards

1 0