[Pkg-nagios-devel] Bug#965329: check_ldaps (and maybe others?) cannot be restricted to IPv4-only checks via -4 cmdline switch

[Mike Gabriel]

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 at 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
-- 

DAS-NETZWERKTEAM
c\o Technik- und Ökologiezentrum Eckernförde
Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde
mobile: +49 (1520) 1976 148
landline: +49 (4351) 850 8940

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabriel at das-netzwerkteam.de, http://das-netzwerkteam.de

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: Digitale PGP-Signatur
URL: <http://alioth-lists.debian.net/pipermail/pkg-nagios-devel/attachments/20200719/ee49eda0/attachment.sig>