Dear colleagues, We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas. For more details, see our new article on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes Kind regards, Philip
Hi, On Wed, Feb 12, 2020 at 10:53:47AM +0100, Philip Homburg wrote:
We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas.
Will these be tagged and de-selectable for new measurements? IOW, I've had enough bad experience with hypervisor packet loss and weird jitter for "anything that is not TCP based" that I wouldn't want to run anything where I'm interested in more than "might it be able to ping the target (at all)?" on VMs running on unknown hypervisors. 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
Hi,
Will these be tagged and de-selectable for new measurements?
Yes, the all have the tag "system-software".
IOW, I've had enough bad experience with hypervisor packet loss and weird jitter for "anything that is not TCP based" that I wouldn't want to run anything where I'm interested in more than "might it be able to ping the target (at all)?" on VMs running on unknown hypervisors.
Our experience is that there is not much difference. Our researchers are preparing a comparison between the two. Stay tuned! Regards, Robert
Hi Philip, Nice, thanks a lot for this! Do you have interest in people having actual hardware probes in places where they also host VMs, to install also the software probes, in order to be able to "compare" them? I mean for your own stats, or to be able to debug issues, etc. Do you also have any info (overall) about impact on CPU/memory/other consumption of the software probe and if there are important differences among different platforms? By the way, it will be nice to have also a version for OpenWRT! Regards, Jordi @jordipalet El 12/2/20 10:53, "ripe-atlas en nombre de Philip Homburg" <ripe-atlas-bounces@ripe.net en nombre de philip.homburg@ripe.net> escribió: Dear colleagues, We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas. For more details, see our new article on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes Kind regards, Philip ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
Hi Jordi, On Wed, Feb 12, 2020 at 11:02:36AM +0100, JORDI PALET MARTINEZ wrote:
Nice, thanks a lot for this!
Do you have interest in people having actual hardware probes in places where they also host VMs, to install also the software probes, in order to be able to "compare" them? I mean for your own stats, or to be able to debug issues, etc.
Do you also have any info (overall) about impact on CPU/memory/other consumption of the software probe and if there are important differences among different platforms?
By the way, it will be nice to have also a version for OpenWRT!
Apparently the CZ.NIC people did most of the work already, because Turris is based on OpenWrt: https://wiki.turris.cz/doc/en/howto/atlas-probe That being said, nothing seems to have been submitted to the OpenWrt packages repository so far: https://github.com/openwrt/packages I agree, it would be nice to have this in the official OpenWrt repositories!
El 12/2/20 10:53, "ripe-atlas en nombre de Philip Homburg" <ripe-atlas-bounces@ripe.net en nombre de philip.homburg@ripe.net> escribió:
Dear colleagues,
We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas.
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
Kind regards, Philip
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
-- Baptiste Jonglez PhD student / ATER Univ. Grenoble Alpes <https://www.univ-grenoble-alpes.fr/> Grenoble INP - Ensimag <https://ensimag.grenoble-inp.fr> LIG lab <https://www.liglab.fr/> Drakkar team <http://drakkar.imag.fr/> | Polaris team at INRIA <https://team.inria.fr/polaris/>
Hi, SW probes have tag "system-Software" and ID > 1000000 Compare 1000069 running in Turris Omnia router (not a virtual machine), and 15861 directly connected to LAN port of the router. From my observation, 1000069 is about 1 to 2 milliseconds faster than 15861 (ping to fast targets). If you can use .IPK package files, they are located https://repo.turris.cz/hbs/omnia/packages/turrispackages/atlas-sw-probe_1.0.... https://repo.turris.cz/hbs/omnia/packages/turrispackages/atlas-probe_2.1.1-1... Cheers Jiri ______________________________________________________________
Od: "Baptiste Jonglez" <baptiste.jonglez@imag.fr> Komu: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> Datum: 12.02.2020 11:15 Předmět: Re: [atlas] RIPE Atlas Software Probes
CC: <philip.homburg@ripe.net, ripe-atlas@ripe.net, mat-wg@ripe.net> Hi Jordi,
On Wed, Feb 12, 2020 at 11:02:36AM +0100, JORDI PALET MARTINEZ wrote:
Nice, thanks a lot for this!
Do you have interest in people having actual hardware probes in places where they also host VMs, to install also the software probes, in order to be able to "compare" them? I mean for your own stats, or to be able to debug issues, etc.
Do you also have any info (overall) about impact on CPU/memory/other consumption of the software probe and if there are important differences among different platforms?
By the way, it will be nice to have also a version for OpenWRT!
Apparently the CZ.NIC people did most of the work already, because Turris is based on OpenWrt: https://wiki.turris.cz/doc/en/howto/atlas-probe
That being said, nothing seems to have been submitted to the OpenWrt packages repository so far: https://github.com/openwrt/packages
I agree, it would be nice to have this in the official OpenWrt repositories!
El 12/2/20 10:53, "ripe-atlas en nombre de Philip Homburg" <ripe-atlas-bounces@ripe.net en nombre de philip.homburg@ripe.net> escribió:
Dear colleagues,
We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas.
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
Kind regards, Philip
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company
This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.
-- Baptiste Jonglez PhD student / ATER Univ. Grenoble Alpes <https://www.univ-grenoble-alpes.fr/> Grenoble INP - Ensimag <https://ensimag.grenoble-inp.fr> LIG lab <https://www.liglab.fr/> Drakkar team <http://drakkar.imag.fr/> | Polaris team at INRIA <https://team.inria.fr/polaris/>
Hi,
SW probes have tag "system-Software" and ID > 1000000
Technically, as of today, that's a good indicator and indeed can be used to quickly judge whether a probe is software or not. However, it's possible that in the future the probe ID allocation will not strictly reflect the release/architecture, so I'd advise everyone to use the tags (system-software) instead where possible. Regards, Robert
I have a hardware probe on an LTE router at home, and my Ubuntu box (with a galmon [1] probe connected) next to it is on another AS, so maybe I'll try this :-)-O I'd also love a version for the mac, by the way. [1] https://galmon.EU greetings, el On 12/02/2020 12:02, JORDI PALET MARTINEZ wrote:
Hi Philip,
Nice, thanks a lot for this!
Do you have interest in people having actual hardware probes in places where they also host VMs, to install also the software probes, in order to be able to "compare" them? I mean for your own stats, or to be able to debug issues, etc.
Do you also have any info (overall) about impact on CPU/memory/other consumption of the software probe and if there are important differences among different platforms?
By the way, it will be nice to have also a version for OpenWRT!
Regards, Jordi @jordipalet
El 12/2/20 10:53, "ripe-atlas en nombre de Philip Homburg" <ripe-atlas-bounces@ripe.net en nombre de philip.homburg@ripe.net> escribió:
Dear colleagues,
We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas.
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
Kind regards, Philip[...] -- Dr. Eberhard W. Lisse \ / Obstetrician & Gynaecologist el@lisse.NA / * | Telephone: +264 81 124 6733 (cell) PO Box 8421 \ / Bachbrecht 10007, Namibia ;____/
Do you have interest in people having actual hardware probes in places where they also host VMs, to install also the software probes, in order to be able to "compare" them? I mean for your own stats, or to be able to debug issues, etc. There are some deployments like that already. We'd much prefer to extend
Hi, the network with new probes in new networks/locations instead and consider this one of the primary reasons to make this a feature.
Do you also have any info (overall) about impact on CPU/memory/other consumption of the software probe and if there are important differences among different platforms? The impact should be minimal.
By the way, it will be nice to have also a version for OpenWRT!
Indeed. I understand the Turris release is essentially openwrt so it's surely possible! :-) Regards, Robert
if someone wants to compare, 4981 (a lovable old v1), 1000004, and 1000006 are on the same lan segment in the same pop with the same vrrp exit etc. randy
my non-scientific comparison: looking at RTTs in traceroutes the old v1 seems a msec slower. All are very stable Romain On 2/14/20 4:12 AM, Randy Bush wrote:
if someone wants to compare, 4981 (a lovable old v1), 1000004, and 1000006 are on the same lan segment in the same pop with the same vrrp exit etc.
randy
To be fair the v1 and v2 (ID<=5000) are 9+ years old tiny embedded devices, their capabilities are nowhere close to anything else one runs Linux on nowadays. Note that our team is also analysing the similarities/differences, but if someone else also wants to look, these are good candidates (same AS, same prefix, approximately same location): https://atlas.ripe.net/probes/1000030/ (sw) https://atlas.ripe.net/probes/28270/ (v3) or: https://atlas.ripe.net/probes/1000041/ (sw) https://atlas.ripe.net/probes/54558/ (v4) Cheers, Robert On 2020-02-14 02:42, Romain Fontugne wrote:
my non-scientific comparison: looking at RTTs in traceroutes the old v1 seems a msec slower. All are very stable
Romain
On 2/14/20 4:12 AM, Randy Bush wrote:
if someone wants to compare, 4981 (a lovable old v1), 1000004, and 1000006 are on the same lan segment in the same pop with the same vrrp exit etc.
randy
If it's interesting to the community I could fire up a software probe at my house where I've also got a v4 probe. That way it would be a fairly direct comparison, even down to the hardware & software probe being in the same switch. ~P. -----Original Message----- From: ripe-atlas <ripe-atlas-bounces@ripe.net> On Behalf Of Robert Kisteleki Sent: 14 February 2020 09:38 To: Romain Fontugne <romain@iij.ad.jp> Cc: ripe-atlas@ripe.net Subject: Re: [atlas] [mat-wg] RIPE Atlas Software Probes To be fair the v1 and v2 (ID<=5000) are 9+ years old tiny embedded devices, their capabilities are nowhere close to anything else one runs Linux on nowadays. Note that our team is also analysing the similarities/differences, but if someone else also wants to look, these are good candidates (same AS, same prefix, approximately same location): https://atlas.ripe.net/probes/1000030/ (sw) https://atlas.ripe.net/probes/28270/ (v3) or: https://atlas.ripe.net/probes/1000041/ (sw) https://atlas.ripe.net/probes/54558/ (v4) Cheers, Robert On 2020-02-14 02:42, Romain Fontugne wrote:
my non-scientific comparison: looking at RTTs in traceroutes the old v1 seems a msec slower. All are very stable
Romain
On 2/14/20 4:12 AM, Randy Bush wrote:
if someone wants to compare, 4981 (a lovable old v1), 1000004, and 1000006 are on the same lan segment in the same pop with the same vrrp exit etc.
randy
Hi Robert, weirdly, some of the SW probes are showing as "online" but do not provide any measurements results [event the Built-in ones], such as your mentioned 1000030 [Latest data point shown is from 2019-12-17 11:57 UTC] Also for example measurement https://atlas.ripe.net/measurements/23955368/ shows 18 out of 71 SW probes were online [at the moment when I created the measurement] but never provided any results. In https://atlas.ripe.net/measurements/23962519/ I requested all probes with tag system-software, you can see how many probes are Online while not providing any results. What I wanted to point out - I run SW probe 1000069 in Turris Omnia router and I noticed the same behavior - after router restart the SW probe goes online and looks fine, but does not send any results, until I restart the ATLAS process manually, then it runs fine until next router's reboot / power cycle. Cheers Jiri ______________________________________________________________
Od: "Robert Kisteleki" <robert@ripe.net> Komu: "Romain Fontugne" <romain@iij.ad.jp> Datum: 14.02.2020 10:38 Předmět: Re: [atlas] [mat-wg] RIPE Atlas Software Probes
CC: <ripe-atlas@ripe.net>
To be fair the v1 and v2 (ID<=5000) are 9+ years old tiny embedded devices, their capabilities are nowhere close to anything else one runs Linux on nowadays.
Note that our team is also analysing the similarities/differences, but if someone else also wants to look, these are good candidates (same AS, same prefix, approximately same location):
https://atlas.ripe.net/probes/1000030/ (sw) https://atlas.ripe.net/probes/28270/ (v3)
or:
https://atlas.ripe.net/probes/1000041/ (sw) https://atlas.ripe.net/probes/54558/ (v4)
Cheers, Robert
On 2020-02-14 02:42, Romain Fontugne wrote:
my non-scientific comparison: looking at RTTs in traceroutes the old v1 seems a msec slower. All are very stable
Romain
On 2/14/20 4:12 AM, Randy Bush wrote:
if someone wants to compare, 4981 (a lovable old v1), 1000004, and 1000006 are on the same lan segment in the same pop with the same vrrp exit etc.
randy
On 12 Feb 2020, at 10:53, Philip Homburg <philip.homburg@ripe.net> wrote:
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
I am wondering, is the RIPE Atlas probe software fully Linux centric or can it run on other modern *IX derviatives? Borja.
On 2020/02/12 11:11 , Borja Marcos wrote:
I am wondering, is the RIPE Atlas probe software fully Linux centric or can it run on other modern *IX derviatives?
The sort answer is yes, it is fully Linux centric. The longer answer is that the code consists of two parts. One part is a collection of shell scripts that manages the probe and the second is C code that performs the actual measurements. The shell scripts are probably easy to move to a different platform as long that platform has a bourne shell. The tricky part is porting the measurement code. For example, on Linux is relatively straightforward to implement a tcptraceroute. On BSD systems that requires a lot more effort. Note that the measurement code was added to busybox (for historical reasons). Busybox is no longer needed, so that code needs to be removed at some point. Philip
On 2020-02-12 21:11:31 (+1100), Borja Marcos wrote:
On 12 Feb 2020, at 10:53, Philip Homburg <philip.homburg@ripe.net> wrote:
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
I am wondering, is the RIPE Atlas probe software fully Linux centric or can it run on other modern *IX derviatives?
It should be fairly straightforward to run the software probe on FreeBSD under the Linux binary compatibility layer ("Linux personality disorder"). I've been meaning to poke at this but so many projects ... so little time. As far as I can tell from casual inspection of the repository, the main complexity is that the code expects its dependencies to live in Linuxy places, rather than where they usually live on Unix. Other than that, as the other Philip (the smart Philip? :-)) points out: it's mostly shell scripts. It would be nice to run RIPE Atlas software probes without having to install (and worse: maintain!) a Linux machine for the purpose. While Linux is an acceptable choice for a tiny embedded appliance with no measurable attack surface, I wouldn't want it on a server. If you have the time: see if you can make it run under Linux binary compatibility on FreeBSD. If you cook up a port, I'll be more than happy to commit it for you! Philip -- Philip Paeps Senior Reality Engineer Alternative Enterprises
"Philip Paeps" writes:
It should be fairly straightforward to run the software probe on FreeBSD under the Linux binary compatibility layer ("Linux personality disorder"). I've been meaning to poke at this but so many projects ... so little time.
When the software probe projects started I offered to make a FreeBSD port version. The developers said that that was a good idea and they would come back to me. jaap
On 2020/02/14 10:50 , Jaap Akkerhuis wrote:
When the software probe projects started I offered to make a FreeBSD port version. The developers said that that was a good idea and they would come back to me.
A FreeBSD port would be nice, but may be a significant amount of work. Philip
Great news! I'm having a few issues getting the Debian .deb file to build, I don't know if it's something specific to my environment (though I've tried it on a few different boxes) or an issue with the git repository, but: [pauleagles@dns2 ~]$ git clone --recursive https://github.com/RIPE-NCC/ripe-atlas-software-probe.git Cloning into 'ripe-atlas-software-probe'... remote: Enumerating objects: 197, done. remote: Counting objects: 100% (197/197), done. remote: Compressing objects: 100% (120/120), done. remote: Total 485 (delta 86), reused 137 (delta 58), pack-reused 288 Receiving objects: 100% (485/485), 112.47 KiB | 0 bytes/s, done. Resolving deltas: 100% (203/203), done. Checking connectivity... done. Submodule 'github-busybox' (https://github.com/RIPE-NCC/ripe-atlas-probe-busybox.git) registered for path 'probe-busybox' Cloning into 'probe-busybox'... remote: Enumerating objects: 310, done. remote: Counting objects: 100% (310/310), done. remote: Compressing objects: 100% (226/226), done. remote: Total 8634 (delta 117), reused 224 (delta 83), pack-reused 8324 Receiving objects: 100% (8634/8634), 10.21 MiB | 14.91 MiB/s, done. Resolving deltas: 100% (3657/3657), done. Checking connectivity... done. fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6 Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule path 'probe-busybox' [pauleagles@dns2 ~]$ [pauleagles@dns2 ~]$ ./ripe-atlas-software-probe/build-config/debian/bin/make-deb ./ripe-atlas-software-probe/build-config/debian/bin/make-deb: 30: cd: can't cd to /home/pauleagles/atlasswprobe-5010-1-work/probe-busybox/libevent-2.1.11-stable [pauleagles@dns2 ~]$ I need to head out now, but I'll have a deeper look into it later. Cheers, Paul. -----Original Message----- From: ripe-atlas <ripe-atlas-bounces@ripe.net> On Behalf Of Philip Homburg Sent: 12 February 2020 09:54 To: ripe-atlas@ripe.net; mat-wg@ripe.net Subject: [atlas] RIPE Atlas Software Probes Dear colleagues, We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas. For more details, see our new article on RIPE Labs: https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes Kind regards, Philip
On 2020/02/12 12:03 , Paul Eagles wrote:
fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6 Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule path 'probe-busybox' [pauleagles@dns2 ~]$
Weird. It seems that the two repos are out of sync. I'll take a look. Philip
On 2020/02/12 12:42 , Philip Homburg wrote:
On 2020/02/12 12:03 , Paul Eagles wrote:
fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6 Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule path 'probe-busybox' [pauleagles@dns2 ~]$
Weird. It seems that the two repos are out of sync. I'll take a look.
Thanks for reporting the problem. The software probe repo is updated and I set the v5010 tag to the new commit. Philip
Wondering if it makes sense to have a Debian and raspbian repo stood up for this. I could easily add this to my clusters of raspi to make the coverage broader. Sent from my iCar
On Feb 12, 2020, at 6:03 AM, Paul Eagles <paul@pauleagles.com> wrote:
Great news!
I'm having a few issues getting the Debian .deb file to build, I don't know if it's something specific to my environment (though I've tried it on a few different boxes) or an issue with the git repository, but:
[pauleagles@dns2 ~]$ git clone --recursive https://github.com/RIPE-NCC/ripe-atlas-software-probe.git Cloning into 'ripe-atlas-software-probe'... remote: Enumerating objects: 197, done. remote: Counting objects: 100% (197/197), done. remote: Compressing objects: 100% (120/120), done. remote: Total 485 (delta 86), reused 137 (delta 58), pack-reused 288 Receiving objects: 100% (485/485), 112.47 KiB | 0 bytes/s, done. Resolving deltas: 100% (203/203), done. Checking connectivity... done. Submodule 'github-busybox' (https://github.com/RIPE-NCC/ripe-atlas-probe-busybox.git) registered for path 'probe-busybox' Cloning into 'probe-busybox'... remote: Enumerating objects: 310, done. remote: Counting objects: 100% (310/310), done. remote: Compressing objects: 100% (226/226), done. remote: Total 8634 (delta 117), reused 224 (delta 83), pack-reused 8324 Receiving objects: 100% (8634/8634), 10.21 MiB | 14.91 MiB/s, done. Resolving deltas: 100% (3657/3657), done. Checking connectivity... done. fatal: reference is not a tree: 0615d3803b7b68cf85f959957b433f1c9fe2f3e6 Unable to checkout '0615d3803b7b68cf85f959957b433f1c9fe2f3e6' in submodule path 'probe-busybox' [pauleagles@dns2 ~]$
[pauleagles@dns2 ~]$ ./ripe-atlas-software-probe/build-config/debian/bin/make-deb ./ripe-atlas-software-probe/build-config/debian/bin/make-deb: 30: cd: can't cd to /home/pauleagles/atlasswprobe-5010-1-work/probe-busybox/libevent-2.1.11-stable [pauleagles@dns2 ~]$
I need to head out now, but I'll have a deeper look into it later.
Cheers,
Paul.
-----Original Message----- From: ripe-atlas <ripe-atlas-bounces@ripe.net> On Behalf Of Philip Homburg Sent: 12 February 2020 09:54 To: ripe-atlas@ripe.net; mat-wg@ripe.net Subject: [atlas] RIPE Atlas Software Probes
Dear colleagues,
We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas.
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
Kind regards, Philip
On Sun, 16 Feb 2020 at 17:00, Jared Mauch <jared@puck.nether.net> wrote:
Wondering if it makes sense to have a Debian and raspbian repo stood up for this. I could easily add this to my clusters of raspi to make the coverage broader.
Even if the RIPE NCC team only provided pre-compiled binaries as downloadable files [0]. It will the process more accessible at bare minimum, also for a wider audience not comfortable with needing to compile the binaries themself. [0]: https://github.com/RIPE-NCC/ripe-atlas-software-probe/issues/27 -- CHRIZTOFFER
Dear colleagues, Probe #1000165 is up and running. Le 12/02/2020 à 10:53, Philip Homburg a écrit :
Dear colleagues,
We are glad to announce that, after several months of development and testing, we are now accepting applications for RIPE Atlas software probes. With several different installation options to choose from, software probes provide future hosts a whole new way to get involved with RIPE Atlas.
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
Kind regards, Philip
-- GnuPg : 156520BBC8F5B1E3 Because privacy matters. « Quand est-ce qu'on mange ? » AD (c) (tm)
Dear Colleagues, Probe #1000165 is up for about 3 days. https://atlas.ripe.net/probes/1000165/#!tab-network *Connection & Traffic* is firmly showing *No data available for Probe # 1000165 for this time period* since start. Do I have something to do more ? Rgds, Jacques -- GnuPg : 156520BBC8F5B1E3 Because privacy matters. « Quand est-ce qu'on mange ? » AD (c) (tm)
On 2020/02/16 16:23 , Jacques Lavignotte wrote:
*Connection & Traffic* is firmly showing *No data available for Probe # 1000165 for this time period* since start.
Do I have something to do more ?
Hi, There are two issues: The first is that by default, the software probe does not report traffic statistics. This is done to protect people who install a software probe on a router. The readme in the software probe repo describes how to enable reporting of traffic statistics (https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/master/README.rst) The second reason is that our processing of traffic statistics needs to be improved, to avoid reporting statistics on down-stream interfaces of a router. We made some changes to make this happen but not all code is there yet. Philip
Le 17/02/2020 à 09:57, Philip Homburg a écrit :
On 2020/02/16 16:23 , Jacques Lavignotte wrote:
*Connection & Traffic* is firmly showing *No data available for Probe # 1000165 for this time period* since start.
Do I have something to do more ?
Hi,
Hi Philip,
(https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/master/README.rst)
Did it and restarted the service. Thanks,
Philip Jacques
-- GnuPg : 156520BBC8F5B1E3 Because privacy matters. « Quand est-ce qu'on mange ? » AD (c) (tm)
Il giorno mer 12 feb 2020 alle ore 10:53 Philip Homburg < philip.homburg@ripe.net> ha scritto: For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
What about upgrading a software probe? I just do a "git pull", make a new .deb and "dpkg -i atlasswprobe-5010-2.deb", but something went wrong. My probe is now disconnected ( https://atlas.ripe.net/probes/1000163/#!tab-network) *systemctl status atlas* ● atlas.service - Atlas Probe Loaded: loaded (/etc/systemd/system/atlas.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-03-02 12:39:16 CET; 8min ago Main PID: 13550 (ATLAS) Tasks: 7 (limit: 2299) Memory: 3.1M CGroup: /system.slice/atlas.service ├─13550 /bin/sh /usr/local/atlas/bin/ATLAS ├─13596 /usr/local/atlas/bb-13.3/usr/sbin/telnetd -b 127.0.0.1 -p 2023 -P /var/atlas-probe/run/telnetd-port2023-pid.vol ├─13617 /usr/local/atlas/bb-13.3/bin/perd -c /var/atlas-probe/crons/main -A 9801 -P /var/atlas-probe/run/perd-main.pid.vol ├─13619 /usr/local/atlas/bb-13.3/bin/eperd -c /var/atlas-probe/crons/7 -A 9807 -P /var/atlas-probe/run/perd-7.pid.vol -O /home/atlas/data/new/7 -i 7 ├─13620 /bin/sh /usr/local/atlas/bin/ATLAS ├─13622 /usr/local/atlas/bb-13.3/bin/eooqd /var/atlas-probe/crons/oneoff -A 9809 -P /var/atlas-probe/run/eooqd.pid.vol -i 9 └─19503 sleep 180 Mar 02 12:45:27 ... ATLAS[13550]: Ping works Mar 02 12:45:27 ... ATLAS[13550]: start reg Mar 02 12:45:27 ... ATLAS[13550]: ATLAS registeration starting Mar 02 12:45:27 ... ATLAS[13550]: REASON_FOR_REGISTRATION NEW NO previous state files Mar 02 12:45:27 ... ATLAS[13550]: REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 Mar 02 12:45:27 ... ATLAS[13550]: ssh -i /var/atlas-probe/etc/probe_key -p 443 atlas@193.0.19.247 INIT Mar 02 12:45:27 ... ATLAS[13550]: 255 REGINIT exit with error Mar 02 12:45:27 ... ATLAS[13550]: RESULT { "id": "9001", "time": 1583149527, "macaddr": "fa163e790ec7", "uptime": 1830743, "buddyinfo": [ 1, 0, 0, 1, 2, 1, 1, 0, 1, 1, Mar 02 12:45:27 ... ATLAS[13550]: condmv: not moving, destination '/var/atlas-probe/data/out/v6addr.txt' exists Mar 02 12:45:27 ... ATLAS[13550]: condmv: not moving, destination '/var/atlas-probe/data/out/simpleping' exists I think that "dpkg -i ..." generates a *new ssh key pair*: ls -l /var/atlas-probe/etc/ total 8 -rw------- 1 atlas nogroup 1811 *Mar 2 12:36* probe_key -rw-r--r-- 1 atlas nogroup 387 *Mar 2 12:36* probe_key.pub Questions: 1) It's possible to upload the new pub key without re-register my probe? 2) it's possibile to preserve the keys during upgrade (mark as conf file in .deb? ) or I need to make a backup before upgrading? E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Università degli Studi di Ferrara
Hi, You can update you new SSH Key on your probe's page such as https://atlas.ripe.net/probes/1000000/ on the bottom you see "Update SSH Key" Otherwise you can backup your two key files [/var/atlas-probe/etc/probe_key and /var/atlas-probe/etc/probe_key.pub] before any update/reinstallation, and overwrite them back after new installation and reboot. Cheers Jiri ______________________________________________________________
Od: "Enrico Ardizzoni" <enrico.ardizzoni@unife.it> Komu: "Philip Homburg" <philip.homburg@ripe.net> Datum: 02.03.2020 12:57 Předmět: Re: [atlas] RIPE Atlas Software Probes
CC: <ripe-atlas@ripe.net, mat-wg@ripe.net> Il giorno mer 12 feb 2020 alle ore 10:53 Philip Homburg < philip.homburg@ripe.net> ha scritto:
For more details, see our new article on RIPE Labs:
https://labs.ripe.net/Members/alun_davies/ripe-atlas-software-probes
What about upgrading a software probe?
I just do a "git pull", make a new .deb and "dpkg -i atlasswprobe-5010-2.deb", but something went wrong.
My probe is now disconnected ( https://atlas.ripe.net/probes/1000163/#!tab-network)
*systemctl status atlas*
● atlas.service - Atlas Probe Loaded: loaded (/etc/systemd/system/atlas.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2020-03-02 12:39:16 CET; 8min ago Main PID: 13550 (ATLAS) Tasks: 7 (limit: 2299) Memory: 3.1M CGroup: /system.slice/atlas.service ├─13550 /bin/sh /usr/local/atlas/bin/ATLAS ├─13596 /usr/local/atlas/bb-13.3/usr/sbin/telnetd -b 127.0.0.1 -p 2023 -P /var/atlas-probe/run/telnetd-port2023-pid.vol ├─13617 /usr/local/atlas/bb-13.3/bin/perd -c /var/atlas-probe/crons/main -A 9801 -P /var/atlas-probe/run/perd-main.pid.vol ├─13619 /usr/local/atlas/bb-13.3/bin/eperd -c /var/atlas-probe/crons/7 -A 9807 -P /var/atlas-probe/run/perd-7.pid.vol -O /home/atlas/data/new/7 -i 7 ├─13620 /bin/sh /usr/local/atlas/bin/ATLAS ├─13622 /usr/local/atlas/bb-13.3/bin/eooqd /var/atlas-probe/crons/oneoff -A 9809 -P /var/atlas-probe/run/eooqd.pid.vol -i 9 └─19503 sleep 180
Mar 02 12:45:27 ... ATLAS[13550]: Ping works Mar 02 12:45:27 ... ATLAS[13550]: start reg Mar 02 12:45:27 ... ATLAS[13550]: ATLAS registeration starting Mar 02 12:45:27 ... ATLAS[13550]: REASON_FOR_REGISTRATION NEW NO previous state files Mar 02 12:45:27 ... ATLAS[13550]: REGHOSTS reg03.atlas.ripe.net 193.0.19.246 2001:67c:2e8:11::c100:13f6 reg04.atlas.ripe.net 193.0.19.247 2001:67c:2e8:11::c100:13f7 Mar 02 12:45:27 ... ATLAS[13550]: ssh -i /var/atlas-probe/etc/probe_key -p 443 atlas@193.0.19.247 INIT Mar 02 12:45:27 ... ATLAS[13550]: 255 REGINIT exit with error Mar 02 12:45:27 ... ATLAS[13550]: RESULT { "id": "9001", "time": 1583149527, "macaddr": "fa163e790ec7", "uptime": 1830743, "buddyinfo": [ 1, 0, 0, 1, 2, 1, 1, 0, 1, 1, Mar 02 12:45:27 ... ATLAS[13550]: condmv: not moving, destination '/var/atlas-probe/data/out/v6addr.txt' exists Mar 02 12:45:27 ... ATLAS[13550]: condmv: not moving, destination '/var/atlas-probe/data/out/simpleping' exists
I think that "dpkg -i ..." generates a *new ssh key pair*:
ls -l /var/atlas-probe/etc/ total 8 -rw------- 1 atlas nogroup 1811 *Mar 2 12:36* probe_key -rw-r--r-- 1 atlas nogroup 387 *Mar 2 12:36* probe_key.pub
Questions:
1) It's possible to upload the new pub key without re-register my probe? 2) it's possibile to preserve the keys during upgrade (mark as conf file in .deb? ) or I need to make a backup before upgrading?
E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Università degli Studi di Ferrara
Il giorno mar 3 mar 2020 alle ore 11:26 <ripe@brite.cz> ha scritto: Hi,
You can update you new SSH Key on your probe's page such as https://atlas.ripe.net/probes/1000000/ on the bottom you see "Update SSH Key" Otherwise you can backup your two key files [/var/atlas-probe/etc/probe_key and /var/atlas-probe/etc/probe_key.pub] before any update/reinstallation, and overwrite them back after new installation and reboot.
Hi Jiri, you're right! Thank You This is the "prerm" script ( a little bit overkill :) ) #!/bin/sh systemctl stop atlas systemctl disable atlas systemctl stop var-atlasdata.mount systemctl disable var-atlasdata.mount rmdir /var/atlasdata rm -r /var/atlas-probe/.ssh rm -r /var/atlas-probe/bin rm -r /var/atlas-probe/crons * rm -r /var/atlas-probe/etc* rm -r /var/atlas-probe/run rm -r /var/atlas-probe/state rm -r /var/atlas-probe/status E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Università degli Studi di Ferrara
On 2020/03/04 11:14 , Enrico Ardizzoni wrote:
This is the "prerm" script ( a little bit overkill :) )
I'm not an expert in debian packaging. Does the prerm get executed during an upgrade? What I remember is that upgrading the debian package works, but maybe I remember wrong. Philip
On 2020/03/04 11:14 , Enrico Ardizzoni wrote:
This is the "prerm" script ( a little bit overkill :) )
I pushed v5010.3 which fixes the prerm script. Unfortuantely, during an upgrade it runs the old script, so upgrading to 5010-3 will still remove the keys. Philip
Il giorno gio 5 mar 2020 alle ore 16:08 Philip Homburg < philip.homburg@ripe.net> ha scritto: I pushed v5010.3 which fixes the prerm script. Unfortuantely, during an
upgrade it runs the old script, so upgrading to 5010-3 will still remove the keys.
Just copy the new prerm script over /var/lib/dpkg/info/atlasswprobe.prerm before upgrading to 5010-3: # cp ripe-atlas-software-probe/build-config/debian/DEBIAN/prerm /var/lib/dpkg/info/atlasswprobe.prerm Thank you Philip E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Università degli Studi di Ferrara
Hi Philip, with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS) stime() has been deprecated and replaced with clock_settime(). Busybox got the following commit back in 11/2019: https://git.busybox.net/busybox/commit/?id=d3539be8f27b8cbfdfee460fe08299158... Compiling on the latest Ubuntu version I applied the attached diff to get things working again. Bye Bernd -- plan b. solutions GmbH Baumeisterstrasse 50, 76137 Karlsruhe, Germany phone: +49 721 388582, fax: +49 721 388581, mailto: info@planb.de CEO: Bernd Strehhuber, registration court: AG Mannheim HRB 701718
Hi Bernd, On 2020/05/24 13:04 , Bernd Strehhuber wrote:
with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS) stime() has been deprecated and replaced with clock_settime(). Busybox got the following commit back in 11/2019:
https://git.busybox.net/busybox/commit/?id=d3539be8f27b8cbfdfee460fe08299158...
Compiling on the latest Ubuntu version I applied the attached diff to get things working again.
I was working on removing busybox code that is not used by the Atlas measurement code. That makes it unnecessary to patch the busybox code. Replacing an stime call directly with clock_settime is not going to work (that code never runs on software probes, so I understand why it works for you). I'll work on a better patch. In any case, thanks. Philip
On 2020/05/24 13:04 , Bernd Strehhuber wrote:
with newer Linux Dists / glibc Versions (tested on Ubuntu 20.04 LTS) stime() has been deprecated and replaced with clock_settime(). Busybox got the following commit back in 11/2019:
https://git.busybox.net/busybox/commit/?id=d3539be8f27b8cbfdfee460fe08299158...
Compiling on the latest Ubuntu version I applied the attached diff to get things working again.
I put a version in the devel branch of the software probe that refers to a newer version of busybox code, which no longer uses stime. Could you please try that version and see if it works on Ubuntu? Philip
participants (18)
-
Baptiste Jonglez -
Bernd Strehhuber -
Borja Marcos -
Chriztoffer Hansen -
Dr Eberhard W Lisse -
Enrico Ardizzoni -
Gert Doering -
Jaap Akkerhuis -
Jacques Lavignotte -
Jared Mauch -
JORDI PALET MARTINEZ -
Paul Eagles -
Philip Homburg -
Philip Paeps -
Randy Bush -
ripe＠brite.cz -
Robert Kisteleki -
Romain Fontugne