I upgraded my central monitoring-machine to debian buster and smokeping 2.7.3-2.
Everything worked out, except the mikrotik-remote-poller ... quitted duty.
Among other remote-polling-probes for smokeping, there's also one for ROS avail.
In short: the smokeP-machine logs into ROS, ROS polls the devices of interest in the remote-network and sends back the runtime results to the smokeP-machine, where the graphical presentation is done.
So far so easy. Setup is straight forward. The probe is avail here (thanks again Vlad):
http://www.hazard.maks.net/blog/index.p ... 9&blogId=1
Code: Select all
local-network remote-network
+--+
+-------------+ +-------------+ +-| |
| | VPN-Link | | | +--+
| smoke | | | | +--+
| ping +-------------------+ ROS +---+-| |
| | <---------------> | | | +--+
| | ssh | | | +--+
+-------------+ +-------------+ +-| |
<----> +--+
ping
Now the problem description and how you could solve it:
- OpenSSHMikrotikPing.pm makes use of FPing.pm
- FPing.pm makes use of the fping-binary of your distribution
- with the buster-release debian switched to fping-version 4.2
- with v4.2 fping supports IPv6 ... so new-options [ --ipv4 and --ipv6 ] are implemented
- these new options are also implemented in FPing.pm
- unfortunately it is not implemented in OpenSSHMikrotikPing.pm
- so when FPing.pm tries to hand-over the new option --ipv4, your remote-poller will fail
what can you do ?
find the FPing.pm perl-modul inside your distribution ... and comment out the IPv4|6-option-sequence like that:
Code: Select all
# protocol => {
# _re => '(4|6)',
# _example => '4',
# _default => '4',
# _doc => "Choose if the ping should use IPv4 or IPv6.",
#
# },
congrats ! ... you just saved 4 hours : )