- if no multiplier is set, simply return the given string. Otherwise we would strip off the unit.
- if used, allocate new space to hold the result which might be larger than the initial input
Signed-off-by: Sven Nierlein <sven@consol.de>
the multiplier function always tried to extract a number, even if the result
is a string because of using a mib.
before:
```
./check_snmp -H hostname -P2c -c public -o IF-MIB::ifAdminStatus.11466 -vvv -r 0
/usr/bin/snmpget -Le -t 10 -r 5 -m ALL -v 2c [context] [authpriv] 10.0.13.11:161 IF-MIB::ifAdminStatus.11466
IF-MIB::ifAdminStatus.11466 = INTEGER: up(1)
Processing oid 1 (line 1)
oidname: IF-MIB::ifAdminStatus.11466
response: = INTEGER: up(1)
SNMP OK - 0 | IF-MIB::ifAdminStatus.11466=0;;
```
the regexp 0 matches, even if the actual result is "up(1)".
after this patch:
```
./check_snmp -H hostname -P2c -c public -o IF-MIB::ifAdminStatus.11466 -vvv -r 0
/usr/bin/snmpget -Le -t 10 -r 5 -m ALL -v 2c [context] [authpriv] 10.0.13.11:161 IF-MIB::ifAdminStatus.11466
IF-MIB::ifAdminStatus.11466 = INTEGER: up(1)
Processing oid 1 (line 1)
oidname: IF-MIB::ifAdminStatus.11466
response: = INTEGER: up(1)
SNMP CRITICAL - *up(1)* |
```
Segfault at line 489 if number of processed lines is greater than number (#1589) of thresholds
Co-authored-by: Lorenz <12514511+RincewindsHat@users.noreply.github.com>
When using a large distributed network with the same group of checks used against a large number of devices, occationally there are missing cards in a few devices that are present in other devices. Rather than having a large number of unknown results, disable active checking on those large number of result or having to create a unique check configuration for those devices.
This option allows you to select an OK, WARNING, CRITICAL or UNKNOWN status while still retaining the default behavior when not present. This also allows a for the check to immediately start checks as intended should the hardware be added that the check is looking for.
when using check_snmp with multiple oids it simply printed the unparsed content
from -w/-c into the thresholds for each oid. So each oid contained the hole -w
from all oids.
./check_snmp ... -o iso.3.6.1.2.1.25.1.3.0,iso.3.6.1.2.1.25.1.5.0 -w '1,2' -c '3,4'
before:
SNMP ... | HOST-RESOURCES-MIB::hrSystemInitialLoadDevice.0=393216;1,2;3,4 HOST-RESOURCES-MIB::hrSystemNumUsers.0=24;1,2;3,4
after:
SNMP ... | HOST-RESOURCES-MIB::hrSystemInitialLoadDevice.0=393216;1;3 HOST-RESOURCES-MIB::hrSystemNumUsers.0=24;2;4
This also applies to fixed thresholds since check_snmp translates negative infinities from: '~:-1' to '@-1:~'
The "-6" optarg now prepends the server_address with "udp6:" for the
snmpget external command as per the net-snmp syntax at:
http://www.net-snmp.org/wiki/index.php/FAQ:Applications_28
Thanks to DrydenK (Roberto Greiner) for the heads up.
* maint:
sslutils: Remove superfluous parenthesis for sslv3 function too
sslutils: remove superfluous parenthesis
check_snmp: modified tests
check_snmp.c: switched DEFAULT_TIMEOUT to DEFAULT_SOCKET_TIMEOUT (provided by utils.h), already used by help description, see issue #1318
install snmpd on travis tests
enable libtab on travis builds
add perl snmp to travis dependencies
NEWS: Mention check_ups performance data fix
Fix incorrect performance data thresholds
check_dhcp: Fix option parsing
Fixes segfaults when running via monitoring worker (off-by-one)
travis: fix http test host
sslutils: Check if OpenSSL supports SSLv3.
Conflicts:
NEWS
plugins/sslutils.c
snmpget already supports using SNMPv3 contexts using the option "-n".
Thus all we need to do is introduce a new argument to check_snmp and
pass the argument on to snmpget using snmpget's option "-n".
Since "-n" is already in use for check_snmp for a different purpose,
we use "-N" instead.
The SNMPv3 noAuthNoPriv security level, somewhat unintuitively, requires
a security name to be passed along together with the request. Check_snmp
previously did not do this, causing snmpget to throw an error:
"External command error: No log handling enabled - turning on stderr
logging
snmpget: No securityName specified"
This patch fixes the issue by always providing the security name when
noAuthNoPriv is specified.
See also:
https:://bugs.op5.com/view.php?id=8385.
Signed-off-by: Anton Lofgren <alofgren@op5.com>
check_snmp becomes capable of evaluating negative values properly,
but it might be returning CRITICALs where it used to return OK and was ignored,
if a negative value turns out to actually be a valid value.
If negative values are valid, this can be worked around,
by adding "~:" to the warning/critical threshold : 100 -> ~:100
This is an initial take at renaming the project to Monitoring Plugins.
It's not expected to be fully complete, and it is expected to break
things (The perl module for instance). More testing will be required
before this goes mainline.
