ntp client ipv6 support
Atul Gupta
I am using ntp package ntp-4.2.4.tar.gz
I want to run ntp client in multicast client mode and i added following line
in ntp.conf file :-
*multicastclient ff05::101*
But it seems there is no multicast socket opened on 123.
ntp logs show following :-
*addto_syslog: getaddrinfo: "ff05::101" invalid host address, ignored
getaddrinfo: "ff05::101" invalid host address, ignored.*
Please help!!!
Thanks & Regards,
Atul.
Steve Kostecke
> I am using ntp package ntp-4.2.4.tar.gz
This release is older than you think.
The current stable is ntp-4.2.6p3
ntp-4.2.4 == NTP-4 v2.4
ntp-4.2.6p3 == NTP-4 v2.6.3
> I want to run ntp client
There is no "ntp client". Either you're using ntpd, sntp, or ntpdate.
> in multicast client mode and i added following line
> in ntp.conf file :-
>
> *multicastclient ff05::101*
>
> But it seems there is no multicast socket opened on 123.
> ntp logs show following :-
>
> *addto_syslog: getaddrinfo: "ff05::101" invalid host address, ignored
> getaddrinfo: "ff05::101" invalid host address, ignored.*
Please try using the current stable release. It may be downloaded from
http://www.ntp.org/downloads.html or http://support.ntp.org/download
Also make sure that your IPv6 networking is configured correctly.
--
Steve Kostecke <kost...@ntp.org>
NTP Public Services Project - http://support.ntp.org/
Atul Gupta
Thanks for your response.
Its difficult for me to move to ntp-4.2.6p3.
Does ntp-4.2.4 doesn't support ipv6 ? I have seen the release notes and it
says that it does support.
Do i need to configure with some option to enable ipv6 multicast support?
Thanks,
Atul.
> _______________________________________________
> questions mailing list
> ques...@lists.ntp.org
> http://lists.ntp.org/listinfo/questions
>
Danny Mayer
> Hi Steve,
> Thanks for your response.
> Its difficult for me to move to ntp-4.2.6p3.
> Does ntp-4.2.4 doesn't support ipv6 ? I have seen the release notes and it
> says that it does support.
> Do i need to configure with some option to enable ipv6 multicast support?
>
NTP needs nothing to support IPv6, it's done so for many years. Your O/S
may. What O/S and version are you using?
What's your difficulty with upgrading NTP?
There was at one point a problem in NTP with multicast on some O/S's but
that was fixed a long time ago. We regularly use multicastclient
FF05::101 on the servers at UDel and elsewhere so it's not the current
version of NTP that's the problem. Move to the latest released version
to test that.
Danny
Rick Jones
various implementations of getaddrinfo(), necessitating some kludges
in netperf to work-around them. It might be worthwhile to write a
little test program that calls getaddrinfo() in a manner similar to
ntp, and call getaddrinfo with several different flavors of IPv6
address.
rick jones
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Danny Mayer
> On 6/15/2011 10:16 PM, Atul Gupta wrote:
>> Hi Steve,
>> Thanks for your response.
>> Its difficult for me to move to ntp-4.2.6p3.
>> Does ntp-4.2.4 doesn't support ipv6 ? I have seen the release notes and it
>> says that it does support.
>> Do i need to configure with some option to enable ipv6 multicast support?
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.
Danny
Rick Jones
> 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...
Danny Mayer
> Danny Mayer <ma...@ntp.org> 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
Rick Jones
> You need to know that it's a numeric address before you call
> getaddrinfo().
Really? Is that for IPv6 specifically, or IP generally?
Netperf has been passing IPs to getaddrinfo() without setting any
special flags.
rick jones
--
Process shall set you free from the need for rational thought.
E-Mail Sent to this address will be added to the BlackLists
> Danny Mayer <ma...@ntp.org> wrote:
>> You need to know that it's a numeric address before you
>> call getaddrinfo().
>
> Really? Is that for IPv6 specifically, or IP generally?
>
> Netperf has been passing IPs to getaddrinfo() without
> setting any special flags.
Perhaps related to multiple returns with the AI_ALL flag?
vs AI_NUMERICHOST flag?
<http://www.rfc-editor.org/rfc/rfc3493.txt>
{in the page 22 -25 range}
--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.
E-Mail Sent to this address will be added to the BlackLists
> Rick Jones wrote:
>> Danny Mayer <ma...@ntp.org> wrote:
>>> You need to know that it's a numeric address before you
>>> call getaddrinfo().
>>
>> Really? Is that for IPv6 specifically, or IP generally?
>>
>> Netperf has been passing IPs to getaddrinfo() without
>> setting any special flags.
>
> {in the page 22 -25 range}
I'm guessing this is it?
<http://ntp.bkbits.net:8080/ntp-dev/?PAGE=patch&REV=433e1854taAmL8-VD-LqZE0jPYNKyw>
Rick Jones
> BlackLists wrote:
> > Rick Jones wrote:
> >> Danny Mayer <ma...@ntp.org> wrote:
> >>> You need to know that it's a numeric address before you
> >>> call getaddrinfo().
> >>
> >> Really? Is that for IPv6 specifically, or IP generally?
> >>
> >> Netperf has been passing IPs to getaddrinfo() without
> >> setting any special flags.
> >
> > <http://www.rfc-editor.org/rfc/rfc3493.txt>
> > {in the page 22 -25 range}
> I'm guessing this is it?
> <http://ntp.bkbits.net:8080/ntp-dev/?PAGE=patch&REV=433e1854taAmL8-VD-LqZE0jPYNKyw>
That looks like a replacement getaddrinfo() implementation?
rick jones
--
the road to hell is paved with business decisions...
Chuck Swiger
> Danny Mayer <ma...@ntp.org> wrote:
>> You need to know that it's a numeric address before you call
>> getaddrinfo().
>
> Really? Is that for IPv6 specifically, or IP generally?
>
> Netperf has been passing IPs to getaddrinfo() without setting any special flags.
Maybe there are broken implementations of getaddrinfo() floating around?
The ones I'm familiar with seem to accept either a hostname or numeric IPv4 or IPv6 addresses.
Regards,
--
-Chuck
John Hasler
> Netperf has been passing IPs to getaddrinfo() without setting any
> special flags.
Chuck Swiger writes:
> Maybe there are broken implementations of getaddrinfo() floating
> around?
On Linux you must set a flag to tell it not to consider the possibility
that what you are passing it is not a numeric address:
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.
CONFORMING TO
POSIX.1-2001. The getaddrinfo() function is documented in RFC 2553.
--
John Hasler
jha...@newsguy.com
Dancing Horse Hill
Elmwood, WI USA
Rick Jones
I may be parsing your sentence incorrectly, but my reading of the
manpage is that one may set AI_NUMERICHOST, in which case node must be
an IP address, but that is not the same thing as saying that if node
is an IP address that AI_NUMERICHOST must be set.
John Hasler
> I may be parsing your sentence incorrectly...
You are.
> ...but my reading of the manpage is that one may set AI_NUMERICHOST,
> in which case node must be an IP address, but that is not the same
> thing as saying that if node is an IP address that AI_NUMERICHOST must
> be set.
If you set the flag node must be an IP number. If you don't set it
getaddrinfo() will figure out for itself what node is (which, IMHO,
makes getaddrinfo() too clever by half). Note that there seems to be no
flag to assert that node is a hostname.
Danny Mayer
> Danny Mayer <ma...@ntp.org> wrote:
>> You need to know that it's a numeric address before you call
>> getaddrinfo().
>
> Really? Is that for IPv6 specifically, or IP generally?
>
> Netperf has been passing IPs to getaddrinfo() without setting any
> special flags.
I seem to recall that there was an issue with IP addresses and
getaddrinfo() on some platforms when you don't specify anything in
hints. I'd have to search bugzilla to find that.
Danny
Danny Mayer
BlackLists wrote:
> BlackLists wrote:
>> Rick Jones wrote:
>>> Danny Mayer <ma...@ntp.org> wrote:
>>>> You need to know that it's a numeric address before you
>>>> call getaddrinfo().
>>>
>>> Really? Is that for IPv6 specifically, or IP generally?
>>>
>>> Netperf has been passing IPs to getaddrinfo() without
>>> setting any special flags.
>>
>> <http://www.rfc-editor.org/rfc/rfc3493.txt>
>> {in the page 22 -25 range}
>
> I'm guessing this is it?
> <http://ntp.bkbits.net:8080/ntp-dev/?PAGE=patch&REV=433e1854taAmL8-VD-LqZE0jPYNKyw>
>
No, that's an emulation piece. It's elsewhere. ntpd/ntp_config.c from
the look of it.
Danny
Majdi S. Abbas
> Over the years, netperf has encountered a number of "funnies" in
> various implementations of getaddrinfo(), necessitating some kludges
> in netperf to work-around them. It might be worthwhile to write a
> little test program that calls getaddrinfo() in a manner similar to
> ntp, and call getaddrinfo with several different flavors of IPv6
> address.
This.
There's at least a couple of bugs in glibc that result
in getaddrinfo() returning something it shouldn't.
NTP itself should be fine; I've run it on dual stack machines
for several years now. I've even run it on machines without IPv4
addresses, although they still had family IN compiled in.
The ntp rev in question is old but it should work provided the
underlying host does.
--msa
Danny Mayer
> John Hasler <jha...@newsguy.com> wrote:
>> Rick Jones wrote:
>>> Netperf has been passing IPs to getaddrinfo() without setting any
>>> special flags.
>
>> Chuck Swiger writes:
>>> Maybe there are broken implementations of getaddrinfo() floating
>>> around?
>
>> On Linux you must set a flag to tell it not to consider the possibility
>> that what you are passing it is not a numeric address:
>
>> 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.
>
>> CONFORMING TO
>> POSIX.1-2001. The getaddrinfo() function is documented in RFC 2553.
>
> I may be parsing your sentence incorrectly, but my reading of the
> manpage is that one may set AI_NUMERICHOST, in which case node must be
> an IP address, but that is not the same thing as saying that if node
> is an IP address that AI_NUMERICHOST must be set.
I think you are misreading it. As I recall, if you don't provide it with
hints, it defaults and does a lookup on the string provided. You have to
set the AI_NUMERICHOST to prevent that.
Can you look at HP's source code for getaddrinfo() on various platforms
and see what it does? I did look at this in considerable detail at the
time that I was working on this one. I don't however remember a lot of
the details.
Danny
Danny Mayer
> Rick Jones wrote:
>> I may be parsing your sentence incorrectly...
>
> You are.
>
>> ...but my reading of the manpage is that one may set AI_NUMERICHOST,
>> in which case node must be an IP address, but that is not the same
>> thing as saying that if node is an IP address that AI_NUMERICHOST must
>> be set.
>
> If you set the flag node must be an IP number. If you don't set it
> getaddrinfo() will figure out for itself what node is (which, IMHO,
> makes getaddrinfo() too clever by half). Note that there seems to be no
> flag to assert that node is a hostname.
The fact that this issue came up at all indicates that getaddrinfo() is
not doing this on at least some platforms. The rest of the discussion is
just that. We fixed the problem to avoid the issue.
Danny
Rick Jones
> Can you look at HP's source code for getaddrinfo() on various
> platforms and see what it does? I did look at this in considerable
> detail at the time that I was working on this one. I don't however
> remember a lot of the details.
I don't have access to HP-UX source these days, sorry.
rick jones
--
I don't interest myself in "why". I think more often in terms of
"when", sometimes "where"; always "how much." - Joubert