[atlas] Re: Disconnected probes…

[Michel Stam]

Hey Ernst,

I would restart the probe. As you’ve read by now there’s been some issues with 
one of the controllers, so this may resolve problems

Sorry about the hassle

Regards

Michel

> On 22 Aug 2024, at 16:16, Ernst J. Oud  wrote:
> 
> All,
> 
> Some of my disconnected probes have connected again, but probe 60200 has not.
> 
> This is not a network issue since on that router a SW probe (1005072) now 
> connects fine (it was disconnected earlier today)
> 
> Would restarting probe 60200 help? It is in an inconvenient place but if 
> restarting helps let me know.
> 
> Regards,
> 
> Ernst J. Oud

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[atlas] Re: RIPE NCC Atlas probes are going offline: `controller INIT exit with error`

[Michel Stam]

Hello Marek,

It seems we are having some issues with the controllers at the moment, this may 
be the root cause of the problem. 

Please be aware though, the current status of the debian package is still very 
much in development as noted in the INSTALL and README. It may not work 
perfectly yet. Next release will include full Debian support.

Regards,

Michel

> On 21 Aug 2024, at 22:40, Marek Küthe  wrote:
> 
> Hello,
> 
> I am running two RIPE NCC Atlas Probes [1] [2] and both went offline a
> few hours after each other and a `controller INIT exit with error`
> appears in the log [3]. What can I do about this?
> 
> The controller also seems to be somehow not pingable [4].
> 
> I use Debian 12 with the self-compiled .deb package (version 5090) and
> use a slightly hardened systemd unit [5].
> 
> [1] https://atlas.ripe.net/probes/1008669/
> [2] https://atlas.ripe.net/probes/1008711/
> [3] 
> https://paste.i2pd.xyz/?2c936299e0b7473f#G9caVaD8bxLiDvSmHF4HEsZAEjMrW7Gchvj2o3e9SkAJ
>  / 
> https://paste.burble.com/?cecb8def804b373d#GyNsT22QBmii4PGZFnRnVP6mLQC9vhsvjCWTfLixnAm
> [4] https://i.ping.pe/o/L/img_oL3R8bjI.png
> [5] 
> https://codeberg.org/mark22k/dn42-router/src/commit/5c855adbbca45263268ba5dc2c658020224af441/roles/config-ripe-atlas/templates/ripe-atlas.service.j2
> 
> I would appreciate an answer!
> 
> -- 
> Marek Küthe
> m...@mk16.de
> er/ihm he/him
> -
> To unsubscribe from this mailing list or change your subscription options, 
> please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the 
> email matching your subscription before you can change your settings. 
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[atlas] Re: software probe DNS resolving not via OS functions

[Michel Stam]

Hi Marco,

The answer is a bit more complex than yes or no :) Let me get into the weeds 
here:

The Atlas UI by default has probes resolve DNS queries using the local (system) 
resolver. This is done to ensure that probes with a non-functional DNS 
configuration can still execute measurements properly, and reach the same 
results other probes would. See below the setting in the Atlas UI:

The Atlas API by default resolves DNS queries on the Atlas infrastructure, that 
is prior to the measurement being executed by the probe. That means the probe 
will not resolve DNS at all, and get a target IP address specified to perform 
the measurement on
Assuming the probe will be asked to locally resolve a DNS query, this can be 
done in 2 ways for most measurements, except 1. Taking ‘ping’ as an example:
Looking at eperd/evping.c, the usage comments list an option -e which forces 
the libc stub resolver to be used
The handling of this -e option is done in eperd/ping.c, line 1359, where 
delay_name_res is set to 0 (it is 1 by default for legacy compatibility).
If delay_name_res is set to 0, host_and_af2sockaddr() is invoked which in turn 
can be found in libbb/xconnect.c at line 352
This in turn invokes str2sockaddr in the same file at line 213 which tries a 
number of ways to resolve the string to an address (IP string to number 
conversion for one), but ends up at line 317 with a call to getaddrinfo()
getaddrinfo() is a function in the std C library
If the -e option is not supplied, it seems that the libevent getaddrinfo() is 
called, which seems to be an asynchronous implementation of the same function 
call.
In conclusion, if the probe is asked to resolve locally, getaddrinfo() is 
called, which should tie into the libc resolver.
The one exception is the ‘DNS’ measurement. In this specific case, the target 
of the measurement is a DNS server, and because the intent is to get detailed 
information from the DNS server, the requests will be performed directly to the 
DNS server without talking to the libc resolver (that cannot provide this level 
of detail).

Hope this helps.

Regards,

Michel

> On 17 Aug 2024, at 06:22, Marco Moock  wrote:
> 
> Hello!
> 
> I have a software probe and it does many DNS requests. I installed the
> nscd cache on my machine, but the probe itself doesn't use the
> operating system's libc functions to resolve names.
> 
> Is there a special reason for that?
> 
> I am aware I can install a real local caching DNS server on the machine
> like dnsmasq, but I would like to ask the question. :-)
> 
> -- 
> kind regards
> Marco
> -
> To unsubscribe from this mailing list or change your subscription options, 
> please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the 
> email matching your subscription before you can change your settings. 
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[atlas] Re: v2 probe repair?

[Michel Stam]

Hello Philip,

Can you tell me whether your problem persists right now? We’ve had some minor 
issues in the infra that may have affected your probe.

Regards,

Michel

> On 3 Aug 2024, at 16:44, Phillip Remaker  wrote:
> 
> Hello!
> 
> I have an 11+ year old v2 probe 
> 
> Seems to be in a reboot loop. Starts up, all LEDs go blank, and it repeats.
> 
> Any diagnostics I can do? Any repairs?
> 
> https://atlas.ripe.net/probes/4111/#tab-network
> -
> To unsubscribe from this mailing list or change your subscription options, 
> please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the 
> email matching your subscription before you can change your settings. 
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[atlas] Re: v1 probe loses connection after a while (and webui needs more love)

[Michel Stam]

Hello Sulev-Madis,

Would you mind trying again? There have been some glitches over the weekend but 
these should have been resolved.

Please let me know.

Regards,

Michel

> On 4 Aug 2024, at 19:03, Sulev-Madis Silber via ripe-atlas 
>  wrote:
> 
> i meant there were recent updates to ripe atlas i noticed
> 
> the recent power outage is separate issue
> 
> but i noticed problems appearing at same time. as it is always powered, i'm 
> suspecting it now had to reconnect or maybe it also reflashes new updates on 
> boot, so now it's different. but i don't know what's happening here. hence 
> the question!
> -
> To unsubscribe from this mailing list or change your subscription options, 
> please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the 
> email matching your subscription before you can change your settings. 
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[atlas]Re: Installing Software Probe

[Michel Stam]

Hi Milad,

Measurement repository should have been updated, can you check again?

Regards,

Michel

> On 22 Jul 2024, at 10:50, Michel Stam  wrote:
> 
> Hello Milad,
> 
> Thank you for reporting! It seems the measurements code does not auto 
> replicate from the internal to the GitHub repository.
> 
> We’re looking into this, I’ll drop a line as soon as it works again.
> 
> Regards,
> 
> Michel
> 
>> On 20 Jul 2024, at 11:09, Milad Afshari  wrote:
>> 
>> Dear RIPE Atlas Team,
>> 
>> I encountered the following error while trying to download the RIPE Atlas 
>> software probe from the RIPE NCC GitHub repository:
>> 
>> 
>> 
>> fatal: remote error: upload-pack: not our ref 
>> d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f
>> 
>> fatal: Fetched in submodule path 'probe-busybox', but it did not contain 
>> d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f. Direct fetching of that commit 
>> failed.
>> 
>> Can you please assist me with this issue?
>> 
>> Kind regards,
>> Milad Afshari
>> 
>> -
>> To unsubscribe from this mailing list or change your subscription options, 
>> please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
>> As we have migrated to Mailman 3, you will need to create an account with 
>> the email matching your subscription before you can change your settings. 
>> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
> 

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

[atlas]Re: Installing Software Probe

[Michel Stam]

Hello Milad,

Thank you for reporting! It seems the measurements code does not auto replicate 
from the internal to the GitHub repository.

We’re looking into this, I’ll drop a line as soon as it works again.

Regards,

Michel

> On 20 Jul 2024, at 11:09, Milad Afshari  wrote:
> 
> Dear RIPE Atlas Team,
> 
> I encountered the following error while trying to download the RIPE Atlas 
> software probe from the RIPE NCC GitHub repository:
> 
> 
> 
> fatal: remote error: upload-pack: not our ref 
> d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f
> 
> fatal: Fetched in submodule path 'probe-busybox', but it did not contain 
> d72872cc6bb9ed5da47dcf1dc726fd8a36c6058f. Direct fetching of that commit 
> failed.
> 
> Can you please assist me with this issue?
> 
> Kind regards,
> Milad Afshari
> 
> -
> To unsubscribe from this mailing list or change your subscription options, 
> please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
> As we have migrated to Mailman 3, you will need to create an account with the 
> email matching your subscription before you can change your settings. 
> More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

-
To unsubscribe from this mailing list or change your subscription options, 
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the 
email matching your subscription before you can change your settings. 
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

Re: [atlas] IPv4 Built-ins fail while IPv6 work

[Michel Stam]

Hi Paul,

The probe has reported a default route in the logs a little while ago, thats 
good.

I just ran a measurement for you to ping 8.8.8.8 (id : 74399066), which yielded 
this:
2024-06-26 12:15:54 log_cron 16674 DEBUG ATLAS PRB_ID@1008458 ONEOFF 
/home/atlas/crons/oneoff evping -4 -c 3 -s 64 -i 1000 -A "74399066" 8.8.8.8
2024-06-26 12:15:54 log_sent 16674 DEBUG ATLAS PRB_ID@1008458 Crontab sent 
successfully to the probe
2024-06-26 12:15:58 _log 16448 DEBUG ATLAS PRB_ID@1008458 bdcsHA RECVD 
 On 26 Jun 2024, at 14:10, RIPE  wrote:
> 
> HI, 
> That might be it. There was no default route configured on my Edgerouter. I 
> have now triied to configure one.
> At the moment netstat -rn does show a default route for IPv4.
> I have restarted the probe, I assume it may take a little time for the 
> measurements to show results.
> What’s strange is is that it did work as a router for my home network. I 
> think I forced the link to the ISP to be the route somehow.
> 
> 
> Thanks,
>   Paul
> 
> 
>> On 26 Jun 2024, at 13:36, Michel Stam  wrote:
>> 
>> Hey Paul,
>> 
>> I did a quick look in the logs and noticed that the probe doesn’t seem to 
>> have a default route for IPv4, but it does for IPv6. Can you check to see if 
>> this is a possible cause?
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 26 Jun 2024, at 09:10, RIPE via ripe-atlas  wrote:
>>> 
>>> Hi,
>>> My old hardware probe seems to have finally given up. So I installed a soft 
>>> probe on my openwrt edgerouter-X, using the openwrt opkg packages.
>>> That seems to work except for all the IPv4 built-ins.
>>> I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and 
>>> does not provide IPv6.
>>> The IPv6 built-ins all show data but the IPv4 ones show ‘No data available 
>>> for the period’
>>> 
>>> From the shell I can ping the addresses used by the built-ins, the names 
>>> also resolve.
>>> 
>>> Any idea what the cause could be ? Or how to find the cause.
>>> 
>>> 
>>> Probe ID = 1008458
>>> Running   OpenWrt 23.05.3, r23809-234f1a2efa
>>> Package: atlas-sw-probe
>>> Version: 5080-2
>>> 
>>> Regards,
>>> Paul
>>> 
>>> 
>>> -- 
>>> ripe-atlas mailing list
>>> ripe-atlas@ripe.net
>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>> 
>> 
> 


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] IPv4 Built-ins fail while IPv6 work

[Michel Stam]

Hey Paul,

I did a quick look in the logs and noticed that the probe doesn’t seem to have 
a default route for IPv4, but it does for IPv6. Can you check to see if this is 
a possible cause?

Regards,

Michel

> On 26 Jun 2024, at 09:10, RIPE via ripe-atlas  wrote:
> 
> Hi,
> My old hardware probe seems to have finally given up. So I installed a soft 
> probe on my openwrt edgerouter-X, using the openwrt opkg packages.
> That seems to work except for all the IPv4 built-ins.
> I have a hurricane.net tunnel as my ISP ( Odido) is stuck in the past and 
> does not provide IPv6.
> The IPv6 built-ins all show data but the IPv4 ones show ‘No data available 
> for the period’
> 
> From the shell I can ping the addresses used by the built-ins, the names also 
> resolve.
> 
> Any idea what the cause could be ? Or how to find the cause.
> 
> 
> Probe ID = 1008458
> Running   OpenWrt 23.05.3, r23809-234f1a2efa
> Package: atlas-sw-probe
> Version: 5080-2
> 
> Regards,
>   Paul
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Software probe keeps going to disconnected

[Michel Stam]

Hi,

Sorry you’re having issues.

Can you please share the probe id with me? It should be in 
/var/atlas-probe/status (top of my head). reg_init_reply.txt

Is this an RPM install or did you compile this by yourself?

Regards,

Michel

> On 17 Jun 2024, at 20:56, vom513  wrote:
> 
> Hello all,
> 
> I have 2 software probes.  One is on a datacenter VPS and the other at home 
> (runs on Proxmox).
> 
> The one at home keeps going to disconnected.  The probe is Debian 12.  Probe 
> version is 5080-1.
> 
> This machine has v6 as well - so I was thinking maybe something with 
> temp/privacy addresses getting reaped but no, I only have one good old EUI-64 
> address on there.
> 
> (Knock on wood) - no other VMs on my Proxmox machine have any issues like 
> this.
> 
> The only thing that looks remotely related (and this happened a bit before 
> Nagios sent out an alert) is this:
> 
> Jun 17 12:34:41 atlas-probe ATLAS[123749]: /usr/local/atlas/bin/ATLAS: 99: 
> kill: No such process
> Jun 17 12:34:41 atlas-probe ATLAS[123749]: no ssh client matching . cleanup 
> state files. for next restart
> Jun 17 12:34:41 atlas-probe ATLAS[123749]: RESULT 9006 done 1718642081 
> bc2411ca94c6 no reginit.vol start registration
> Jun 17 12:34:41 atlas-probe ATLAS[123749]: 
> /var/atlas-probe/status/reginit.vol does not exist try new reg
> Jun 17 12:34:45 atlas-probe ATLAS[123749]: Ping works
> Jun 17 12:34:45 atlas-probe ATLAS[123749]: /usr/local/atlas/bin/ATLAS: 92: 
> kill: No such process
> Jun 17 12:34:45 atlas-probe ATLAS[123749]: start reg
> Jun 17 12:34:45 atlas-probe ATLAS[144349]: ATLAS registration starting
> Jun 17 12:34:45 atlas-probe ATLAS[144349]: REREG_TIMER 1718416507 expired now 
> is 1718642085
> Jun 17 12:34:45 atlas-probe ATLAS[144349]: REREG_TIMER_EXPIRED  go re 
> register REREG_TIMER 1  , now is 1718642085
> Jun 17 12:34:45 atlas-probe ATLAS[144349]: 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
> Jun 17 12:34:45 atlas-probe ATLAS[144349]: ssh -p 443 
> at...@reg03.atlas.ripe.net INIT
> Jun 17 12:34:48 atlas-probe ATLAS[144349]: Got good controller info
> Jun 17 12:34:48 atlas-probe ATLAS[144349]: check cached controller info from 
> previous registration
> Jun 17 12:34:48 atlas-probe ATLAS[144349]: NO cached controller info. NO 
> REMOTE port info
> Jun 17 12:34:48 atlas-probe ATLAS[144349]: Do a controller INIT
> Jun 17 12:34:48 atlas-probe ATLAS[144349]: Controller init -p  443 
> at...@ctr01.atlas-prod.aws.ripe.net  INIT
> 
> I believe I should see an persistent ssh outbound ?  The only ESTAB is me 
> ssh’ing in, and a 443 to RIPE:
> 
> root@atlas-probe:/home/vom# ss -planto | grep ESTAB
> ESTAB 0  0 192.168.69.111:22  
>192.168.64.21:65409 
> users:(("sshd",pid=145083,fd=4),("sshd",pid=145059,fd=4)) 
> timer:(keepalive,115min,0)
> ESTAB 0  0  [2603:6011:6300:1f02:be24:11ff:feca:94c6]:37176 
> [2a13:27c0:1c:d01:cc61:f3a3:920d:cd88]:443   users:(("ssh",pid=144380,fd=3)) 
> timer:(keepalive,103min,0)   
> 
> Let me know what else I can look at.  I assume there is some debug I can 
> crank up ?  
> 
> Just going to reboot this for now to get it happy and get Nagios to shut up.  
> 
> Thanks.
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Question about TLS test

