- ripe-atlas - mailman.ripe.net

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 08 Sep '22

08 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

Probe on sailboat with Starlink
by Michael Markstaller 02 Sep '22

02 Sep '22

Hi, just a question: any interest to have a probe on a sailboat with Starlink (not officially supported) Just got my probe Probe #27837 fixed again at home (usb-stick RO/dead) and now I wonder if I leave it at home or take it with me over Adriatic/Atlantic. And if yes, some API-way to update location would be nice as we're moving:-) best regards Michael Markstaller Softwareentwicklung & IT-Dienstleistungen Am Birkengarten 19b 82024 Taufkirchen Tel: +49-89-21553825, Mobile: +49-179-2080789 USt-ID: DE293191950

11 14

New on RIPE Labs: 240/4 As Seen by RIPE Atlas
by Qasim Lone 23 Aug '22

23 Aug '22

Dear colleagues, In this new article on RIPE Labs, we use data from RIPE Atlas probes to investigate the usage of 240/4, a block of IPv4 addresses 'reserved for future use' and formally known as Class E in the wild. https://labs.ripe.net/author/qasim-lone/2404-as-seen-by-ripe-atlas/ Kind regards, Qasim

1 0

Updated RIPE Atlas Documentation
by camin 22 Aug '22

22 Aug '22

Dear colleagues, A new version of the RIPE Atlas documentation has been published. We have consolidated the text in places and improved the structure to make it easier to find content. The new version can be found at: https://atlas.ripe.net/docs/ Regards, Chris Amin

5 9

Re: [atlas] My experiences with a SW probe…
by Michel Stam 07 Jul '22

07 Jul '22

