- ripe-atlas - mailman.ripe.net

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Robert Kisteleki 30 Dec '22

30 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

8 9

Re: [atlas] DNS issue
by Mezgani Ali 30 Dec '22

30 Dec '22

> Hello, > > > I set my probe and I got a problem with DNS. > > Please what figure out on my probe ? Maybe I have to set other DNS address into my ADSL Router. > > Any query are welcome. Regards, > > > > Mezgani Ali's home > General > <https://atlas.ripe.net/frames/probes/63005/#tab-general>Network > <https://atlas.ripe.net/frames/probes/63005/#tab-network>Built-ins > <https://atlas.ripe.net/frames/probes/63005/#tab-builtins>UDMs > <https://atlas.ripe.net/frames/probes/63005/#tab-udms>Status (beta) > <https://atlas.ripe.net/frames/probes/63005/#tab-status> > General InformationEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/general/> > Id 63005 > MAC Address D8:58:D7:03:02:C0 > Architecture atlas-mox > Firmware Version None > Router Type > Bandwidth Limit Not set > DNS Entry Simple: > p63005.probes.atlas.ripe.net <http://p63005.probes.atlas.ripe.net/> > Shared Publicly Yes > User Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#user-tags> Mobile Datacentre IPv6 Tunnel IPv66to4 ADSL VPN Native IPv4 IPv6-onlyDocker > System Tags <https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags> V5 DNS problem suspected > <https://atlas.ripe.net/frames/probes/63005/ripestat/9002/> > Connection & Traffic > > > Connected Time 3 months > > Management SharingEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/sharing/> > Currently you're not sharing this probe within your LIR. > > The management of this probe is not allowed for any other individuals. > > NotificationsEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/notifications/> > There aren't any downtime notifications configured for this probe. > There aren't any uptime reports sent for this probe. > Transfer OwnershipEdit <https://atlas.ripe.net/frames/probes/63005/form-fragment/transfer/> > You can transfer ownership of the probe to someone else by submitting this form. Note that this change cannot be undone. > > 3 months > #63005 > Firmware > None > Architecture > atlas-mox > MAC Address > D8:58:D7:03:02:C0 > Update Location <https://atlas.ripe.net/frames/probes/63005/location/> > <3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg><3939.jpeg><3940.jpeg> > <a51052730657106d6f160440dd590bec.png> > + > <https://atlas.ripe.net/probes/63005/#>- > <https://atlas.ripe.net/probes/63005/#>Leaflet <http://leafletjs.com/> | Tiles © Esri > Kind regards, > > Mezgani Ali > ali.mezgani(a)nativelabs.ma <mailto:ali.mezgani@nativelabs.ma> > https://wiki.debian.org/mezgani <https://wiki.debian.org/mezgani> > > ⢀⣴⠾⠻⢶⣦⠀ Active member of IETF, GNU, Debian, FreeBSD and Kernel. > ⣾⠁⢠⠒⠀⣿⡁ > ⢿⡄⠘⠷⠚⠋⠀ > ⠈⠳⣄⠀ > > > >> On 30/12/2022, at 17:54, Gert Doering <gert(a)space.net <mailto:gert@space.net>> wrote: >> >> Hi, >> >> On Fri, Dec 30, 2022 at 08:42:18AM -0800, Randy Bush wrote: >>> i asked this quietly before, but let me be more direct. >>> >>> how much private data is there actually? what percentage of the stored >>> data is private? >> >> Indeed, this is a good question. If it turns out that there is a lone >> private measurement from me, or "in the sub-percent range", I'm willing >> to let myself be convinced in the name of "make the measurement backend >> more simple = robust"... >> >> Gert Doering >> -- NetMaster >> -- >> have you enabled IPv6 on something today...? >> >> SpaceNet AG Vorstand: Sebastian v. Bomhard, Michael Emmer >> Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann >> D-80807 Muenchen HRB: 136055 (AG Muenchen) >> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 >> -- >> ripe-atlas mailing list >> ripe-atlas(a)ripe.net <mailto:ripe-atlas@ripe.net> >> https://lists.ripe.net/mailman/listinfo/ripe-atlas >

1 0

Probe 24434 down but pingable
by Dave 30 Dec '22

30 Dec '22

Hi, One of my probes is pingable but the status is disconnected for over a day. Could it be that it has troubles with DNS over IPv6 and that it is not smart enough to fall back to IPv4? https://atlas.ripe.net/probes/24434/#tab-general Thanks, Dave

3 4

Re: [atlas] A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

L.S. All the probes in NL that I had a look at, in a variety of different ASN’s, have no data available via the Atlas web of via the api (JSON, Magellan) for a.o. built-in measurement 1009 (ping to a.root-servers.net) and several others after December 22nd, around 18:00 hrs. UTC. When I have a look at German probes there is data available. This thus appears to be a problem with all and only Dutch probes’ data. A normal ping via a Windows command line works fine, i.e. a.root-servers.net is reachable. Creating a ping measurement via Magellan to a.root-servers.net using Dutch probes generates results, i.e. the probe infrastructure works but data storage does not, for data from probes in NL. Rather serious problem I guess. No mentioning on status.ripe.net though. Had an email conversation with Robert from the Atlas team today. No solution yet. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

2 1

Apologies for OOO reply
by Guy Meyer 23 Dec '22

23 Dec '22

Hi all, As some of you might have seen, something went wrong with my out-of-office email settings, and I'm sorry that you received the email multiple times. We're cleaning up the mailing list, and I wish you all happy holidays and a great year ahead. Kind regards, Guy Meyer

1 0

A number of built-ins stopped?
by Ernst J. Oud 23 Dec '22

23 Dec '22