[Michel Stam]

Hello Marcelo

The current implementation manually does the first part of the handshake then 
disconnects when it receives the certificate from the remote server. It does 
not make use of OpenSSL.

Regards,

Michel

> On 8 Mar 2024, at 10:42, marcelo bagnulo braun  wrote:
> 
> Hi,
> 
> I understand (from a previous post in this ml) that the TLS test available in 
> the Atlas probes uses OpenSSL.
> 
> Could anyone tell me the exact command used by the probe when executing the 
> test? I was assuming it uses something like:
> 
> openssl s_client -connect :port
> 
> Is this correct? Does it includes further options?
> 
> Thanks, marcelo
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Tomhais STARTTLS: Cad a tharla?

[Michel Stam]

Hi Niall,

It is on the backlog for implementation and I have taken a brief look at it to 
gauge complexity, but due to resourcing issues have not completed it. It is not 
in the production, nor the development code at this point in time.

Cheers,

Michel

> On 1 Mar 2024, at 18:54, Niall O'Reilly  wrote:
> 
> Back in December 2022, there was a proposal to support
> STARTTLS measurements.
> (https://www.ripe.net/ripe/mail/archives/ripe-atlas/2022-December/005234.html)
> 
> I wonder, whether this proposal was implemented ?
> 
> I've just tried using the measurement definition form
> (https://atlas.ripe.net/measurements/form/), where the
> only TLS-related option seems to need the target to
> be ready to receive a client hello.
> 
> /Niall
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] BADMD-APP error for v3 probe #25855

[Michel Stam]

Hi Hans,

Not a problem at all, please do update the list. Although I sent a similar 
response there IIRC.

The probe is in a continuous upgrade loop. It downloads kernel, downloads 
application, tries an upgrade, fails, reboots, tries again. Since the USB flash 
has been replaced 3 times and the kernel is also reported “bad” I can only 
conclude that the internal flash is then flawed. I’ve had several returned 
probes with that issue too.

Please mark the 25855 as a write off yes :) thank you Hans!

Cheers,

Michel

> On 22 Nov 2023, at 19:22, Hans Kuhn  wrote:
> 
> Hi Michel,
> 
> Thanks for looking at the logfiles. Do you mind if I update the ripe-atlas 
> mailing list thread sharing your findings?
> 
> Please don't send a replacement probe. I have plenty. :)
> 
> Randy provided me with a replacement probe to install and it's now online 
> (#25898).
> 
> Shall I mark #25855 as a "write off"?
> 
> warm regards, Hans
> 
> 
> On 22 Nov 2023, at 4:56, Michel Stam wrote:
> 
>> Hi Hans,
>> 
>> I just looked at the logfiles. What I’ve seen with the probe is that it is 
>> continuously trying to download the firmware for the unit itself (the 
>> kernel), then the firmware for the usb stick (the application). Since this 
>> process does not yield a working situation, I am afraid that the internal 
>> flash is dead. Any unit I have seen this on so far would remain in this 
>> deadlock forever.
>> 
>> Trying to resurrect this probe by opening it up may be an option but would 
>> wipe any of its state, including the keys necessary to communicate with the 
>> Atlas backend. That is not gonna yield the correct result I’m afraid.
>> 
>> What I will do is send you instructions to apply for a new probe. I’ll 
>> notify the relevant people and you’ll get a replacement v5 shipped to you. 
>> Will that help?
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 20 Nov 2023, at 22:03, Hans Kuhn  wrote:
>>> 
>>> Hi,
>>> 
>>> I'm trying to resurrect a v3 probe that had a status of "Bad Firmware". I 
>>> did the usual:
>>> 
>>> Unplug the probe from its power source
>>> Remove the USB stick from the probe
>>> Plug in the probe WITHOUT the USB stick
>>> Wait for ten minutes
>>> Insert the USB stick
>>> 
>>> I've tried 3 different 8G USB drives and they all give the same result, 
>>> which is the BADMD-APP-5080 and BADMD-KERNEL-1110 error in the SOS log.
>>> 
>>> Is there anything that I can do to resurrect this probe? I'm not afraid to 
>>> TFTP...
>>> 
>>> Thanks!
>>> 
>>> Hans
>>> 
>>> -- 
>>> ripe-atlas mailing list
>>> ripe-atlas@ripe.net
>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] BADMD-APP error for v3 probe #25855

[Michel Stam]

Hi Hans,

I just looked at the logfiles. What I’ve seen with the probe is that it is 
continuously trying to download the firmware for the unit itself (the kernel), 
then the firmware for the usb stick (the application). Since this process does 
not yield a working situation, I am afraid that the internal flash is dead. Any 
unit I have seen this on so far would remain in this deadlock forever.

Trying to resurrect this probe by opening it up may be an option but would wipe 
any of its state, including the keys necessary to communicate with the Atlas 
backend. That is not gonna yield the correct result I’m afraid.

What I will do is send you instructions to apply for a new probe. I’ll notify 
the relevant people and you’ll get a replacement v5 shipped to you. Will that 
help?

Regards,

Michel

> On 20 Nov 2023, at 22:03, Hans Kuhn  wrote:
> 
> Hi,
> 
> I'm trying to resurrect a v3 probe that had a status of "Bad Firmware". I did 
> the usual:
> 
>  Unplug the probe from its power source
>  Remove the USB stick from the probe
>  Plug in the probe WITHOUT the USB stick
>  Wait for ten minutes
>  Insert the USB stick
> 
> I've tried 3 different 8G USB drives and they all give the same result, which 
> is the BADMD-APP-5080 and BADMD-KERNEL-1110 error in the SOS log.
> 
> Is there anything that I can do to resurrect this probe? I'm not afraid to 
> TFTP...
> 
> Thanks!
> 
> Hans
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe issues - now recovered

[Michel Stam]

Hi Nigel,

Sounds familiar, replacing the USB would have been my first suggestion. Good 
call!

Hope it works well for the next 8 years.

Regards,

Michel

> On 4 Sep 2023, at 12:28, Nigel Metheringham  wrote:
> 
> Probe Id 22680
> 
> This v3 probe started playing up a couple of months back but I had not had a 
> chance to properly investigate until this weekend.
> 
> Symptoms were that it disconnected and reconnected every minute or so - my 
> August availability report was nearly 14K lines long!   Packet trace showed 
> that it was connecting to the RIPE atlas hosts on port 433 (but talking ssh), 
> and after a minute or so was sent a FIN from the RIPE end.
> 
> Tried a few things without success, so replaced the USB stick this morning, 
> and so far (only a few hours in) that appears to have fixed the issue...
> 
> The replaced USB stick was the original I got with the hardware something 
> over 8 years back.
> 
>   Nigel.
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] repeating v2 probe usb failure

[Michel Stam]

Hey Randy, 

Typically these sticks have a wear levelling algorithm. My best guess would be 
that filling the stick with garbage would cause it to reallocate any failed 
blocks on the flash memory and substitute them with working blocks. How 
well/long that will last depends on the amount of writes to disk, the amount of 
‘good’ sectors available and the quality of the wear levelling algorithm.

But as said, its a guess.

Cheers,

Michel

> On 14 Aug 2023, at 16:48, Randy Bush  wrote:
> 
> michel,
> 
>> You should be able to order a stick from the net. I would also check
>> the USB power cable (the USB A - Mini-B cable), and the power
>> supply. If the unit doesn’t get enough power a similar problem may
>> occur.
> 
> power measures as good.  will order a usb replacement.  but, in the
> meantime, jaap suggested reformatting the current stick to something
> silly so the software would fully reformat it to atlas friendly.  for
> the moment, that seems to have worked.
> 
> all clues appreciated.
> 
> randy


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Link-Local ICMP messages for Atlas probe

[Michel Stam]

Hi Daryl,

Can’t say I’ve seen it before, can the firewall be a bit too strict?

I read ICMP messages, but I don’t see this in the log you post. Do you have any 
idea what sort of ICMP messages?

Regards,

Michel

> On 14 Aug 2023, at 04:36, Daryl Morse  wrote:
> 
> I've been hosting an Atlas probe since February 2019. I have native 
> dual-stack gigabit fibre internet service and my router is pfSense. Recently, 
> I noticed that there are hundreds of messages in the log of the router like 
> the following:
> 
> Aug 12 22:38:54 kernel cannot forward src fe80:5::1cce:5fff:fe02:61b6, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 22:36:06 kernel cannot forward src fe80:5::e65d:370f:fc45:b5ba, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 22:11:31 kernel cannot forward src fe80:5::3c01:20ff:fee5:f601, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 17:45:08 kernel cannot forward src fe80:5::2a0:a50f:fcdb:db7c, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 15:47:09 kernel cannot forward src fe80:5::2a0:a50f:fcb9:c28e, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 08:13:04 kernel cannot forward src fe80:5::2a0:a50f:fc8a:8134, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 06:55:33 kernel cannot forward src fe80:5::bac2:530f:fc39:164a, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 03:39:05 kernel cannot forward src fe80:5::2a0:a50f:fc8a:85c0, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 01:17:54 kernel cannot forward src fe80:5::e6fc:820f:fcea:2016, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 12 00:55:09 kernel cannot forward src fe80:5::ee9e:cd0f:fc0d:79d4, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 11 15:47:11 kernel cannot forward src fe80:5::4271:830f:fce5:7fa, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 11 15:25:42 kernel cannot forward src fe80:5::bac2:530f:fcd4:fdd2, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 11 07:33:53 kernel cannot forward src fe80:5::cd08:c204:cc63:2d32, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 11 06:17:19 kernel cannot forward src fe80:5::fe33:420f:fcdc:5932, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 11 04:49:00 kernel cannot forward src fe80:5::7e25:860f:fc44:6742, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 22:41:25 kernel cannot forward src fe80:5::9ca0:15ff:fe87:842e, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 14:38:59 kernel cannot forward src fe80:5::c80a:daff:fe92:b8b7, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 10:55:07 kernel cannot forward src fe80:5::2a0:a50f:fc8a:6ea0, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 08:57:19 kernel cannot forward src fe80:5::46aa:500f:fceb:ad66, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 05:47:09 kernel cannot forward src fe80:5::b68a:5f0f:fcb2:1040, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 03:24:58 kernel cannot forward src fe80:5::2a0:a50f:fcb6:5ea2, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 03:08:55 kernel cannot forward src fe80:5::2a0:a50f:fc90:9d4, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 00:17:07 kernel cannot forward src fe80:5::e65d:370f:fc44:15ba, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> Aug 10 00:07:07 kernel cannot forward src fe80:5::2a0:a50f:fcb7:7c, dst 
> 2001:569:585f:b00:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
> 
> The messages occur in groups of three, spaced a few seconds apart.
> 
> All of the messages start with fe80:5. Even if I strip off the "5", none of 
> them seem to convert into MAC addresses, so I can't use that to figure out 
> what type of device is pinging the probe.
> 
> There are no entries in the NDP table corresponding to these messages.
> 
> I have no idea how long this has been happening. I only noticed it when I was 
> setting up a new server to host pfsense.
> 
> My probe is RIPE-Atlas-Probe-52209.
> 
> I'm interested to know if anyone else has experienced this.
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] repeating v2 probe usb failure

[Michel Stam]

Hey Randy,

You should be able to order a stick from the net. I would also check the USB 
power cable (the USB A - Mini-B cable), and the power supply. If the unit 
doesn’t get enough power a similar problem may occur.

Regards,

Michel

> On 13 Aug 2023, at 23:25, Randy Bush  wrote:
> 
> probe 25898 had a usb failure.  i did the unplug usb, power cycle, wait,
> replug usb.  it worked for most of a day and then failed again.  rinse
> repeat.  oops, this last time, it has yet to return.
> 
> can i just order a usb off the net and replace it?  or do i just replace
> the unit?
> 
> randy
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] System tag

[Michel Stam]

Hello Ernst,

From the top of my head, the system-generated tags are done based on internal 
measurements the probe does. 

CTR-HEL09 has had a reboot about 3 days ago, and your probe seems to connect to 
CTR-HEL09 mostly, so that would explain that disconnect. I am not sure the 
tagging is related to the connection with the controller being lost, it’s more 
likely that one of the internal measurements did not get the expected response 
and concluded IPv4 wasn’t stable enough. It seems to have resolved, just now 
the probe showed as being stable again.

Hope this helps. Let me know if you need me to dig a bit further.

Regards,

Michel

> On 3 Aug 2023, at 22:43, Ernst J. Oud  wrote:
> 
> Hi, 
> 
> Further to my question; checked my logs and on at the date/time the 
> connection history of this probe is reported as “disconnected” (2023-08-01 
> 06:41:54 UTC) there was no problem whatsoever on my internet connection.
> 
> So why was the probe disconnected? I see that status for my probes quite a 
> lot, is it the controller (ctr-hel09) that needs to go get a beer or what?
> 
> Regards,
> 
> Ernst J. Oud
> 
>> On 3 Aug 2023, at 22:33, Ernst J. Oud  wrote:
>> 
>> I noticed that the system tag “IPv4 stable 1d” is gone from my probe at:
>> 
>> https://atlas.ripe.net/probes/1005104/
>> 
>> I use that tag as a criteria to select active probes for measurements. But I 
>> noticed that my own probe was not included in my measurements.
>> 
>> Which is weird since my probe has been online for 2.5 days (normally it is 
>> more stable, but my ISP had a small downtime).
>> 
>> So my question is what triggers this tag? The tag is self explanatory but 
>> what does “stable” mean?
>> 
>> Regards,
>> 
>> Ernst J. Oud
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] DoH and DoT measurements

[Michel Stam]

Hello Grzegorz,

The resolve_on_probe flag is used to have the probe do DNS resolution, 
otherwise the backend takes care of that.

Cheers,

Michel

> On 26 Jul 2023, at 17:47, Ponikierski, Grzegorz  wrote:
> 
> Indeed “tls” flag seems to work. Thanks!
>  
> After first try with DoT providers like one.one.one.one or dns.google 
> <http://dns.google/> I have additional question. When exactly FQDN from 
> “target” is resolved to IP? Is RIPE Atlas resolve domain to IP only once 
> during measurements creation or is each probe resolve domain to IP 
> individually? It’s important details for me because I will work with FQDN 
> that will resolve do different IP depending on user location so if it is 
> resolved only once by RIPE Atlas system then probes will be using sub-optimal 
> IPs to run tests.
>  
> Regards,
> Grzegorz
>  
> From: Michel Stam mailto:ms...@ripe.net>>
> Date: Wednesday, 26 July 2023 at 17:13
> To: "Ponikierski, Grzegorz" mailto:gponi...@akamai.com>>
> Subject: Re: [atlas] DoH and DoT measurements
>  
> Hey Grzegorz, 
>  
> It’s a bit hidden, but in the measurement definition I think the key ’tis’ 
> needs to be set to the boolean value ’true’. That should enable DNS over TLS.
>  
> Cheers,
>  
> Michel
> 
> 
> On 26 Jul 2023, at 17:09, Ponikierski, Grzegorz  <mailto:gponi...@akamai.com>> wrote:
>  
> I have reviewed API Manual and Reference but I don’t see anything about DoH 
> or DoT. Maybe I have overlooked something?
>  
> Regards,
> Grzegorz
>  
> From: Michel Stam mailto:ms...@ripe.net>>
> Date: Wednesday, 26 July 2023 at 15:30
> To: "Ponikierski, Grzegorz" mailto:gponi...@akamai.com>>
> Cc: "ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>"  <mailto:ripe-atlas@ripe.net>>
> Subject: Re: [atlas] DoH and DoT measurements
>  
> Hello Gzzegorz, 
>  
> If I saw correctly DNS over TLS should be possible. Some initial steps have 
> been taken to implement DNS over HTTP(S) but such is not available yet.
> You will probably have to use the API to schedule one, though
>  
> RIPE Atlas docs | RIPE Atlas Documentation | Docs 
> <https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$>
> atlas.ripe.net 
> <https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$>
> 
>  
> <https://urldefense.com/v3/__https:/atlas.ripe.net/docs/__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKwtF0RHE$>
>  
> Hope this helps,
>  
> Regards,
>  
> Michel
>  
>  
> 
> 
> 
> On 26 Jul 2023, at 15:09, Ponikierski, Grzegorz via ripe-atlas 
> mailto:ripe-atlas@ripe.net>> wrote:
>  
> Hi!
>  
> Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE 
> Atlas?
>  
> Regards,
> Grzegorz
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
> https://lists.ripe.net/mailman/listinfo/ripe-atlas 
> <https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atlas__;!!GjvTz_vk!UIWbNOgesINdK7phtPcRFUNL6Ah4klT6w0UBrDN6eQQavoEWGbvHAf3Q-h2r1ErslWGKT9WPC80$>
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] DoH and DoT measurements

