[Nagiosplug-devel] [ nagiosplug-Bugs-3031365 ] check_ntp_time picks IPv6 address when no IPv6 is available

SourceForge.net noreply at sourceforge.net
Wed Jul 21 23:34:44 CEST 2010


Bugs item #3031365, was opened at 2010-07-19 01:22
Message generated for change (Comment added) made by tarvin
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3031365&group_id=29880

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: General plugin execution
Group: v1.4.14
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Troels Arvin (tarvin)
Assigned to: Nobody/Anonymous (nobody)
Summary: check_ntp_time picks IPv6 address when no IPv6 is available

Initial Comment:
Example:
$ check_ntp_time -H ns.tele.dk
Address family not supported by protocol
can not create new socket

ns.tele.dk has two A records:
ns.tele.dk.		85584	IN	AAAA	2001:6c8:2:100::53
ns.tele.dk.		15704	IN	A	193.162.159.194

The server where check_ntp_time is run on has no IPv6 address.

Now,
$ check_ntp_time -H 193.162.159.194
NTP OK: Offset 5.13792038e-05 secs|offset=0.000051s;60.000000;120.000000;

In other words: If I hardcode the IP-address to check, and choose an IPv4 address, things work. But if I leave it up to check_ntp_time to choose among the available A records, it chooses the IPv6 one, even though the server being run from doesn't have any IPv6 address.

Other apps on the server seem to be better at choosing the IPv4 address when there is a choice between IPv4 and IPv6. Example:
The ftp.sunet.se site has both an IPv4 (194.71.11.69) and an IPv6 address (2001:6b0:19::64); and it responds to both FTP and HTTP. Both "elinks" and "curl" pick the right (IPv4) address when accessing ftp.sunet.se, using either protocol; e.g.:
$ curl -v --head http://ftp.sunet.se
* About to connect() to ftp.sunet.se port 80
*   Trying 194.71.11.69... connected
* Connected to ftp.sunet.se (194.71.11.69) port 80
> HEAD / HTTP/1.1
> User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
> Host: ftp.sunet.se
> Accept: */*
> 
< HTTP/1.1 200 OK
HTTP/1.1 200 OK
< Date: Sun, 18 Jul 2010 23:20:38 GMT
Date: Sun, 18 Jul 2010 23:20:38 GMT
< Server: Apache/2.2.14 (Unix)
Server: Apache/2.2.14 (Unix)
< Accept-Ranges: bytes
Accept-Ranges: bytes
< Content-Type: text/html
Content-Type: text/html

* Connection #0 to host ftp.sunet.se left intact
* Closing connection #0

----------------------------------------------------------------------

>Comment By: Troels Arvin (tarvin)
Date: 2010-07-21 23:34

Message:
By the way: I have observed this problem on Red Hat Enterprise Linux 5.5
and Fedora Linux 13.

----------------------------------------------------------------------

Comment By: Troels Arvin (tarvin)
Date: 2010-07-21 22:23

Message:
Thomas:
check_ntp_time doesn't call my system's ntpdate. check_ntp_time is a
binary - not a script. And it only links to the most basic libraries (i.e.:
it doesn't link to any NTP-related libraries).
The code for the plugin:
http://nagiosplug.git.sourceforge.net/git/gitweb.cgi?p=nagiosplug/nagiosplug;a=blob;f=plugins/check_ntp_time.c

----------------------------------------------------------------------

Comment By: Thomas Gelf (thomas_gelf)
Date: 2010-07-21 18:32

Message:
Hi Troels,

I stumbled over your bug report - and I guess your ntpdate is the one
to blame for this. What ntpdate version are you currently using? It
seems that this issue has been fixed somewhere by mid-2009. Before
this those tools just checked whether you have IPv6 support - right
now they also verify whether your IPv6-Connectivity will work.

As a workaround you can pass "-4" as an additional parameter to your
call to check_ntp_time, that should help. I'd therefore suggest to
close this bug report - check_ntp_time is IMO not the right place to
fix this.

Regards,
Thomas Gelf

NB: If I'm wrong please feel free to correct me! As this is the very
    first time I ever gave a closer look to a a Nagios component, you
    shouldn't trust my words at all ;-)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=397597&aid=3031365&group_id=29880




More information about the Devel mailing list