Hi, Both on the atlas webpages as via the api, data for a number of built-ins stop at December 22th, at around 18:00 UTC for all my probes in 4 different ISP’s, all in NL. For instance measurement 1009, ping to a.root-servers.net stopped at that time while measurement 1010, ping to b.root-servers.net continues normally. Also stopped are: #1017 Ping to ctr-nue13.atlas.ripe.net #1012 Ping to d.root-servers.net #1013 Ping to e.root-servers.net #1015 Ping to h.root-servers.net #1005 Ping to i.root-servers.net Any idea what is causing this? Regards, Ernst J. Oud

1 0

Proposal: Generic HTTP measurements [GENERIC-HTTP]
by Robert Kisteleki 22 Dec '22

22 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

3 2

Low cost, low energy consumption probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for Windows. These small PC’s consume a lot more than the Ripe supplied HW probes. So I looked for a cheap and *very* low energy alternative. TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW has been ported to it. With some acrobatics I managed to turn it into an excellent alternative. Runs fine, energy consumption 700 mW (!). The device is as small as the Ripe supplied probe. Since the flash memory of this device is too small for some of the required libraries, the acrobatics involved copying them to RAM and putting links to them in flash. This means that with FTP after a power outage a couple of files need to be copied to the device and that one command must be given after that. There is a more expensive version with a USB port so that a USB stick can be used to store those files. Will investigate that option. If someone here wants a detailed write-up let me know and I will invest the time to write it. Regards, Ernst J. Oud

3 4

Enable/Disable software probe
by Ernst J. Oud 21 Dec '22

21 Dec '22

Hi, Two questions: 1. What would be the best way to temporarily disable (and enable again) a software probe? Is there some command for this besides killing all processes and run the ATLAS script again? Running a probe on CentOS, OpenWRT and Ubuntu 18.04 (all on separate ISP’s). I am currently logging the latency differences between HW and SW probes (both natively and under VMware emulation). Differences appear to be in the 1.5 ms. range. Negligible for my 4G networks but on my fiber line such a difference is more than 30% of the average latency. Will post more results soon. 2. Why can’t Magellan report on the first ping latency to ping.ripe.net? It always reports “No packets found”. All other reports work fine. TIA. Regards, Ernst J. Oud

2 1

Proposal: Measure well-known CDNs,[CDN-HTTP]
by Dirk-Jan van Helmond 20 Dec '22

20 Dec '22

Hi RIPE Atlas users, I stumbled upon this thread and I wanted to chime in. I work for Cloudflare and we of course use a wide set of external visibility and performance management tools to track our visibility. But on occasions I also use the RIPE Atlas network to perform some specific reachability tests. I believe the distribution of probes and the fact that they're als in eyeball ASN is a really valuable factor that RIPE Atlas has. At the moment I'm running into a limitation around HTTP tests. I would like to use the RIPE Atlas network to curl some pages to retrieve and evaluate the HTTP headers. This is currently not possible with Atlas as it is only allowed to probe Anchors for safety reasons, which I fully understand and support (you don't want to turn Atlas into a botnet). The HTTP targets that I would like to probe would be all on our IP space, so I don't see a direct risk from the outbound part of the request. I can see there is some risk with the return part, where the content from an "unknown" system gets returned to a probe in someone's private network, with possible ramifications. So I was pondering about two possible options that can potentially help me, but not risk the Atlas project or demonstrate favoritism towards particular companies. 1) One of the options would be to open up some of our IP space to the probes for HTTP probes. 2) The other option would be for us to host an Anchor and put our CDN in front of it. That way RIPE has complete control over the returned data. I would love to hear the general consensus on such approach and the viability of it Best Regards, -- Dirk-Jan van Helmond On 17/12/2022 00:19, Barry Raveendran Greene wrote: > > >> On Dec 16, 2022, at 23:29, Stephane Bortzmeyer <bortzmeyer at nic.fr> wrote: >> >> There is a larger problem here, a more strategic one: such a feature >> would contribute to the centralisation of the Internet, which is >> already too important. Tagging some targets are "important" and >> "worthy of measurements" would mean that we consider some HTTP servers >> to be more useful than others. That would be a bad message from RIPE. > > We’ve come full circle - we started with centralized PTTs - moved to a decentralized ASN/Paul Baran model - now Re-centralized based on marketing domination. > > +1 with Stephane’s observation. The selection of who to measure is a statement. +1 Also, while the data would be useful, I don't think the role of the ripe ncc is to grade commercial services. Let other companies or individual researchers do that. -- Dirk-Jan van Helmond Leader Solutions Engineering EMEA mobile: +31611645622 email: dirkjan(a)cloudflare.com www.cloudflare.com <https://www.cloudflare.com/>

1 0

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki)
by Renny Leal 16 Dec '22

16 Dec '22