[Michel Stam]

Hello Gzzegorz,

If I saw correctly DNS over TLS should be possible. Some initial steps have 
been taken to implement DNS over HTTP(S) but such is not available yet.
You will probably have to use the API to schedule one, though

https://atlas.ripe.net/docs/
Hope this helps,

Regards,

Michel



> On 26 Jul 2023, at 15:09, Ponikierski, Grzegorz via ripe-atlas 
>  wrote:
> 
> Hi!
>  
> Is it possible to run DNS over HTTPS and DNS over TLS measurements with RIPE 
> Atlas?
>  
> Regards,
> Grzegorz
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net 
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Recovered probe v3

[Michel Stam]

Hi Renny,

The only way to get the firmware back on is to ship the unit back to us, we 
will look it up in and try to recover it. Unfortunately this is not a process 
you can do yourself.

Regards,

Michel

> On 24 Jun 2023, at 03:45, Renny Leal  wrote:
> 
> Hi folks
>  
> I’ve recovered one V3 probe but sadly the person who got it flashed the 
> tp-link original firmware to the device.
>  
> Is there any way to get the ripe atlas firmware back to it?
>  
> Thanks in advance
>  
>  
> Enviado desde Correo  para 
> Windows
>  
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net 
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] state of the source code repository and releases [was: upgrading an original soft probe]

[Michel Stam]

Hi Lukas!

Sorry for the delay in response, I was off for a few days and for some reason 
your mail got buried beneath a pile of other mail.

Let me give you a bit of a background;

About a year or so ago we set up a CI/CD pipeline for the software and hardware 
probes. The intent being that the software would be built by a clean platform 
every single time a commit was tagged for building, or if any of the major 
branches were updated. This all happens from an internal repository that is not 
publicly accessible.

Somewhere around that time we also started with a new development strategy. 
A master branch which contains production-ready code. This is the code that 
users can deploy on their own setup, and it is also the code that the RPMs and 
the hardware probe firmware will be built on.
A testing branch on which the master branch is essentially a pointer. The 
testing branch contains code that is being readied for the next production 
release
A devel(opment) branch that contains code which is by its nature feature 
complete, but may not be fully tested yet. This code is merged into the testing 
branch upon completion and unit testing.
Ticket branches that run off the development branch and contain features that 
may or may not work

Out of all of this, only the tags and master branch pointers are automatically 
synced from the internal repository to the GitHub repository. This is by intent 
to discourage people from deploying code which is not feature complete. For 
sake of transparency, as well as convenience, this code is visible. Well 
spotted! :)

The versioning is your next implied question- any number divisible by 10 is a 
production release (5060, 5070, 5080). Any other number is either a development 
or a testing release. I would recommend to use the master branch or any tag 
which is divisible by 10, which in essence would be a (previous) production 
release.

As to decreasing numbers. At the time there were two people working on 
different features at the same time, some of which we were both testing on 
different probe platforms simultaneously. One was working on 5083 the other on 
5081/2. Ugly, yes. I believe I was restructuring for the version 3 hardware 
probe at that time.
Ideally we would sync only the release tags and not the development tags, but 
unfortunately that is not how the internal repository (Gitlab) works.

The current released version is 5080. I’m working on the next release as we 
speak, which will include a restructure to accommodate providing packages to 
the RHEL repositories. I’m interested in talking to debian distribution 
maintainers who are willing to help do the same for Debian. OpenWRT is also 
something I’ll be looking at.

Short and simple. Master contains the latest production code. Use it in good 
health :)

Cheers,

Michel

> On 4 Jun 2023, at 20:03, Lukas Tribus  wrote:
> 
> Hello Michel,
> 
> 
> On Sun, 12 Feb 2023 at 22:51, Michel Stam  wrote:
>> 
>> Hello Randy,
>> 
>> We are currently actually looking at providing packages for other 
>> distributions, through
>> the regular repositories of the distribution. However that means we have to 
>> work pieces
>> of the software probe to comply to distribution standards. I cannot 
>> guarantee right now
>> whether Debian will be provided, but this is something I would personally 
>> like to see.
> 
> For third party package maintainers and users willing to compile from source:
> 
> What is the currently released version of the atlas-software-probe?
> 
> HW probes seem to be running 5080.
> 
> On the git repository we have the following tags:
> 
> 2022 Sep 19: 5080 was tagged
> 2022 Nov 30: 5083 was tagged
> 2022 Dec 9: 5082 was tagged
> 2023 Feb 24: 5081 was tagged
> 2023 Feb 28: 5084 was tagged
> 
> 
> Is 5080 the current release, which HW probes are running, and the
> newer tags in the source code repository should be ignored?
> Is 5084 the current release, but HW probes are lagging behind?
> Why did we see decreasing versioning tags from November to February?
> Where can a third party package maintainer (or a user compiling from
> source) find authoritative information about what the latest atlas SW
> probe actually is?
> 
> There is only a single branch in the git repository, which is master.
> However while the 5080 tag seems to be in the master branch, the newer
> tags are not, so I guess that means 5080 is indeed the last properly
> released version.
> 
> 
> But I really don't like to guess and I don't see how anyone not
> directly involved in the SW development of the probe would be able to
> package it considering the ambiguity in the source code repository.
> 
> 
> 
> Thanks,
> 
> Lukas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe DHCPv6 support

[Michel Stam]

Thanks Gert,

That will do nicely for a test bed. I will add that to the ticket.

Cheers,

Michel


> On 19 May 2023, at 08:51, Gert Doering  wrote:
> 
> Hi,
> 
> On Thu, May 18, 2023 at 04:41:58PM +0200, Michel Stam wrote:
>> Do you have examples for that on relevant DHCPv6 implementations?
> 
> With ISC-DHCPv6, it's very straightforward
> 
> # global options
> option dhcp6.name-servers 2001:608::2, 2001:608::1;
> option dhcp6.domain-search "space.net", "test.space.net";
> default-lease-time 86400;
> preferred-lifetime 7200;
> 
> # Set preference to 255 (maximum) in order to avoid waiting for
> # additional servers when there is only one
> option dhcp6.preference 255;
> 
> # SpaceNet TestNetz wifi
> subnet6 2001:608:0:99::/64 {
>range6 2001:608:0:99:a000::100 2001:608:0:99:a000::500;
>ddns-rev-domainname "ip6.arpa";
>ddns-domainname "test.space.net";
> }
> 
> 
> Gert Doering
>-- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe DHCPv6 support

[Michel Stam]

Hi Simon,

I was actually thinking about the server side, not the client side. The client 
side I’ll figure out, I have some experience with OpenWRT ;)

Do you have examples for that on relevant DHCPv6 implementations?

Regards,

Michel

> On 15 May 2023, at 20:57, Simon Brandt via ripe-atlas  
> wrote:
> 
> Hi Michel,
> 
> sorry, i don't have an OpenWrt device that's using DHCPv6 in client mode.
> But it should be easy. Make sure the 'odhcp6c' package is installed (which is 
> the case by default).
> Then change the protocol option for the interface:
> 
> /etc/config/network
> 
> config interface 'eth0'
> option proto 'dhcpv6'
> 
> Check out this link to see als available options for the DHCPv6 client mode:
> https://openwrt.org/docs/guide-user/network/ipv6/configuration#protocol_dhcpv6
> 
> 
> As far is i can see, you can only use OpenWrt in DHCPv4 client mode OR in 
> DHCPv6 client mode. So i guess, you have to write a small script. First try 
> DHCPv6 and check if you can successfully get a configuration. If not, fall 
> back to DHCPv4. Continuously toggle between DHCPv6 and DHCPv4 as long as you 
> don't get a configuration. I would begin this loop with DHCPv6. Also keep in 
> mind, that some DHCP server respond slow, so better wait a little bit, before 
> switching the protocol.
> 
> 
> BR,
> Simon
> 
> 
> 
> On 15.05.23 09:12, Michel Stam wrote:
>> Hi,
>> 
>> Good discussion!
>> 
>> I’m currently looking at basing all the probes (3, 4 and 5) on OpenWRT 22.03 
>> which is the latest stable. What I’ll do is take this along in the 
>> deliberations, and see if I can fit this into the firmware image somehow.
>> 
>> Simon: can you provide the exact setup you use for testing? (Config snippets 
>> etc) I typically don’t have a problem on my setup here, but thats RA + 
>> DHCPv6, I don’t use DHCPv6 for the actual assignment.
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 9 May 2023, at 20:27, Simon Brandt via ripe-atlas  
>>> <mailto:ripe-atlas@ripe.net> wrote:
>>> 
>>> That should be "odhcp6c"
>>> 
>>> https://openwrt.org/packages/pkgdata/odhcp6c
>>> https://github.com/openwrt/odhcp6c
>>> 
>>> 
>>> BR,
>>> Simon
>>> 
>>> On 09.05.23 20:22, Philip Homburg wrote:
>>>> 
>>>> In any case, Atlas probes run a stripped down version of OpenWRT. It may 
>>>> help
>>>> if somebody can figure out which OpenWRT packages need to be added to 
>>>> enable DHCPv6.
>>> 
>>> -- 
>>> ripe-atlas mailing list
>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe DHCPv6 support

[Michel Stam]

Hi,

Good discussion!

I’m currently looking at basing all the probes (3, 4 and 5) on OpenWRT 22.03 
which is the latest stable. What I’ll do is take this along in the 
deliberations, and see if I can fit this into the firmware image somehow.

Simon: can you provide the exact setup you use for testing? (Config snippets 
etc) I typically don’t have a problem on my setup here, but thats RA + DHCPv6, 
I don’t use DHCPv6 for the actual assignment.

Regards,

Michel

> On 9 May 2023, at 20:27, Simon Brandt via ripe-atlas  
> wrote:
> 
> That should be "odhcp6c"
> 
> https://openwrt.org/packages/pkgdata/odhcp6c
> https://github.com/openwrt/odhcp6c
> 
> 
> BR,
> Simon
> 
> On 09.05.23 20:22, Philip Homburg wrote:
>> 
>> In any case, Atlas probes run a stripped down version of OpenWRT. It may help
>> if somebody can figure out which OpenWRT packages need to be added to 
>> enable DHCPv6.
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] upgrading an original soft probe

[Michel Stam]

Hello Thomas,

The code of the software probe is the same as for the hardware probes, however 
the release process currently involves manual steps. This means that there can 
be a little while between one platform and the next being released. Sorry about 
that, we’re working very hard on automating this. 

Cheers,

Michel

> On 11 Feb 2023, at 12:21, Thomas Schäfer  wrote:
> 
> Am Freitag, 10. Februar 2023, 18:17:23 CET schrieb Randy Bush:
>> michael
>> 
>>> You may try and build a 5080 package, then upgrade from debian. I’d
>>> keep a backup of the keys in /var/atlas-probe/etc (top of my head)
>>> just in case.
>> 
>> is there a path where a simple `apt update; apt upgrade` will work
>> ongoing?  building and installing debs is s last century.
> 
> did you miss that thread ?
> 
> https://www.ripe.net/ripe/mail/archives/ripe-atlas/2023-January/
> thread.html#5322
> 
> A long discussion without results.
> 
> I would also to be happy to have a repository, so the atlas gets updated, 
> when 
> I update the OS/packages. (apt upgrade, zypper update)
> Even announcement  here doesn't work. Sometimes I see my hw probe has a 
> higher 
> version number than my sw probes and it is not easy to find out why.
> 
> 
> Regards,
> Thomas
> 
> 
> 
> 
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] upgrading an original soft probe

[Michel Stam]

Hello Randy,

We are currently actually looking at providing packages for other 
distributions, through the regular repositories of the distribution. However 
that means we have to work pieces of the software probe to comply to 
distribution standards. I cannot guarantee right now whether Debian will be 
provided, but this is something I would personally like to see.

You can find the instructions here:
https://github.com/RIPE-NCC/ripe-atlas-software-probe/blob/master/INSTALL.rst
ripe-atlas-software-probe/INSTALL.rst at master · 
RIPE-NCC/ripe-atlas-software-probe
github.com

When checking out, use “git checkout 5080” to checkout the 5080 tag.

Let me know how it works!

Cheers,

Michel


> On 10 Feb 2023, at 18:17, Randy Bush  wrote:
> 
> michael
> 
>> You may try and build a 5080 package, then upgrade from debian. I’d
>> keep a backup of the keys in /var/atlas-probe/etc (top of my head)
>> just in case.
> 
> is there a path where a simple `apt update; apt upgrade` will work
> ongoing?  building and installing debs is s last century.
> 
> and where are the instructions to find 5080 and build that deb?
> 
> randy

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] upgrading an original soft probe

[Michel Stam]

Hi Randy,

You may try and build a 5080 package, then upgrade from debian. I’d keep a 
backup of the keys in /var/atlas-probe/etc (top of my head) just in case. 

Cheers,

Michel

> On 10 Feb 2023, at 17:27, Randy Bush  wrote:
> 
> i have a probe, 104, on a deb 10 vm that was installed in the
> rotterdam hackathon.  the detritus looks as if it was built using a deb
> install of atlasswprobe-5000-1.deb.
> 
> two days ago, it stopped working in some way; i have not pursued,
> figuring i was dealing with an antique.
> 
> is there a path to make it current?
> 
> randy
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Measurement question

[Michel Stam]

Hey Roberto,

I’m not sure what I’m seeing here, but it could be that the host refuses ICMP 
or UDP but accepts TCP (websites). 

Would that explain it?

Regards,

Michel