Hey Ernst, Thanks for your email. Regarding the busybox implementation, there’s history here. As I understand it, the first probes were implemented on a system without a memory management unit. This created the problem that starting and restarting processes caused memory fragmentation. That lead to the system running out of memory, which is why an approach was chosen with a multi-call binary: Only one program loaded into memory, and busybox already was implemented and available on the system. Of course, since the version 3 probes (the TPLINK), there is no need anymore. There is a memory management unit taking care of this. However, the code was retained because it was already implemented. Later on, the decision was made to offer an installable software probe package for regular Linux systems, which is in essence the same code running on the hardware probes, which brings us to today. Today you find busybox even on regular Linux systems, but then typically in the initrd environment, prior to the system booting from the root filesystem. We’re currently refactoring parts of the probes to make things easier to maintain. This may mean, without guaranteeing it, that this can change in the future. Why ATLAS starts properly using /etc/init.d and not on boot, I cannot say. It can be as simple as the networking not being available or a race condition. I would suggest to touch base with the author of this code and ask? The debate whether a Windows version would be beneficial is something that we should have with a wider audience, and should cover such topics as 24/7 availability, usability and convenience for the user. I merely want to point out that the engineering effort may be significant. If other people would like to weigh in on this matter, that would be welcome. Will keep you posted. Regards, Michel > On 6 Jul 2022, at 16:18, Ernst J. Oud <ernstoud(a)gmail.com> wrote: > > Michel, > > Thanks for the concise answer. > > Good to know that my problems with the CentOS installation can be reproduced. Turns out I am not an idiot after all :-) > > In a Linux container in Docker Desktop for Windows even the standard Linux traceroute command of Ubuntu or CentOS does not work. Ping does but traceroute does not. As per my previous email, it seems that this a vpnkit bug in Docker. Not a lot that can be done, on GitHub I asked for progress on this issue, no response yet. > > On my Windows 10 PC I measure a pretty constant 940/940 speed using Ookla SpeedTest. Only when VMware was installed also on that PC in bridge mode, those measurements went haywire. Ofcourse a bridge for networking between the host and a virtual machine requires a network driver in VMware doing some trickery. That might explain why. Ofcourse this has nothing to do with the SW probe itself. > > Thanks for the input on telnetd and busybox. When I had a look at the SW probe after installation I indeed wondered what the heck was going on with a busybox binary, which in embedded Linux environments and in small Linux distributions such as Alpine, has its place. Did not understand why RIPE created a multi-call binary for the probe. And calling it busybox is even more confusing… > > Still doesn’t explain why stopping the ATLAS service and restarting it does correctly load the RIPE telnetd daemon but starting the service at boot does not. > > For me a Windows version only would mean saving disk space for VMWare and a virtual machine on that mini PC. Also I noticed that the traceroute results of the SW probe are around 1 ms. higher in the first hop, due to the probe running in a virtual machine. Both issues are not a big deal. What I meant more is that the amount of people willing to install the probe, if a Windows service would be available, would be potentially much, much larger. The Windows client community is so much larger than the Linux client community… > > Take care, > > Met vriendelijke groet / Regards, > > Ernst J. Oud > > > > Met vriendelijke groet, > > Ernst J. Oud >> On 6 Jul 2022, at 14:07, Michel Stam <mstam(a)ripe.net> wrote: >> >> Hi Ernst, >> >> First of all, thanks for the logs. >> >> I will group all the individual subtopics of this email :) I hope I caught all of them. If not, you know where to find me. >> >> Centos VM install: >> =============== >> I just did a clean install on a VM here, it seems there’s indeed something wrong with the repository on our end. YUM does not seem to find the atlasswprobe package. I’ll have a look why this is and get back to you. >> >> Traceroute in Docker for Windows: >> =========================== >> I have not seen this combination before. I do know that we’re doing very low-level networking communication to get such as traceroute & ping to work. We could try and see if this works, but there is a chance that this is reaching a limitation within Linux containers under Windows. Are you aware of any that may affect this? >> (Raw IP sockets). >> >> Speed on VMs: >> ============= >> I’m not sure its related, but in a previous life I did quite a few tests on the LAN with iPerf. I noticed that performance reports with Windows (hosts) were consistently lower than with Linux hosts. No VMs involved, running on the host itself (flat point-to-point without firewalls etc). Maximum speed I’ve ever observed with 2 Linux laptops and iPerf over a 1G switch is around the 900-930Mbps. If Windows laptops were involved (same hardware), typically 700-800 Mbps. >> >> I’ll add that these were my observations at the time, and mileage may vary on other hardware/OS combinations. I used a Dell Latitude and a Dell Precision laptop. I never investigated further than this, because my goal was to test the infrastructure, not the endpoints. It may be relevant here, though. >> >> OpenWRT: >> ========= >> There’s a bit of history here. The measurement code of Atlas was derived from a Busybox release at some point in the distant past. The telnetd from Busybox was repurposed to host a process for the backend to communicate with the probe. So while its called telnetd, its not the telnetd that you’d expect in a regular Linux system, it works quite differently from the original purpose of telnetd (a shell). I believe software probes typically install it in /usr/local/atlas/bb-13.3/bin. >> >> It seems the community probe installs files in /usr/libexec/atlas-probe, so there’s the first difference. The startup scripts also do things quite a bit different than the RIPE NCC version does. This may be a second indication. >> There’s also a rpcd process added that works differently. >> >> We do have a cleanup of the way the software probe works on our roadmap, and it will be good to touch base with the author of the community version to align. As yet, it seems the community version and the RIPE NCC version have diverged somewhat. As yet, it is probably better to contact the author of the community version for this particular issue. >> >> Windows: >> ======== >> A Windows port would mean looking at what is feasible on the Windows platform, which may involve significant recoding, if not rewriting. Even libraries such as MINGW32 might not fully resolve this. >> We would appreciate if someone would be willing to put time into such an effort, otherwise I don’t think we will be able to create such a version in the near future. >> >> I am curious though, how would a Windows version of the probe software work better for you than the existing Linux version? >> >> Will keep you posted on the CentOS bug. >> >> Regards, >> >> Michel >> >>> On 5 Jul 2022, at 18:50, Ernst J. Oud <ernstoud(a)gmail.com <mailto:ernstoud@gmail.com>> wrote: >>> >>> Michel, >>> >>> Twice (once in Docker Desktop for Windows and once in VMware Player 16) I exactly followed the instructions as in https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/CentOS… <https://github.com/RIPE-NCC/ripe-atlas-probe-doc/blob/master/manuals/CentOS…> and twice in the last step, the actual installation of the binary package (yum install atlasswprobe), yum complained that there was no such package. I then downloaded it directly from https://ftp.ripe.net/ripe/atlas/software-probe/centos7/noarch/ripe-atlas-re… <https://ftp.ripe.net/ripe/atlas/software-probe/centos7/noarch/ripe-atlas-re…> and did a yum install of that package which worked fine. >>> >>> Traceroute in Linux containers on Docker Desktop for Windows is known to not work (see: https://github.com/moby/vpnkit/issues/194 <https://github.com/moby/vpnkit/issues/194>) and in VMware it only works in bridge mode. >>> >>> However on the Windows 10 PC on which I run hourly SpeedTests and ping tests those tests were impacted after installation of VMWare, CentOS and the probe on that PC. I have gigabit fiber and instead of 940/940 Mbps. the speeds fluctuated, between 900/900 and 900/800. Perhaps an effect of VMware bridge mode on a physical Ethernet port shared with the Windows host. >>> >>> When using NAT mode in VMware on that PC again traceroute did not work, only the first hop is shown, subsequent hops showed * * *. >>> >>> Not to worry, I installed the probe on CentOS on VMware on another dedicated mini Windows 10 PC using bridged network mode and all is well. (Another PC in my home network…). >>> >>> Earlier On OpenWRT 21.01 I installed the probe from the Luci GUI, i.e. https://openwrt.org/packages/pkgdata/atlas-probe <https://openwrt.org/packages/pkgdata/atlas-probe>. This is the community version. It ran fine but I didn’t want to sacrifice a router just for this purpose. >>> >>> Why the ATLAS script fails to load telnetd in that OpenWRT environment is beyond me. Manual installs of telnetd worked fine so the executable is found. No errors in dmesg or anywhere else. Logging in via SSH and doing an “/etc/init.d/atlas stop” and then an “/etc/init.d/atlas start” worked fine. Perhaps telnetd is started from init.d with priority S30 too early in the boot process? >>> >>> As stated above, the install of the SW probe requires on Windows a hypervisor or VMware (perhaps Virtualbox will also work) which means that Windows users must be able to know how that all works and must have basic Linux knowledge. Perhaps a Windows version of the probe would mean a lot more probes in future? Hard to estimate whether it is worth the development effort for RIPE. Ping, traceroute and scheduling work fine in Windows so a Windows app is technically possible but a lot of work perhaps. >>> >>> Let me know if the issue of step 4 of the install under CentOS cannot be reproduced, then I will do it again with a log of all commands issued, but I cut/pasted the commands from the installation instructions mentioned above. So I am pretty sure there is a small error on the RIPE end of things. I see there are 3 versions of the binary on the RIPE FTP site mentioned above, perhaps yum as instructed in the instructions loads the wrong version? >>> >>> Thanks for your time. >>> >>> Met vriendelijke groet / Regards, >>> >>> Ernst J. Oud >>> >>>> On 5 Jul 2022, at 13:26, Michel Stam <mstam(a)ripe.net <mailto:mstam@ripe.net>> wrote: >>>> >>>> Hi Ernst, >>>> >>>> Sorry to hear you are having issues with installing the probe software. >>>> >>>> Can you maybe provide a step by step instruction how you got to the yum atlasswprobe error? I would like to check that everything is ok on our end. >>>> >>>> Secondly, regarding the bandwidth problems, can you explain what kind of issues you experience in non-bridged modes? What have you tried, and what was the result? Traceroute is known to work through NAT connections, which is typically what hypervisors use to share the connection (if bridging is not used). >>>> >>>> On your OpenWRT probe installation attempt, it seems there are 2 versions in the field; >>>> A version maintained by RIPE NCC used solely for the hardware probes. >>>> A community package written by the OpenWRT community, which uses the software probe implementation >>>> You mentioned having startup problems with the telnet daemon on the OpenWRT community package, I cannot say why this is, but the most likely culprit is the software not being able to find the location of the binary. Do you get any errors during startup? >>>> >>>> On a Windows implementation, there has not been a decision to do so as yet, I’m not sure whether the raw packets that are sent by the various measurements would work with Windows, but to be honest, this has not been investigated. Can you explain your use case for a Windows based implementation? >>>> >>>> Regards, >>>> >>>> Michel >>>> >>>>> On 2 Jul 2022, at 19:23, Ernst J. Oud <ernstoud(a)gmail.com <mailto:ernstoud@gmail.com>> wrote: >>>>> >>>>> Don’t know whether this is the place to share experiences but … >>>>> >>>>> I installed a SW probe in Docker for Windows (the Alpine version). Turns out traceroute doesn’t work in that setup. So I installed VMware player on that PC (the latest version can coexist with Hyper-V which Docker requires) and CentOS and the binary of the probe. Of which the instructions on the Ripe Atlas site doesn’t work in the last step (yum complains no package atlasswprobe found in the repo). Manual download and install did work however. Hurrah. >>>>> >>>>> Turns out traceroute in that setup only works with VMware in bridged network mode. Fine. But… all my bandwidth tests on that same box suddenly showed strange impacts… so either a working probe and accept incorrect bandwidth tests (using Ookla SpeedTest) or find another solution. Apparently the bridge in VMware and Windows on the same physical Ethernet port influence each other. >>>>> >>>>> Tried the probe on OpenWRT on a small router. Works fine but I don’t want to dedicate this router to just probe work. Also the ATLAS service from init.d refuses to run the telnetd daemon at startup. Weird. >>>>> >>>>> So installed VMware on a separate Windows 10 headless box (Minix Z83) that I had spare with CentOS and the binary. Runs fine. Finally. >>>>> >>>>> Will kill the other two probes once I am convinced it now finally works. >>>>> >>>>> Thanks Ripe for this excellent tool! A Windows version would help however :-) >>>>> >>>>> Regards, >>>>> >>>>> Ernst >>>>> -- >>>>> ripe-atlas mailing list >>>>> ripe-atlas(a)ripe.net <mailto:ripe-atlas@ripe.net> >>>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas <https://lists.ripe.net/mailman/listinfo/ripe-atlas> >>>> >>