May the non-public measurements cost more in terms of credits or even money to support the infrastructure? El 16 dic. 2022 11:28 a. m., ripe-atlas-request(a)ripe.net escribió: Send ripe-atlas mailing list submissions to ripe-atlas(a)ripe.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.ripe.net/mailman/listinfo/ripe-atlas or, via email, send a message with subject or body 'help' to ripe-atlas-request(a)ripe.net You can reach the person managing the list at ripe-atlas-owner(a)ripe.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ripe-atlas digest..." Today's Topics: 1. Re: Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Petr ?pa?ek) 2. RIPE Atlas Quarterly Planning Q1 2023 (Robert Kisteleki) 3. Re: Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Robert Kisteleki) 4. Re: Proposal: Remove support for non-public measurements [ONLY-PUBLIC] (Magnus Sandberg) 5. Re: Proposal: Generic HTTP measurements [GENERIC-HTTP] (Hugo Salgado) 6. New RIPE Atlas stream release (Chris Amin) 7. Re: Proposal: Measure well-known CDNs,[CDN-HTTP] (Stephane Bortzmeyer) ---------------------------------------------------------------------- Message: 1 Date: Fri, 16 Dec 2022 12:21:03 +0100 From: Petr ?pa?ek <pspacek(a)isc.org> To: ripe-atlas(a)ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <06d70394-ea13-9be7-486e-a9017a77ba39(a)isc.org> Content-Type: text/plain; charset=UTF-8; format=flowed On 15. 12. 22 19:41, Steve Gibbard wrote: > I worry that that would have a ?chilling effect? on use of the service. I hear your concerns, and have a proposal how to quantify this concern: - First, amend the page to say that all the data are public. (Possibly also switch the flag, but that can be a separate step.) - Second, observe what has changed in the usage pattern. - Third, evaluate. That way we don't need to stay in limbo over hypothetical situations but get real data. Side note about usefulness of one-off measurement history: I think it _might_ be is interesting for anyone doing study on any given outage, or even study about optimization practices over time. For example, the DNS community has service called DNSViz which does just one-off measurements, and yet, researchers come and write papers based on data from DNSViz. HTH. -- Petr ?pa?ek ------------------------------ Message: 2 Date: Fri, 16 Dec 2022 12:32:11 +0100 From: Robert Kisteleki <robert(a)ripe.net> To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] RIPE Atlas Quarterly Planning Q1 2023 Message-ID: <d4aacacc-9691-d6f4-3cbb-ae0e9ad2d18f(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Dear colleagues, The quarterly plans for RIPE Atlas can now be found at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas In the last quarter, we worked on several proposals to change the RIPE Atlas behaviour, including implementing general availability of HTTP measurements and removing the ability to schedule ?non-public? measurements. This quarter, we?ll continue with the distribution of the v5 RIPE Atlas hardware probes to hosts, ambassadors and sponsors as well as work on other items proposed by the community. 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 Research and Development Manager RIPE NCC ------------------------------ Message: 3 Date: Fri, 16 Dec 2022 12:56:45 +0100 From: Robert Kisteleki <robert(a)ripe.net> To: Magnus Sandberg <mem(a)fallback.netnod.se>, ripe-atlas(a)ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <36a79d58-83e1-4e93-a707-aa47a653ac2e(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Hi, > The definition of a "small" test could be something like; > - maximum 20 probes > - runs for maximum 60 minutes > - is repeated maximum 10 times > ? (if you run every 300sec you have to limit the endtime to 50 minutes) What would you propose the API to do if this rule is violated? Should it outright refuse the measurement, or should it silently turn on the public flag (silently, because even if we emit a warning, it is probably never seen by a human...)? > With such limits you can troubleshoot things (non-publicly) but you > can't build your monitoring system on top of that. I guess this hinges on what level of support (legal, technical or other) we're aiming for when it comes to others building services on top of RIPE Atlas. Regards, Robert ------------------------------ Message: 4 Date: Fri, 16 Dec 2022 14:13:47 +0100 From: Magnus Sandberg <mem(a)fallback.netnod.se> To: Robert Kisteleki <robert(a)ripe.net>, ripe-atlas(a)ripe.net Subject: Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC] Message-ID: <2ed5e29a-9590-f20c-fd6f-f21e58846d40(a)fallback.netnod.se> Content-Type: text/plain; charset=UTF-8; format=flowed On 2022-12-16 at 12:56, Robert Kisteleki wrote: > Hi, > >> The definition of a "small" test could be something like; >> - maximum 20 probes >> - runs for maximum 60 minutes >> - is repeated maximum 10 times >> ?? (if you run every 300sec you have to limit the endtime to 50 minutes) > > What would you propose the API to do if this rule is violated? Should it > outright refuse the measurement, or should it silently turn on the > public flag (silently, because even if we emit a warning, it is probably > never seen by a human...)? I think the safest thing would be to refuse with an error message. Just override a setting with just a warning is probably not enough, as you wrote. >> With such limits you can troubleshoot things (non-publicly) but you >> can't build your monitoring system on top of that. > > I guess this hinges on what level of support (legal, technical or other) > we're aiming for when it comes to others building services on top of > RIPE Atlas. I really love RIPE Atlas and all the possibilities that come with an open and mature platform. I think as much as possible should be open and reusable by others. However, I understand that some people in some cases have other wishes. Regards, // mem ------------------------------ Message: 5 Date: Fri, 16 Dec 2022 10:15:09 -0300 From: Hugo Salgado <hsalgado(a)nic.cl> To: Robert Kisteleki <robert(a)ripe.net> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Proposal: Generic HTTP measurements [GENERIC-HTTP] Message-ID: <Y5xvXQ1ICmRBpPEv@pepino> Content-Type: text/plain; charset="us-ascii" Dear Robert, As I have expressed at other times, I think we have to be very careful with enabling HTTP probes due to traffic increase issues. I have personally delivered quite a few probes to remote locations in regions with very poor connectivity, and the host's first concern is how much bandwidth the measurements take up. I have always reassured them that these are only network level connectivity measurements, and no web traffic. It seems to me that in the first world it may be difficult to imagine places where a few megabytes per month of traffic matters, but that is the case in remote regions, and I think the benefit of having an Atlas network with worldwide coverage is greater than being able to perform higher layer measurements or monitoring. It seems to me that the idea of making it "opt-in" with a tag on the probe is the right one, even if it makes its deployment and usability slow at first. I sincerely believe we have a responsibility to hosts that currently help in complex regions. Thanks and regards, Hugo Salgado NIC Chile - .CL On 15:03 14/12, Robert Kisteleki wrote: > Dear RIPE Atlas users, > > We recently published a RIPE Labs article containing a few proposals: > https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. > We'd like to encourage you to express your comments about this proposal (if > you'd like to share them) here. > > Regards, > Robert Kisteleki > For the RIPE Atlas team > > -- > ripe-atlas mailing list > ripe-atlas(a)ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <https://lists.ripe.net/ripe/mail/archives/ripe-atlas/attachments/20221216/e…> ------------------------------ Message: 6 Date: Fri, 16 Dec 2022 15:34:04 +0100 From: Chris Amin <camin(a)ripe.net> To: ripe-atlas(a)ripe.net Subject: [atlas] New RIPE Atlas stream release Message-ID: <d278c506-e467-5f3f-040b-296efd878b05(a)ripe.net> Content-Type: text/plain; charset=UTF-8; format=flowed Dear colleagues, The new version of the RIPE Atlas streaming API is now available. As mentioned in the previous e-mail, the API can now be accessed using either plain WebSockets or plain GET requests. Socket.IO support is being maintained for now, so you don't have to immediately change your installations, but the new interfaces should be preferred wherever possible. The documentation can be found at: https://atlas.ripe.net/docs/apis/streaming-api/ Kind regards, Chris Amin RIPE NCC On 30/11/2022 10:31, Chris Amin wrote: > In around three weeks we will be releasing a new version of the RIPE > Atlas stream (https://atlas-stream.ripe.net) with an API based on > WebSockets and plain HTTP requests. > > The current Socket.IO interface will be maintained for backwards > compatibility for the near future, but some subscription parameters will > be dropped due to extremely low or no usage. These are: > > * Historic playback (startTime, endTime) ? note that this does not > include sendBacklog, which will still work as now > * Arbitrary server-side filtering of fields (equalsTo, greaterThan, > lessThan) ? note that filtering by "prb", "msm", "type" etc will work as > now > > We can see from the service logs that each of these parameters has > either not been used at all or used by a single IP address in the past > month, so the impact should be minimal. However, if you happen to be > using one of these parameters then please get in touch with me. > > Aside from these changes, existing use cases should continue to work as > they do now, and we will be monitoring closely for any issues. > > There will be more information on the new API, including complete > documentation, closer to the time. ------------------------------ Message: 7 Date: Fri, 16 Dec 2022 16:28:07 +0100 From: Stephane Bortzmeyer <bortzmeyer(a)nic.fr> To: Robert Kisteleki <robert(a)ripe.net> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP] Message-ID: <Y5yOh9hvnmGG0PCV(a)nic.fr> Content-Type: text/plain; charset=us-ascii On Wed, Dec 14, 2022 at 03:02:46PM +0100, Robert Kisteleki <robert(a)ripe.net> wrote a message of 15 lines which said: > We recently published a RIPE Labs article containing a few proposals: > https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. > We'd like to encourage you to express your comments about this proposal (if > you'd like to share them) here. (In the Cons) "Possible arguments about which provider to include in this set and which to refuse." There is a larger problem here, a more strategic one: such a feature would contribute to the centralisation of the Internet, which is already too important. Tagging some targets are "important" and "worthy of measurements" would mean that we consider some HTTP servers to be more useful than others. That would be a bad message from RIPE. ------------------------------ Subject: Digest Footer -- ripe-atlas mailing list ripe-atlas(a)ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas ------------------------------ End of ripe-atlas Digest, Vol 136, Issue 15 *******************************************