> On 8 Feb 2023, at 17:56, roberto.lucign...@caleidos.it wrote:
> 
> Hi Michel,
> I have one last question.
>  
> In the diagram below_
> 
>  
> The route on the left is marked as “Target not reached” and the one on the 
> right is marked as “Target reached” but from both location I’m able to reach 
> the website hosted on the target, which is the difference ?
>  
> Regards,
> Roberto
> From: ripe-atlas  <mailto:ripe-atlas-boun...@ripe.net>> on behalf of 
> roberto.lucign...@caleidos.it <mailto:roberto.lucign...@caleidos.it> 
> mailto:roberto.lucign...@caleidos.it>>
> Date: Wednesday, 8 February 2023 at 16:43
> To: Michel Stam mailto:ms...@ripe.net>>
> Cc: Qasim Lone mailto:ql...@ripe.net>>, Alexander Burke via 
> ripe-atlas mailto:ripe-atlas@ripe.net>>, Emile Aben 
> mailto:ea...@ripe.net>>
> Subject: Re: [atlas] Measurement question
> 
> Hi Michael,
> thank you very much for the explanation. I made another measure using UDP and 
> now the collected routes make more sense. I was not aware of the 5 hops 
> without response.
>  
> Glad we spot out a particular case 😊
>  
> Regards,
> Roberto
>  
>  
> From: Michel Stam mailto:ms...@ripe.net>>
> Date: Wednesday, 8 February 2023 at 14:08
> To: roberto.lucign...@caleidos.it <mailto:roberto.lucign...@caleidos.it> 
> mailto:roberto.lucign...@caleidos.it>>
> Cc: Qasim Lone mailto:ql...@ripe.net>>, Emile Aben 
> mailto:ea...@ripe.net>>, Alexander Burke via ripe-atlas 
> mailto:ripe-atlas@ripe.net>>
> Subject: Re: [atlas] Measurement question
> 
> Hello Roberto,
> 
> I’ve done the exact same measurement too, using the 3 types of traceroute 
> available (ICMP, UDP and TCP).
> UDP:
> (https://atlas.ripe.net/measurements/49826077/#general)
> 
> 
> 
> TCP:
> (https://atlas.ripe.net/measurements/49826078/#general)
> 
> 
> ICMP:
> (https://atlas.ripe.net/measurements/49826076/#general)
> 
> 
> The way the traceroute works in Atlas is that if 5 hops have been received 
> without response, the trace skips over to TTL 255 and ends the traceroute. 
> This is what you see with TCP and ICMP. The traceroute stops for lack of 
> response. To prove that, I’ve run the trace again, skipping hops 1-7, for 
> both ICMP and TCP:
> 
> https://atlas.ripe.net/measurements/49826868/#general
> 
> 
> https://atlas.ripe.net/measurements/49826959/#general
> 
> 
> 
> 100.64.0.0/10 is CGN (Carrier Grade NAT), RFC 6598.
> Looking at the traceroute differently:
> Hop 1 (AS16509, Amazon EU West, Amazon-02)
> Hop 2-7 CGN
> Hop 8-9 (AS unknown, but between UK and US, IPROU3-ARIN, so Amazon IP routing 
> 3)
> Hop 10 (AS unknown, but between UK and US, IPROU3-ARIN/ARMP-ARIN, Amazon IP 
> routing)
> Hop 11-15 CGN
> Hop 16 (AS unknown,  presumably US, IPROU3-ARIN/ARMP-ARIN, I presume Amazon 
> IP routing still)
> Hop 17-19 CGN
> Hop 20 (AS13335, Cloudflare US)
>  
> So it seems like every cloud zone interconnect (amazon Europe west, US, then 
> Cloudflare) transitted goes through a CGN setup. Not sure but I can 
> understand if this confuses some types of traffic.
> 
> I don’t think there’s anything wrong with your setup, but the results are 
> interesting. I’ve copied a couple of our researchers onto the mail as they 
> may be interested in this as well.
>  
> Regards,
>  
> Michel
> 
> 
> 
> On 8 Feb 2023, at 11:33, roberto.lucign...@caleidos.it 
> <mailto:roberto.lucign...@caleidos.it> wrote:
> 
> Hi Michael,
> for example, one measure ID is this one: 49813750
> The result says there are 7 HOPS.
>  The result of the traceroute made directly on the host is the following one
>  traceroute to www.madghigno.tech <http://www.madghigno.tech/> 
> (172.67.221.209), 30 hops max, 60 byte packets
> 1  52.56.0.19  24.303 ms 52.56.0.31  9.067 ms 52.56.0.17  29.663 ms
> 2  * 100.65.18.192  7.843 ms 100.65.19.176  6.252 ms
> 3  100.66.8.254  1.563 ms 100.66.8.146  0.697 ms 100.66.8.168  1.449 ms
> 4  100.66.10.138  8.469 ms 100.66.10.14  5.713 ms 100.66.10.6  8.127 ms
> 5  100.66.7.77  1.653 ms 100.66.6.173  2.658 ms *
> 6  100.66.4.75  2.726 ms 100.66.4.87  2.327 ms 100.66.4.89  1.550 ms
> 7  100.65.10.65  0.533 ms 100.65.11.1  0.857 ms 100.65.10.161  8.616 ms
> 8  15.230.158.29  2.062 ms 15.230.158.171  5.998 ms 15.230.158.27  1.617 ms
> 9  15.230.158.164  1.315 ms 52.94.33.120  2.089 ms 15.230.158.40  1.484 ms
> 10  54.239.101.83  1.440 ms 150.222.65.23  1.358 m

Re: [atlas] Duplicate packet detection in traceroute results

[Michel Stam]

Hello Ana,

I took a very quick look in the traceroute code, see here:
https://github.com/RIPE-NCC/ripe-atlas-probe-measurements/blob/7c03fba082e93b7a1f0f14cc3769bb31e83909e3/eperd/traceroute.c
ripe-atlas-probe-measurements/traceroute.c at 
7c03fba082e93b7a1f0f14cc3769bb31e83909e3 · 
RIPE-NCC/ripe-atlas-probe-measurements
github.com

It seems that a sequence number in the traceroute packet is used. If this 
sequence number is received back it’s marked as ‘response received’. If another 
response is received within a certain timeframe, it’s tagged as a duplicate. 
Otherwise its a late packet.

Hope it helps.

Cheers,

Michel

> On 20 Jan 2023, at 11:38, Ana Custura  wrote:
> 
> Hi everyone,
> 
> Just a question on how Atlas detects duplicate ('dup') packets in a 
> traceroute.
> 
> Is the 'dup' field added to a result when two received packets are exactly 
> the same, regardless of whether they were received for a different initial 
> TTL? 
> 
> Or are any packets that were unexpectedly received for a specific TTL marked 
> as duplicates (e.g. if you receive 6 replies from 2 different IP addresses to 
> the 3 initial packets sent with TTL 1, will 3 of these replies be marked as 
> duplicates)?
> 
> Thanks for your help!
> 
> Regards,
> Ana
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] V3 Probe: USB Flash Drive Filesystem Corrupted

[Michel Stam]

Thanks for the update Simon,

Let me know if the issues return.

Cheers,

Michel

> On 11 Jan 2023, at 14:31, ripe@toppas.net wrote:
> 
> Hi Michel,
> 
> the Probe ID is 25993.
> There are so many cheap USB sticks with extremely low write speed, even USB 
> 3.0 sticks.
> What made me think that the sticks speed could cause the tag is, that my 
> probe had it tagged for a long time, but still the probe did it's job. It was 
> online, delivering results, etc.
> 
> I have replaced the broken USB stick with a fast one from Transcend 6 days 
> ago. Since then, the tag did not appear again. I haven't checked for the 
> blink patterns, sorry. If the Tag will appear again, i will try a different 
> power supply and cable, as you suggested.
> 
> BR,
> Simon
> 
> 
> On 11.01.23 12:39, Michel Stam wrote:
>> Hi Simon,
>> 
>> I would expect a more recent USB stick to complete a write / read operation 
>> more quickly than one of its older counterparts. Thats not a guarantee, I 
>> know. Funny enough, I actually used an old stick on one of my development V3 
>> the other week and was surprised how slow the performance was (but the 
>> system did still work).
>> 
>> When the V3 probes have issues, usually its either:
>> Power supply failing
>> Cabling failing
>> USB stick corrupt (unlikely after 3 units).
>> 
>> Working setups sometimes degrade over time. Something I’ve seen with a USB 
>> analyser a good few years back is that some USB sticks don’t report write 
>> errors when the stick dies.
>> 
>> I will dig a bit where the flash filesystem corrupted tag comes from and get 
>> back to you.
>> 
>> Can you message me the probe ids that are causing issues? (Privately if you 
>> want to keep it off-list).
>> 
>> And if you have the possibility, please humour me and try a completely 
>> different power supply and cable. It has resolved issues for me before. Just 
>> to get it out of the way.
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 9 Jan 2023, at 20:36, ripe@toppas.net <mailto:ripe@toppas.net> 
>>> wrote:
>>> 
>>> Hi Michel,
>>> 
>>> Thanks for you answer. I'm using an Ikea KOPPLA (204.150.27) which provides 
>>> 17W. It's powering two v3 probes and one v4 probe. The other probes work 
>>> well, so i don't think that the power supply is causing this.
>>> 
>>> What i meant was, that maybe some USB sticks are to slow and thus not able 
>>> to perform writing of a big chunk of data in the expected time, and 
>>> therefore the USB flash/filesystem is considered broken? Can you tell the 
>>> exact cause for the "Flash drive filesystem corrupted"-tag is? What 
>>> triggers this?
>>> 
>>> I am aware that USB 3.0 is backwards compatible, but since USB 3.0 sticks 
>>> are faster, maybe it makes sense to stick with them (hehe), to ensure that 
>>> at least the full USB 2.0 potential is used.
>>> 
>>> BR,
>>> Simon
>>> 
>>> 
>>> On 09.01.23 12:26, Michel Stam wrote:
>>>> Hi Simon,
>>>> 
>>>> First thing that comes to mind to me, do you maybe have a power problem? 
>>>> If the unit receives just enough power to boot the base TP-Link, but not 
>>>> to power the USB stick this may trigger these problems. Would you be able 
>>>> to boot the unit with a different power supply (try 5W at the least or 
>>>> 10W), to see if this makes a difference?
>>>> 
>>>> Speed shouldn’t be much of an issue, USB to my knowledge is backwards 
>>>> compatible.
>>>> 
>>>> Cheers,
>>>> 
>>>> Michel
>>>> 
>>>>> On 31 Dec 2022, at 22:31, ripe@toppas.net 
>>>>> <mailto:ripe@toppas.net> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> i have two v3 probes and i'm experiencing issues: "USB Flash Drive 
>>>>> Filesystem Corrupted"
>>>>>  
>>>>> I have tried multiple USB Sticks, including brand new ones and also 
>>>>> sticks from "good" brands like Lexar and Sandisk.
>>>>> The issue is not permanent, the error appears and disappears from time to 
>>>>> time:
>>>>> 
>>>>> 2022-12-22 @ 12:14:04 UTCProbe auto-taggedYour probe #x was 
>>>>> automatically tagged as "system: Flash drive filesystem corrupted"
>>>>> 2022-12-22 @ 18:14:42 UTCProbe auto-untaggedYour probe #x was 
>>>>> automatically untagged as "system: Flash drive filesystem corrupted"
>>>>> 
>>>>> This leads me to the thought, that the flash storage is not the real 
>>>>> problem. It's unlikely, since i tried multiple dongles. Could it be 
>>>>> possible, that not the flash storage is broken, but the speed of the USB 
>>>>> dongles is too low?
>>>>> 
>>>>> All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is 
>>>>> not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice?
>>>>> 
>>>>> What do you think?
>>>>> 
>>>>> BR,
>>>>> Simon
>>>>> -- 
>>>>> ripe-atlas mailing list
>>>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>>> 
>> 
> 

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] V3 Probe: USB Flash Drive Filesystem Corrupted

[Michel Stam]

Hi Simon,

I would expect a more recent USB stick to complete a write / read operation 
more quickly than one of its older counterparts. Thats not a guarantee, I know. 
Funny enough, I actually used an old stick on one of my development V3 the 
other week and was surprised how slow the performance was (but the system did 
still work).

When the V3 probes have issues, usually its either:
Power supply failing
Cabling failing
USB stick corrupt (unlikely after 3 units).

Working setups sometimes degrade over time. Something I’ve seen with a USB 
analyser a good few years back is that some USB sticks don’t report write 
errors when the stick dies.

I will dig a bit where the flash filesystem corrupted tag comes from and get 
back to you.

Can you message me the probe ids that are causing issues? (Privately if you 
want to keep it off-list).

And if you have the possibility, please humour me and try a completely 
different power supply and cable. It has resolved issues for me before. Just to 
get it out of the way.

Regards,

Michel

> On 9 Jan 2023, at 20:36, ripe@toppas.net wrote:
> 
> Hi Michel,
> 
> Thanks for you answer. I'm using an Ikea KOPPLA (204.150.27) which provides 
> 17W. It's powering two v3 probes and one v4 probe. The other probes work 
> well, so i don't think that the power supply is causing this.
> 
> What i meant was, that maybe some USB sticks are to slow and thus not able to 
> perform writing of a big chunk of data in the expected time, and therefore 
> the USB flash/filesystem is considered broken? Can you tell the exact cause 
> for the "Flash drive filesystem corrupted"-tag is? What triggers this?
> 
> I am aware that USB 3.0 is backwards compatible, but since USB 3.0 sticks are 
> faster, maybe it makes sense to stick with them (hehe), to ensure that at 
> least the full USB 2.0 potential is used.
> 
> BR,
> Simon
> 
> 
> On 09.01.23 12:26, Michel Stam wrote:
>> Hi Simon,
>> 
>> First thing that comes to mind to me, do you maybe have a power problem? If 
>> the unit receives just enough power to boot the base TP-Link, but not to 
>> power the USB stick this may trigger these problems. Would you be able to 
>> boot the unit with a different power supply (try 5W at the least or 10W), to 
>> see if this makes a difference?
>> 
>> Speed shouldn’t be much of an issue, USB to my knowledge is backwards 
>> compatible.
>> 
>> Cheers,
>> 
>> Michel
>> 
>>> On 31 Dec 2022, at 22:31, ripe@toppas.net <mailto:ripe@toppas.net> 
>>> wrote:
>>> 
>>> Hello,
>>> 
>>> i have two v3 probes and i'm experiencing issues: "USB Flash Drive 
>>> Filesystem Corrupted"
>>>  
>>> I have tried multiple USB Sticks, including brand new ones and also sticks 
>>> from "good" brands like Lexar and Sandisk.
>>> The issue is not permanent, the error appears and disappears from time to 
>>> time:
>>> 
>>> 2022-12-22 @ 12:14:04 UTCProbe auto-taggedYour probe #x was 
>>> automatically tagged as "system: Flash drive filesystem corrupted"
>>> 2022-12-22 @ 18:14:42 UTCProbe auto-untaggedYour probe #x was 
>>> automatically untagged as "system: Flash drive filesystem corrupted"
>>> 
>>> This leads me to the thought, that the flash storage is not the real 
>>> problem. It's unlikely, since i tried multiple dongles. Could it be 
>>> possible, that not the flash storage is broken, but the speed of the USB 
>>> dongles is too low?
>>> 
>>> All dongles I tried were USB 2.0, not 3.0, since the TP-Link TL-MR3020 is 
>>> not USB 3.0 capable anyway. But maybe USB 3.0 is a better choice?
>>> 
>>> What do you think?
>>> 
>>> BR,
>>> Simon
>>> -- 
>>> ripe-atlas mailing list
>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
> 

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] V3 Probe: USB Flash Drive Filesystem Corrupted

[Michel Stam]

Hi Simon,

First thing that comes to mind to me, do you maybe have a power problem? If the 
unit receives just enough power to boot the base TP-Link, but not to power the 
USB stick this may trigger these problems. Would you be able to boot the unit 
with a different power supply (try 5W at the least or 10W), to see if this 
makes a difference?

Speed shouldn’t be much of an issue, USB to my knowledge is backwards 
compatible.

Cheers,

Michel

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


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Michel Stam]

No worries Michael, all good :)

Cheers,

Michel