1 0

My experiences with a SW probe…
by Ernst J. Oud 05 Jul '22

05 Jul '22

Don’t know whether this is the place to share experiences but … I installed a SW probe in Docker for Windows (the Alpine version). Turns out traceroute doesn’t work in that setup. So I installed VMware player on that PC (the latest version can coexist with Hyper-V which Docker requires) and CentOS and the binary of the probe. Of which the instructions on the Ripe Atlas site doesn’t work in the last step (yum complains no package atlasswprobe found in the repo). Manual download and install did work however. Hurrah. Turns out traceroute in that setup only works with VMware in bridged network mode. Fine. But… all my bandwidth tests on that same box suddenly showed strange impacts… so either a working probe and accept incorrect bandwidth tests (using Ookla SpeedTest) or find another solution. Apparently the bridge in VMware and Windows on the same physical Ethernet port influence each other. Tried the probe on OpenWRT on a small router. Works fine but I don’t want to dedicate this router to just probe work. Also the ATLAS service from init.d refuses to run the telnetd daemon at startup. Weird. So installed VMware on a separate Windows 10 headless box (Minix Z83) that I had spare with CentOS and the binary. Runs fine. Finally. Will kill the other two probes once I am convinced it now finally works. Thanks Ripe for this excellent tool! A Windows version would help however :-) Regards, Ernst

2 1

Connectivity Issue - Software Probe ID 1002750
by Thomas Kessler 02 Jul '22

02 Jul '22

Hi there, a software probe of mine - ID 1002750 - has stop working about 30 days ago and I seem not to be able to get it to connect again. tcpdump shows plenty of communication between the probe and reg03 / reg04.atlas.ripe.net. As well, the probe sending SOS DNS queries but neither seem to have any effect. RIPE Atlas Console shows the probe as being descended and the SOS DNS queries are not reported there either. I've check the probes registered public key and there should be no issue. Any ideas? Best regards Thomas

1 0

Overuse of software probes
by Ponikierski, Grzegorz 30 Jun '22

30 Jun '22

Hello all! Software probes is great improvement for Atlas environment and it made deployments so much easier and more scalable. One of my probes is also software probe on Raspberry Pi. However, me and my team noticed that sometimes software probes are overused and make measurements more cumbersome to interpret. For example we found that there 4 software probes in AWS Johannesburg [1] and 15 software probes in Hostinger Sao Paulo [2]. That's total overkill. These 15 probes in Hostinger Sao Paulo is 21% of all connected probes in Brazil. All of them delivers practically the same results so without additional data filtering (which is not easy) they can dramatically skew final results for Brazil. With this I would like to open discussion how to handle this situation. Please share your thoughts about these questions: * How can we standardize data filtering for such case? * How to proactively and automatically detect overuse of probes? * How can we encourage software probes hosts to avoid deployments in data centers which are already covered by Atlas? * How to give incentives to deploy probes in data centers without existing probes? [1] 4 software probes inside AWS Johannesburg: 1000707<https://atlas.ripe.net/frames/probes/1000707/> 1001397<https://atlas.ripe.net/frames/probes/1001397/> 1002066<https://atlas.ripe.net/frames/probes/1002066/> 1002632<https://atlas.ripe.net/frames/probes/1002632/> [2] 15 software probes inside Hostinger Sao Paulo 1003554<https://atlas.ripe.net/frames/probes/1003554/> 1003555<https://atlas.ripe.net/frames/probes/1003555/> 1003556<https://atlas.ripe.net/frames/probes/1003556/> 1003557<https://atlas.ripe.net/frames/probes/1003557/> 1003558<https://atlas.ripe.net/frames/probes/1003558/> 1003559<https://atlas.ripe.net/frames/probes/1003559/> 1003560<https://atlas.ripe.net/frames/probes/1003560/> 1003561<https://atlas.ripe.net/frames/probes/1003561/> 1003562<https://atlas.ripe.net/frames/probes/1003562/> 1003563<https://atlas.ripe.net/frames/probes/1003563/> 1003564<https://atlas.ripe.net/frames/probes/1003564/> 1003565<https://atlas.ripe.net/frames/probes/1003565/> 1003566<https://atlas.ripe.net/frames/probes/1003566/> 1003567<https://atlas.ripe.net/frames/probes/1003567/> 1003568<https://atlas.ripe.net/frames/probes/1003568/> Regards, Grzegorz Ponikierski

