You are here: Home > Participate > Join a Discussion > RIPE Forum
RIPE Forum v1.4.1

RIPE Atlas

Threaded
Collapse

[atlas] RIPE Atlas Software Probes

User Image

Philip Homburg

2020-02-12 10:53:47 CET

RIPE NCC staff member

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

User Image

Gert Doering

2020-02-12 10:56:55 CET

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
User Image

Jordi Palet Martinez

2020-02-12 11:02:36 CET

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 _at_ ripe _dot_ net en nombre de philip.homburg _at_ ripe _dot_ 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.





Borja Marcos

2020-02-12 11:11:31 CET


> On 12 Feb 2020, at 10:53, Philip Homburg <philip.homburg _at_ ripe _dot_ 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.


User Image

Baptiste Jonglez

2020-02-12 11:15:03 CET

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 _at_ ripe _dot_ net en nombre de philip.homburg _at_ ripe _dot_ 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 
Grenoble INP - Ensimag 
LIG lab 
Drakkar team   |  Polaris team at INRIA 
User Image

Eberhard Lisse

2020-02-12 11:34:57 CET

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 _at_ ripe _dot_ net en nombre de philip.homburg _at_ ripe _dot_ 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 _at_ lisse _dot_ NA             / *      | Telephone: +264 81 124 6733 (cell)
PO Box 8421              \      /
Bachbrecht 10007, Namibia ;____/

User Image

Paul Eagles

2020-02-12 12:03:10 CET

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 _at_ ripe _dot_ net> On Behalf Of Philip Homburg
Sent: 12 February 2020 09:54
To: ripe-atlas _at_ ripe _dot_ net; mat-wg _at_ ripe _dot_ 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

ripe@brite.cz

2020-02-12 12:06:54 CET

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.1-1_arm_cortex-a9_vfpv3.ipk https://repo.turris.cz/hbs/omnia/packages/turrispackages/atlas-probe_2.1.1-1_arm_cortex-a9_vfpv3.ipk

Cheers
Jiri


______________________________________________________________
> Od: "Baptiste Jonglez" <baptiste.jonglez _at_ imag _dot_ fr>
> Komu: "JORDI PALET MARTINEZ" <jordi.palet _at_ consulintel _dot_ es>
> Datum: 12.02.2020 11:15
> Předmět: Re: [atlas] RIPE Atlas Software Probes
>
> CC: <philip.homburg _at_ ripe _dot_ net, ripe-atlas _at_ ripe _dot_ net, mat-wg _at_ ripe _dot_ 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 _at_ ripe _dot_ net en nombre de philip.homburg _at_ ripe _dot_ 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 
>Grenoble INP - Ensimag 
>LIG lab 
>Drakkar team   |  Polaris team at INRIA 
>
>

User Image

Philip Homburg

2020-02-12 12:42:56 CET

RIPE NCC staff member

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

User Image

Robert Kisteleki

2020-02-12 12:52:46 CET

RIPE NCC staff member

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


User Image

Robert Kisteleki

2020-02-12 12:57:35 CET

RIPE NCC staff member

Hi,


> 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
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


User Image

Robert Kisteleki

2020-02-12 13:00:19 CET

RIPE NCC staff member

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

User Image

Philip Homburg

2020-02-12 13:23:49 CET

RIPE NCC staff member

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

User Image

Philip Homburg

2020-02-12 16:03:04 CET

RIPE NCC staff member

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

User Image

Jacques Lavignotte

2020-02-13 19:19:46 CET

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)

User Image

Randy Bush

2020-02-13 20:12:07 CET

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

User Image

Romain Fontugne

2020-02-14 02:42:04 CET

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
> 

User Image

Philip Paeps

2020-02-14 05:19:07 CET

On 2020-02-12 21:11:31 (+1100), Borja Marcos wrote:
> On 12 Feb 2020, at 10:53, Philip Homburg <philip.homburg _at_ ripe _dot_ 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

User Image

Robert Kisteleki

2020-02-14 10:37:55 CET

RIPE NCC staff member

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
>>
> 

User Image

Jaap Akkerhuis

2020-02-14 10:50:38 CET

 "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

User Image

Paul Eagles

2020-02-14 10:56:57 CET

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 _at_ ripe _dot_ net> On Behalf Of Robert Kisteleki
Sent: 14 February 2020 09:38
To: Romain Fontugne <romain _at_ iij.ad _dot_ jp>
Cc: ripe-atlas _at_ ripe _dot_ 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
>>
> 

ripe@brite.cz

2020-02-14 11:07:09 CET

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 _at_ ripe _dot_ net>
> Komu: "Romain Fontugne" <romain _at_ iij.ad _dot_ jp>
> Datum: 14.02.2020 10:38
> Předmět: Re: [atlas] [mat-wg] RIPE Atlas Software Probes
>
> CC: <ripe-atlas _at_ ripe _dot_ 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
>>>
>> 
>
>
>

User Image

Philip Homburg

2020-02-14 11:29:07 CET

RIPE NCC staff member

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

User Image

Randy Bush

2020-02-14 18:02:09 CET

> To be fair the v1 and v2 (ID<=5000) are 9+ years old tiny embedded
> devices

ageist!!!

User Image

Jacques Lavignotte

2020-02-16 16:23:41 CET

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)

User Image

Jared Mauch

2020-02-16 17:00:40 CET

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 _at_ pauleagles _dot_ 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 _at_ ripe _dot_ net> On Behalf Of Philip Homburg
> Sent: 12 February 2020 09:54
> To: ripe-atlas _at_ ripe _dot_ net; mat-wg _at_ ripe _dot_ 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
> 

User Image

Chriztoffer Hansen

2020-02-16 17:44:49 CET

On Sun, 16 Feb 2020 at 17:00, Jared Mauch <jared _at_ puck.nether _dot_ 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

User Image

Philip Homburg

2020-02-17 09:57:41 CET

RIPE NCC staff member

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

User Image

Jacques Lavignotte

2020-02-17 12:08:25 CET


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)