- ripe-atlas - mailman.ripe.net

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

Riple Atlas + openwrt + docker + gns3 + debian
by Gery Escalier 07 Sep '22

07 Sep '22

Hi, I'm doing tests with OpenWrt SNAPSHOT, r20377-ca5c695a45 on docker in a gns3 lab and on debian 11. At the moment it allows me to carry out tests and later it will allow me to work with old routers and other hardware that can run openwrt. root@OpenWrt:~# /etc/init.d/atlasSyntax: /etc/init.d/atlas [command] Available commands: start Start the service stop Stop the service restart Restart the service reload Reload configuration files (or restart if service does not implement reload) enable Enable service autostart disable Disable service autostart enabled Check if service is started on boot Check if service is running status Service status trace Start with syscall trace info Dump procd service info get_key print probe public key (used for probe registration) probeid print probe id log print probe status log create_backup backup ssh key to tar.gz load_backup 'backup.tar.gz' load backup ssh key from tar.gz create_key create probe priv/pub key root@OpenWrt:~# /etc/init.d/atlas info{ "atlas": { "instances": { "instance1": { "running": true, "pid": 4707, "command": [ "/usr/libexec/atlas-probe-scripts/bin/ATLAS" ], "term_timeout": 5 I have done the configuration that the software probe account requires, I have done the configuration of the riple atlas package to generate the ssh keys and connect with my riple atlas account. I have had the probe 100% operational for several hours and generated credits, the problem I currently have is that when I turn off and start gns3 I have to install the Ripe Atlas packages from scratch in openwrt, configure it and generate the ssh keys again, update the keys in my Ripe Atlas account. At the moment I am using this option for testing, but it would be interesting if openwrt saves the data persistently, I am looking for information on what the problem may be, I am commenting on it in case someone who has used openwrt and something similar has come up. I will be updating news. Greetings. Gery

2 2

Group in Spanish Riple Atlas?
by Gery Escalier 06 Sep '22

06 Sep '22

Hello everyone, I have the doubt if there is any group in Spanish where I can participate, I have been documenting myself about Riple Atlas and I have been able to activate a software probe using openwrt, gns3 and Debian. It is always more interesting to be able to carry out tests and others participating with the community. I have seen some videos of the deployathons in which Michela G. and Agustin F. participated, that is why I was encouraged to configure the probe and understood a little better about the Riple Atlas project. I will also participate here and I will be sending emails with my queries. Thank you very much, best regards! Gery

4 6