13 19

Probe on OpenWRT does not load telnetd
by Ernst J. Oud 30 Jun '22

30 Jun '22

Just a tip for OpenWRT users. I noticed that during most reboots my new SW probe on OpenWRT 21.02 does not load the telnetd daemon. No idea why but I saw that its priority in init.d is rather high (S30), i.e. it loads rather early. Perhaps that is the problem but instead I test for telnetd running in the ATLAS loop and load the daemon if not. Regards, Ernst J. Oud Met vriendelijke groet, Ernst J. Oud > On 30 Jun 2022, at 12:00, ripe-atlas-request(a)ripe.net wrote: > > 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: Overuse of software probes (Emile Aben) > 2. Re: Probe on sailboat with Starlink (Daniel Karrenberg) > 3. Re: Assigned AS vs. Advertising AS (ripe.net(a)toppas.net) > 4. Re: Overuse of software probes (Romain Fontugne) > 5. RIPE Atlas Quarterly Planning Q3 2022 (Robert Kisteleki) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 29 Jun 2022 14:34:08 +0200 > From: Emile Aben <emile.aben(a)ripe.net> > To: "Ponikierski, Grzegorz" <gponikie(a)akamai.com>, RIPE Atlas > <ripe-atlas(a)ripe.net> > Subject: Re: [atlas] Overuse of software probes > Message-ID: <7f053467-59c6-69e0-6a33-44a1b42efdd2(a)ripe.net> > Content-Type: text/plain; charset=UTF-8; format=flowed > >> Emile Aben, I would be happy to see code for detecting overly similar >> probes. It would save a lot of time spend on data filtering. > > These are snapshots of data for probe similarity detection [1] in IPv4 > and IPv6 > > https://sg-pub.ripe.net/emile/probe-similarity/probe_similarity_ipv4-2022-0… > https://sg-pub.ripe.net/emile/probe-similarity/probe_similarity_ipv6-2022-0… > > This calculates 3 similarity values between 0 and 1 (the last 3 values > in the csv). Pick the middle one if you don't care about the details. > > There are 54k probe-pairs with similarity values over 0.5, > 7.4k with value over 0.95 > 6.7k with value over 0.99 > > My gut feeling is that anything over 0.95 is likely very redundant for > many types of measurements. > > There seems to be a cluster of about 400 probes that are very similar to > each other, and a couple of smaller clusters too. > > Happy to work with you and others to see if we can make this into > something that is operationally valuable. > > kind regards, > Emile Aben > RIPE NCC > > [1] Holterbach, Thomas, et al. "Measurement vantage point selection > using a similarity metric." Proceedings of the Applied Networking > Research Workshop. 2017. > https://trac.ietf.org/trac/irtf/export/478/www/content/anrw/2017/anrw17-fin… > > > > > ------------------------------ > > Message: 2 > Date: Wed, 29 Jun 2022 14:46:26 +0200 > From: Daniel Karrenberg <dfk(a)ripe.net> > To: Stephen Strowes <s(a)sdstrowes.co.uk>, ripe-atlas(a)ripe.net > Subject: Re: [atlas] Probe on sailboat with Starlink > Message-ID: <2df11fd5-5385-ee11-e5fc-ded5839a6beb(a)ripe.net> > Content-Type: text/plain; charset=UTF-8; format=flowed > > > >> On 28-06-2022 19:46, Stephen Strowes wrote: >> ... I have no idea how starlink decides what ground station to bounce >> your service down onto, it might be interesting to see how it works >> the further you get from home. > > https://starlink.sx/ is a nice *simulation* that provides some graphical > insight in what POPs might be used and why. > NB: one can set the user location at the top right. > > Daniel > > PS: Receiving my starlink RV in a few days. I will test it at home > first. If there is a spare probe, I'll be happy to connect it later. > > > > ------------------------------ > > Message: 3 > Date: Wed, 29 Jun 2022 18:05:44 +0200 > From: ripe.net(a)toppas.net > To: Gert Doering <gert(a)space.net> > Cc: ripe-atlas(a)ripe.net > Subject: Re: [atlas] Assigned AS vs. Advertising AS > Message-ID: <9049c43c-8f51-8710-9061-6ce680a83eeb(a)toppas.net> > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > Hi Gert, > > thanks for your clarification! But you still get my point, do you? > If a prefix was assigned to an entity other than the one that is advertising the prefix, for example: 80.187.128.0/22 > > Announcing: Deutsche Telekom AG (AS3320) > Assigned: T-Mobile Deutschland GmbH (AS44178) > > The information (original prefix receiver) is stored in the RIPE DB, right? It could be compared to what we see via BGP. > I am aware that a single entity can have multiple AS numbers, but when different entities are "involved", more transparency would be great. > > Or am i missing something here? > > BR, > Simon > >> On 29.06.22 10:54, Gert Doering wrote: >> Hi, >>> On Wed, Jun 29, 2022 at 10:30:22AM +0200, Simon Brandt via ripe-atlas wrote: >>> Another example would be a multi ASN company which announces all >>> prefixes from a single ASN via BGP, even though the prefixes are >>> assigned to various AS numbers. Since the RIRs do have the information, >>> to which AS a specific prefix is assigned to, >> prefixes are not assigned to "AS" numbers, ever. >> prefixes are assigned to entities, as are AS numbers. >> ROAs and/or route(6): objects are used to tie both together - and it's >> in the authority of the network (prefix) holder to state which AS is >> allowed and expected to announce a given prefix, not the RIR. >> Repeat: the RIR has no say in "which AS is tied a prefix". >> Gert Doering >> -- NetMaster >

