#965329 check_ldaps (and maybe others?) cannot be restricted to IPv4-only checks via -4 cmdline switch

Package:
monitoring-plugins-standard
Source:
monitoring-plugins
Description:
Plugins for nagios compatible monitoring systems (standard)
Submitter:
Mike Gabriel
Date:
2021-12-20 05:21:03 UTC
Severity:
normal
#965329#5
Date:
2020-07-19 16:10:29 UTC
From:
To:
Package: monitoring-plugins-standard
Version: 2.2-6

Hi,

I just stumbled over a peculiar thing.

I migrated one of my LDAP server that gets monitored via Icinga2 for
IPv6 and IPv4 connectivity separately. The LDAP hosts IPv6 setup is
still buggy after its migration and the Icinga2 host for now gets
blocked by the providers firewall and cannot reach the the LDAP
server's IPv6 address (like a fw DROP or a routing problem). (I filed
a ticket with the server hoster for that, so this is off-topic here).

However...

I'd expect the IPv4 check_ldaps test to succeed (and see a check_ldaps
timeout for the IPv6 test). But that's not the case.

I obfuscated IPs a bit in the below strace output:

IPv4

   1.2.3.4 is the LDAP server to check
   5.6.7.8 is the Icinga2 host that does the check

IPv6

   2a01:xxxx::101 is the LDAP server to check
   2001:xxxx::2 is the Icinga2 host that does the check

The check is:

   check_ldaps -4 -3 -b dc=my,dc=domain -H ldap-server-x-on.my.domain -p636

I expect that the check happens on IPv4 only and IPv6 checking is
totally omitted.

The check does not work. It hangs and gives a "CRITICAL - Socket
timeout after 10 seconds"

Running this with strace -f reveals that the check is _NOT_ being done
on the IPv4 addresses, but via the IPv6 addresses. This is not what I
told the command to do via command line switch "-4".

Stracing the command call...

```
(root@icinga-host) {~} # strace -f /usr/lib/nagios/plugins/check_ldaps
-4 -3 -b dc=my,dc=domain -H ldap-server-x-on.my.domain -p636

[...]
recvmsg(3, {msg_name={sa_family=AF_NETLINK, nl_pid=0,
nl_groups=00000000}, msg_namelen=12, msg_iov=[{iov_base={{len=20,
type=NLMSG_DONE, flags=NLM_F_MULTI, seq=1595174041, pid=24211}, 0},
iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 20
close(3)                                = 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(636),
sin_addr=inet_addr("1.2.3.4")}, 16) = 0
getsockname(3, {sa_family=AF_INET, sin_port=htons(49266),
sin_addr=inet_addr("5.6.7.8")}, [28->16]) = 0
close(3)                                = 0
socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET6, sin6_port=htons(636),
inet_pton(AF_INET6, "2a01:xxxx::101", &sin6_addr),
sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = 0
getsockname(3, {sa_family=AF_INET6, sin6_port=htons(44501),
inet_pton(AF_INET6, "2001:xxxx::2", &sin6_addr),
sin6_flowinfo=htonl(0), sin6_scope_id=0}, [28]) = 0
close(3)                                = 0
socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) = 3
fcntl(3, F_SETFD, FD_CLOEXEC)           = 0
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0

vvvvvvvvvvvvvvvvvvvv

connect(3, {sa_family=AF_INET6, sin6_port=htons(636),
inet_pton(AF_INET6, "2a01:xxxx::101", &sin6_addr),
sin6_flowinfo=htonl(0), sin6_scope_id=0}, 28) = ? ERESTARTSYS (To be
restarted if SA_RESTART is set)
--- SIGALRM {si_signo=SIGALRM, si_code=SI_KERNEL} ---

^^^^^^^^^^^^^^^^^^^^ WTF??? Why IPv6 here...?


openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=2995, ...}) = 0
read(4, "# Locale name alias data base.\n#"..., 4096) = 2995
read(4, "", 4096)                       = 0
close(4)                                = 0
openat(AT_FDCWD,
"/usr/share/locale/en_US/LC_MESSAGES/monitoring-plugins.mo", O_RDONLY)
= -1 ENOENT (No such file or directory)
openat(AT_FDCWD,
"/usr/share/locale/en/LC_MESSAGES/monitoring-plugins.mo", O_RDONLY) =
-1 ENOENT (No such file or directory)
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x3), ...}) = 0
write(1, "CRITICAL - Socket timeout after "..., 43CRITICAL - Socket
timeout after 10 seconds
) = 43
exit_group(2)                           = ?
+++ exited with 2 +++
```

Hope this makes sense to someone and that there is a proper upstream
issue tracker to forward this problem to. If it gets addressed by
someone, a fix-up for buster would be great (I'd volunteer to test and
handle the SRU for this).

Mike

#965329#10
Date:
2021-12-20 05:10:25 UTC
From:
To:
Hi Mika,

Am 19.07.20 um 18:10 schrieb Mike Gabriel:

I'm not able to reproduce this on Debian 11 and with
monitoring-plugins-standard 2.3.1.

Are you able to test that on your side?

Many thanks, Jan.