- ripe-atlas - mailman.ripe.net

probes on mobile opérateurs
by Cristel Pelsser 13 Jan '23

13 Jan '23

Hello, We are looking for RIPE atlas probes that are connected to mobile operators. Could you drop me an email with the id of the probe if you have such a probe? We found some but would like to enlarge our study. Best regards, Cristel

4 3

Proposal: Remove support for non-public measurements [ONLY-PUBLIC]
by Robert Kisteleki 11 Jan '23

11 Jan '23

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

15 24

V3 Probe: USB Flash Drive Filesystem Corrupted
by ripe.net＠toppas.net 11 Jan '23

11 Jan '23

Hello, i have two v3 probes and i'm experiencing issues: "USB Flash Drive Filesystem Corrupted" I have tried multiple USB Sticks, including brand new ones and also sticks from "good" brands like Lexar and Sandisk. The issue is not permanent, the error appears and disappears from time to time: 2022-12-22 @ 12:14:04 UTC Probe auto-tagged Your probe #xxxxx was automatically tagged as "system: Flash drive filesystem corrupted" 2022-12-22 @ 18:14:42 UTC Probe auto-untagged Your probe #xxxxx was automatically untagged as "system: Flash drive filesystem corrupted" This leads me to the thought, that the flash storage is not the real problem. It's unlikely, since i tried multiple dongles. Could it be possible, that not the flash storage is broken, but the speed of the USB dongles is too low? All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice? What do you think? BR, Simon

2 6

Proposal: Add support for STARTTLS measurements [STARTTLS]
by Robert Kisteleki 09 Jan '23

09 Jan '23

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

4 3

Re: [atlas] Ability to traceroute to 240/4 - software vs. hardware probes
by Seth David Schoen 09 Jan '23

09 Jan '23

Hi! I noticed that Phillip Homburg merged a RIPE Atlas client patch in November of last year, based on our request, that removes the Atlas probe's inability to test addresses in 0/8 and 240/4. https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/commit/59475f848b… So, I just tried a couple of measurements to 240.1.2.3 to see how Atlas would handle them: https://atlas.ripe.net/measurements/48100582/ https://atlas.ripe.net/measurements/48100585/ (I don't expect these to succeed, as no part of 240/4 is publicly announced in BGP; the interesting information to be garnered from this isn't whether the probes succeed, but how they fail.) For the first measurement, with ping, 6 hardware probes and 4 software probes all gave the same result: "Unreachable" (which is what you would get if you ran this on any ordinary Internet host with command-line ping). For the second measurement, with traceroute, 6 hardware probes all actually attempted the traceroute (getting failures after some small number of network hops), while 3 software probes all reported back "!address not allowed". What could account for the difference in how hardware and software probes handle this task? I would have thought that the change from last November would make software probes willing to attempt these.

2 2

Magellan report on built-in measurement 1
by Ernst J. Oud 09 Jan '23

09 Jan '23

Asked this question before but that post did not make it to the mailing list: Why can’t Magellan report on built-in measurement 1 (first hop)? It always shows “No packets found”. Met vriendelijke groet/Regards, Ernst J. Oud

2 1

Positively meant critique …
by Ernst J. Oud 09 Jan '23

09 Jan '23

LS. Is there a kind of common understanding what this mailing list is about? What its purpose is? I see important discussions such as those on private measurements but no conclusions… I ask questions that lead to response from a RIPE employee but not to answers/solutions… (For instance on why results from first hop measurement to ping.ripe.net cannot be reported on by Magellan.) Can RIPE give some explanation what the use for them is of this mailing list? Are there other entries into RIPE for support questions? Would some kind of forum not be a much better solution to discuss matters with probe “owners” instead of using old fashioned unstructured mailing lists… the way we did things when the internet was in its infancy? Regards, Ernst J. Oud

2 1

New version of the WR802N probe write-up
by Ernst J. Oud 04 Jan '23

04 Jan '23

L.S. Added a paragraph on security. Shame on me not adding that in the first version. Available at http://www.kineta.nl/atlas/wr802n-write-up-v2.pdf Regards, Ernst J. Oud

1 0

Use TP-Link WR802N as an Atlas probe
by Ernst J. Oud 04 Jan '23

04 Jan '23

Hi, I promised to create a write-up on how to turn the low cost, energy efficient, TP-Link travel router WR802N into a fully functional Atlas probe. This write-up is now available at: http://www.kineta.nl/atlas/wr802n-write-up-v1.pdf Might be an idea perhaps to also mention the document somewhere on the RIPE Atlas blog pages? My email address is on the last page of the document for any questions. In case you wonder, kineta.nl is the (very, very old) website of my company before I retired. The .pdf is malware free (at least that is what Microsoft Defender says). If your house burns down following the actions in the document don't blame me. Happy hacking. Regards, Ernst

3 2

Updating software probe version (with .deb package)
by Seth David Schoen 31 Dec '22

31 Dec '22

Hi, I have a software probe which I installed by creating a Debian package from source (as described in INSTALL.rst). The documentation suggests that one should regularly update software probe versions, and I'm interested in upgrading mine -- I was reminded by my earlier question about 240/4, as I may be running a client version from prior to when the patch allowing 240/4 scans was merged. The documentation doesn't specifically mention how to upgrade; can I assume that making a new .deb from current sources, and then installing that with dpkg on a machine where an older .deb is installed, will maintain the credentials and identity of my existing probe? It won't wipe everything out and require me to re-register as a new software probe, right?

2 1

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

31 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 31 Dec '22

31 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 24 Dec '22

24 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