> On 9 Jan 2023, at 11:47, Michael J. Oghia  wrote:
> 
> Ah OK, great! Thank you, and sorry for being such a nooby luddite :-)
> 
> Best,
> -Michael
> 
> 
> On Mon, Jan 9, 2023 at 11:42 AM Michel Stam  <mailto:ms...@ripe.net>> wrote:
>> Hi Michael,
>> 
>> Oh of course, happy new year to you too (keep forgetting).
>> 
>> In that case, you don’t have to do anything to keep your probe up to date, 
>> this should all happen automatically.
>> 
>> Cheers,
>> 
>> Michel
>> 
>>> On 9 Jan 2023, at 11:31, Michael J. Oghia >> <mailto:mike.og...@gmail.com>> wrote:
>>> 
>>> Hi Michel,
>>> 
>>> Happy New Year! Yes, exactly, the small white probes.
>>> 
>>> Best,
>>> -Michael
>>> 
>>> On Mon, Jan 9, 2023 at 11:27 AM Michel Stam >> <mailto:ms...@ripe.net>> wrote:
>>>> Hi Michael,
>>>> 
>>>> Are you running hardware probes (the small white boxes)? 1100 only applies 
>>>> to those.
>>>> 
>>>> Let me know.
>>>> 
>>>> Regards,
>>>> 
>>>> Michel
>>>> 
>>>>> On 9 Jan 2023, at 11:12, Michael J. Oghia >>>> <mailto:mike.og...@gmail.com>> wrote:
>>>>> 
>>>>> Hi Michel, all:
>>>>> 
>>>>> I'm a big fan of the Atlas programme, and have hosted probes for years 
>>>>> now (and I'm an active member of this community). However, I don't have a 
>>>>> technical or engineering background and while one of my probes is close 
>>>>> to me, another is not. Both of the probes I host have firmware version 
>>>>> 5080 (1100). 
>>>>> 
>>>>> Is there anything I need to do right now to update the software? And if 
>>>>> not (e.g., it's the latest for now), can the NCC provide detailed 
>>>>> instructions for how to do so (i.e., in the style of "WikiHow") so we can?
>>>>> 
>>>>> Best,
>>>>> -Michael
>>>>> 
>>>>> 
>>>>> On Mon, Jan 9, 2023 at 10:19 AM Michel Stam >>>> <mailto:ms...@ripe.net>> wrote:
>>>>>> Hi guys,
>>>>>> 
>>>>>> The automatic update for the CentOS package was removed as of 5080. This 
>>>>>> means that the update to 5080 will still be automatic, but not any more 
>>>>>> after this (say 5090 onwards).
>>>>>> This was a request by several users because Atlas forced the update, 
>>>>>> which violated their sysadmin policies.
>>>>>> 
>>>>>> As to updating the package, we are looking to see if it is possible to 
>>>>>> make an RPM that is part of the base RedHat repository, together with a 
>>>>>> packager. We could do something similar for Debian (possibly others, 
>>>>>> such as OpenWRT).
>>>>>> 
>>>>>> I’m not sure what you mean with methods:
>>>>>> How many probe users are using auto-update is a bit difficult to answer, 
>>>>>> since right now it is forced, but as of the next software release it 
>>>>>> will not be. 
>>>>>> Which operating systems are used is also a bit difficult since we do not 
>>>>>> provide an official Debian package yet, and the software does not 
>>>>>> differentiate between different flavours of Linux.
>>>>>> 
>>>>>> Hope this helps.
>>>>>> 
>>>>>> Regards,
>>>>>> 
>>>>>> Michel
>>>>>> 
>>>>>> > On 8 Jan 2023, at 01:36, Seth David Schoen >>>>> > <mailto:sch...@loyalty.org>> wrote:
>>>>>> > 
>>>>>> > Alexander Bochmann writes:
>>>>>> > 
>>>>>> >> When using the CentOS binary repo as recommended, the software should 
>>>>>> >> auto-update during normal system update procedures.
>>>>>> >> 
>>>>>> >> For source releases (Debian), you're more or less on your own. 
>>>>>> >> Updating 
>>>>>> >> is still easy - just go through the initial installation again, minus 
>>>>>> >> registration.
>>>>>> > 
>>>>>> > I see, so that's a pretty significant difference in the experiences of
>>>>>> > people using different systems.
>>>>>> > 
>>>>>> > Is it clear how many probe users use each of these methods? (which
>>>>>> > might indicate whether it could be worth maintaining a more automated
>>>>>> > installation method for Debian-based systems)
>>>>>> > 
>>>>>> > -- 
>>>>>> > ripe-atlas mailing list
>>>>>> > ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>>>>> > https://lists.ripe.net/mailman/listinfo/ripe-atlas
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> ripe-atlas mailing list
>>>>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>>>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>>>> 
>> 

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Michel Stam]

Hi Michael,

Oh of course, happy new year to you too (keep forgetting).

In that case, you don’t have to do anything to keep your probe up to date, this 
should all happen automatically.

Cheers,

Michel

> On 9 Jan 2023, at 11:31, Michael J. Oghia  wrote:
> 
> Hi Michel,
> 
> Happy New Year! Yes, exactly, the small white probes.
> 
> Best,
> -Michael
> 
> On Mon, Jan 9, 2023 at 11:27 AM Michel Stam  <mailto:ms...@ripe.net>> wrote:
>> Hi Michael,
>> 
>> Are you running hardware probes (the small white boxes)? 1100 only applies 
>> to those.
>> 
>> Let me know.
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 9 Jan 2023, at 11:12, Michael J. Oghia >> <mailto:mike.og...@gmail.com>> wrote:
>>> 
>>> Hi Michel, all:
>>> 
>>> I'm a big fan of the Atlas programme, and have hosted probes for years now 
>>> (and I'm an active member of this community). However, I don't have a 
>>> technical or engineering background and while one of my probes is close to 
>>> me, another is not. Both of the probes I host have firmware version 5080 
>>> (1100). 
>>> 
>>> Is there anything I need to do right now to update the software? And if not 
>>> (e.g., it's the latest for now), can the NCC provide detailed instructions 
>>> for how to do so (i.e., in the style of "WikiHow") so we can?
>>> 
>>> Best,
>>> -Michael
>>> 
>>> 
>>> On Mon, Jan 9, 2023 at 10:19 AM Michel Stam >> <mailto:ms...@ripe.net>> wrote:
>>>> Hi guys,
>>>> 
>>>> The automatic update for the CentOS package was removed as of 5080. This 
>>>> means that the update to 5080 will still be automatic, but not any more 
>>>> after this (say 5090 onwards).
>>>> This was a request by several users because Atlas forced the update, which 
>>>> violated their sysadmin policies.
>>>> 
>>>> As to updating the package, we are looking to see if it is possible to 
>>>> make an RPM that is part of the base RedHat repository, together with a 
>>>> packager. We could do something similar for Debian (possibly others, such 
>>>> as OpenWRT).
>>>> 
>>>> I’m not sure what you mean with methods:
>>>> How many probe users are using auto-update is a bit difficult to answer, 
>>>> since right now it is forced, but as of the next software release it will 
>>>> not be. 
>>>> Which operating systems are used is also a bit difficult since we do not 
>>>> provide an official Debian package yet, and the software does not 
>>>> differentiate between different flavours of Linux.
>>>> 
>>>> Hope this helps.
>>>> 
>>>> Regards,
>>>> 
>>>> Michel
>>>> 
>>>> > On 8 Jan 2023, at 01:36, Seth David Schoen >>> > <mailto:sch...@loyalty.org>> wrote:
>>>> > 
>>>> > Alexander Bochmann writes:
>>>> > 
>>>> >> When using the CentOS binary repo as recommended, the software should 
>>>> >> auto-update during normal system update procedures.
>>>> >> 
>>>> >> For source releases (Debian), you're more or less on your own. Updating 
>>>> >> is still easy - just go through the initial installation again, minus 
>>>> >> registration.
>>>> > 
>>>> > I see, so that's a pretty significant difference in the experiences of
>>>> > people using different systems.
>>>> > 
>>>> > Is it clear how many probe users use each of these methods? (which
>>>> > might indicate whether it could be worth maintaining a more automated
>>>> > installation method for Debian-based systems)
>>>> > 
>>>> > -- 
>>>> > ripe-atlas mailing list
>>>> > ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>>> > https://lists.ripe.net/mailman/listinfo/ripe-atlas
>>>> 
>>>> 
>>>> -- 
>>>> ripe-atlas mailing list
>>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>> 

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Michel Stam]

Hi Michael,

Are you running hardware probes (the small white boxes)? 1100 only applies to 
those.

Let me know.

Regards,

Michel

> On 9 Jan 2023, at 11:12, Michael J. Oghia  wrote:
> 
> Hi Michel, all:
> 
> I'm a big fan of the Atlas programme, and have hosted probes for years now 
> (and I'm an active member of this community). However, I don't have a 
> technical or engineering background and while one of my probes is close to 
> me, another is not. Both of the probes I host have firmware version 5080 
> (1100). 
> 
> Is there anything I need to do right now to update the software? And if not 
> (e.g., it's the latest for now), can the NCC provide detailed instructions 
> for how to do so (i.e., in the style of "WikiHow") so we can?
> 
> Best,
> -Michael
> 
> 
> On Mon, Jan 9, 2023 at 10:19 AM Michel Stam  <mailto:ms...@ripe.net>> wrote:
>> Hi guys,
>> 
>> The automatic update for the CentOS package was removed as of 5080. This 
>> means that the update to 5080 will still be automatic, but not any more 
>> after this (say 5090 onwards).
>> This was a request by several users because Atlas forced the update, which 
>> violated their sysadmin policies.
>> 
>> As to updating the package, we are looking to see if it is possible to make 
>> an RPM that is part of the base RedHat repository, together with a packager. 
>> We could do something similar for Debian (possibly others, such as OpenWRT).
>> 
>> I’m not sure what you mean with methods:
>> How many probe users are using auto-update is a bit difficult to answer, 
>> since right now it is forced, but as of the next software release it will 
>> not be. 
>> Which operating systems are used is also a bit difficult since we do not 
>> provide an official Debian package yet, and the software does not 
>> differentiate between different flavours of Linux.
>> 
>> Hope this helps.
>> 
>> Regards,
>> 
>> Michel
>> 
>> > On 8 Jan 2023, at 01:36, Seth David Schoen > > <mailto:sch...@loyalty.org>> wrote:
>> > 
>> > Alexander Bochmann writes:
>> > 
>> >> When using the CentOS binary repo as recommended, the software should 
>> >> auto-update during normal system update procedures.
>> >> 
>> >> For source releases (Debian), you're more or less on your own. Updating 
>> >> is still easy - just go through the initial installation again, minus 
>> >> registration.
>> > 
>> > I see, so that's a pretty significant difference in the experiences of
>> > people using different systems.
>> > 
>> > Is it clear how many probe users use each of these methods? (which
>> > might indicate whether it could be worth maintaining a more automated
>> > installation method for Debian-based systems)
>> > 
>> > -- 
>> > ripe-atlas mailing list
>> > ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>> > https://lists.ripe.net/mailman/listinfo/ripe-atlas
>> 
>> 
>> -- 
>> ripe-atlas mailing list
>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Michel Stam]

Hi Gert,

Thank you for pitching in.

The hardware probes are fully managed by RIPE NCC, and their only purpose is to 
execute measurements. I agree here, whether to update is up to RIPE NCC.
On software probes, RIPE NCC is not in control of the unit. The software probe 
may run other services and updating is up to its local sysadmin. Consider 
operating system updates, which are updated by RIPE NCC on the hardware probes, 
but cannot be updated on software probes.

To automatically update, the solution here is a simple CRON job which executes 
yum -q update atlasswprobe periodically (say once per day or so), which was the 
solution that was part of the RPM up to 5080. Would it help if we add this to 
the instructions?

Regards,

Michel
> On 9 Jan 2023, at 10:52, Gert Doering  wrote:
> 
> Hi,
> 
> On Mon, Jan 09, 2023 at 10:19:34AM +0100, Michel Stam wrote:
>> The automatic update for the CentOS package was removed as of 5080. This 
>> means that the update to 5080 will still be automatic, but not any more 
>> after this (say 5090 onwards).
>> This was a request by several users because Atlas forced the update, which 
>> violated their sysadmin policies.
> 
> I find this surprising, to say the least.
> 
> The whole point about ATLAS Probes is "RIPE NCC manages them" - as host
> of a handful of hardware probes, I have no say in whether I want them
> upgraded or not, or what they should do or not do.
> 
> So I would expect all software probes to always upgrade themselves,
> and this be clearly communicated to SW probe hosts.
> 
> If this violates your sysadmin policies, you shouldn't run 3rd-party
> maintained *and operated* software.
> 
> Gert Doering
>-- NetMaster
> -- 
> have you enabled IPv6 on something today...?
> 
> SpaceNet AG  Vorstand: Sebastian v. Bomhard, Michael Emmer
> Joseph-Dollinger-Bogen 14Aufsichtsratsvors.: A. Grundner-Culemann
> D-80807 Muenchen HRB: 136055 (AG Muenchen)
> Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Encouraging people to upgrade software probe versions

[Michel Stam]

Hi guys,

The automatic update for the CentOS package was removed as of 5080. This means 
that the update to 5080 will still be automatic, but not any more after this 
(say 5090 onwards).
This was a request by several users because Atlas forced the update, which 
violated their sysadmin policies.

As to updating the package, we are looking to see if it is possible to make an 
RPM that is part of the base RedHat repository, together with a packager. We 
could do something similar for Debian (possibly others, such as OpenWRT).

I’m not sure what you mean with methods:
How many probe users are using auto-update is a bit difficult to answer, since 
right now it is forced, but as of the next software release it will not be. 
Which operating systems are used is also a bit difficult since we do not 
provide an official Debian package yet, and the software does not differentiate 
between different flavours of Linux.

Hope this helps.

Regards,

Michel

> On 8 Jan 2023, at 01:36, Seth David Schoen  wrote:
> 
> Alexander Bochmann writes:
> 
>> When using the CentOS binary repo as recommended, the software should 
>> auto-update during normal system update procedures.
>> 
>> For source releases (Debian), you're more or less on your own. Updating 
>> is still easy - just go through the initial installation again, minus 
>> registration.
> 
> I see, so that's a pretty significant difference in the experiences of
> people using different systems.
> 
> Is it clear how many probe users use each of these methods? (which
> might indicate whether it could be worth maintaining a more automated
> installation method for Debian-based systems)
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Low cost, low energy consumption probe

[Michel Stam]

Hello Stijn,

What kind of locations are you looking at for your probes? We don’t bite if 
asked, but yes is not guaranteed :)

The v5 hardware probe is a custom design based off the Turris Mox.

If we would do something like this we would need to split the Atlas application 
from the OS firmware, which for hardware probes currently is bundled. This to 
some extent ensures that the probe is not doing anything else (security).

There’s a couple of considerations to be had here, mostly with regard to 
support and security.
Can you detail why you want to BYOP (Build-Your-Own-Probe)?

Regards,

Michel

> On 19 Dec 2022, at 18:10, Stijn Jonker via ripe-atlas  
> wrote:
> 
> Hi Ernst, Hi Others,
> 
> I would be interested as well maybe even exploring the USB model/option. 
> However I would be keen to pursue only if it would be low maintenance as the 
> current HW probes (i.e. config via portal, sw updates covered etc). To be 
> fair I think an additional option might be that instead of sending out probes 
> for free, that somehow you can order a probe directly or via Ripe or some 
> reseller by providing a kitlist. As I would be keen to deploy some additional 
> probes here and there (think ±12 locations at the end) but don't dare to ask 
> for additional probes...
> 
> So maybe instead of reinventing the wheel, @ripe would it be an consideration 
> to provide an kitlist/place to purchase the previous or current V5 HW model?
> 
> -- 
> Met vriendelijke groet,
> Stijn Jonker
> 
> 
> 
> 
>> On 19 Dec 2022, at 16:42, Ernst J. Oud  wrote:
>> 
>> Hi,
>> 
>> I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for 
>> Windows. These small PC’s consume a lot more than the Ripe supplied HW 
>> probes.
>> 
>> So I looked for a cheap and *very* low energy alternative.
>> 
>> TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on 
>> Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW 
>> has been ported to it. With some acrobatics I managed to turn it into an 
>> excellent alternative. Runs fine, energy consumption 700 mW (!). The device 
>> is as small as the Ripe supplied probe.
>> 
>> Since the flash memory of this device is too small for some of the required 
>> libraries, the acrobatics involved copying them to RAM and putting links to 
>> them in flash. This means that with FTP after a power outage a couple of 
>> files need to be copied to the device and that one command must be given 
>> after that.
>> 
>> There is a more expensive version with a USB port so that a USB stick can be 
>> used to store those files. Will investigate that option.
>> 
>> If someone here wants a detailed write-up let me know and I will invest the 
>> time to write it.
>> 
>> Regards,
>> 
>> Ernst J. Oud
>> -- 
>> ripe-atlas mailing list
>> ripe-atlas@ripe.net
>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Low cost, low energy consumption probe

[Michel Stam]

Hi Ernst,

It’s always good to get some of the acrobatics on paper. As it happens, I’m 
looking at the v3 hardware probe, which is a TP-Link TL-MR3220 with 4MB of 
internal flash and 32 MB of RAM. I share your pain ;)

Can you tell me how you measured power consumption on the devices mentioned?

Regards,

Michel

> On 19 Dec 2022, at 16:42, Ernst J. Oud  wrote:
> 
> Hi,
> 
> I have probes running on VMware (CentOS), Ubuntu (native) and on Docker for 
> Windows. These small PC’s consume a lot more than the Ripe supplied HW probes.
> 
> So I looked for a cheap and *very* low energy alternative.
> 
> TP-Link sells the WR802N mini travel router for around USD 20 (o.a. on 
> Amazon) that runs the latest version of OpenWRT fine and the Atlas probe SW 
> has been ported to it. With some acrobatics I managed to turn it into an 
> excellent alternative. Runs fine, energy consumption 700 mW (!). The device 
> is as small as the Ripe supplied probe.
> 
> Since the flash memory of this device is too small for some of the required 
> libraries, the acrobatics involved copying them to RAM and putting links to 
> them in flash. This means that with FTP after a power outage a couple of 
> files need to be copied to the device and that one command must be given 
> after that.
> 
> There is a more expensive version with a USB port so that a USB stick can be 
> used to store those files. Will investigate that option.
> 
> If someone here wants a detailed write-up let me know and I will invest the 
> time to write it.
> 
> Regards,
> 
> Ernst J. Oud
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Add support for STARTTLS measurements [STARTTLS]

[Michel Stam]

Hi Alex,

Thanks for your support!

Please note that the proposal as yet does not include the ability to validate. 
The proposal does deliver upon the information which would enable such to 
happen.
In effect it adds upon the existing SSL measurement and will provide the same 
level of information.

Just to clarify.

Cheers,

Michel

> On 15 Dec 2022, at 06:11, Alexander Burke via ripe-atlas 
>  wrote:
> 
> Hello,
> 
> As a security and privacy specialist, I am absolutely in favour of RIPE Atlas 
> gaining the ability to detect and measure phenomena such as STARTTLS 
> stripping, certificate replacement, etc.
> 
> Cheers,
> Alex
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Enable/Disable software probe

[Michel Stam]

Hi Ernst,

Let me answer your questions;

The easiest way to stop ATLAS is systemctl stop atlas, or /etc/init.d/atlas 
stop (on OpenWRT). Not too sure there, the public OpenWRT package diverged a 
bit from our startup process.

I’m not too sure on the Magellan report, can you share some details?

Regards,

Michel

> On 11 Dec 2022, at 16:19, Ernst J. Oud  wrote:
> 
> Hi,
> 
> Two questions:
> 
> 1.
> What would be the best way to temporarily disable (and enable again) a 
> software probe? Is there some command for this besides killing all processes 
> and run the ATLAS script again?
> 
> Running a probe on CentOS, OpenWRT and Ubuntu 18.04 (all on separate ISP’s).
> 
> I am currently logging the latency differences between HW and SW probes (both 
> natively and under VMware emulation). Differences appear to be in the 1.5 ms. 
> range. Negligible for my 4G networks but on my fiber line such a difference 
> is more than 30% of the average latency. Will post more results soon.
> 
> 2.
> Why can’t Magellan report on the first ping latency to ping.ripe.net? 
> It always reports “No packets found”. All other reports work fine.
> 
> TIA.
> 
> Regards,
> 
> Ernst J. Oud
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Shiny new v5 probe reveals problem with virtual probe

[Michel Stam]

Hi Niall,

FYI he v5 is basically a modified Turris Mox. You’re getting a nice Turris 
collection there :)

