I believe firmware 5020, which is being rolled out now, adds this to software probes. In your case the SOS messages were just delivered a bit later.
ok, false positive then ;-)
2. The ./status/ssh_err.txt file showed the following message: « RSA host key for IP address '178.63.8.31' not in list of known hosts. »
This is safe to ignore. No host keys need to be added manually.
Noted.
3. I tried to set up a test one-off measurement using my sw probe by manually selecting its ID on the measurement setup screen, but it would not register the probe. I also noted after 12+ hours that no UDM was active for the probe from other users (from my experience with a hardware probe I have been operating for a while, it should be put at use by the network pretty quickly unless I am too impatient here ;-) ).
This one was interesting, so we tracked it down. It turns out that the probes which have bandwidth limits set but don't report their bandwidth usage were not scheduled to do UDMs. This only affects SW probes where bandwidth reporting is opt-in.
We are addressing this with improved documentation on bandwidth limits and changing the logic of how this is applied to software probes.
Thanks for the feedback. I have now remove the bandwidth limit I had initially put, have created a new measurement, and confirm that it includes the sw probe. One last question though: you mention bandwidth reporting being "opt-in" for sw probes, but I can't seem to find where the setting can be adjusted on the probe web page. Is it user-modifiable somewhere ?
The firmware only uses ssh for outgoing connections, so while these changes may have seemed to help, they probably didn't :-)
Thanks for the confirmation. It was also my understanding that the probe does not accept incoming connections (which would not go through my firewall as it is configured now anyway), but with the SSH error log, I reverted the whole OpenSSH config back to defaults "just in case" ;-) Regards, Thierry