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.
* 'master' of https://github.com/ozamosi/nagios-plugins:
check_snmp: Close potential for using uninitialized memory
check_snmp: Dynamically grow all data structures
Conflicts:
plugins/check_snmp.c
Commit bd78299056 reintroduced support for
inverse threshold ranges such as "2:1", but it broke standard thresholds
such as "1:2" (by converting this range into "1") or "1:" (by converting
this range into "@:2"). This commit fixes those two bugs, plus an
off-by-one error while computing the number of bytes to allocate when
handling inverse thresholds (two additional bytes were allocated where
three were required to hold '@' and ':' and '\0'). While at it, we also
check whether malloc(3) succeeded.
This was reported by clang, and in order for it to understand attributes
properly, I had to modify the macro that checks for non-gcc compilers.
Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
Before this patch, there was a constant, MAX_OIDS, that determined the
amount of slots most (but not all - see labels) array data structures
would have. It was set to 8.
Some users would like to use more than that, but rather than bumping the
constant, let's use the same type of logic we already use for labels -
grow the space 8 slots at a time. This will allow us to potentially
support an infinite amount of oids - or at least as many as the
packetsize on the SNMP server allows, which is usually significantly
smaller than infinity, yet often larger than 8.
Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
The memory allocation mixed up number of bytes with number of pointers,
meaning as soon as we'd reach (on 64 bit systems) the second argument,
we'd start writing it outside of our allocated memory.
Normally, this isn't too visible, but as soon as you (again, on my 64
bit system) reach argument number 8, you get a segfault. It is easily
reproducible with:
check_snmp -o '' -l '' -o '' -l '' -o '' -l '' -o '' -l '' \
-o '' -l '' -o '' -l '' -o '' -l '' -o '' -l ''
This patch allocates the proper amount of memory, to fix the issue.
Signed-off-by: Robin Sonefors <robin.sonefors@op5.com>
Dying without a hint of what went wrong is just plain annoying. With
this patch we at least get a hint.
While at it, we fix the string offset so the output we're interested
in doesn't keep the equal sign that snmpget prints.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Once upon a time, check_snmp used to accept inverse ranges in the
format of '2:1' to mean "alert if value is inside this range".
Since commit 7cb3ae0933, ranges such
as those have instead triggered the error "Range format incorrect"
and resulted in an UNKNOWN warning state. This patch attempts to
fix the situation so that the old-style ranges continues to mean
exactly what the once did and people with lots of snmp checks can
avoid a bazillion false positives from their environments.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Fixes many instances of
warning: ignoring return value of 'asprintf', declared with attribute warn_unused_result [-Wunused-result]
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
Fix the code which accepts a comma-separated list of labels specified
via the "-l" option.
(Spotted by Oskar Liljeblad in Debian bug report #647020, forwarded by
Jan Wagner.)
This reverts commit 896962a1ad.
Conflicts:
NEWS
plugins/tests/check_snmp.t
Notes:
Reverting because I rebased a patch that was doing the same thing, plus
fixing more related regressions, and both didn't work together.
I kept the tests intact except for one that wouldn't pass on 1.4.14
either
Original patch to make Timeticks works as in check_snmp v1.4.14, it turns
out is_numeric isn't so useful and treating all types as numeric works
best for backwards-compatibility. This is how it used to work in 1.4.14.
As a special case, I also make calculate_rate look up for numeric values
as it would otherwise return the last value instead.
This patch tries to detect and output nicely multi-line strings. This
method is broken by design; only a count of double-quotes and escapes
could work in every situation.
Bug #2832884 reported problem with translations outputting pot file
headers. This is caused by "" matching the header of the translation
files.
This patch moves gettext macros inside utils macros and update some
french translations.
Rework last patch, copying the converted portion of the string rather
than re-converting it. This is safer for backwards-compatibility as the
value is never modified.