IPv6 works is a tag that is added based on the result of a few measurements, 
see here:
https://atlas.ripe.net/docs/getting-started/probe-tags.html#basic-connectivity

Hope this helps

Cheers,

Michel

> On 30 Nov 2022, at 17:54, Niall O'Reilly  wrote:
> 
> Hello, everyone.
> 
> TL; DR: clue needed configuring Turris Omnia for virtual Atlas probe.
> 
> I'm delighted to have a shiny new v5 probe, which is operation
> since the day before yesterday.
> 
> The new probe has been automatically tagged "IPv6 Works".
> On account of this, I've noticed that my virtual probe,
> running on my Turris Omnia, has the complementary tag,
> "IPv6 Doesn't Work."
> 
> I suspect that I've not configured firewalling on my Turris
> properly.
> 
> If any of you have sorted this, I would appreciate some clue.
> 
> Thanks in anticipation.
> Niall
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] New V5 Probe with IPv4 Discovery issues

[Michel Stam]

Hello Nate,

I’m wondering what will happen if you visit http://ip-echo.ripe.net/ (note 
http:// not https://). Would you mind doing this?

I agree that redirecting traffic to your local DNS server is not a viable 
solution.

Lastly, do you have the ability to connect the unit to the Internet without a 
firewall in between, to see if this makes a difference?

Regards,

Michel
> On 30 Nov 2022, at 19:55, Nate Weibley  wrote:
> 
> Michel,
> 
> First, my apologies for initially misspelling your name! I went ahead and 
> rebooted the probe while monitoring traffic from it on the LAN and only saw a 
> single active https session originating from the probe to an edgecast CDN 
> endpoint in VA over IPv4: https://,/xztP6My.png 
> <https://i.imgur.com/xztP6My.png> 
> 
> I monitored all the DNS queries hitting my server after the reboot and didn't 
> see any come in for ip-echo.ripe.net <http://ip-echo.ripe.net/> either. I 
> could use OPNSense to capture all outbound DNS traffic from the probe and 
> redirect it to my server to see if the probe is trying to resolve that host 
> directly elsewhere, but obviously manipulating the probe's outbound DNS 
> traffic isn't a viable long term solution for it to function properly. The 
> probe was generating plenty of other DNS queries hitting my DNS server during 
> this time though. I also disabled DNS64 as I don't actually have IPv6-only 
> clients inside my network anymore. Unsurprisingly that did not have an effect 
> on the IPv4 issue given I'm not seeing DNS requests for the ip-echo test. The 
> DNS requests made to my DNS server since the probe was reset (all requests 
> after 11:41) can be seen here: https://i.imgur.com/AlLKeCk.png
> 
> OPNSense is fully up to date on release 22.7.8. I'm at a bit of a loss as to 
> what is going on as well. Is there a way to pull logs or diagnostics from the 
> probe itself to see what it thinks is going on? 
> 
> -Nate
> 
> On Wed, Nov 30, 2022 at 10:13 AM Michel Stam  <mailto:ms...@ripe.net>> wrote:
>> Hello Nate,
>> 
>> Can you check that there are active v4 TCP sessions, namely a port 443/TCP 
>> session? That should be there for the probe to be able to talk to the 
>> infrastructure.
>> 
>> Depending on the measurement the probe may directly contact name servers, 
>> correct, but it may also use your provided name servers.
>> 
>> I’m not sure how often the echo queries happen, but I expect during initial 
>> connect, not continuously. A simple reboot would prove that.
>> 
>> I don’t see a particular problem in your description as yet, I’ve seen the 
>> probes happily running on v4 / v6 dual stack networks (no DNS64 though) 
>> without any problems. Not sure what makes it different here, is there maybe 
>> a more recent version of OPNSense available
>> 
>> It’s important that the probe is not restricted from accessing the Internet, 
>> because this is the nature of the measurements it does. It will also use 
>> old-style DNS, not only DNS over TLS, not sure if this is a problem.
>> 
>> Keep me posted.
>> 
>> Cheers,
>> 
>> Michel
>> 
>> 
>>> On 30 Nov 2022, at 17:00, Nate Weibley >> <mailto:nweib...@gmail.com>> wrote:
>>> 
>>> Michael,
>>> 
>>> Thank you for your troubleshooting guidance. I do not see any evidence of 
>>> OPNSense blocking the IPv4 traffic originating from the probe; to the 
>>> contrary I see IPv4 UDP and ICMP traffic passing through the LAN interface 
>>> via the default allow rule (I have the probe on my main LAN to establish 
>>> everything is working and will move it to my isolated IOT VLAN once 
>>> comfortable). Many other IPv4 devices also connected to the LAN network 
>>> function normally over IPv4. 
>>> 
>>> Here's a screenshot of all the probe IPv4 traffic I see, as well as all of 
>>> the traffic which does not match a pass rule on all non-WAN interfaces in 
>>> my network: https://imgur.com/a/GCMR9sz 
>>> 
>>> Additionally I do not see any recent DNS queries for ip-echo.ripe.net 
>>> <http://ip-echo.ripe.net/> in my DNS resolver logs, though I suspect the 
>>> probe may be directly querying other resolvers directly for those requests 
>>> (I do see plenty of other DNS traffic from the probe on my local DNS server 
>>> though). I was initially suspicious that having DNS64 support enabled in my 
>>> unbound resolver may be to blame, but since I don't see requests hitting it 
>>> I'm not confident that is the case. My upstream DNS servers (I run Adguard 
&g

Re: [atlas] New V5 Probe with IPv4 Discovery issues

[Michel Stam]

Hello Nate,

Can you check that there are active v4 TCP sessions, namely a port 443/TCP 
session? That should be there for the probe to be able to talk to the 
infrastructure.

Depending on the measurement the probe may directly contact name servers, 
correct, but it may also use your provided name servers.

I’m not sure how often the echo queries happen, but I expect during initial 
connect, not continuously. A simple reboot would prove that.

I don’t see a particular problem in your description as yet, I’ve seen the 
probes happily running on v4 / v6 dual stack networks (no DNS64 though) without 
any problems. Not sure what makes it different here, is there maybe a more 
recent version of OPNSense available

It’s important that the probe is not restricted from accessing the Internet, 
because this is the nature of the measurements it does. It will also use 
old-style DNS, not only DNS over TLS, not sure if this is a problem.

Keep me posted.

Cheers,

Michel


> On 30 Nov 2022, at 17:00, Nate Weibley  wrote:
> 
> Michael,
> 
> Thank you for your troubleshooting guidance. I do not see any evidence of 
> OPNSense blocking the IPv4 traffic originating from the probe; to the 
> contrary I see IPv4 UDP and ICMP traffic passing through the LAN interface 
> via the default allow rule (I have the probe on my main LAN to establish 
> everything is working and will move it to my isolated IOT VLAN once 
> comfortable). Many other IPv4 devices also connected to the LAN network 
> function normally over IPv4. 
> 
> Here's a screenshot of all the probe IPv4 traffic I see, as well as all of 
> the traffic which does not match a pass rule on all non-WAN interfaces in my 
> network: https://imgur.com/a/GCMR9sz 
> 
> Additionally I do not see any recent DNS queries for ip-echo.ripe.net 
> <http://ip-echo.ripe.net/> in my DNS resolver logs, though I suspect the 
> probe may be directly querying other resolvers directly for those requests (I 
> do see plenty of other DNS traffic from the probe on my local DNS server 
> though). I was initially suspicious that having DNS64 support enabled in my 
> unbound resolver may be to blame, but since I don't see requests hitting it 
> I'm not confident that is the case. My upstream DNS servers (I run Adguard 
> Home locally for my LAN clients, though the probe has been set to bypass all 
> filter rules) are my local OPNSense unbound instance and DNS-over-TLS to 
> 1.1.1.1 and 8.8.8.8. 
> 
> I will keep poking around to see if I can uncover anything that may be 
> getting blocked or rerouted from the probe.
> 
> -Nate
> 
> On Wed, Nov 30, 2022 at 5:18 AM Michel Stam  <mailto:ms...@ripe.net>> wrote:
>> Hello Nate,
>> 
>> Sorry to hear you’ve been having problems with the V5 probe.
>> 
>> It seems that your probe is not able to contact the IP echo service at 
>> ip-echo.ripe.net <http://ip-echo.ripe.net/> to derive its IP address. 
>> Because of this, IPv4 is presumed to be non-functional and the probe will 
>> not execute IPv4 measurements.
>> 
>> Can you take a good look at the OPNSense configuration to see if any v4 
>> traffic going towards the internet is being filtered?
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 28 Nov 2022, at 16:31, Nate Weibley >> <mailto:nweib...@gmail.com>> wrote:
>>> 
>>> I received a shiny new V5 probe via post on Saturday and got it up and 
>>> running yesterday on my dual-stack network.  The probe in question is: 
>>> https://atlas.ripe.net/probes/62490/ 
>>> 
>>> It has been operational for about 18 hours and quickly indicated that IPv6 
>>> connectivity was functional, but it has only momentarily indicated IPv4 
>>> connectivity was established. I can see IPv4 ICMP and UDP traffic 
>>> originating from the probe passing through my opnsense router on the IPv4 
>>> WAN interface so I know IPv4 traffic is flowing. I also see the correct 
>>> IPv4 DHCP lease info for my LAN on the probe's network status page. 
>>> 
>>> Probe address discovery does not show a valid IPv4 connection address or IP 
>>> Echo Service listed, only the Local IP of my probe. I've tried power 
>>> cycling the probe but it doesn't seem to impact this issue. 
>>> 
>>> Are there any other troubleshooting steps I should try?
>>> -- 
>>> ripe-atlas mailing list
>>> ripe-atlas@ripe.net <mailto:ripe-atlas@ripe.net>
>>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
>> 

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] New V5 Probe with IPv4 Discovery issues

[Michel Stam]

Hello Nate,

Sorry to hear you’ve been having problems with the V5 probe.

It seems that your probe is not able to contact the IP echo service at 
ip-echo.ripe.net to derive its IP address. Because of this, IPv4 is presumed to 
be non-functional and the probe will not execute IPv4 measurements.

Can you take a good look at the OPNSense configuration to see if any v4 traffic 
going towards the internet is being filtered?

Regards,

Michel

> On 28 Nov 2022, at 16:31, Nate Weibley  wrote:
> 
> I received a shiny new V5 probe via post on Saturday and got it up and 
> running yesterday on my dual-stack network.  The probe in question is: 
> https://atlas.ripe.net/probes/62490/ 
> 
> It has been operational for about 18 hours and quickly indicated that IPv6 
> connectivity was functional, but it has only momentarily indicated IPv4 
> connectivity was established. I can see IPv4 ICMP and UDP traffic originating 
> from the probe passing through my opnsense router on the IPv4 WAN interface 
> so I know IPv4 traffic is flowing. I also see the correct IPv4 DHCP lease 
> info for my LAN on the probe's network status page. 
> 
> Probe address discovery does not show a valid IPv4 connection address or IP 
> Echo Service listed, only the Local IP of my probe. I've tried power cycling 
> the probe but it doesn't seem to impact this issue. 
> 
> Are there any other troubleshooting steps I should try?
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] IPv6 and the V5 probe

[Michel Stam]

Hi Eric,

I’ve tested SLAAC and SLAAC+DHCPv6 and these work. SLAAC works with the 
condition that DNS servers are not assigned.
Are you on a DHCPv6 only setup?

No configuration is necessary on the Atlas website, although if you previously 
had a static configuration that will need to be reverted to automatic before 
you move to another location.

Let me know.

Regards,

Michel

> On 12 Nov 2022, at 14:10, Eric Kochen  wrote:
> 
> Issue resolved. Turned out to be a pfSense configuration issue.
> 
>> Op 12 nov. 2022, om 12:18 heeft Eric Kochen  het volgende 
>> geschreven:
>> 
>> Hi,
>> 
>> My V5 is up and running. For some reason public IPv6 is not detected or not 
>> working, yet.
>> 
>> I have a dual-stack connection and IPv6 is a DHCPv6 Prefix Delegation 
>> configuration.
>> 
>> Does this work with the V5 probe? Anything I need to configure at the Atlas 
>> website maybe?
>> -- 
>> ripe-atlas mailing list
>> ripe-atlas@ripe.net
>> https://lists.ripe.net/mailman/listinfo/ripe-atlas
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hi Simon,

This development happened before my joining RIPE NCC, but my guess is that this 
is historical. Having the OpenSSL library requires more flash and memory, 
something which the version 1 and 2 probes did not really have.
This doesn’t mean that this needs to be the same going forward, just that 
adding OpenSSL will take more time, and providing we find a good use for that.

Cheers,

Michel