2 1

Upcoming RIPE Atlas stream release in December
by Chris Amin 16 Dec '22

16 Dec '22

Dear colleagues, In around three weeks we will be releasing a new version of the RIPE Atlas stream (https://atlas-stream.ripe.net) with an API based on WebSockets and plain HTTP requests. The current Socket.IO interface will be maintained for backwards compatibility for the near future, but some subscription parameters will be dropped due to extremely low or no usage. These are: * Historic playback (startTime, endTime) — note that this does not include sendBacklog, which will still work as now * Arbitrary server-side filtering of fields (equalsTo, greaterThan, lessThan) — note that filtering by "prb", "msm", "type" etc will work as now We can see from the service logs that each of these parameters has either not been used at all or used by a single IP address in the past month, so the impact should be minimal. However, if you happen to be using one of these parameters then please get in touch with me. Aside from these changes, existing use cases should continue to work as they do now, and we will be monitoring closely for any issues. There will be more information on the new API, including complete documentation, closer to the time. Kind regards, Chris Amin RIPE NCC

1 1

RIPE Atlas Quarterly Planning Q1 2023
by Robert Kisteleki 16 Dec '22

16 Dec '22

Dear colleagues, The quarterly plans for RIPE Atlas can now be found at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas In the last quarter, we worked on several proposals to change the RIPE Atlas behaviour, including implementing general availability of HTTP measurements and removing the ability to schedule “non-public” measurements. This quarter, we’ll continue with the distribution of the v5 RIPE Atlas hardware probes to hosts, ambassadors and sponsors as well as work on other items proposed by the community. 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 Research and Development Manager RIPE NCC

1 0

Request for Atlas credits for teaching and research
by Nitinder Mohan 16 Dec '22

16 Dec '22

Dear RIPE Atlas community, I am a postdoctoral researcher in Technical University of Munich, Germany. I am coming to you with a request to transfer some of your surplus Atlas credits to my account nitinder.mohan(a)tum.de if possible. I work on several Internet measurements research problems which rely on Atlas platform for measurements. Additionally, I am also planning to give out a cloud connectivity measurment assignment to my course students to give them hands-on experience with Atlas -- which exceeds my local credit generation rate. Your help will be highly appreciated! Thanks and Regards Nitinder Mohan Technical University Munich (TUM) https://www.nitindermohan.com/

10 11

Re: [atlas] Non-public probes?
by Ernst J. Oud 15 Dec '22

15 Dec '22

Chris, Weird. That probe is on AS15435 (just like me) which is an ISP that not yet offer any ipv6 functionality. So how come ipv4-works is not tagged? But thanks for the clarification that this tag is the reason I can’t add it. I can’t do any ipv6 measurements to try. Regards Ernst J. Oud

1 0

Re: [atlas] Non-public probes?
by Ernst J. Oud 15 Dec '22

15 Dec '22

But what is going on then with: https://atlas.ripe.net/frames/probes/1003690 This probe is within AS15435 and when I list all probes in that AS it is shown, but I cannot add it to a measurement, it is rejected. Using a curl request to: stat.ripe.net/data/atlas-probes/data.json?resouce=15435 shows this probe, with a tag “is_public” : false and I cannot access this probe’s info via the link above, I cannot add it to a measurement and I cannot access any data it collects. How does this rhyme to that non-public “probes are therefore contributing very nearly as much to the network as everybody else”? Regards, Ernst J. Oud

4 4

Non-public probes?
by Ernst J. Oud 15 Dec '22

15 Dec '22

Hi, Just recently I realized that a probe can be labeled as “non-public”. Why is this allowed? Atlas is a community effort. Why are probe “owners” allowed to have benefits from using Atlas without sharing data? Regards, Ernst J. Oud

2 1

Proposal: remove per-hop “late” packets from traceroute [LATE-PACKETS]
by Robert Kisteleki 15 Dec '22

15 Dec '22

Dear RIPE Atlas users, We recently published a RIPE Labs article containing a few proposals: https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/. We'd like to encourage you to express your comments about this proposal (if you'd like to share them) here. Regards, Robert Kisteleki For the RIPE Atlas team

