[From nobody Wed Nov 4 16:05:04 2026 Received: (at submit) by bugs.debian.org; 19 Jul 2020 16:10:35 +0000 X-Spam-Checker-Version: SpamAssassin 3.4.2-bugs.debian.org_2005_01_02 (2018-09-13) on buxtehude.debian.org X-Spam-Level: X-Spam-Status: No, score=-20.9 required=4.0 tests=BAYES_00, FOURLA, HAS_PACKAGE, PGPSIGNATURE,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP, WORD_WITHOUT_VOWELS autolearn=ham autolearn_force=no version=3.4.2-bugs.debian.org_2005_01_02 X-Spam-Bayes: score:0.0000 Tokens: new, 36; hammy, 150; neutral, 289; spammy, 0. spammytokens: hammytokens:0.000-+--H*ct:application, 0.000-+--H*ct:protocol, 0.000-+--H*ct:micalg, 0.000-+--H*ct:signed, 0.000-+--H*ct:pgp-signature Return-path: <mike.gabriel@das-netzwerkteam.de> Received: from fregna.das-netzwerkteam.de ([148.251.53.130]:51554) by buxtehude.debian.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <mike.gabriel@das-netzwerkteam.de>) id 1jxBtb-0005Kk-GJ for submit@bugs.debian.org; Sun, 19 Jul 2020 16:10:35 +0000 Received: from grimnir.das-netzwerkteam.de (grimnir.das-netzwerkteam.de [IPv6:2a01:4f8:202:1381::105]) by fregna.das-netzwerkteam.de (Postfix) with ESMTPS id 7201460330 for <submit@bugs.debian.org>; Sun, 19 Jul 2020 16:10:29 +0000 (UTC) Received: from das-netzwerkteam.de (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id 5EFC7C0167 for <submit@bugs.debian.org>; Sun, 19 Jul 2020 18:10:29 +0200 (CEST) Received: from [2001:470:6aa7:1f::b] ([2001:470:6aa7:1f::b]) by mail.das-netzwerkteam.de (Horde Framework) with HTTPS; Sun, 19 Jul 2020 16:10:29 +0000 Date: Sun, 19 Jul 2020 16:10:29 +0000 Message-ID: <20200719161029.Horde.cTRcF5e1wqrYPiQkHfFQDUP@mail.das-netzwerkteam.de> From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de> To: submit@bugs.debian.org Subject: check_ldaps (and maybe others?) cannot be restricted to IPv4-only checks via -4 cmdline switch User-Agent: Horde Application Framework 5 Accept-Language: de,en Organization: DAS-NETZWERKTEAM X-Originating-IP: 2001:470:6aa7:1f::b X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Content-Type: multipart/signed; boundary="=_KfP10WhT1KIWeWkHSFY3F7I"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Delivered-To: submit@bugs.debian.org This message is in MIME format and has been PGP signed. --=_KfP10WhT1KIWeWkHSFY3F7I Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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=20=20 IPv6=20and IPv4 connectivity separately. The LDAP hosts IPv6 setup is=20=20 still=20buggy after its migration and the Icinga2 host for now gets=20=20 blocked=20by the providers firewall and cannot reach the the LDAP=20=20 server's=20IPv6 address (like a fw DROP or a routing problem). (I filed=20= =20 a=20ticket 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=20= =20 timeout=20for 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=3Dmy,dc=3Ddomain -H ldap-server-x-on.my.domain -= p636 I expect that the check happens on IPv4 only and IPv6 checking is=20=20 totally=20omitted. The check does not work. It hangs and gives a "CRITICAL - Socket=20=20 timeout=20after 10 seconds" Running this with strace -f reveals that the check is _NOT_ being done=20= =20 on=20the IPv4 addresses, but via the IPv6 addresses. This is not what I=20= =20 told=20the command to do via command line switch "-4". Stracing the command call... ``` (root@icinga-host) {~} # strace -f /usr/lib/nagios/plugins/check_ldaps=20= =20 -4=20-3 -b dc=3Dmy,dc=3Ddomain -H ldap-server-x-on.my.domain -p636 [...] recvmsg(3, {msg_name=3D{sa_family=3DAF_NETLINK, nl_pid=3D0,=20=20 nl_groups=3D00000000}, msg_namelen=3D12, msg_iov=3D[{iov_base=3D{{len=3D20,= =20=20 type=3DNLMSG_DONE, flags=3DNLM_F_MULTI, seq=3D1595174041, pid=3D24211}, 0},= =20=20 iov_len=3D4096}], msg_iovlen=3D1, msg_controllen=3D0, msg_flags=3D0}, 0) = =3D 20 close(3) =3D 0 socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) =3D 3 connect(3, {sa_family=3DAF_INET, sin_port=3Dhtons(636),=20=20 sin_addr=3Dinet_addr("1.2.3.4")}, 16) =3D 0 getsockname(3, {sa_family=3DAF_INET, sin_port=3Dhtons(49266),=20=20 sin_addr=3Dinet_addr("5.6.7.8")}, [28->16]) =3D 0 close(3) =3D 0 socket(AF_INET6, SOCK_DGRAM|SOCK_CLOEXEC, IPPROTO_IP) =3D 3 connect(3, {sa_family=3DAF_INET6, sin6_port=3Dhtons(636),=20=20 inet_pton(AF_INET6,=20"2a01:xxxx::101", &sin6_addr),=20=20 sin6_flowinfo=3Dhtonl(0), sin6_scope_id=3D0}, 28) =3D 0 getsockname(3, {sa_family=3DAF_INET6, sin6_port=3Dhtons(44501),=20=20 inet_pton(AF_INET6,=20"2001:xxxx::2", &sin6_addr),=20=20 sin6_flowinfo=3Dhtonl(0), sin6_scope_id=3D0}, [28]) =3D 0 close(3) =3D 0 socket(AF_INET6, SOCK_STREAM, IPPROTO_IP) =3D 3 fcntl(3, F_SETFD, FD_CLOEXEC) =3D 0 setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) =3D 0 setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) =3D 0 vvvvvvvvvvvvvvvvvvvv connect(3, {sa_family=3DAF_INET6, sin6_port=3Dhtons(636),=20=20 inet_pton(AF_INET6,=20"2a01:xxxx::101", &sin6_addr),=20=20 sin6_flowinfo=3Dhtonl(0), sin6_scope_id=3D0}, 28) =3D ? ERESTARTSYS (To be= =20=20 restarted=20if SA_RESTART is set) --- SIGALRM {si_signo=3DSIGALRM, si_code=3DSI_KERNEL} --- ^^^^^^^^^^^^^^^^^^^^ WTF??? Why IPv6 here...? openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) =3D = 4 fstat(4, {st_mode=3DS_IFREG|0644, st_size=3D2995, ...}) =3D 0 read(4, "# Locale name alias data base.\n#"..., 4096) =3D 2995 read(4, "", 4096) =3D 0 close(4) =3D 0 openat(AT_FDCWD,=20=20 "/usr/share/locale/en_US/LC_MESSAGES/monitoring-plugins.mo",=20O_RDONLY)=20= =20 =3D -1 ENOENT (No such file or directory) openat(AT_FDCWD,=20=20 "/usr/share/locale/en/LC_MESSAGES/monitoring-plugins.mo",=20O_RDONLY) =3D= =20=20 -1=20ENOENT (No such file or directory) fstat(1, {st_mode=3DS_IFCHR|0620, st_rdev=3Dmakedev(0x88, 0x3), ...}) =3D 0 write(1, "CRITICAL - Socket timeout after "..., 43CRITICAL - Socket=20=20 timeout=20after 10 seconds ) =3D 43 exit_group(2) =3D ? +++ exited with 2 +++ ``` Hope this makes sense to someone and that there is a proper upstream=20=20 issue=20tracker to forward this problem to. If it gets addressed by=20=20 someone,=20a fix-up for buster would be great (I'd volunteer to test and=20= =20 handle=20the SRU for this). Mike --=20 DAS-NETZWERKTEAM c\o=20Technik- und =C3=96kologiezentrum Eckernf=C3=B6rde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernf=C3=B6rde 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@das-netzwerkteam.de, http://das-netzwerkteam.de --=_KfP10WhT1KIWeWkHSFY3F7I Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCgAdFiEEm/uu6GwKpf+/IgeCmvRrMCV3GzEFAl8UcHMACgkQmvRrMCV3 GzGU4hAAsWv/e1ieE2Lkk3TuYxqMNK/7pkrQsUgrD5wBDPsYXJBPj8w5KACWn8ak 0qwnYcydCD8EMPT60zw0OhcqTBwY13UXnXbb9W6qWStD9K0lVr/DeNUCcValEnCp 5xhBIfNFFK93jIilOzZrStg5UY2iiOzSlxGBrIbU1EOWfI5oqiuImf241/8tuAFC sNU7CTuLVCxjz0e1f4Vg83rxsWrYRQEWafekvsEFPSnxclKI/TwEcRbAe2+lfU6k VihqHtB4qPRnHeKClDPf66zVoZ7CPkAScgmFirYzYgwCQjv80v+0OjMIDFalpFV+ qVUhtKR4SIxcUlDiu/Tmju77wQ1vZGghmNaq1ObMoWDuSx1vbB/gWNUs0yPH7k7Y aQNXK4lAaG+Tm/5WovfEp+gusNC3EJHVTGH3RFwQw+UHfJSjvnrInSs/fepUkixn 5aFJWLGpzM7Al6OCOq+7m5f4He7+IDhfJLX7ysA1MjILHq80kmN1+/JB1YQJUQj8 Ja7i4QKy2ALVsmV/YdepQoGLKCyVr8t/dHTmN+nsOHXZx/ZrEiqHmvbtGbvSCrKP 3ZxWSg+WbmltJVByxl+ecAeZNSoBZprQVd6mysc96ZmyiPGhwefI/UXMGyzh/ER3 pSV9BIe31Q/DruJTj0lLk3lBZAYkUghVarGGOqp83Ovj14T+WDE= =unJ6 -----END PGP SIGNATURE----- --=_KfP10WhT1KIWeWkHSFY3F7I-- ]