> On 11 Nov 2022, at 14:16, ripe@toppas.net wrote:
> 
> Hi Michel,
> 
> Thanks for your feedback!
> 
>> Note: the SSL measurement currently does not use the OpenSSL library.
> Is that a reason to not use OpenSSL for SMTP measurements? Are there any 
> reasons to not use OpenSSL?
> 
> 
> BR,
> Simon
> 
> 
> 
> 
> On 11.11.22 13:57, Michel Stam wrote:
>> Hi Simon,
>> 
>> This seems to have gotten a bit idle since RIPE85. Let me give a bit of an 
>> update:
>> 
>> Adding TLSv1.3 is gonna be tricky since the SSL measurement implements the 
>> first stages of the TLS handshake only. This means adding that complexity to 
>> the code, which as Niall commented to me is not trivial. Note: the SSL 
>> measurement currently does not use the OpenSSL library.
>> Other than retrieving the certificate from the peer, no other validation 
>> happens in the current SSL measurement. This includes not validating the 
>> certificate chain, which may be a self-signed certificate.
>> Adding STARTTLS the way OpenSSL has done it involves issuing the appropriate 
>> command after receiving certain output from the remote end, then starting 
>> the TLS handshake. This should be doable.
>> 
>> Hope this helps, have a nice weekend!
>> 
>> Regards,
>> 
>> Michel
>> 
>>> On 20 Oct 2022, at 17:30, Michel Stam >> <mailto:ms...@ripe.net>> wrote:
>>> 
>>> Hello Simon,
>>> 
>>> I’ll first have a look at OpenSSL to gauge the amount of effort required. 
>>> I’ll also look at the existing SSL measurement to see what that offers. 
>>> That will likely provide the best path forward. Lastly, I’ll have an 
>>> internal discussion on measuring SMTP/STARTTLS/etc.
>>> 
>>> Ripe 85 is up next week, I’ll be attending there, so my response may be 
>>> delayed somewhat.
>>> 
>>> Please bear with me.
>>> 
>>> Regards,
>>> 
>>> Michel
>>> 
>>>> On 16 Oct 2022, at 03:37, ripe@toppas.net <mailto:ripe@toppas.net> 
>>>> wrote:
>>>> 
>>>> Hi Michael,
>>>> 
>>>>> Both netcat and openssl wait for the 220 to continue. If a timeout would 
>>>>> occur during the STARTTLS phase, or before the 220, would this differ 
>>>>> from a conclusion perspective? In other words, is it necessary to test 
>>>>> once for the 220 to appear (or a timeout), then another time to see if 
>>>>> the STARTTLS completes?
>>>> 
>>>> If you have a timeout while waiting for the initial 220 response (service 
>>>> ready), the service is not available. Maybe the SMTP daemon is not running 
>>>> or not answering for some reason, or there's a network issue. If a timeout 
>>>> occurs later during the STARTTLS phase, the server is available and also 
>>>> the underlying network connection seems to be fine. So yes, the conclusion 
>>>> would be a different. But we still don't have to run two separate tests, i 
>>>> think.
>>>> 
>>>>> Could this be folded into a single test that does a 220, then the 
>>>>> STARTTLS and will report error when there’s a fail in the process?
>>>> 
>>>> Yes. Since we do not really want to send an e-mail, we can probably use 
>>>> OpenSSL for everything in a single run. If you use the -debug parameter, 
>>>> you'll get *very* detailed output which contains all informations we want 
>>>> (except for response-times, i think). There might be a more elegant way to 
>>>> get a better-looking output from OpenSSL. But I don't know how, to be 
>>>> honest. I haven't read the whole man-page :)
>>>> 
>>>>> $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 
>>>>> <http://mahimahi.ripe.net:25/> -debug
>>>> 
>>>> Most work is probably to study the OpenSSL documentation, to find out the 
>>>> different error messages we have to expect, depending on the problems we 
>>>> might face:
>>>> 
>>>> - TCP handsha

Re: [atlas] placing a probe into wireless networks (not terrestrial)

[Michel Stam]

Hi All,

Giving the topic a bit of a poke again;
After some internal discussion, wireless probes in general could be tagged by 
looking at particular AS numbers (this excludes wifi of course). Specifically 
to StarLink, this could be possible but would require further understanding of 
the way internet measurement would work with these satellites. 

Does anyone have insights that they could share in this regard?

Regards,

Michel

> On 28 Oct 2022, at 10:32, Robert Kisteleki  wrote:
> 
> On 2022-10-28 10:04, Kurt Kayser wrote:
> 
>> I would be offering support to try to establish such a probe and help to 
>> setup a project defition.
>> Any thoughts or feedback to this idea?
> 
> In addition to what's already been said: it's useful for the whole community 
> to increase the diversity of the network. So, the more networks we can have 
> probes in, the merrier!
> 
> While doing so I find it highly useful to add proper meta-data as well (ie. 
> probe tags) to aid people understanding what they observe. For example it is 
> confusing to see high RTTs for a probe, unless it's documented that it's on a 
> (non-LEO) satellite link for example.
> 
> Side-note: at the moment we have 31 probes connected on SPACEX-STARLINK 
> (AS14593), see 
> https://atlas.ripe.net/results/maps/network-coverage/?filter=AS14593
> 
> Regards,
> Robert
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hi Simon,

This seems to have gotten a bit idle since RIPE85. Let me give a bit of an 
update:

Adding TLSv1.3 is gonna be tricky since the SSL measurement implements the 
first stages of the TLS handshake only. This means adding that complexity to 
the code, which as Niall commented to me is not trivial. Note: the SSL 
measurement currently does not use the OpenSSL library.
Other than retrieving the certificate from the peer, no other validation 
happens in the current SSL measurement. This includes not validating the 
certificate chain, which may be a self-signed certificate.
Adding STARTTLS the way OpenSSL has done it involves issuing the appropriate 
command after receiving certain output from the remote end, then starting the 
TLS handshake. This should be doable.

Hope this helps, have a nice weekend!

Regards,

Michel

> On 20 Oct 2022, at 17:30, Michel Stam  wrote:
> 
> Hello Simon,
> 
> I’ll first have a look at OpenSSL to gauge the amount of effort required. 
> I’ll also look at the existing SSL measurement to see what that offers. That 
> will likely provide the best path forward. Lastly, I’ll have an internal 
> discussion on measuring SMTP/STARTTLS/etc.
> 
> Ripe 85 is up next week, I’ll be attending there, so my response may be 
> delayed somewhat.
> 
> Please bear with me.
> 
> Regards,
> 
> Michel
> 
>> On 16 Oct 2022, at 03:37, ripe@toppas.net <mailto:ripe@toppas.net> 
>> wrote:
>> 
>> Hi Michael,
>> 
>>> Both netcat and openssl wait for the 220 to continue. If a timeout would 
>>> occur during the STARTTLS phase, or before the 220, would this differ from 
>>> a conclusion perspective? In other words, is it necessary to test once for 
>>> the 220 to appear (or a timeout), then another time to see if the STARTTLS 
>>> completes?
>> 
>> If you have a timeout while waiting for the initial 220 response (service 
>> ready), the service is not available. Maybe the SMTP daemon is not running 
>> or not answering for some reason, or there's a network issue. If a timeout 
>> occurs later during the STARTTLS phase, the server is available and also the 
>> underlying network connection seems to be fine. So yes, the conclusion would 
>> be a different. But we still don't have to run two separate tests, i think.
>> 
>>> Could this be folded into a single test that does a 220, then the STARTTLS 
>>> and will report error when there’s a fail in the process?
>> 
>> Yes. Since we do not really want to send an e-mail, we can probably use 
>> OpenSSL for everything in a single run. If you use the -debug parameter, 
>> you'll get *very* detailed output which contains all informations we want 
>> (except for response-times, i think). There might be a more elegant way to 
>> get a better-looking output from OpenSSL. But I don't know how, to be 
>> honest. I haven't read the whole man-page :)
>> 
>>> $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 
>>> <http://mahimahi.ripe.net:25/> -debug
>> 
>> Most work is probably to study the OpenSSL documentation, to find out the 
>> different error messages we have to expect, depending on the problems we 
>> might face:
>> 
>> - TCP handshake not successfull
>> - Server does not reply with 220 (timeout)
>> - Server does not reply with 220 (server replies with another 4xx or 5xx 
>> code)
>> - Server is not ESMTP capable**
>> - Connection successfull, but the server does not offer 250-STARTTLS (not 
>> supported or suppressed because of MITM attack)
>> - 250-STARTTLS was offered, but establishing encryption was still not 
>> successful for some reason
>> 
>> and maybe other typical certificate problems like:
>> 
>> - certificate invalid (self-signed)
>> - certificate invalid (expired)
>> - certificate invalid (broken chain)
>> 
>> 
>> **
>> SMTP Encryption is optional, but it is not supported by the original SMTP 
>> protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP 
>> "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by 
>> RFC 1869. From a communication perspective, the main difference is, that the 
>> initiator of the SMTP connection (client) is using EHLO instead of HELO 
>> (EHLO = Enhanced HELO). If the server does support ESMTP, it will tell the 
>> client it's features. If the server does not support ESMTP, it will reply 
>> with an error. I don't know what the OpenSSL output looks like, if you try 
>> to connect to a server which does not support ESMTP. It will probably output 
>&g

Re: [atlas] placing a probe into wireless networks (not terrestrial)

[Michel Stam]

Hi Kurt,

Thanks for a post, it was good having a chat.

What I would like to know, on a more high-level note, is how the community sees 
measuring the Internet via wireless channels. This brings some challenges, 
because measurements can be affected by such as interference (weather, radio, 
solar, etc) and also the probe itself moving.

That of course does not detract from the initial question of deploying probes 
on LEO networks, but rather should be seen as adding on to it.

Regards,

Michel

> On 28 Oct 2022, at 10:04, Kurt Kayser  wrote:
> 
> Dear Atlas-ml-followers,
> 
> this a summary of a brief discussion I had with Michel Stam during RIPE85.
> 
> We believe there might be a great value putting up a public Internet 
> monitoring probe (vantage point) into low earth orbit satellite systems, such 
> as Starlink.
> 
> Monitoring from terrestrial end-points delivers high variances, due to 
> frequent sat-changes.
> 
> If we could put up an ATLAS-probe (be it SW - which is probably easier than 
> HW) into a specific plane, we could add interesting tests and try to 
> interpret the values depending on position over specific areas, atmospheric 
> influences, solar influences as well as other effects that would change 
> signal patterns.
> 
> I would be offering support to try to establish such a probe and help to 
> setup a project defition.
> 
> Any thoughts or feedback to this idea?
> 
> Best regards
> 
> Kurt Kayser
> 
> 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hello Simon,

I’ll first have a look at OpenSSL to gauge the amount of effort required. I’ll 
also look at the existing SSL measurement to see what that offers. That will 
likely provide the best path forward. Lastly, I’ll have an internal discussion 
on measuring SMTP/STARTTLS/etc.

Ripe 85 is up next week, I’ll be attending there, so my response may be delayed 
somewhat.

Please bear with me.

Regards,

Michel

> On 16 Oct 2022, at 03:37, ripe@toppas.net wrote:
> 
> Hi Michael,
> 
>> Both netcat and openssl wait for the 220 to continue. If a timeout would 
>> occur during the STARTTLS phase, or before the 220, would this differ from a 
>> conclusion perspective? In other words, is it necessary to test once for the 
>> 220 to appear (or a timeout), then another time to see if the STARTTLS 
>> completes?
> 
> If you have a timeout while waiting for the initial 220 response (service 
> ready), the service is not available. Maybe the SMTP daemon is not running or 
> not answering for some reason, or there's a network issue. If a timeout 
> occurs later during the STARTTLS phase, the server is available and also the 
> underlying network connection seems to be fine. So yes, the conclusion would 
> be a different. But we still don't have to run two separate tests, i think.
> 
>> Could this be folded into a single test that does a 220, then the STARTTLS 
>> and will report error when there’s a fail in the process?
> 
> Yes. Since we do not really want to send an e-mail, we can probably use 
> OpenSSL for everything in a single run. If you use the -debug parameter, 
> you'll get *very* detailed output which contains all informations we want 
> (except for response-times, i think). There might be a more elegant way to 
> get a better-looking output from OpenSSL. But I don't know how, to be honest. 
> I haven't read the whole man-page :)
> 
>> $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25 -debug
> 
> Most work is probably to study the OpenSSL documentation, to find out the 
> different error messages we have to expect, depending on the problems we 
> might face:
> 
> - TCP handshake not successfull
> - Server does not reply with 220 (timeout)
> - Server does not reply with 220 (server replies with another 4xx or 5xx code)
> - Server is not ESMTP capable**
> - Connection successfull, but the server does not offer 250-STARTTLS (not 
> supported or suppressed because of MITM attack)
> - 250-STARTTLS was offered, but establishing encryption was still not 
> successful for some reason
> 
> and maybe other typical certificate problems like:
> 
> - certificate invalid (self-signed)
> - certificate invalid (expired)
> - certificate invalid (broken chain)
> 
> 
> **
> SMTP Encryption is optional, but it is not supported by the original SMTP 
> protocoll (RFC 821). To use STARTTLS, the mailserver has to support SMTP 
> "Service Extensions" aka. ESMTP. ESMTP has been introduced 13 years later by 
> RFC 1869. From a communication perspective, the main difference is, that the 
> initiator of the SMTP connection (client) is using EHLO instead of HELO (EHLO 
> = Enhanced HELO). If the server does support ESMTP, it will tell the client 
> it's features. If the server does not support ESMTP, it will reply with an 
> error. I don't know what the OpenSSL output looks like, if you try to connect 
> to a server which does not support ESMTP. It will probably output some error 
> message. This error should be evaluated by the Atlas SMTP measurement too. 
> 99.9% of all mailservers nowadays should support ESMTP, but there might be 
> some usecases... "special application blabla". It could be possible that 
> someone would start a Atlas SMTP measurement for a non-ESMTP compliant 
> target. That's why i am mention this.
> 
> 
> BR,
> Simon
> 
> 
> 
> On 05.10.22 17:55, Michel Stam wrote:
>> Hi Simon,
>> 
>> Thanks for the rundown, that helps.
>> 
>> The Atlas measurement code uses something different than nc, but that isn’t 
>> really relevant, the process is roughly the same.
>> 
>> I have a question, though. Both netcat and openssl wait for the 220 to 
>> continue. If a timeout would occur during the STARTTLS phase, or before the 
>> 220, would this differ from a conclusion perspective? In other words, is it 
>> necessary to test once for the 220 to appear (or a timeout), then another 
>> time to see if the STARTTLS completes? Could this be folded into a single 
>> test that does a 220, then the STARTTLS and will report error when there’s a 
>> fail in the process?
>> 
>> As to the TCP traceroute, this is something used by p

Re: [atlas] Revive an abandoned probe?

[Michel Stam]

Hello Ernst,

If you reconnect the probe it should automatically get online again and start 
working.

Let me know how it works out!

Regards,

Michel

> On 6 Oct 2022, at 21:11, Ernst J. Oud  wrote:
> 
> 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
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hi Simon,

Thanks for the rundown, that helps.

The Atlas measurement code uses something different than nc, but that isn’t 
really relevant, the process is roughly the same.

I have a question, though. Both netcat and openssl wait for the 220 to 
continue. If a timeout would occur during the STARTTLS phase, or before the 
220, would this differ from a conclusion perspective? In other words, is it 
necessary to test once for the 220 to appear (or a timeout), then another time 
to see if the STARTTLS completes? Could this be folded into a single test that 
does a 220, then the STARTTLS and will report error when there’s a fail in the 
process?

As to the TCP traceroute, this is something used by people to measure service 
availability using Atlas. It isn’t something I came up with perse, but yes its 
to measure response time as well as availability of the service at the TCP 
level.

With regard to additional check such as DANE, these lie somewhere between 
DNSSEC and TLS measurement. I’ll make a note of this, thanks for the suggestion.

As to measurements in general, all currently support IPv6 to my knowledge. I 
agree that new ones should support this too.

Regards,

Michel


