[collectd] ntpd plugin complaining

[Luboš Staněk]

Hi Florian,
I tried to resolve the problem, I cannot let it be wrong.

My findings:

getnameinfo(const struct sockaddr *sa, socklen_t salen, char *host,
size_t hostlen, char *serv, size_t servlen, int flags);

"The getnameinfo() function is used to convert a sockaddr structure to a
pair of host name and service strings. The sockaddr structure sa should
point to either a sockaddr_in or sockaddr_in6 structure (for IPv4 or
IPv6 respectively) that is salen bytes long."

sockaddr_in6 in our case (you check the ntpd's `v6_flag')
struct sockaddr_in6 {
        unsigned short int      sin6_family;    /* AF_INET6 */
        __u16                   sin6_port;      /* Transport layer port # */
        __u32                   sin6_flowinfo;  /* IPv6 flow information */
        struct in6_addr         sin6_addr;      /* IPv6 address */
        __u32                   sin6_scope_id;  /* scope id (new in
RFC2553) */
};

But the ntpd uses in6_addr (you have this structure in info_peer_summary):
struct in6_addr
{
        union
        {
                __u8            u6_addr8[16];
                __u16           u6_addr16[8];
                __u32           u6_addr32[4];
        } in6_u;

When I modified the function parameters to sockaddr_in6, I got
unresolved numeric addresses , ex: ::2f70:726f:632f:3130:3635:342f and
.rrd files. And the famous "ntpd plugin: getnameinfo failed: ai_family
not supported" was a history.
I did not tested it but I am convinced that in case of the working IPV6
only network the unmodified call returns empty peername.


The test should be whether the system supports and works with IPV6 and
only after successful test we should try to resolve the ipv6 address
returned in the ntpd response. In all other case we should use only IPV4.


In the 1) case the ipv6 module is not loaded and /proc/net/if_inet6 does
not exist. The interfaces have no ipv6 addresses.
In the 2) case the ipv6 module is loaded  and /proc/net/if_inet6 exists
but the interfaces have only "Scope:Link" inet6 addresses (except ::1).
The IPV6 working interface should have more than HW address.


I hope this helps,
Lubos


Florian Forster napsal(a):
> On Fri, Oct 27, 2006 at 03:09:25PM +0200, Lubo?? Stan??k wrote:
>>> That'd be my fault, I'm afraid.. Why's that error occuring in your case?
>>> AF_INET6 should be supported by pretty much all operating systems now -
>>> even that evil one ;)
> 
>> Everything I cannot handle is evil. :)
> 
> I smell yet another proof for the evilness of women.. *smirk*
> 
>> 1) The system is configured for only IPV4, module ipv6 is disabled.
>> /etc/modprobe.conf - alias net-pf-10 off
>> /ets/sysconfig/network-scripts/ifcfg-<interface> - IPV6INIT=no
>> Module ipv6 is not loaded.
>> ntpd does not listen on ::#123.
>> Every 10 seconds collectd[*]: ntpd plugin: getnameinfo failed: ai_family
>> not supported.
> 
> That is surprising, because `getnameinfo' is only ever called if one of
> ntpd's peers has the `v6_flag' set. However, no explicit address family
> is passed to `getnameinfo', but it examines the `struct sockaddr', which
> is provided by the NTP-daemon.
> 
>> Oct 27 14:56:03 ls collectd[23815]: rrd_update failed:
>>   ntpd/time_offset-0.0.0.0.rrd: illegal attempt to update using time
>>   1161953762 when last update time is 1161953762 (minimum one second
>>   step)
> 
> The problem here appears to be, that the peer could not be resolved. At
> least it's not normal, that the IP-address 0.0.0.0 is being used.
> 
> All in all I have the suspicion that your ntpd is returning funky data.
> Could you tell me which version you're using and if the following
> command works:
>   ntpdc -c peers localhost
> 
> Regards,
> -octo