if we ping a target which does not return any packets (normal ping returns "Request timed out.")
the check_winping.exe throws these errors:
check_winping -H xyz --warning 100,11% --critical 200,21% --packets 10 -4 --timeout 5
Use of uninitialized value $message in pattern match (m//) at check_winping.pl line 99, <PINGOUT> line 4.
Use of uninitialized value $message in concatenation (.) or string at check_winping.pl line 139, <PINGOUT> line 4.
WINPING CRITICAL - Terminating on signal SIGINT(2)
Using --verbose I did 3 tests: one with a reachable target, one with an unreachable target and the last with no response at all which causes the error.
Output line number two for each test cases:
2: Reply from y.y.y.y: bytes=32 time=1ms TTL=61
2: Reply from x.x.x.x: Destination net unreachable.
2: Request timed out.
The last test produces the error in line 99 and line 139 and says $message is not initialized.
The code at line 99: next if $message =~ /TTL=\d+/;
The regex in line 97 searches for a colon. The last test case does not contain a colon in the output like the other two and thus $message has no content which throws the error.
This is now fixed. Please download version 184.108.40.206 at Free software section.
We still face a problem:
Looking into the code the ping command is executed once with the desired number of packets. If the packets are lost as described earlier the situation is like this: after the default timeout of 10 seconds for the first packet the output appears as expected. But if you use for example 10 packets the output is there after 10 seconds but the plugin "hangs" for 100 seconds. The reason is that the filehandle for the ping command cannot be closed before the ping command has terminated. Hence the plugin cannot exit. It has to wait until for all 10 packets the (default) timeout is reached.
But what is more important is that if the first ping has no response the plugin tries to exit and does not evaluate the other 9 pings (which could return a valid result). This is definetely not what you want because the final result of the plugin is wrong in such a situation.
Thanks a lot for your investigations and suggestions. We will try to come up with a solution.
Maybe a possible approach is to execute the ping command always with exactly one packet but do this in a loop as often as the number of desired packets is.
What is the current situation? When do you think can we expect a solution?