> On 1 Oct 2022, at 17:11, ripe@toppas.net wrote:
> 
> Hi Michel,
> 
>> That would would indeed mean a combination of TCP and SSL measurement to 
>> achieve all 3 required functions. Is it problematic if the result comes from 
>> multiple steps? If so, can you explain how?
>> The intent of the measurement would be to validate whether an SMTP server is:
>> reachable
>> responsive
>> capable of secured transmissions
> 
> First, let's define the testmethod. In my opinion:
> 
> - reachable
> 3-way TCP Handshake with target on tcp/25 successful?
> 
> - responsive
> when establishing and SMTP connection, does the smtp-server signalize 
> readiness of the service (SMTP 220)?
> 
> - capable of secured transmissions
> when sending an EHLO, the server will tell us his features. 250-STARTTLS 
> should be there.
> 
> 
> For all three checks, it's the easiest to use netcat.
> 
> Reachability:
>> $ nc -vz mahimahi.ripe.net 25
>> mahimahi.ripe.net [193.0.19.114] 25 (smtp) open
> 
> Note, that we have not measured the response time. That's why you wanted to 
> use TCP Traceroute, right? We can also go with TCP Traceroute here.
> 
> 
> Responsiveness (wait for 220):
>> $ nc -C mahimahi.ripe.net 25
>> 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:25:22 +0200
>> quit
>> 221 mahimahi.ripe.net closing connection
> 
> You might want to use the -w option here, to specify a timeout.
> 
> 
> capable of secured transmissions (send EHLO and check response):
>> $ nc -C mahimahi.ripe.net 25
>> 220 mahimahi.ripe.net ESMTP Sat, 01 Oct 2022 15:54:04 +0200
>> EHLO p123456.probes.atlas.ripe.net
>> 250-mahimahi.ripe.net Hello p123456.probes.atlas.ripe.net [123.123.123.123]
>> 250-SIZE 52428800
>> 250-8BITMIME
>> 250-ETRN
>> 250-PIPELINING
>> 250-PIPE_CONNECT
>> 250-STARTTLS
>> 250 HELP
> 
> 
> To check the Certificate validity and if encryption is indeed successful, we 
> can use OpenSSL:
>> $ openssl s_client -starttls smtp -connect mahimahi.ripe.net:25
> (output to long, i stripped it)
> 
> 
> 
>> You’re correct, the current SSL measurement does not support any form of 
>> STARTTLS, this is something that would have to be considered for 
>> implementation. I assume, much like with SMTP, similar cases could be made 
>> for IMAP4/POP3 or XMPP.
> Yeah, as far as i know, STARTTLS is also used for imap, pop3, xmpp and ftp 
> (ftps, not sftp).
> 
> 
> As i said before, there are additional e-mail security features that we could 
> check. There's MTA-STS, where we would have to perform a combination of HTTP 
> and SSL check. Also, there is DANE, where we would perform a combination of 
> DNS and SSL check (including DNSSEC). But DANE can be used for other 
> protocols as well, not only SMTP. DNSSEC/DANE are perhaps worth a separate 
> check type.
> 
> Last but no least, we should check for Forward-confirmed reverse DNS and 
> matching SMTP banner, which is a combination of DNS and netcat check. This 
> would be a reasonable part of every smtp measurement.
> 
> 
> Please note, that the creator of the measurement should either specify the 
> exact mailserver FQDN, or the target Domain. In the latter case, an MX record 
> lookup has to be performed before the measurement starts, not while the 
> measurement is running. Otherwise it could cause credit consumption trouble, 
> if suddenly multiple mx records are added the domain, while the measurement 
> is running.
> 
> Oh, and please mak

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hi Simon,

> >Can we achieve the first 2 items of this measurement by doing a TCP 
> >traceroute on port 25?
> I would say no. Using TCP Traceroute, you can may check for 
> reachability/responsiveness of the host, but not the actual service (smtp).

That would would indeed mean a combination of TCP and SSL measurement to 
achieve all 3 required functions. Is it problematic if the result comes from 
multiple steps? If so, can you explain how?

I just noticed that the SSL measurement offers a time to connect, response 
time, certificates as well as SSL alerts which may be leveraged, see here: 
https://atlas.ripe.net/docs/apis/result-format/#version-4610 
<https://atlas.ripe.net/docs/apis/result-format/#version-4610>, under "Version 
4610 TLS (SSL) GET Cert”. TCP traceroute may not be necessary in this case, 
although I understand it is typically used to determine service availability.

> >Does the SSL measurement cover the intended use cases?
> I would say no. Correct me if am am wrong. Usually (for example HTTPS or 
> LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was 
> successfull. For SMTP, that doesn't work. That's because regular SMTP 
> communication starts first, so both sides can negotiate if SSL/TLS encryption 
> is possible (via Enhanced SMTP Status Codes). However, as far as i know, 
> OpenSSL does support SMTP and STARTTLS. So you could probably modify the 
> existing SSL measurement.
> 
> Keep in mind that there's also MTA-STS and DANE, which are really enhancing 
> SMTPs security. A dedicated SMTP measurement would be a good thing.


You’re correct, the current SSL measurement does not support any form of 
STARTTLS, this is something that would have to be considered for 
implementation. I assume, much like with SMTP, similar cases could be made for 
IMAP4/POP3 or XMPP.
I would like to understand if there are particulars you are looking for that 
need to be considered outside of STARTTLS support?

Regards,

Michel


> On 23 Sep 2022, at 17:08, ripe@toppas.net wrote:
> 
> Hi Michel,
> 
> >Are we monitoring the Internet or monitoring a service using the proposed 
> >SMTP measurement?
> First of all, we are monitoring the service of a specific target. Same as 
> http or ntp measurements, just another protocol. But we also monitor the 
> Internet. Using an SMTP measurement, we could identify censorship or discover 
> Man-in-the-middle attacks (downgrade attack by suppressing the STARTTLS 
> command).
> 
> >Can we achieve the first 2 items of this measurement by doing a TCP 
> >traceroute on port 25?
> I would say no. Using TCP Traceroute, you can may check for 
> reachability/responsiveness of the host, but not the actual service (smtp).
> 
> >Does the SSL measurement cover the intended use cases?
> I would say no. Correct me if am am wrong. Usually (for example HTTPS or 
> LDAPS) the SSL/TLS encryption starts right after the TCP 3-way Handshake was 
> successfull. For SMTP, that doesn't work. That's because regular SMTP 
> communication starts first, so both sides can negotiate if SSL/TLS encryption 
> is possible (via Enhanced SMTP Status Codes). However, as far as i know, 
> OpenSSL does support SMTP and STARTTLS. So you could probably modify the 
> existing SSL measurement.
> 
> Keep in mind that there's also MTA-STS and DANE, which are really enhancing 
> SMTPs security. A dedicated SMTP measurement would be a good thing.
> 
> BR,
> Simon
> 
> 
> 
> On 23.09.22 16:04, Michel Stam wrote:
>> Hi everyone,
>> 
>> Great that this request sparked a good discussion on the merits of a 
>> measurement, as well as its potential impact on servers around the world. 
>> Good to see this!
>> 
>> So I’m going to do a quick recap here, hoping that I capture the intent and 
>> the concerns correctly. Please correct me if I err.
>> 
>> The intent of the measurement would be to validate whether an SMTP server is:
>> reachable
>> responsive
>> capable of secured transmissions
>> 
>> The concern is that such a check would trigger one of a variety of anti spam 
>> measures in place around the world, and/or cause undue traffic to SMTP 
>> server operators.
>> 
>> With this in mind, I am wondering: 
>> Are we monitoring the Internet or monitoring a service using the proposed 
>> SMTP measurement? 
>> Can we achieve the first 2 items of this measurement by doing a TCP 
>> traceroute on port 25?
>> Does the SSL measurement cover the intended use cases?
>>  Is it worth exploring STARTTLS support as an extension and what would the 
>> implications be?
>> 
>> Have a good weekend!
>> 
>> Best regards,

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hi everyone,

Great that this request sparked a good discussion on the merits of a 
measurement, as well as its potential impact on servers around the world. Good 
to see this!

So I’m going to do a quick recap here, hoping that I capture the intent and the 
concerns correctly. Please correct me if I err.

The intent of the measurement would be to validate whether an SMTP server is:
reachable
responsive
capable of secured transmissions

The concern is that such a check would trigger one of a variety of anti spam 
measures in place around the world, and/or cause undue traffic to SMTP server 
operators.

With this in mind, I am wondering: 
Are we monitoring the Internet or monitoring a service using the proposed SMTP 
measurement? 
Can we achieve the first 2 items of this measurement by doing a TCP traceroute 
on port 25?
Does the SSL measurement cover the intended use cases?
 Is it worth exploring STARTTLS support as an extension and what would the 
implications be?

Have a good weekend!

Best regards,

Michel

> On 21 Sep 2022, at 00:11, Avamander  wrote:
> 
> > Making arguments based upon extreme cases, assumptions, or 
> > potential-for-collateral-damage is not scientific. "I know one that even 
> > [...]" Anecdotal  evidence isn't scientific.
> 
> From the perspective of your previous sentences that's kinda humorous. "To 
> avoid unnecessary costs incurred from disruption of service, excessive 
> traffic, annoyances using up *my* time, and countless other reasonable 
> rationale from *my* point of view." Because sure, a few (hypothetical RIPE 
> probe) connections are exactly that, zero exaggeration, right?
> 
> In the end such fail2ban-fueled (or similar) behaviour I initially addressed, 
> is exactly a non-scientific extreme-case assumption-based approach. There are 
> better and even more standard ways. 
> 
> Crutch solutions out in the wild shouldn't be a showstopper for measuring the 
> ecosystem. (That is already quite neglected)
> 
> > What _objective_ risk/benefit analysis are you basing your opinions upon?
> 
> And you? What's the implication here about systems being as trigger-happy as 
> previously described?
> 
> Because sure, at some point rate limits make total sense, but certainly not 
> at the point where it would ban any potential RIPE probes.
> 
> >  Are you a systems administrator?
> 
> Let's not get into such measuring contests, even if it is the RIPE Atlas 
> mailing list.
> 
> On Tue, Sep 20, 2022 at 11:42 PM Paul Theodoropoulos via ripe-atlas 
> mailto:ripe-atlas@ripe.net>> wrote:
> On 9/20/2022 10:45 AM, Avamander wrote:
>> Great to hear it works for you, but the potential unfortunate collateral 
>> from such a blanket action is not really RIPE Atlas' problem. There are more 
>> fine-grained methods against bruteforce attempts and open relay probes, than 
>> triggering on a few connections.
> What _objective_ risk/benefit analysis are you basing your opinions upon? Are 
> you a systems administrator? My responsibility is to avoid unnecessary costs 
> incurred from disruption of service, excessive traffic, annoyances using up 
> *my* time, and countless other reasonable rationale from *my* point of view.  
> 
> You suggest that it is "not really RIPE Atlas' problem". That's very true. 
> And it is not really my problem if I bounce yoinky, pointless probes of my 
> server, and ruthlessly block them from contacting my server ever again. My 
> server, my choice, my wallet, nobody's business but my own.
>> Some webmasters ban IP's for simply visiting a domain, I know one that even 
>> dispatches an email to your ISP's abuse@ address upon visit. Should RIPE 
>> Atlas probes then not probe any HTTP servers? The answer is obviously no, 
>> they shouldn't care.
> Making arguments based upon extreme cases, assumptions, or 
> potential-for-collateral-damage is not scientific. "I know one that even 
> [...]" Anecdotal  evidence isn't scientific.
> 
> Note, I run a probe myself. I don't block any RIPE Atlas traffic on my 
> separate servers hosted on AWS, Oracle, and GCE. 
> 
> -- 
> Paul Theodoropoulos
> anastrophe.com -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net 
> https://lists.ripe.net/mailman/listinfo/ripe-atlas 
> 
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] RIPE Atlas SMTP Measurement

[Michel Stam]

Hello Simon,

Thank you for the suggestion.

I have a couple of questions to get a better idea:
Can you maybe describe what a SMTP measurement would look like?
Simple EHLO/HELO
Sending an email to a designated address (which would then validate that the 
SMTP server is capable of relaying etc.)
How would DNSBL or other spam prevention techniques fit into this? 
What would the result be? 
Delay until mail received
Response time by the actual mail server
Using the Received: headers to get a “traceroute” like result.
What about the more uncommon ports such as 565 (SMTP+SSL/TLS) or 587 (mail 
submission port).
How can we prevent this implementation from having RIPE Atlas be identified as 
a spam bot network?
 
Best regards,

Michel

> On 3 Sep 2022, at 14:48, Simon Brandt via ripe-atlas  
> wrote:
> 
> Hello,
> 
> i'd like to start a discussion about having a RIPE Atlas SMTP measurements.
> First of all: yes, i know there's a big obstacle for such a measurement type. 
> A lot of probes are deployed using enduser internet-connections like dsl, 
> cable, etc. with dynamic/eyeball IP addresses. Those IP spaces are usually 
> blocked by SMTP servers as approach to reduce spam mails. For Example: by 
> using blocklists like Spamhaus PBL. So a proper SMTP measurement wouldn't 
> work.
> 
> BUT we could have an easy way for RIPE Atlas probe hosters to signalize, that 
> their probe is eligible for SMTP measurements:
> 
> Step 1: enable "Simple DNS Entry"
> Step 2: create a matching reverse DNS record for the probes IP address
> 
> Everybody who is able so configure a reverse DNS record for his probes IP 
> address, is most likely using a non-dynamic/non-home ip address space e.g. a 
> datacenter or office network. If an ISP provides the option for his customers 
> to configure a reverse DNS record, it's most likely a "business-customer" 
> subnet which can be used to run mailservers. After Step 1+2 are done, the 
> RIPE Atlas platform would easily be able to verify if forward-confirmed 
> reverse DNS is successful, and if so, automatically enable that probe for 
> SMTP measurements. Alternatively: probe hosters choose their own 
> Forward-confirmed reverse DNS name and submit it on the RIPE Atlas website.
> 
> Also: if we would have STMP measurements, forward-confirmed reverse DNS 
> should be mandatory for anchors, or is it already?
> 
> Why should we have SMTP measurements?
> 
> Besides general reachability checks, we could also evaluate SMTP response 
> codes. But the most important thing for me is this: the SMTP protocol is old. 
> Very old. From a security point of view, it's absolutely outdated. Most 
> security features have been added years after the initial RfC. Thus, those 
> security features are optional. Mandatory SMTP encryption is not provided by 
> the SMTP RfC. So both sides have to signalize, that they are capable of 
> encryption using the STARTTLS command. An attacker (man-in-the-middle) can 
> perform a downgrade attack by suppressing the STARTTLS command. So both sides 
> are forced to fallback and communicate unencrypted. RIPE Atlas would be a 
> really good tool to identify such attacks, by monitor/measure the (enhanced) 
> status codes of a target.
> 
> But there's more!
> I see a two-sided model here. Either use the RIPE Atlas SMTP measurements to 
> monitor/measure your own mailserver by alot of other RIPE probes out there, 
> OR probe hosters could run SMTP measurements originating from their own probe 
> to find out, if their own IP address is currently blocked by other 
> mailservers.
> 
> 
> What do you think?
> 
> 
> BR,
> Simon
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] My experiences with a SW probe…

[Michel Stam]

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

Re: [atlas] My experiences with a SW probe…

[Michel Stam]

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  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@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Ongoing problem with DoT measurements

[Michel Stam]

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 
>  wrote:
> 
> 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@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/PDIwMjIwMzI0MTIzMzE1LkdBMjcyMTIwQGxhcGVyb3VzZS5zb3VyY2VzLm9yZz4=).
>  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@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Future of Software Anchors

[Michel Stam]

Hi Lukas,

Great to hear you’re using Atlas :)

I’m sorry, we haven’t uploaded the latest repository because we are 
restructuring a few things internally to streamline our development process.
We will upload updated repositories once this has completed, which will include 
5070.

Can you hold on for a bit longer?

Best regards,

Michel

> On 28 May 2022, at 16:27, Lukas Magauer via ripe-atlas  
> wrote:
> 
> 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
>  
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net 
> https://lists.ripe.net/mailman/listinfo/ripe-atlas 
> 
-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe TLS stack

[Michel Stam]

Hello Christopher,

The probes use OpenSSL for the TLS stack, the exact features compiled in depend 
a little on the probe used, but right now the software will support up to TLS 
v1.2.

Is there any feature in particular you’re looking for?

Regards,

Michel

> On 12 May 2022, at 11:50, Christopher Wood  wrote:
> 
> 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
> -- 
> ripe-atlas mailing list
> ripe-atlas@ripe.net
> https://lists.ripe.net/mailman/listinfo/ripe-atlas


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas