[collectd] ntpd plugin complaining [hopefully FIXED]

[Florian Forster]

Hi Lubos,

sorry for my slow reply :/

On Tue, Oct 31, 2006 at 07:16:35PM +0100, Lubo?? Stan??k wrote:
> 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.

Though you were a little mystic here, I got the point: We don't pass a
`struct sockaddr_in6' here, but a `struct in6_addr'. Since the first
four bytes of this structure don't match either `AF_INET' or `AF_INET6'
the routine returns with an appropriate error. The compiler did not
catch this, since you need to explicitely cast the `sockaddr_in6' to a
`sockaddr'..

I've written a patch which copies the `in6_addr' into a `sockaddr_in6'
and then passes this, hopefully resolving the problem.

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

`getnameinfo' is defined in RFC2553, named `Basic Socket Interface
Extensions for IPv6', thus such a test is not reasonable. Besides, a
system without IPv6 addresses should still be able to resolve IPv6-
addresses - it's just another QType being set..

> I hope this helps,

It did, thank you very much :) I'll push the changes to the repository
as soon as I've applied your sensors patches :)

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20061101/cf114e83/attachment.pgp