2 1

Atlas api down
by Ernst J. Oud 14 Dec '22

14 Dec '22

Hi, As of around 17:30 UTC on December 13th, all measurements other than built-ins, from the website or via Magellan, report no results. The website just hangs and Magellan times out. I believe all access via the api to be broken. I read that maintenance is pending, but that is scheduled the 14th… What’s up? Regards, Ernst J. Oud

3 6

atlas related mails come 4 times
by Endre Szabo 12 Dec '22

12 Dec '22

Hi chaps, Just recently any mail from atlas monitoring shows up 4 times in my inbox. 4 exact copies of a mail (Message-Id is also the same), in the same time, in 4 different SMTP sessions. Anyone else noticed such behavior? Also, I've just subscribed to this list and the subscription confirmation request mail came twice :D One via IPv4 and one via IPv6. Apparently no other senders have this issue on my end. --Endre

3 2

Unknown probe in my account
by Giuseppe Macario 08 Dec '22

08 Dec '22

Hello everyone, I have a probe that works properly but, a few weeks ago, my account also started to show a probe that doesn't work and that I don't know. I contacted atlas @ripe.net to ask for clarification but I didn't get anything (apart from a semi-automated message). So could anyone delete this unknown probe? https://atlas.ripe.net/probes/63078/ Thank you.

2 4

Removing the "technical updates" RSS feed
by Robert Kisteleki 07 Dec '22

07 Dec '22

Dear all, As of yesterday there's a new section in the documentation where we will publish information about the new releases for probe firmware and important UI/API changes: https://atlas.ripe.net/docs/releases/ With this, we plan to stop producing the RSS feed about "technical updates" - which had the same information until now. There's some use of this still, presumably from RSS readers that have been configured some time ago and fetch the feed ever since. (The top 5 clients accessing this correspond to 70% of the queries to this URL.) In theory we could retrofit the creation of the RSS feed into the new way of publishing the release news, but we would only consider this if there's a strong enough demand for it. So please let us know if you have reasons to insist on keeping the feed alive! Thank you, Robert Kisteleki RIPE Atlas

1 0

Issue to create measurement on the webpage
by Alexis MARCOU 07 Dec '22

07 Dec '22

Hi All, I'm trying to create a measure on the website : https://atlas.ripe.net/measurements/form/ But, when I click on the "Ping", a query is sent, but the interface is not updated with the parameters received ... Am I the only one with this issue ? Alexis

2 1

Shiny new v5 probe reveals problem with virtual probe
by Niall O'Reilly 01 Dec '22

01 Dec '22

Hello, everyone. TL; DR: clue needed configuring Turris Omnia for virtual Atlas probe. I'm delighted to have a shiny new v5 probe, which is operation since the day before yesterday. The new probe has been automatically tagged "IPv6 Works". On account of this, I've noticed that my virtual probe, running on my Turris Omnia, has the complementary tag, "IPv6 Doesn't Work." I suspect that I've not configured firewalling on my Turris properly. If any of you have sorted this, I would appreciate some clue. Thanks in anticipation. Niall

2 2

New V5 Probe with IPv4 Discovery issues
by Nate Weibley 01 Dec '22

01 Dec '22

I received a shiny new V5 probe via post on Saturday and got it up and running yesterday on my dual-stack network. The probe in question is: https://atlas.ripe.net/probes/62490/ It has been operational for about 18 hours and quickly indicated that IPv6 connectivity was functional, but it has only momentarily indicated IPv4 connectivity was established. I can see IPv4 ICMP and UDP traffic originating from the probe passing through my opnsense router on the IPv4 WAN interface so I know IPv4 traffic is flowing. I also see the correct IPv4 DHCP lease info for my LAN on the probe's network status page. Probe address discovery does not show a valid IPv4 connection address or IP Echo Service listed, only the Local IP of my probe. I've tried power cycling the probe but it doesn't seem to impact this issue. Are there any other troubleshooting steps I should try?

2 5

Format change for index pages of RIS MRT data files and RIPE Atlas daily dataset dumps
by Robert Kisteleki 24 Nov '22

24 Nov '22