1 0

RIPE Atlas Quarterly Planning Q3 2022
by Robert Kisteleki 30 Jun '22

30 Jun '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 continue with the development of the v5 RIPE Atlas hardware probes among other items as well as start working on two proposals to implement general availability of HTTP measurements and restricting the ability to schedule "non-public measurements". The goal of our quarterly planning is to communicate the work we’re doing for the coming months, get your input and start a discussion on other developments we should work on. 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

Assigned AS vs. Advertising AS
by ripe.net＠toppas.net 29 Jun '22

29 Jun '22

Hi Everyone, worldwide, there are a lot of IP prefixes which are not advertised by the owner AS. Instead, another AS announces the prefix on behalf of the owner. For example: Amazon allows you to announce your prefix via AWS. For other people, this can lead to misassumptions (assuming a wrong IP owner). https://aws.amazon.com/about-aws/whats-new/2018/10/announcing-the-general-a… Another example would be a multi ASN company which announces all prefixes from a single ASN via BGP, even though the prefixes are assigned to various AS numbers. Since the RIRs do have the information, to which AS a specific prefix is assigned to, i would like to ask for more transparency. I would appreciate, if we could see more details here, and even more important: filter for such criterias when creating a new measurement. Anyone else here, who thinks that's useful? BR, Simon

2 2

DNS issues
by Phillip Remaker 29 Jun '22

29 Jun '22

