On 6/17/2011 12:24 PM, Rick Jones wrote: > 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 :)
You need to know that it's a numeric address before you call getaddrinfo(). Previously we were not checking and it was actually doing the lookup. That was the bug. For the purpose of the code in question it was not necessary to make the call at all so we now skip the call altogether. Danny _______________________________________________ questions mailing list [email protected] http://lists.ntp.org/listinfo/questions