Dear RIS and RIPE Atlas users, On Wednesday, 30 November 2022 we are planning to migrate the web server at <https://data.ris.ripe.net/> as well as <https://data-store.ripe.net> from Apache httpd to nginx. This will affect how the file listings in HTML index pages are generated, including the following: * RIS MRT data files (updates and dumps) * RIPE Atlas daily dataset dumps If you rely on the format of these pages, you need to update your software. Before we do the upgrade, you could check the new format of the index pages at: https://test-data.ris.ripe.net/rrc00/ We would like to ask you to avoid relying on the specific format of the index.html files. If you are fetching BGP dump files, please use the REST API that is described at: https://ris.ripe.net/docs/40_Prototypes/15_per_rrc_dumps.html You might also consider using per-peer dump files instead: https://ris.ripe.net/docs/40_Prototypes/10_per_peer_dumps.html We want to encourage you to provide your feedback on the API, so that we could improve it and build a similar API for the update files. If you are fetching update files, please use direct URLs to files as described at: https://ris.ripe.net/docs/20_raw_data_mrt.html#name-and-location Kind regards, Oleg Muravskiy, Robert Kisteleki RIPE NCC

1 0

Magellan
by Ernst J. Oud 18 Nov '22

18 Nov '22

L.S. In the meantime I have found that there is a hardcoded 5 minute timeout for streams to end. However, after this timeout the message “Disconnected from stream” appears and the ripe-atlas process appears to “hang”, a ctrl-c appears to be the only option, python then interrupts within threading.py and client.py. What is it doing, what is it waiting for? Any solution? Regards, Ernst J. Oud

2 1

Magellan streaming and ctrl-c behavior
by Ernst J. Oud 15 Nov '22

15 Nov '22