I have installed a probe (/14226) at a rural fixed wireless location which has had intermittent issues from the carrier (AT&T). I got the tag about a DNS issue (Doesn't Resolve A, DNS Problem Suspected). Is it possible to get logs for when the DNS issue happened so I can take it up with the carrier? Also, when does the DNS problem tage clear? Thanks!

3 2

Credits Request
by Martin, Noah S 29 Jun '22

29 Jun '22

Hi all, I’m a new PhD student at Tufts University in Boston, and I'm starting to work on a cloud latency project. If anyone has credits to spare, donations would be greatly appreciated! My account is noah.martin(a)tufts.edu<mailto:noah.martin@tufts.edu> 100k credits would be perfect to get started on my experiments. Thanks, Noah Martin

8 8

Re: [atlas] Credits Request
by Marc Goldburg 29 Jun '22

29 Jun '22

Hi Noah, Just transferred 1m credits. Good luck and please share results when possible. Marc

1 0

Re: [atlas] ripe-atlas Digest, Vol 130, Issue 15
by ignacio.leon 29 Jun '22

29 Jun '22

Hi Noah, 1 Million credits transferred to you. Good luck with your research cheers -- Ignacio Leon Halcyon Pin Mill Rd IP9 1JN Suffolk United Kingdom ignacio.leon(a)yleon.com Mobile: +44 (0) 782 614 5208 On 28.06.2022 21:22, ripe-atlas-request(a)ripe.net wrote: > 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: Credits Request (Nick Hilliard) > 2. Re: Credits Request (David Prall) > 3. Re: Credits Request (Martin, Noah S) > 4. Re: Credits Request (Fadloe Robby) > 5. Re: Credits Request (Rich Smith) > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 28 Jun 2022 19:45:13 +0100 > From: Nick Hilliard <nick(a)foobar.org> > To: "Martin, Noah S" <Noah.Martin(a)tufts.edu> > Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> > Subject: Re: [atlas] Credits Request > Message-ID: <2096ae3c-bbb8-769b-41a7-889d1bc0996c(a)foobar.org> > Content-Type: text/plain; charset=utf-8; format=flowed > > Martin, Noah S wrote on 28/06/2022 19:42: > >> I?m a new PhD student at Tufts University in Boston, and I'm starting >> to >> work on a cloud latency project. If anyone has credits to spare, >> donations would be greatly appreciated! My account is >> noah.martin(a)tufts.edu <mailto:noah.martin@tufts.edu>?100k credits >> would >> be perfect to get started on my experiments. > > just transferred 10m - just drop an email to the atlas community if you > need any more. And we'd love to see any outcomes! > > Nick > > ------------------------------ > > Message: 2 > Date: Tue, 28 Jun 2022 15:44:13 -0400 > From: David Prall <dcp(a)dcptech.com> > To: ripe-atlas(a)ripe.net > Subject: Re: [atlas] Credits Request > Message-ID: <1de5dfeb-d68f-79aa-f44e-9da972d8a9dc(a)dcptech.com> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Noah, > Did the same 10 million > > David > > -- > https://dprall.net > > On 6/28/2022 2:45 PM, Nick Hilliard wrote: Martin, Noah S wrote on > 28/06/2022 19:42: I?m a new PhD student at Tufts University in Boston, > and I'm starting > to work on a cloud latency project. If anyone has credits to spare, > donations would be greatly appreciated! My account is > noah.martin(a)tufts.edu <mailto:noah.martin@tufts.edu>?100k credits > would be perfect to get started on my experiments. > just transferred 10m - just drop an email to the atlas community if you > need any more.? And we'd love to see any outcomes! > > Nick ------------------------------ Message: 3 Date: Tue, 28 Jun 2022 19:45:55 +0000 From: "Martin, Noah S" <Noah.Martin(a)tufts.edu> To: Nick Hilliard <nick(a)foobar.org> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Credits Request Message-ID: <8799C872-A640-4C49-9F23-88E136FE7002(a)tufts.edu> Content-Type: text/plain; charset="utf-8" Thanks so much! > On Jun 28, 2022, at 2:45 PM, Nick Hilliard <nick(a)foobar.org> wrote: > > Martin, Noah S wrote on 28/06/2022 19:42: > >> I?m a new PhD student at Tufts University in Boston, and I'm starting >> to work on a cloud latency project. If anyone has credits to spare, >> donations would be greatly appreciated! My account is >> noah.martin(a)tufts.edu <mailto:noah.martin@tufts.edu> 100k credits >> would be perfect to get started on my experiments. > > just transferred 10m - just drop an email to the atlas community if you > need any more. And we'd love to see any outcomes! > > Nick ------------------------------ Message: 4 Date: Wed, 29 Jun 2022 04:19:07 +0800 From: Fadloe Robby <frobby(a)ulm.ac.id> To: "Martin, Noah S" <Noah.Martin(a)tufts.edu> Cc: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: Re: [atlas] Credits Request Message-ID: <CADRCOtH42Bokrge+9cBJfsuQYKR7n5LDX4Gyy34aUToqVy1_sw(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Noah Martin, I just sent you 30 million. Good luck with your research cloud latency project , and let us know if you need any more I'm sure many others will send you much more over the coming days. Pada tanggal Rab, 29 Jun 2022 pukul 02.42 Martin, Noah S < Noah.Martin(a)tufts.edu> menulis: > Hi all, > > I?m a new PhD student at Tufts University in Boston, and I'm starting > to > work on a cloud latency project. If anyone has credits to spare, > donations > would be greatly appreciated! My account is noah.martin(a)tufts.edu 100k > credits would be perfect to get started on my experiments. > > Thanks, > Noah Martin > > -- > ripe-atlas mailing list > ripe-atlas(a)ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -- Thank you for your consideration. Best regards, Fadloe Robby Telp/WA : 0812-5154-3201 Univeritas Lambung Mangkurat UPT PTIK Univeritas Lambung Mangkurat gedung Rektorat Lantai III Jalan Brigjen H. Hasan Basri Banjarmasin 70123 Telp./Fax. (0511) 330 5195,

1 0

Meaning behind "TU_BAD_ADDR" error
by Meikel Kokowski 22 Jun '22

22 Jun '22

Good evening, While parsing data from some of my measurements (using ripe.atlas.sagan) I stumbled over the “TU_BAD_ADDR” error. The error message is only “true” which makes it difficult to understand its origin. Furthermore, as opposed to other errors, such as “timeout”, no error is indicated by the is_error method of the DnsResult object. Instead I can only find this in the raw_data (in the dns respone object). In my measurements I send the same DNS query (using probe’s IPv6-address) to public resolver and the probes local resolver over UDP and TCP respectively. The TU_BAD_ADDR error occurred solely on measurements to the probes local resolver over TCP. Respective measurements using the same probes over UDP do not report this error. Another observation is that the source address of the response is not set in the majority of the cases (but that is not always the case). An example measurement is #41853554 (the counter-measurement over UDP #41853806). Does anyone know more about this? Best regards, Meikel

1 0

RIPE Atlas down?
by Ernst J. Oud 22 Jun '22

22 Jun '22

Hi, I noticed that of the probes I checked here in The Netherlands, all logging stops at around 03:00 today (June, 22nd). Checked a probe in Germany, same thing but stopped a couple of hours later it seems. Is there some problem? Regards, Ernst J. Oud > On 21 Jun 2022, at 12:00, ripe-atlas-request(a)ripe.net wrote: > > 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: No data for ping to second hop? (Ernst J. Oud) > 2. Re: No data for ping to second hop? (Ponikierski, Grzegorz) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 20 Jun 2022 19:09:01 +0200 > From: "Ernst J. Oud" <ernstoud(a)gmail.com> > To: ripe-atlas(a)ripe.net > Subject: Re: [atlas] No data for ping to second hop? > Message-ID: <E7C26305-00C5-4527-9FE1-F0534352F82E(a)gmail.com> > Content-Type: text/plain; charset="us-ascii" > > Hi, > > Thanks for the reply. But it appears to be a common problem for Linux containers in Docker Desktop for Windows. All traceroute commands only show asterisks. As explained here: > > https://github.com/moby/vpnkit/pull/302 > > (vpnkit is used by Docker in Windows). > > So I will have to install the probe in a native Linux environment instead. > > Which raises another question: if I get the probe running in native Linux, can I transfer my current probe ID to this new installation? Or do I have to apply for a new probe (and disconnect the other)? > > Regards, > > Ernst > >> On 20 Jun 2022, at 12:00, ripe-atlas-request(a)ripe.net wrote: >> >> Re: No data for ping to second hop? >

3 2

Re: [atlas] No data for ping to second hop?
by Ernst J. Oud 20 Jun '22

20 Jun '22

Hi, Thanks for the reply. But it appears to be a common problem for Linux containers in Docker Desktop for Windows. All traceroute commands only show asterisks. As explained here: https://github.com/moby/vpnkit/pull/302 (vpnkit is used by Docker in Windows). So I will have to install the probe in a native Linux environment instead. Which raises another question: if I get the probe running in native Linux, can I transfer my current probe ID to this new installation? Or do I have to apply for a new probe (and disconnect the other)? Regards, Ernst > On 20 Jun 2022, at 12:00, ripe-atlas-request(a)ripe.net wrote: > > Re: No data for ping to second hop?

2 1

No data for ping to second hop?
by Ernst J. Oud 19 Jun '22

19 Jun '22

Hi, Out of curiosity, all my “Built-ins” in my software probe show data except ”#2 Second Hop to ping.ripe.net (193.0.0.164)” which shows: “No data available for [Probe ID] / 2 for this time period.” Any advice? Regards, Ernst Update: This appears to be a docker for Windows issue. My software probe runs on Alpine Linux in docker on Windows 10 WSL. Investigating further…

2 1

No data for ping to second hop?
by Ernst J. Oud 17 Jun '22

17 Jun '22

Hi, Out of curiosity, all my “Built-ins” in my software probe show data except ”#2 Second Hop to ping.ripe.net (193.0.0.164)” which shows: “No data available for [Probe ID] / 2 for this time period.” Any advice? Regards, Ernst

1 0

Discrepancy in documentation?
by Stephane Bortzmeyer 09 Jun '22

09 Jun '22

[Message already sent on 6 june but it never appeared in my mailbox. Is there some email problem at RIPE?] In the documentation <https://beta-docs.atlas.ripe.net/apis/metadata-reference/>, various HTTP methods are used (for instance DELETE to delete a measurement), which is nice, but the examples ("Try it") always show the method GET.

2 1

How to get DNS return codes and TTLs
by Dallan Adamson 09 Jun '22

09 Jun '22

I'm doing research that requires me to use DNS recursive resolvers around the world. At a minimum from these recursive resolvers I need to know what return code the probe received from the recursive resolver as well as the TTL of the record from the same request. I haven't found a way to get both of these when doing DNS measurements with Ripe Atlas probes, is there a way to do this?

2 1

Future of Software Anchors
by Lukas Magauer 04 Jun '22

04 Jun '22

Hi everybody! I have been running a Software probe on CentOS 8 since mid 2020. (and since switched it to Rocky Linux 8) It’s unsupported, but also didn’t really make any problems, just worked fine with the yum repo distributed package! Great that there are already plans to support newer versions as well! And has there something changed in the distribution of the package? Because the latest changes of version 5070 don’t look like they appeared in the GitHub repo? Best regards, Lukas On 14/05/2022 11:14, ripe.net--- via ripe-atlas wrote: Hi Simon, > So it does not really make sense, to set up a new Anchor with CentOS 7, > i guess. What are the plans, dear RIPE Labs? > I searched the atlas mailinglist topics for "software anchor" and > "centos 7" but didn't find anything. For now, we are still deploying Atlas anchors with CentOS 7. However, in the latter half of this year, we plan to work on adapting our configuration systems to a newer Linux distribution. After that, we will upgrade all the Atlas anchors (hardware and virtual) to the newer distribution. Regards, Anand Buddhdev RIPE NCC Hi everyone, accoring to this site, a CentOS 7 installation is required for running a Software Anchor: https://atlas.ripe.net/docs/anchor-installation-vm/ But CentOS 7 will be End-of-Lifetime in two years (30. Juni 2024). https://wiki.centos.org/About/Product So it does not really make sense, to set up a new Anchor with CentOS 7, i guess. What are the plans, dear RIPE Labs? I searched the atlas mailinglist topics for "software anchor" and "centos 7" but didn't find anything. Greetings, Simon

3 3

Re: [atlas] Ongoing problem with DoT measurements
by Michel Stam 31 May '22

31 May '22

Hi Meikel, Sorry for the silence. I had noticed your issue and apparently forgot to reply we were looking into it. As it is we are, bear with us, I will respond as soon as we have an update. Regards, Michel > On 31 May 2022, at 12:19, Meikel Kokowski <meikel.kokowski(a)stud.uni-hannover.de> wrote: > > Does really no one have any idea or thought concerning this problem? > Anything would be appreciated! > > From: Meikel Kokowski <mailto:meikel.kokowski@stud.uni-hannover.de> > Sent: Tuesday, 24 May 2022 02:48 > To: ripe-atlas(a)ripe.net <mailto:ripe-atlas@ripe.net> > Subject: [atlas] Ongoing problem with DoT measurements > > Dear RIPE Mailing List, > > in the context of my final thesis I am conducting research related to DNS (Do53 and DoT) using RIPE Atlas probes. In preparation for the main measurement I issued, to around 4800 probes, DNS queries > > 1) over TLS [measurement ID: 41196896] and > 2) over Do53 (standard) [measurement ID: 41196980] > > While Do53 works perfectly, DoT seems not to yield any results at all. In the RIPE Atlas forum I found a similar question (https://www.ripe.net/participate/mail/forum/ripe-atlas/PDIwMjIwMzI0MTIzMzE1…). According to that thread, a configuration error on the probes causes the problem. That post is 2 months ago and the problem seems to subsist. Could you provide an update to the current situation to this problem and a possible date for a fix? > > Thank you! > > Best, > Meikel > > -- > ripe-atlas mailing list > ripe-atlas(a)ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas

1 0

Re: [atlas] Ongoing problem with DoT measurements
by Meikel Kokowski 31 May '22

31 May '22

Does really no one have any idea or thought concerning this problem? Anything would be appreciated! From: Meikel Kokowski Sent: Tuesday, 24 May 2022 02:48 To: ripe-atlas(a)ripe.net Subject: [atlas] Ongoing problem with DoT measurements Dear RIPE Mailing List, in the context of my final thesis I am conducting research related to DNS (Do53 and DoT) using RIPE Atlas probes. In preparation for the main measurement I issued, to around 4800 probes, DNS queries 1) over TLS [measurement ID: 41196896] and 2) over Do53 (standard) [measurement ID: 41196980] While Do53 works perfectly, DoT seems not to yield any results at all. In the RIPE Atlas forum I found a similar question (https://www.ripe.net/participate/mail/forum/ripe-atlas/PDIwMjIwMzI0MTIzMzE1…). According to that thread, a configuration error on the probes causes the problem. That post is 2 months ago and the problem seems to subsist. Could you provide an update to the current situation to this problem and a possible date for a fix? Thank you! Best, Meikel

1 0

AS34659
by Jacques Lavignotte 29 May '22

29 May '22

Hi, I may be wrong but it looks like there are 3 probes at ASN34659 (Keyyo) and only 1 is up ? Can anyone confirm ? Thanks, Jacques -- GnuPg : 156520BBC8F5B1E3 Because privacy matters. « Quand est-ce qu'on mange ? » AD (c) (tm)

2 1

Looking for a hardware probe
by Giuseppe Macario 25 May '22

25 May '22

Hello everyone, I would like to host a new Atlas probe (for AS203591) but I understand that RIPE is not shipping probes anymore; I applied online but nobody responded. Therefore, feel free write me an email if you have one for sale, in which case I am willing to pay via PayPal. I will also ask RIPE for a new probe ID, so the history attached to your old probe will be reset. PS: not interested in software probes. -- Giuseppe Macario, PhD https://giuseppemacario.men https://www.giuseppemacario.it

5 4

RIPE-Atlas measurements showed "No recent report available"
by Tingting Lu 25 May '22

25 May '22

Hi all, I am using RIPE-Atlas to generate some ping measurements for my testing ip recently. It worked very well until yesterday. Starting from May 23rd, most of my measurements only have results for a few probes. Most probes showed "No recent report available". Does anyone have the same problem or know what's going on there? -- Regards, Tingting Lu

3 3

RIPE-Atlas measurements showed "No recent report available" [DUP]
by POULET Benoit 25 May '22

25 May '22

Hello, Sorry i can't reply to the already started thread as i'm a new subscriber. I can confirm the problem. I have a lot of measurements with "No recent report available" For examples : https://atlas.ripe.net/measurements/41368751/ https://atlas.ripe.net/measurements/41368760/ https://atlas.ripe.net/measurements/41368768/ It's stared from (UTC+2h) : May 23, 2022 11:28:57 AM

1 0

Ongoing problem with DoT measurements
by Meikel Kokowski 23 May '22

23 May '22

Dear RIPE Mailing List, in the context of my final thesis I am conducting research related to DNS (Do53 and DoT) using RIPE Atlas probes. In preparation for the main measurement I issued, to around 4800 probes, DNS queries 1) over TLS [measurement ID: 41196896] and 2) over Do53 (standard) [measurement ID: 41196980] While Do53 works perfectly, DoT seems not to yield any results at all. In the RIPE Atlas forum I found a similar question (https://www.ripe.net/participate/mail/forum/ripe-atlas/PDIwMjIwMzI0MTIzMzE1…). According to that thread, a configuration error on the probes causes the problem. That post is 2 months ago and the problem seems to subsist. Could you provide an update to the current situation to this problem and a possible date for a fix? Thank you! Best, Meikel

1 0

Probe TLS stack
by Christopher Wood 16 May '22

16 May '22

Hi folks, Apologies in advance if the answer to this question is available online somewhere, but I’m wondering if anyone knows what TLS stack is used in Atlas probes, and in particular, what sort of TLS features are configurable by such probes. Best, Chris

2 2

Future of Software Anchors
by ripe.net＠toppas.net 15 May '22

15 May '22

Hi everyone, accoring to this site, a CentOS 7 installation is required for running a Software Anchor: https://atlas.ripe.net/docs/anchor-installation-vm/ But CentOS 7 will be End-of-Lifetime in two years (30. Juni 2024). https://wiki.centos.org/About/Product So it does not really make sense, to set up a new Anchor with CentOS 7, i guess. What are the plans, dear RIPE Labs? I searched the atlas mailinglist topics for "software anchor" and "centos 7" but didn't find anything. Greetings, Simon

3 2

Atlas probes, IPv6, EUI-64, and privacy
by Alexander Burke 03 May '22

03 May '22

Hello all, I couldn't help but notice that my Atlas probe is using an EUI-64 IPv6 address. It has come to light that the presence of even one device using an EUI-64 address on a network has a negative effect on privacy for the whole network: https://arxiv.org/abs/2203.08946 Thoughts? Cheers and thanks in advance, Alex

2 1

My probe's not doin' IPv6
by Edward Lewis 24 Apr '22

24 Apr '22

General question… My probe was doing IPv6 until 15 July 2021 but not it is not. Is there any way to discover why it is no longer IPv6’ing? I did change my ISP connection equipment about that time, so something did change on my end. But IPv6 works for other devices. When I go to www.ripe.net <http://www.ripe.net/> it tells me I came from an IPv6 address. The device has been pretty steady - 99.71% the last week, 99.91% for the last month (30days). It was off-line 29 minutes earlier today (the notice made me think to look), but never off line more than 10 minutes since mid-July. There’s one stretch of 34d+ of continuous uptime. Run-of-the-mill home connection via a cableTV company. Is there anyway to ask a probe why it doesn’t have an IPv6 address (via DHCP)? Ed

5 7

TLSv1.3 Support
by Antonios Chariton 23 Apr '22

23 Apr '22

I’ve ran a measurement against a host that only support TLSv1.3 ( https://atlas.ripe.net/measurements/40393656/#probes ) and all probes came back with "Error: protocol_version”. Do they not support the latest version of TLS? I only seem to be able to get them to work with TLSv1.2 or lower. Thanks, Antonios

1 0

json with all probes
by Cristel Pelsser 23 Apr '22

23 Apr '22

Hi, Can someone point me to the location of the json file with all the probes and their properties? Cristel

2 2

Moving on
by Philip Homburg 06 Apr '22

06 Apr '22

Hi Atlas Users, After ten years at the RIPE NCC it is time for me to move on. Normally, that is not something that would be announced on a public mailing list. However, I get quite a bit of email that is directly sent to me. This is to let you know that I will not be able to read future email sent to this address. I have two new colleagues who will work on probe firmware development. They are Guy Meyer <gmeyer(a)ripe.net> and Michel Stam <mstam(a)ripe.net>. I'm sure they will be happy to help. As for me, I will be <philip(a)nlnetlabs.nl> from now on. Philip Homburg

3 2

RIPE Atlas Quarterly Planning Q2 2022
by Robert Kisteleki 31 Mar '22

31 Mar '22

Dear colleagues, We are now publishing our quarterly planning for RIPE Atlas. This is available at: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas The goals of publishing our planning are to be transparent about the work we will be carrying out in the coming months, to get your input on those plans, and hear what you would like to see the RIPE NCC work on going forward. We will provide status updates as the work progresses and add input from the community to the pages. We will also archive previous plans so you can track how we progress with 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

New on RIPE Labs: Bias in Internet Measurement Infrastructure
by Alun Davies 28 Mar '22

28 Mar '22

Dear colleagues, In this new article on RIPE Labs, Pavlos Sermpezis talks about analysing bias in the Internet measurement infrastructures like RIPE Atlas and RIPE RIS. Are these infrastructures biased? How much of a problem is it if they are? What does bias even look like here? Find out more: https://labs.ripe.net/author/pavlos_sermpezis/bias-in-internet-measurement-… Kind regards, Alun Davies RIPE Labs Editor RIPE NCC

1 0