Danny Mayer <[email protected]> wrote: > I misread the original question. The error you are seeing in the log > is the result of attempting to lookup the IP address as if it was a > name. I fixed that issue a long time ago so it you use an IP address > instead of a FQDN it won't try to get the address. So the short > answer is: upgrade.
getaddrinfo() is *supposed* to be able to be given an IP address as the "host" and deal with it accordingly. For example, from the getaddrinfo manpage on my Linux system: node specifies either a numerical network address (for IPv4, numbers-and-dots notation as supported by inet_aton(3); for IPv6, hexadecimal string format as supported by inet_pton(3)), or a network hostname, whose network addresses are looked up and resolved. If hints.ai_flags contains the AI_NUMERICHOST flag then node must be a numerical network address. The AI_NUMERICHOST flag suppresses any potentially lengthy network host address lookups. So, while it may have been expedient to change the ntp code to not call getaddrinfo() with an IP address, the bug was probably not in ntp, but in getaddrinfo. Ostensibly then, if an upgrade of ntp code is precluded, the upgrade the OP might make would be to the platform's getaddrinfo() call :) rick jones -- I don't interest myself in "why". I think more often in terms of "when", sometimes "where"; always "how much." - Joubert these opinions are mine, all mine; HP might not want them anyway... :) feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH... _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