Hi, If I use the older Docker container for the ripe atlas CLI tools (Magellan) (at https://hub.docker.com/r/anuragbhatia/ripe-atlas-tools) a newly created measurement streams its results and then Magellan exits and the container exits. Since the aforementioned image is old and displays results wrongly using erroneous Unicode conversion, which was solved in later Magellan versions, I created a new image using the latest Magellan code. Now all is well except that after results have been streamed, Magellan waits for ctrl-c. This is as per the Magellan docs of the stream command, but very annoying. I planned to automate things, sending a ctrl-c keystroke is not easy in this case. I don’t know whether the older Magellan code did not wait for ctrl-c or whether the creator of the older Docker image changed the code somewhere. It would be an idea to add an option to the the Magellan measure command whether to stop after streaming or to stop after a certain amount of results are in, like the “—limit” command for the stream command which unfortunately is not an option of the measurement command. I think the only option is to create a measurement with the —no-report option, get the measurement-ID from the URL and then use the report command, instead of streaming. Any ideas? Met vriendelijke groet / Regards, Ernst J. Oud

1 0

Can't register software probe
by roberto.lucignani＠caleidos.it 15 Nov '22

15 Nov '22

Hi all, I download the probe software image from: https://github.com/Jamesits/docker-ripe-atlas Changed the RSA key in /var/atlas-probe/etc generating a new one with: ssh-keygen -t rsa -b 4096 Trying to register the software probe at: https://atlas.ripe.net/apply/swprobe/ I get the following error: * The public key does not match our regular expression for this key type I tried generating other keys, but I always get the same error. Regards, Roberto -- This message contains confidential information and is intended only for the individual named. If you are not the named addressee, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this message by mistake and delete this message from your system. E-mail transmission cannot be guaranteed to be secure or error-free, because information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message that arise as a result of e-mail transmission.

2 1

IPv6 and the V5 probe
by Eric Kochen 14 Nov '22

14 Nov '22

Hi, My V5 is up and running. For some reason public IPv6 is not detected or not working, yet. I have a dual-stack connection and IPv6 is a DHCPv6 Prefix Delegation configuration. Does this work with the V5 probe? Anything I need to configure at the Atlas website maybe?

2 3

RIPE Atlas SMTP Measurement
by ripe.net＠toppas.net 11 Nov '22

11 Nov '22

Hello, i'd like to start a discussion about having a RIPE Atlas SMTP measurements. First of all: yes, i know there's a big obstacle for such a measurement type. A lot of probes are deployed using enduser internet-connections like dsl, cable, etc. with dynamic/eyeball IP addresses. Those IP spaces are usually blocked by SMTP servers as approach to reduce spam mails. For Example: by using blocklists like Spamhaus PBL. So a proper SMTP measurement wouldn't work. BUT we could have an easy way for RIPE Atlas probe hosters to signalize, that their probe is eligible for SMTP measurements: Step 1: enable "Simple DNS Entry" Step 2: create a matching reverse DNS record for the probes IP address Everybody who is able so configure a reverse DNS record for his probes IP address, is most likely using a non-dynamic/non-home ip address space e.g. a datacenter or office network. If an ISP provides the option for his customers to configure a reverse DNS record, it's most likely a "business-customer" subnet which can be used to run mailservers. After Step 1+2 are done, the RIPE Atlas platform would easily be able to verify if forward-confirmed reverse DNS is successful, and if so, automatically enable that probe for SMTP measurements. Alternatively: probe hosters choose their own Forward-confirmed reverse DNS name and submit it on the RIPE Atlas website. Also: if we would have STMP measurements, forward-confirmed reverse DNS should be mandatory for anchors, or is it already? Why should we have SMTP measurements? Besides general reachability checks, we could also evaluate SMTP response codes. But the most important thing for me is this: the SMTP protocol is old. Very old. From a security point of view, it's absolutely outdated. Most security features have been added years after the initial RfC. Thus, those security features are optional. Mandatory SMTP encryption is not provided by the SMTP RfC. So both sides have to signalize, that they are capable of encryption using the STARTTLS command. An attacker (man-in-the-middle) can perform a downgrade attack by suppressing the STARTTLS command. So both sides are forced to fallback and communicate unencrypted. RIPE Atlas would be a really good tool to identify such attacks, by monitor/measure the (enhanced) status codes of a target. But there's more! I see a two-sided model here. Either use the RIPE Atlas SMTP measurements to monitor/measure your own mailserver by alot of other RIPE probes out there, OR probe hosters could run SMTP measurements originating from their own probe to find out, if their own IP address is currently blocked by other mailservers. What do you think? BR, Simon

5 26

placing a probe into wireless networks (not terrestrial)
by Kurt Kayser 11 Nov '22

11 Nov '22

Dear Atlas-ml-followers, this a summary of a brief discussion I had with Michel Stam during RIPE85. We believe there might be a great value putting up a public Internet monitoring probe (vantage point) into low earth orbit satellite systems, such as Starlink. Monitoring from terrestrial end-points delivers high variances, due to frequent sat-changes. If we could put up an ATLAS-probe (be it SW - which is probably easier than HW) into a specific plane, we could add interesting tests and try to interpret the values depending on position over specific areas, atmospheric influences, solar influences as well as other effects that would change signal patterns. I would be offering support to try to establish such a probe and help to setup a project defition. Any thoughts or feedback to this idea? Best regards Kurt Kayser

3 3

V5 probes
by Ernst J. Oud 10 Nov '22

10 Nov '22

L.S. Is there a sneak preview of the V5 probes available somewhere? Regards, Ernst J. Oud

8 14

Credit sponsorship
by Finn Holler 07 Nov '22

07 Nov '22

Hello, I am looking for probe operators, with a credit surplus, who would want to transfer some credits to my RIPE Atlas account (email: finn.holler(a)student.uni-tuebingen.de). These credits are required for me to interact with the measurement API, which I want to explore and ideally use, to implement a service indicating the connectivity status of various internet services to tenants of local student housing. The plan is to register some probes, so this credit sponsorship is only necessary for initial trials. Best, -Finn

5 7

Breaking API change?
by Ray Bellis 26 Oct '22

26 Oct '22

ISC's Root System Atlas visualiser used to use this API call to access the built-in root system measurements: <${apiUrl}/measurements/${m}/latest/?fields=responses.0.response_time,responses.0.abuf.answers.0.data.0&freshness=1800> where ${m} is the measurement number. It used to return this object: { probe_id1: [ [ latency, site1 ], ... ] probe_id2: [ [ latency, site1 ], ... ] ... } It now returns this array instead: [ [probe_id1, latency, site], ... [probe_id1, latency, site], [probe_id2, latency, site], ... ] and I had to explicitly request the probe_id field in order to get it. Was this change intentional, a regression, or did I not use the API right in the first place? cheers, Ray

2 3

V4 probe looses connection
by Szabolcs Sipos 22 Oct '22

22 Oct '22

Hi, I have a probe (#53985, V4, fw: 5070) that goes offline after 1-2 days of uptime and does not recover unless rebooted. The probe responds to ping (even from a different subnet). Packet capture reveals that it renews its DHCP lease normally, but does not initiate any higher level connection. I will try to keep the probe online for a few days so that you can run some tests if you wish. Regards, Szabolcs

1 0

Shared probes not shown anymore in "my atlas"
by Dave 20 Oct '22

20 Oct '22

Hi, In the past the probes that had shared management were shown below the owned probes. This is not the case anymore. Is this intentional? Can it be restored? Thanks, Dave

2 1

ATLAS page broken because of Cloudflare
by Max Grobecker 16 Oct '22

16 Oct '22

Hi, on my network, the RIPE ATLAS page is not working because mandatory resources (i.e. Javascript) can't be loaded, because appearently ripe.net is now running behind Cloudflare and is blocking requests to static resources - see attached network console screenshot of my browser. There should be made a rule to exclude static assets or trusted origins from this type of filtering. This is maybe also affecting other pages, which include resources directly from www.ripe.net. I'm accessing this over a mobile network via IPv6 (Telefonica Germany), so it's not a "other bad person behind same CGNAT" problem but a seemingly static rule to always challenge the client. Greetings, Max

1 0

Re: [atlas] Apply for Quantum Internet Hackathon: 1-2 December, 6 locations & online
by Gery Escalier 15 Oct '22

15 Oct '22

Fantastic Vesna! thank you so much for sharing it on the list! Gery

1 0

Apply for Quantum Internet Hackathon: 1-2 December, 6 locations & online
by Vesna Manojlovic 14 Oct '22

14 Oct '22

Dear RIPE Atlas users, I know this is not directly related, but many of you are enthusiastic about (new) technology in general, so it might interest you: The RIPE NCC is co-organising a Quantum Internet Hackathon simultaneously in six nodes on 1-2 December 2022. Join us in Amsterdam, Dublin, Padua, Poznan, Sarajevo, Tashkent - and online! Apply here: https://www.ripe.net/participate/forms/apply/quantum-internet-hackathon-202… Top-3 Goals of this event: * Sharing existing software and protocols for the Quantum Internet * Producing tools & documentation, or learning/interaction materials * Forging connections between participants and between nodes Partner organisations: PSNC, GÉANT, SURF, Trinity College Dublin, QuTech, University of Padova, INHA University in Uzbekistan, Maynooth University, University of Sarajevo, RIPE NCC Find out more here: https://labs.ripe.net/author/karla-white/take-part-in-the-quantum-internet-… Regards, Vesna -- Senior Community Builder, RIPE NCC https://labs.ripe.net/author/becha/

1 0

Tagging probes which are using the ISP's DNS server?
by Max Grobecker 11 Oct '22

11 Oct '22

Hi, a few days ago I wanted to debug a name resolution problem of one of our domains. For this reason, I wanted to test if probes inside a specific ASN are having difficulties to resolve a specific name (because only customers of this ISP were complaining). This lead to very mixed results, mostly because some of the selected probes did queries to a public DNS service like Google, Quad9 and so on. The problem existed only with the provider's DNS servers for some reason. It did take some time to make a script which tried to filter out these probes, so I wondered if anyone else had the same use-case and problem. Is there a way to automatically tag probes, which are (seemingly) using the ISP's own DNS servers, or, at least, not a well-known public service? This could be done maybe by querying a special DNS name which returns the IP address from where the query was received (like "whoami.akamai.net"). By comparing the ASN of the probe and the ASN of the IP address returned by the DNS query, one could determine, if the ISP's servers are used. This would also be true for people running their own recursor, but this could be filtered as well very easy. If an ISP is using multiple ASN, this could be a problem. Maybe there's an easy solution for this as well. Probes which pass this test, could then be tagged with "DNS-using-ISP-server" or something like that and explicitly be selected for specific DNS resolution tests. Greetings, Max

9 12

v4 Probe Available
by Alexander Burke 10 Oct '22

10 Oct '22

Hello all, I have one more v4 probe available for distribution. If anyone is interested in (reliably!) hosting it, please email me off-list with your address, and I'll get it out to you. First reply gets it. Cheers, Alex

1 0

Revive an abandoned probe?
by Ernst J. Oud 10 Oct '22

10 Oct '22

Hi, As a result of my experiments some three moments ago I have an abandoned probe (OpenWRT). If I power it again will it start working again or do I need te re-apply for a new probe? Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud

3 2

Re: [atlas] V5 probes
by Colin Johnston 07 Oct '22

07 Oct '22

Can someone put me down for a v1 to v5 replacement please ? My v1 at present powered by usb from bt homehub Thanks in advance Colin Sent from my iPod > On 3 Oct 2022, at 12:19, Robert Kisteleki <robert(a)ripe.net> wrote: >

7 9

API error
by Ernst J. Oud 07 Oct '22

07 Oct '22

Hi, Since a short while (1 or 2 days) I get an authorization error when downloading the data from the built-in first and second hop to ping.ripe.net. Thus: https://atlas.ripe.net/api/v2/measurements/1/results/?probe_ids=1004467&sta… Gives: {"error":{"detail":"Authentication credentials were not provided.","status":403,"title":"Forbidden","code":104}} If I logon with my credentials via “My Atlas”, I get: {"error":{"detail":"You do not have permission to perform this action.","status":403,"title":"Forbidden","code":104}} All other tests let me download the data fine, logged in or not. Same happens to download first and second hop data of other public probes. Any clues? Regards, Ernst J. Oud

2 2

Re: [atlas] API error
by Ernst J. Oud 05 Oct '22

05 Oct '22

L.S. If for some reason this api error bug takes longer to resolve and the data is important for you, a work around is to download this data from ripestat. Click on the link on your builtins page for the larger graph and click the download button top right. Use this download link to download future data by changing the start and end time in the URL. Reason I use the data from the first hop latency is that my CentOS probe in a VMware Player VM on Windows 10 (bridged) takes 2-3 ms. for the first hop. To get more realistic data for other measurements I subtract this first hop latency data from data of other measurements. Wrote some Freebasic code for this and created my own graphs using the good, old, trusted application ploticus. From the host Windows 10 PC first hop is max 0.5 ms. so the VMware software bridge is not very efficient to get a connection going. If the CentOS VM is kept busy, the first hop is much faster. It is as if Windows and/or VMware suspends/sleeps the thread of the bridge when not active. I searched but did not find any more reports let alone solutions for this weird first hop phenomenon in VMware/Windows environments. Regards, Ernst J. Oud

1 0

Re: [atlas] API error
by Dimeji Fayomi 05 Oct '22

05 Oct '22

Hi, I have also been experiencing this authorization error when I attempt to download first and second hop ping data of public probes. I'd please appreciate any tips or pointers to dealing with this. Thanks Dimeji -- Dimeji Fayomi

2 1

Alternative second hop ?
by Ernst J. Oud 01 Oct '22

01 Oct '22

Hi, On the “Built-ins” tab of the probe dashboard in the drop down list there is a log to download called “Ping Alternative Second Hop”. What is this? It returns an empty data set… BTW… any news on the error when downloading first and second hop data? Regards, Ernst J. Oud

1 0

RIPE Atlas Quarterly Planning Q4 2022
by Robert Kisteleki 27 Sep '22

27 Sep '22

Dear colleagues, The quarterly plans for RIPE Atlas can now be found at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas In this quarter, we will start shipping the v5 RIPE Atlas hardware probes to hosts, ambassadors and sponsors as well as continue working on other items proposed by the community. We hope that by providing these plans, we can better inform the community of the ongoing developments on RIPE Atlas and get feedback on our work. 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 Research and Development Manager RIPE NCC

1 0

Change in Probe Archive API
by Johan ter Beest 26 Sep '22

26 Sep '22

Dear probe hosts, Since 2013 we are creating a daily snapshot of the probe API which is available at https://atlas.ripe.net/api/v2/probes/archive Until today, this snapshot included some probes which had never connected. Starting with the snapshot of today (26 / 09/ 2022) we will exclude all never connected probes from the archive as they do not provide any useful information. Previous snapshots will not be altered. In addition to this change, every known probe will now have a probestatus page at https://atlas.ripe.net/probes/<probe ID>/ where previously some of these probes would generate a 404. Let us know if you have any question or comment about this change. Kind regards, Johan ter Beest RIPE Atlas Team

1 0