Hello everybody,

With ntp 4.2.4, I strangely get a very slow display of the ntp -p
billboard. Example:

| $ ntpq -p
|      remote           refid      st t when poll reach   delay   offset  jitter
| ==============================================================================
|  SHM(0)          .DCF.            0 l    -   64    0    0.000    0.000   0.004
| *LOCAL(0)        .LOCL.           8 l   60   64  377    0.000    0.000   0.004

This takes more than a minute to display, line by line. A named querylog
shows that it's due to DNS resolver delays until timeout. It seems that
when showing a refid, ntpq does a DNS A request on the name
"DCF.<localdomain>", gets immediatly a "does not exist" authoritative
answer. Then it does an A request on "DCF" alone, without answer until
timeout. Then only ntpq displays the line and ".DCF." with the added
dots around. The same happens for other refids LOCL, INIT, and such.
However when the refid is an ntp server, it's displayed as dotted quad
immediatly, without delay.

Now I have 2 questions:

 - Why does ntpq request A on refids? I remember the good old reverse
PTR resolution long ago when refids were IPv4s. But why an A?

 - What's broken on my system so that not qualified hostnames are not
considered local (my named forwards those A requests to my provider's
servers)?


Thankfully, Serge.
-- 
Serge point Bets arobase laposte point net

Serge Bets wrote:

> Hello everybody,
> 
> With ntp 4.2.4, I strangely get a very slow display of the ntp -p
> billboard. Example:
> 
> | $ ntpq -p
> |      remote           refid      st t when poll reach   delay   offset  jitter
> | ==============================================================================
> |  SHM(0)          .DCF.            0 l    -   64    0    0.000    0.000   0.004
> | *LOCAL(0)        .LOCL.           8 l   60   64  377    0.000    0.000   0.004
> 
> This takes more than a minute to display, line by line. A named querylog
> shows that it's due to DNS resolver delays until timeout. It seems that
> when showing a refid, ntpq does a DNS A request on the name
> "DCF.<localdomain>", gets immediatly a "does not exist" authoritative
> answer. Then it does an A request on "DCF" alone, without answer until
> timeout. Then only ntpq displays the line and ".DCF." with the added
> dots around. The same happens for other refids LOCL, INIT, and such.
> However when the refid is an ntp server, it's displayed as dotted quad
> immediatly, without delay.
> 
> Now I have 2 questions:
> 
>  - Why does ntpq request A on refids? I remember the good old reverse
> PTR resolution long ago when refids were IPv4s. But why an A?
> 
>  - What's broken on my system so that not qualified hostnames are not
> considered local (my named forwards those A requests to my provider's
> servers)?

Most TCP/IP stacks have a file (/etc/resolv.conf) that contains:
"domain <mydefault domain>"
"nameserver <isp_server1>"
"nameserver <isp_server2>"

The "domain" entry tells your resolver which domain to use if none is 
specified.  If you don't have a domain statement. . . .

HTH

Hello Richard,

 On Friday, January 26, 2007 at 15:22:24 -0500, Richard B. Gilbert wrote:

> Most TCP/IP stacks have a file (/etc/resolv.conf) that contains:
> "domain <mydefault domain>"

First thank you for your quick reply. OK: My /etc/resolv.conf seems
correct, just 2 lines:

| domain	<my-local-domain>
| nameserver	<lan-server-ip>

And it seems to work for other commands: Existing short names are
qualified and resolved immediatly, and non-existing ones get an error.
Only ntpq seems to timeout...

Your suggestion gave me a test idea: ntpq worked fast again when I added
to /etc/hosts:

| 127.0.0.2	DCF
| 127.0.0.3	INIT
| 127.0.0.4	LOCL

But... I imagine this can't be a clean solution! ;-)


Serge.
-- 
Serge point Bets arobase laposte point net

Serge Bets wrote:

> Hello Richard,
> 
>  On Friday, January 26, 2007 at 15:22:24 -0500, Richard B. Gilbert wrote:
> 
> 
>>Most TCP/IP stacks have a file (/etc/resolv.conf) that contains:
>>"domain <mydefault domain>"
> 
> 
> First thank you for your quick reply. OK: My /etc/resolv.conf seems
> correct, just 2 lines:
> 
> | domain	<my-local-domain>
> | nameserver	<lan-server-ip>
> 
> And it seems to work for other commands: Existing short names are
> qualified and resolved immediatly, and non-existing ones get an error.
> Only ntpq seems to timeout...
> 
> Your suggestion gave me a test idea: ntpq worked fast again when I added
> to /etc/hosts:
> 
> | 127.0.0.2	DCF
> | 127.0.0.3	INIT
> | 127.0.0.4	LOCL
> 
> But... I imagine this can't be a clean solution! ;-)
> 
> 
> Serge.

This is beginning to look like a bug!  I'd suggest filing a bug report.
I don't have a link handy but you should be able to find a link to 
"bugzilla" on the NTP web page http://www.ntp.org/

On 2007-01-28, Richard B. Gilbert <rgilbert88@comcast.net> wrote:
>
> This is beginning to look like a bug!  I'd suggest filing a bug report.
> I don't have a link handy but you should be able to find a link to 
> "bugzilla" on the NTP web page http://www.ntp.org/

http://bugs.ntp.isc.org/

-- 
Steve Kostecke <kostecke@ntp.isc.org>
NTP Public Services Project - http://ntp.isc.org/

In article <slrnernp11.pls.serge.bets@laposte.net>,
 Serge Bets <serge.bets@NOSPAM.laposte.invalid> writes:
>Your suggestion gave me a test idea: ntpq worked fast again when I added
>to /etc/hosts:

Did you try ntpq -p -n?

Does that go quickly?  That's what I use always.

Chris

Serge Bets wrote:
> Hello everybody,
> 
> With ntp 4.2.4, I strangely get a very slow display of the ntp -p
> billboard. Example:
> 
> | $ ntpq -p
> |      remote           refid      st t when poll reach   delay   offset  jitter
> | ==============================================================================
> |  SHM(0)          .DCF.            0 l    -   64    0    0.000    0.000   0.004
> | *LOCAL(0)        .LOCL.           8 l   60   64  377    0.000    0.000   0.004
> 
> This takes more than a minute to display, line by line. A named querylog
> shows that it's due to DNS resolver delays until timeout. It seems that
> when showing a refid, ntpq does a DNS A request on the name
> "DCF.<localdomain>", gets immediatly a "does not exist" authoritative
> answer. Then it does an A request on "DCF" alone, without answer until
> timeout. Then only ntpq displays the line and ".DCF." with the added
> dots around. The same happens for other refids LOCL, INIT, and such.
> However when the refid is an ntp server, it's displayed as dotted quad
> immediatly, without delay.
> 

This is wrong and needs to get fixed.

> Now I have 2 questions:
> 
>  - Why does ntpq request A on refids? I remember the good old reverse
> PTR resolution long ago when refids were IPv4s. But why an A?

Are you looking at the wire and seeing these packets? If so please file
a bug report. As you said it shouldn't be attempting DNS lookups for these.

> 
>  - What's broken on my system so that not qualified hostnames are not
> considered local (my named forwards those A requests to my provider's
> servers)?
> 
Fully qualified domain names should always be used to avoid these problems.

What does your named.conf look like? You have to be explicit to request
that it forward zones for lookups. This part really belongs in
bind-users (comp.protocols.dns.bind if you prefer newsgroups).  named
will *not* qualify names and will take whatever it's given. dig doesn't
do that either unless you use the +search option. That's deliberate.

Danny
(Swapping his NTP hat for his BIND hat)
> 
> Thankfully, Serge.

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Hello Chris,

 On Saturday, January 27, 2007 at 22:57:31 -0600, tomnykds@comcast.net wrote:

> Did you try ntpq -p -n?

Also slow, because of exact same DNS A requests on "DCF" and "LOCL"
refid names. Apparently -n disables only the reverse resolution of the
"remote" column:

| $ ntpq -pn
|      remote           refid      st t when poll reach   delay   offset  jitter
| ==============================================================================
| *127.127.28.0    .DCF.            0 l   60   64  377    0.000    0.180   0.144
|  127.127.1.0     .LOCL.           8 l   16   64  377    0.000    0.000   0.004


Serge.
-- 
Serge point Bets arobase laposte point net

Serge Bets wrote:

> Hello Chris,
> 
>  On Saturday, January 27, 2007 at 22:57:31 -0600, tomnykds@comcast.net wrote:
> 
> 
>>Did you try ntpq -p -n?
> 
> 
> Also slow, because of exact same DNS A requests on "DCF" and "LOCL"
> refid names. Apparently -n disables only the reverse resolution of the
> "remote" column:
> 
> | $ ntpq -pn
> |      remote           refid      st t when poll reach   delay   offset  jitter
> | ==============================================================================
> | *127.127.28.0    .DCF.            0 l   60   64  377    0.000    0.180   0.144
> |  127.127.1.0     .LOCL.           8 l   16   64  377    0.000    0.000   0.004
> 
> 
> Serge.

The bug is that ntpq should not be interpreting the refid at all!  It's 
a text string, not an IP address and should not be treated as one.  Yes, 
sometimes the refid IS an IP address but it still should be treated as a 
simple text string!

>>> In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:

Richard> The bug is that ntpq should not be interpreting the refid at all!
Richard> It's a text string, not an IP address and should not be treated as
Richard> one.  Yes, sometimes the refid IS an IP address but it still should
Richard> be treated as a simple text string!

How can the code tell the difference between a refid that is a string and
one that is an IP address?

I want to stop doing this resolution altogether, but the last time I asked
Dave about this he said he wanted to keep the lookup in place, even though
it is only useful for IPv4.

H

Harlan Stenn wrote:
>>>> In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> Richard> The bug is that ntpq should not be interpreting the refid at all!
> Richard> It's a text string, not an IP address and should not be treated as
> Richard> one.  Yes, sometimes the refid IS an IP address but it still should
> Richard> be treated as a simple text string!
> 
> How can the code tell the difference between a refid that is a string and
> one that is an IP address?
> 
> I want to stop doing this resolution altogether, but the last time I asked
> Dave about this he said he wanted to keep the lookup in place, even though
> it is only useful for IPv4.
> 

Let me repeat myself. The refid should *never* be looked up. It's an ID
and not an address. Similarly refclocks themselves should not be looked
up and we should know that. This is a bug plain and simple and it should
 be logged as such.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Harlan,

No; I never said that or you misunderstood me on another matter. The 
ntpq implementer Dennis Fergusson had his reasons for using DNS on 
refclock addresses, but I never asked him about why and have had no 
problem with that on any server over the life of the program. It 
certainly could be a problem should the local DNS be very slow and I 
have no problem should somebody take the trouble to remove the feature. 
There is a macro somewhere that recognizes whether the address is a 
refclock.

Dave

Harlan Stenn wrote:
>>>>In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> 
> Richard> The bug is that ntpq should not be interpreting the refid at all!
> Richard> It's a text string, not an IP address and should not be treated as
> Richard> one.  Yes, sometimes the refid IS an IP address but it still should
> Richard> be treated as a simple text string!
> 
> How can the code tell the difference between a refid that is a string and
> one that is an IP address?
> 
> I want to stop doing this resolution altogether, but the last time I asked
> Dave about this he said he wanted to keep the lookup in place, even though
> it is only useful for IPv4.
> 
> H

Harlan Stenn wrote:

>>>>In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> 
> Richard> The bug is that ntpq should not be interpreting the refid at all!
> Richard> It's a text string, not an IP address and should not be treated as
> Richard> one.  Yes, sometimes the refid IS an IP address but it still should
> Richard> be treated as a simple text string!
> 
> How can the code tell the difference between a refid that is a string and
> one that is an IP address?
> 

ISTR reading something from Dave here to the effect that the REFID was 
NOT an IP address even if it had the form of an IP address.

You should be able to parse the string to see if it does have the proper 
form to be an IP address: D.D.D.D  where D is one to three decimal digits.

Dave,

I did a lot of driving today and I'm pretty tired.

I believe the desired goal is to display the refid field in 2 forms:

- the "string" form in the case of a refclock
- a non-IPv4 format otherwise

The last time I talked to you I recall you said you wanted to keep the IPv4
format because it helped you understand exactly what machine was being
referenced.

This topic is being discussed at:

 http://ntp.isc.org/bin/view/Dev/UpdatingTheRefidFormat

and I believe the issue is now more complicated because we can now specify
an arbitrary stratum for a refclock, which means we can no longer use the
stratum as the means to decide if a refid is the name of a refclock or not.

It should be pretty easy to stop doing DNS lookups on the refid.

It may be more Interesting to do more, as I am no longer sure we can
cleanly decide when a refid refers to a refclock or not.

H

>>> In article <2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:

Richard> You should be able to parse the string to see if it does have the
Richard> proper form to be an IP address: D.D.D.D where D is one to three
Richard> decimal digits.

But I do not believe we get a string in this case.

H

Harlan Stenn wrote:
[]
> I want to stop doing this resolution altogether, but the last time I
> asked Dave about this he said he wanted to keep the lookup in place,
> even though it is only useful for IPv4.
>
> H

Even though this was not Dave's intention, as a user I find it very 
helpful to see what reference IP addresses (with an option to convert to 
names) servers are using one level up.  Perhaps others find it useful as 
well.

David 

"Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message
news:2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com...
> Harlan Stenn wrote:
>> In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d@comcast.com>, "Richard B.
Gilbert" <rgilbert88@comcast.net> writes:

>>> The bug is that ntpq should not be interpreting the refid at all!
>>> It's a text string, not an IP address and should not be treated as
>>> one.  Yes, sometimes the refid IS an IP address but it still should
>>> be treated as a simple text string!
>>
>> How can the code tell the difference between a refid that is a string
>> and one that is an IP address?
>
> ISTR reading something from Dave here to the effect that the REFID was
> NOT an IP address even if it had the form of an IP address.

IIRC, it's either a string (for reference clocks) or a hash (for ipv4/6).
For ipv6, the original address can't be recovered. For ipv4, the hash is
an identity transform and people forget it's not really an address.

Only the upstream server knows how it got that refid. The local host can
but guess. Perhaps tag bits are in order; certainly it's nice for humans
to see hostnames (and refclock names) where applicable and possible.

Groetjes,
Maarten Wiltink

Harlan Stenn wrote:
>>>> In article <2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> Richard> You should be able to parse the string to see if it does have the
> Richard> proper form to be an IP address: D.D.D.D where D is one to three
> Richard> decimal digits.
> 
> But I do not believe we get a string in this case.
> 
> H

It's always a string. This is using the mode 6 protocol.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Harlan Stenn wrote:
> Dave,
> I believe the desired goal is to display the refid field in 2 forms:
> 
> - the "string" form in the case of a refclock
> - a non-IPv4 format otherwise
> 

These are both string formats. There are no non-IPv4 formats.

> The last time I talked to you I recall you said you wanted to keep the IPv4
> format because it helped you understand exactly what machine was being
> referenced.

Nevertheless this is just a string. The only thing that the ntpq code
does is add periods to the beginning and end of a refclock type. We
should never be performing lookups since a refid just looks like an IPv4
address but should not be confused with one.

> 
> This topic is being discussed at:
> 
>  http://ntp.isc.org/bin/view/Dev/UpdatingTheRefidFormat
> 
> and I believe the issue is now more complicated because we can now specify
> an arbitrary stratum for a refclock, which means we can no longer use the
> stratum as the means to decide if a refid is the name of a refclock or not.
> 

The code doesn't do that anyway, it never looks at the stratum before it
tries to interpret the refid. In fact it attempts to do a DNS lookup
first before it tries to decide if it's a refclock, irrespective of the
contents of the refid. See doprintpeers() in ntpq/ntpq-sub.c.

> It should be pretty easy to stop doing DNS lookups on the refid.
> 
> It may be more Interesting to do more, as I am no longer sure we can
> cleanly decide when a refid refers to a refclock or not.
> 

You need to look at the code, but it's very straightforward to decide that.

Note that there's a second issue in that the remote names can also not
be IP addresses and that is what I think you are talking about rather
than the refid.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David J Taylor wrote:
> Harlan Stenn wrote:
> []
>> I want to stop doing this resolution altogether, but the last time I
>> asked Dave about this he said he wanted to keep the lookup in place,
>> even though it is only useful for IPv4.
>>
>> H
> 
> Even though this was not Dave's intention, as a user I find it very 
> helpful to see what reference IP addresses (with an option to convert to 
> names) servers are using one level up.  Perhaps others find it useful as 
> well.
> 
> David 

You can use dig to lookup names from addresses if you really need to
know and since the value of the refid is not necessarily an IPv4 address
it's not something we should be doing anyway.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Maarten Wiltink wrote:
> "Richard B. Gilbert" <rgilbert88@comcast.net> wrote in message
> news:2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com...
>> Harlan Stenn wrote:
>>> In article <0eednfx366oTvCDYnZ2dnUVZ_u-unZ2d@comcast.com>, "Richard B.
> Gilbert" <rgilbert88@comcast.net> writes:
> 
>>>> The bug is that ntpq should not be interpreting the refid at all!
>>>> It's a text string, not an IP address and should not be treated as
>>>> one.  Yes, sometimes the refid IS an IP address but it still should
>>>> be treated as a simple text string!
>>> How can the code tell the difference between a refid that is a string
>>> and one that is an IP address?
>> ISTR reading something from Dave here to the effect that the REFID was
>> NOT an IP address even if it had the form of an IP address.
> 
> IIRC, it's either a string (for reference clocks) or a hash (for ipv4/6).
> For ipv6, the original address can't be recovered. For ipv4, the hash is
> an identity transform and people forget it's not really an address.
> 
> Only the upstream server knows how it got that refid. The local host can
> but guess. Perhaps tag bits are in order; certainly it's nice for humans
> to see hostnames (and refclock names) where applicable and possible.
> 

It only makes sense for refclocks. Otherwise use dig to do lookups if
the refid is really an IPv4 address.

Danny

> Groetjes,
> Maarten Wiltink

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Harlan,

The string comes from a table in ./libntp/clocktypes.c. That table is 
indexed byu the reference clock type number. It is displayed as the 
server name in ntpq. There is no need to look it up. The ntpq program 
can know when to use the string by the 127.127 prefix, which is how the 
ISREFCLK() macro works.

Dave

Harlan Stenn wrote:
>>>>In article <2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> 
> Richard> You should be able to parse the string to see if it does have the
> Richard> proper form to be an IP address: D.D.D.D where D is one to three
> Richard> decimal digits.
> 
> But I do not believe we get a string in this case.
> 
> H

Harlan Stenn wrote:

>>>>In article <2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
> 
> 
> Richard> You should be able to parse the string to see if it does have the
> Richard> proper form to be an IP address: D.D.D.D where D is one to three
> Richard> decimal digits.
> 
> But I do not believe we get a string in this case.
> 
> H


Hmmmmm!!   If you get the refid as a 32 bit binary integer, it's not so 
easy.  But somewhere, somehow, somebody is deciding whether to display 
that as, say, ".WWV."  or "0.87.87.88".

David J Taylor wrote:

> Harlan Stenn wrote:
> []
> 
>>I want to stop doing this resolution altogether, but the last time I
>>asked Dave about this he said he wanted to keep the lookup in place,
>>even though it is only useful for IPv4.
>>
>>H
> 
> 
> Even though this was not Dave's intention, as a user I find it very 
> helpful to see what reference IP addresses (with an option to convert to 
> names) servers are using one level up.  Perhaps others find it useful as 
> well.
> 
> David 
> 
> 

I don't see a problem with that as long as ntpq does not do DNS lookups 
by default.

David L. Mills wrote:
> Harlan,
> 
> The string comes from a table in ./libntp/clocktypes.c. That table is 
> indexed byu the reference clock type number. It is displayed as the 
> server name in ntpq. There is no need to look it up. The ntpq program 
> can know when to use the string by the 127.127 prefix, which is how the 
> ISREFCLK() macro works.
> 
> Dave

It's ISREFCLOCKADR() actually, but that's a quibble.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Harlan Stenn <stenn@ntp.isc.org> wrote:

> Richard> The bug is that ntpq should not be interpreting the refid at all!
> Richard> It's a text string, not an IP address and should not be treated as
> Richard> one.  Yes, sometimes the refid IS an IP address but it still should
> Richard> be treated as a simple text string!
> 
> How can the code tell the difference between a refid that is a string and
> one that is an IP address?
> 
> I want to stop doing this resolution altogether, but the last time I asked
> Dave about this he said he wanted to keep the lookup in place, even though
> it is only useful for IPv4.

I've just tried a test with ntpq 4.2.4 and I do not see this behaviour
of looking up the refid in the DNS for ntpq -p, or ntpq -np.  ntpq -p
does show lookups for the PTRs of the server IPv4 addresses in my host
config and A lookups for the corresponding names.  However I'm running
ntpd 4.2.2 not 4.2.4, so could the refid lookups be in ntpd?

As I read the code of ntpq, the refid string is passed to decodenetnum()
to check if it is a valid IP address, which in turn calls getaddrinfo()
with hints flag AI_NUMERICHOST.  On Solaris the man page for that says

     If the AI_NUMERICHOST bit is set in the ai_flags  member  of
     the hints structure, then a non-null nodename string must be
     a numeric  host  address  string.   Otherwise  an  error  of
     EAI_NONAME is returned.  This flag prevents any type of name
     resolution service (such as DNS) from being called.

I don't think the original poster said what OS he's using, but perhaps
there is a difference here?

-- 
Ronan Flood <usenet@umbral.org.uk>

>>> In article <Tbhvh.2749$9S5.1684@text.news.blueyonder.co.uk>, "David J Taylor" <david-taylor@blueyonder.co.not-this-bit.nor-this-part.uk> writes:

David> Even though this was not Dave's intention, as a user I find it very
David> helpful to see what reference IP addresses (with an option to convert
David> to names) servers are using one level up.  Perhaps others find it
David> useful as well.

Yes, it is useful and it only works for IPv4.

Now that we support IPv6 and given the current refid "mechanism", I am
unaware of a way we can look a a given refid and *know* how to decode it.

H

Harlan Stenn wrote:
>>>> In article <Tbhvh.2749$9S5.1684@text.news.blueyonder.co.uk>,
>>>> "David J Taylor"
>>>> <david-taylor@blueyonder.co.not-this-bit.nor-this-part.uk> writes:
>
> David> Even though this was not Dave's intention, as a user I find it
> very David> helpful to see what reference IP addresses (with an
> option to convert David> to names) servers are using one level up.
> Perhaps others find it David> useful as well.
>
> Yes, it is useful and it only works for IPv4.
>
> Now that we support IPv6 and given the current refid "mechanism", I am
> unaware of a way we can look a a given refid and *know* how to decode
> it.
>
> H

Thanks, Harlan.

It's a pity you don't know that it's IPv4, and therefore can be 
decoded....

Cheers,
David 

Richard,

Yes, you point out the second problem other than the IPv6 problem. The 
string you see usually applies to the local clock, or any other 
reference clock operated at a stratum other than one. Perhaps the most 
elegant solution is for the local clock driver to insert the IPv4 host 
address or IPv6 hash as the reference ID.

Dave

Richard B. Gilbert wrote:

> Harlan Stenn wrote:
> 
>>>>> In article <2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com>, "Richard 
>>>>> B. Gilbert" <rgilbert88@comcast.net> writes:
>>
>>
>>
>> Richard> You should be able to parse the string to see if it does have 
>> the
>> Richard> proper form to be an IP address: D.D.D.D where D is one to three
>> Richard> decimal digits.
>>
>> But I do not believe we get a string in this case.
>>
>> H
> 
> 
> 
> Hmmmmm!!   If you get the refid as a 32 bit binary integer, it's not so 
> easy.  But somewhere, somehow, somebody is deciding whether to display 
> that as, say, ".WWV."  or "0.87.87.88".

Guys,

I think the "decode the refid" problem is just a bit more difficult than we
have been discussing.

My notes on this show that we *used* to be able to decode the refid based on
stratum:

- S0: the refid contains a KOD code
- S1: the refid is the refclock type
- S2+: the refid contains a "token" that IDs the server we are syncing with

and for the S2+ case, if the remote server is giving us an IPv4 address then
the refid is that IPv4 address.

There are now 2 additional complicating matters

- the address can be IPv4 or IPv6, and we do not seem to have a way to
  know which it is

- A refclock can now advertise as being "worse" than S1

We already sometimes have to follow the associd chain - I am wondering if we
may need to do something similar here.

H

Richard B. Gilbert wrote:
> Harlan Stenn wrote:
> 
>>>>> In article <2LGdnbKXL8u5HyDYnZ2dnUVZ_u2mnZ2d@comcast.com>, "Richard B. Gilbert" <rgilbert88@comcast.net> writes:
>>
>> Richard> You should be able to parse the string to see if it does have the
>> Richard> proper form to be an IP address: D.D.D.D where D is one to three
>> Richard> decimal digits.
>>
>> But I do not believe we get a string in this case.
>>
>> H
> 
> 
> Hmmmmm!!   If you get the refid as a 32 bit binary integer, it's not so 
> easy.  But somewhere, somehow, somebody is deciding whether to display 
> that as, say, ".WWV."  or "0.87.87.88".
> 

Yes, ntpq gets a string of the form 127.127.?.? and converts it to that.
It's really that simple.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Ronan Flood wrote:
> Harlan Stenn <stenn@ntp.isc.org> wrote:
> 
>> Richard> The bug is that ntpq should not be interpreting the refid at all!
>> Richard> It's a text string, not an IP address and should not be treated as
>> Richard> one.  Yes, sometimes the refid IS an IP address but it still should
>> Richard> be treated as a simple text string!
>>
>> How can the code tell the difference between a refid that is a string and
>> one that is an IP address?
>>
>> I want to stop doing this resolution altogether, but the last time I asked
>> Dave about this he said he wanted to keep the lookup in place, even though
>> it is only useful for IPv4.
> 
> I've just tried a test with ntpq 4.2.4 and I do not see this behaviour
> of looking up the refid in the DNS for ntpq -p, or ntpq -np.  ntpq -p
> does show lookups for the PTRs of the server IPv4 addresses in my host
> config and A lookups for the corresponding names.  However I'm running
> ntpd 4.2.2 not 4.2.4, so could the refid lookups be in ntpd?
> 
> As I read the code of ntpq, the refid string is passed to decodenetnum()
> to check if it is a valid IP address, which in turn calls getaddrinfo()
> with hints flag AI_NUMERICHOST.  On Solaris the man page for that says
> 
>      If the AI_NUMERICHOST bit is set in the ai_flags  member  of
>      the hints structure, then a non-null nodename string must be
>      a numeric  host  address  string.   Otherwise  an  error  of
>      EAI_NONAME is returned.  This flag prevents any type of name
>      resolution service (such as DNS) from being called.
> 
> I don't think the original poster said what OS he's using, but perhaps
> there is a difference here?
> 

Yes except it tries to call decodenetnum() first before it fails and
falls back to trying to see if it's a refclock or just a string. The
decode call should not be there at all for refid's.

I was a bit off on a previous message. Sometimes the refid value
returned over the wire contains things like "GPS" in which case there is
nothing to interpret. Sometimes it contains the refclock "IPv4 address",
ie 127.127.?.?, and this is then interpreted and converted to a refclock
type.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Ronan Flood wrote:
> Harlan Stenn <stenn@ntp.isc.org> wrote:
> 
> 
>>Richard> The bug is that ntpq should not be interpreting the refid at all!
>>Richard> It's a text string, not an IP address and should not be treated as
>>Richard> one.  Yes, sometimes the refid IS an IP address but it still should
>>Richard> be treated as a simple text string!
>>
>>How can the code tell the difference between a refid that is a string and
>>one that is an IP address?
>>
>>I want to stop doing this resolution altogether, but the last time I asked
>>Dave about this he said he wanted to keep the lookup in place, even though
>>it is only useful for IPv4.
> 
> 
> I've just tried a test with ntpq 4.2.4 and I do not see this behaviour
> of looking up the refid in the DNS for ntpq -p, or ntpq -np.  ntpq -p
> does show lookups for the PTRs of the server IPv4 addresses in my host
> config and A lookups for the corresponding names.  However I'm running
> ntpd 4.2.2 not 4.2.4, so could the refid lookups be in ntpd?
> 

OK. Here's a stupid question. Under what possible circumstances,
with what possible refid, would an A record lookup be meaningful
in the first place? I agree with the (at least one) previous poster
that the IPV4 PTR lookup is often helpful.

-Tom

Tom Smith <smith@alum.mit.edu> wrote:

> OK. Here's a stupid question. Under what possible circumstances,
> with what possible refid, would an A record lookup be meaningful
> in the first place? I agree with the (at least one) previous poster
> that the IPV4 PTR lookup is often helpful.

I'd say it's not meaningful, as when the refid is a "name" it's one
of the refclock names (GPS, MSF, PPS etc).

If the refid is an IPv4 address you could do a PTR lookup, then an
A lookup on the resulting name as a cross check.  That appears to be
what the xntp version of ntpq -p does, but not explicitly; I think
the A lookup is done internally by some library routine.


BTW Danny, your mail to the ntp:questions list isn't showing up in the
newsgroup.


-- 
Ronan Flood <usenet@umbral.org.uk>

Harlan,

Correct your notes.

A KoD packet by definition has leap bits 11 (unsync) and stratum zero 
(unspec) and shows refid a 4-character kiss code (which includes zero as 
a no-op). Note we are talking about the packet on the wire; ntpd maps 
zero on the wire to 16 in the code. In all other cases the packet 
contains the system refid, however that is determined.

If the system peer is a refclock (stratum 0), the system refid is the 
clock refid, which normally is a 4-character string. Some reference 
clock drivers change this on-fly.

If operating in orphan mode and the host is the orphan parent (stratum 
greater than 0), the system refid is the loopback address.

In all other cases the system refid is either the IP4 source address or 
IPv6 source address hash for the system peer; that is, the source from 
which the system variables are inherited.

Be truly advised the purpose of the refid is not for pretty display; the 
purpose is to detect and reject timing loops. A timing loop is defined 
where the other guy is synchronized to me or where both of us are 
synchronized to the same server. Yes, there are some potentially ugly 
consequences where a mixture of IPv4 and IPv6 addresses are in use.

For ntpq the choices are: If the peer shows leap 11 and stratum 0 show 
the refid as kiss code. Otherwise, if stratum 1 show the refid as ASCII 
string. Otherwise, show a dotted quad on the understanding that, if it 
doesn't look like a IPv4 address, it probably isn't.

The most common misinterpretation might be the local clock driver 
operating at elevated stratum. The present rules show an ugly 
dotted-quad string. The local clock driver should change its refid to 
the loopback address.

Dave

Harlan Stenn wrote:
> Guys,
> 
> I think the "decode the refid" problem is just a bit more difficult than we
> have been discussing.
> 
> My notes on this show that we *used* to be able to decode the refid based on
> stratum:
> 
> - S0: the refid contains a KOD code
> - S1: the refid is the refclock type
> - S2+: the refid contains a "token" that IDs the server we are syncing with
> 
> and for the S2+ case, if the remote server is giving us an IPv4 address then
> the refid is that IPv4 address.
> 
> There are now 2 additional complicating matters
> 
> - the address can be IPv4 or IPv6, and we do not seem to have a way to
>   know which it is
> 
> - A refclock can now advertise as being "worse" than S1
> 
> We already sometimes have to follow the associd chain - I am wondering if we
> may need to do something similar here.
> 
> H

>>> In article <epo4ni$iob$1@scrotar.nss.udel.edu>, "David L. Mills" <mills@udel.edu> writes:

David> Be truly advised the purpose of the refid is not for pretty display;
David> the purpose is to detect and reject timing loops. A timing loop is
David> defined where the other guy is synchronized to me or where both of us
David> are synchronized to the same server. Yes, there are some potentially
David> ugly consequences where a mixture of IPv4 and IPv6 addresses are in
David> use.

Fine with me...

David> For ntpq the choices are: If the peer shows leap 11 and stratum 0
David> show the refid as kiss code. Otherwise, if stratum 1 show the refid
David> as ASCII string. Otherwise, show a dotted quad on the understanding
David> that, if it doesn't look like a IPv4 address, it probably isn't.

Dave, so you are OK with me implementing this?  And I would *much* prefer to
lose the dotted quad output (or at least have the output be a display
option) because the dotted quad takes up a lot of room.

David> The most common misinterpretation might be the local clock driver
David> operating at elevated stratum. The present rules show an ugly
David> dotted-quad string. The local clock driver should change its refid to
David> the loopback address.

Do you want to make this change to the driver or should I?

H

David L. Mills wrote:
> Richard,
> 
> Yes, you point out the second problem other than the IPv6 problem. The 
> string you see usually applies to the local clock, or any other 
> reference clock operated at a stratum other than one. Perhaps the most 
> elegant solution is for the local clock driver to insert the IPv4 host 
> address or IPv6 hash as the reference ID.
> 

Which one? This has been one of my discussion issues over the years as
it relates to refids. You can have multiple addresses per NIC and
multiple NICs and then you have IPv4 and multiple IPv6 addresses. Which
do you choose. My answer has been that a system has one and only one
refid for all interfaces, packets, etc whether sent as a unicast
response, a multicast packet or a broadcast packet, none of which should
matter.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Harlan Stenn wrote:
> Guys,
> 
> I think the "decode the refid" problem is just a bit more difficult than we
> have been discussing.
> 
> My notes on this show that we *used* to be able to decode the refid based on
> stratum:
> 
> - S0: the refid contains a KOD code
> - S1: the refid is the refclock type
> - S2+: the refid contains a "token" that IDs the server we are syncing with
> 
> and for the S2+ case, if the remote server is giving us an IPv4 address then
> the refid is that IPv4 address.
> 
> There are now 2 additional complicating matters
> 
> - the address can be IPv4 or IPv6, and we do not seem to have a way to
>   know which it is
> 
> - A refclock can now advertise as being "worse" than S1
> 
> We already sometimes have to follow the associd chain - I am wondering if we
> may need to do something similar here.
> 
> H

Guys, we need to stop this. You are all making wild assumptions about
what gets returned to ntpq and what it does with the data. None of them
are correct. It pays to look at both the data and what ntpq does with it
in the code.

Here for example is the data returned to ntpq with just the -p option
for pogo.udel.edu:

"srcadr=127.127.4.1, srcport=123, dstadr=127.0.0.1, dstport=123, leap=0,
stratum=0, precision=-13, rootdelay=0.000, rootdispersion=1.000,
refid=GPS2, reach=0xff, unreach=0, hmode=3, pmode=4, hpoll=6, ppoll=10,
flash=0x0, keyid=0, ttl=0, off"

What's the refid here? GPS2! What does ntpq -p display?
     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
+SPECTRACOM(1)   .GPS2.           0 l   69   64  377    0.000    0.065
 0.012

Here's a different response data:

"srcadr=209.87.233.53, srcport=123, dstadr=128.4.1.20, dstport=123,
leap=0, stratum=2, precision=-17, rootdelay=1.511,
rootdispersion=24.109, refid=209.87.233.50, reach=0xff, unreach=0,
hmode=3, pmode=4, hpoll=6, ppoll=6, flash=0x1000, keyi"

This time the refid looks like an IPv4 address. This time this is what
you get:

     remote           refid      st t when poll reach   delay   offset
jitter
==============================================================================
 time1.chu.nrc.c 209.87.233.50    2 u   73   64  377   53.945   -0.432
 6.620

So can someone tell me what problem they are trying to solve? It has
nothing to do with refid's which are completely clear.

What the code DOES do and should not do is the following:

a) try and convert the refid into an intenet name for the address, ie a
DNS lookup;
b) if that fails and the length of the refid data is <= 4 assume it's a
refclock code (like GPS) and surrounds it with dots.

It's a) which causes the problem and is completely unnecessary.

Does this make the issue clearer?

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

"Danny Mayer" <mayer@ntp.isc.org> wrote in message
news:45BDF362.802@ntp.isc.org...
> Maarten Wiltink wrote:

>> IIRC, [the refid]'s either a string (for reference clocks) or a hash
>> (for ipv4/6). For ipv6, the original address can't be recovered. For
>> ipv4, the hash is an identity transform and people forget it's not
>> really an address.

BTW, I am assuming here that the refid is communicated as 32 bits.


>> Only the upstream server knows how it got that refid. The local host
>> can but guess. Perhaps tag bits are in order; certainly it's nice
>> for humans to see hostnames (and refclock names) where applicable and
>> possible.
>
> It only makes sense for refclocks. Otherwise use dig to do lookups if
> the refid is really an IPv4 address.

In another post, you pointed to the dig option in case 'you really need
to know'. Of course, if I trust my upstream servers and the people who
put them up, I strictly don't.

I still think it's _nice_ to see hostnames if possible. If humans
reacted as well to IP addresses as to DNS names, you wouldn't have a BIND
hat. Personally, I appreciate the existence of that hat, and that someone
wears it.

Groetjes,
Maarten Wiltink

"Maarten Wiltink" <maarten@kittensandcats.net> wrote in message
news:45c05de2$0$325$e4fe514c@news.xs4all.nl...
>> Maarten Wiltink wrote:

>>> IIRC, [the refid]'s either a string (for reference clocks) or a hash
>>> (for ipv4/6). For ipv6, the original address can't be recovered. For
>>> ipv4, the hash is an identity transform and people forget it's not
>>> really an address.
>
> BTW, I am assuming here that the refid is communicated as 32 bits.

And I just found out that this assumption was wrong; it's a string
after all.

That should make it dead easy to pass information about what the value
in it means, should that discussion ever terminate on such a note.
For loop detection, a unique cookie suffices; it doesn't need to be
human-parseable or self-describing or in fact meaningful at all.

Groetjes,
Maarten Wiltink

mayer@ntp.isc.org (Danny Mayer) wrote:

> What the code DOES do and should not do is the following:
> 
> a) try and convert the refid into an intenet name for the address, ie a
> DNS lookup;
> b) if that fails and the length of the refid data is <= 4 assume it's a
> refclock code (like GPS) and surrounds it with dots.
> 
> It's a) which causes the problem and is completely unnecessary.

But a) shouldn't do that: decodenetnum() calling getaddrinfo() with
AI_NUMERICHOST is effectively just a check that it is a syntactically
valid IP address -- there should be no DNS lookups generated.

The original query seems to have come from someone with a broken OS,
or perhaps using a different version of ntpq.

-- 
Ronan Flood <usenet@umbral.org.uk>

Hi Ronan,

 On Monday, January 29, 2007 at 18:28:59 +0000, Ronan Flood wrote:

> the refid string is passed to decodenetnum() to check if it is a valid
> IP address, which in turn calls getaddrinfo() with hints flag
> AI_NUMERICHOST.

It seems you are right on the track: My system has no getaddrinfo(). So
ntpq 4.2.4 uses its own bundled replacement from libntp/ntp_rfc2553.c,
which doesn't seem to make use of AI_NUMERICHOST. I don't understand
enough those subtilities to be able to confirm it for sure, but this
hypothesis seems to be the favorite by far. Thanks Ronan!


Serge.
-- 
Serge point Bets arobase laposte point net

Hello David,

 On Monday, January 29, 2007 at 7:17:07 +0000, David J Taylor wrote:

> I find it very helpful to see what reference IP addresses (with an
> option to convert to names) servers are using one level up. Perhaps
> others find it useful as well.

As option to convert IPv4 refids to names, try the following patch:
Reverse resolves IPv4s by default, disabled by option -n just like the
"remote" column. Displays nonsense when there is anything vaguely
smelling like IPv6 in the neighborhood.


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
--- ntp-4.2.4/ntpq/ntpq-subs.c	Fri Dec 29 00:02:02 2006
+++ ntp-4.2.4.mod/ntpq/ntpq-subs.c	Mon Jan 22 21:11:41 2007
@@ -1425,7 +1425,7 @@ doprintpeers(
 						    refnumtoa(&dstadr);
 					else
 						dstadr_refid =
-						    stoa(&dstadr);
+						    nntohost(&dstadr);
 				} else if ((int)strlen(value) <= 4) {
 					refid_string[0] = '.';
 					(void) strcpy(&refid_string[1], value);
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


Serge.
-- 
Serge point Bets arobase laposte point net

Serge Bets <serge.bets@NOSPAM.laposte.invalid> wrote:

> It seems you are right on the track: My system has no getaddrinfo(). So
> ntpq 4.2.4 uses its own bundled replacement from libntp/ntp_rfc2553.c,
> which doesn't seem to make use of AI_NUMERICHOST.

Ah, I hadn't spotted that: that is a bug in the ntpq code.
I think it can be fixed in ntp_rfc2553.c/do_nodename(),
something along these lines:

--- ntp_rfc2553.c.orig	Thu Dec 28 12:03:08 2006
+++ ntp_rfc2553.c	Thu Feb  1 11:40:40 2007
@@ -397,6 +397,9 @@
 	 * Look for a name
 	 */
 
+	if (hints && (hints->ai_flags & AI_NUMERICHOST))
+		return (EAI_NONAME);
+
 	errval = DNSlookup_name(nodename, AF_INET, &hp);
 
 	if (hp == NULL) {


There are probably more elegant alternatives ...

-- 
Ronan Flood <usenet@umbral.org.uk>

Maarten Wiltink wrote:
> "Maarten Wiltink" <maarten@kittensandcats.net> wrote in message
> news:45c05de2$0$325$e4fe514c@news.xs4all.nl...
>>> Maarten Wiltink wrote:
>> BTW, I am assuming here that the refid is communicated as 32 bits.
> 
> And I just found out that this assumption was wrong; it's a string
> after all.
> 

Just to be clear here. It's only a string when being returned as a
response an ntpq query that's returned to ntpq in a NTP Mode 6 packet.
The refid that's in an NTP packet as defined by the protocol is still a
32-bit quantity.

Danny

> That should make it dead easy to pass information about what the value
> in it means, should that discussion ever terminate on such a note.
> For loop detection, a unique cookie suffices; it doesn't need to be
> human-parseable or self-describing or in fact meaningful at all.
> 
> Groetjes,
> Maarten Wiltink
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

 On Thursday, February 1, 2007 at 0:34:10 +0100, Serge Bets wrote:

> It seems you are right on the track: My system has no getaddrinfo().
> So ntpq 4.2.4 uses its own bundled replacement from
> libntp/ntp_rfc2553.c, which doesn't seem to make use of
> AI_NUMERICHOST.

Confirmed: libntp/ntp_rfc2553.c:getaddrinfo() calls do_nodename(), which
calls DNSlookup_name(), regardless of AI_NUMERICHOST. To confirm it
experimentaly I made the DNSlookup_name() call conditional. And then
ntpq -p display becomes normally fast, and DNS logs show no more
importune A queries. Problem solved: Bravo Ronan, thank you very much,
and thanks to all contributors. :-)

Next step is to report this to bugzilla, I suppose. Could anyone suggest
a proper fix? Mine works as proof but is probably inapropriate:


= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
--- ntp-4.2.4/libntp/ntp_rfc2553.c	Thu Dec 28 13:03:08 2006
+++ ntp-4.2.4.mod/libntp/ntp_rfc2553.c	Thu Feb  1 14:30:16 2007
@@ -397,7 +397,10 @@ do_nodename(
 	 * Look for a name
 	 */
 
-	errval = DNSlookup_name(nodename, AF_INET, &hp);
+	if ((hints->ai_flags & AI_NUMERICHOST) == 0)
+		errval = DNSlookup_name(nodename, AF_INET, &hp);
+	else
+		errval = EAI_NONAME;	/* ?? */
 
 	if (hp == NULL) {
 		if (errval == TRY_AGAIN || errval == EAI_AGAIN)
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =


Serge.
-- 
Serge point Bets arobase laposte point net

Danny Mayer wrote:
> David J Taylor wrote:
>> Harlan Stenn wrote:
>> []
>>> I want to stop doing this resolution altogether, but the last time I
>>> asked Dave about this he said he wanted to keep the lookup in place,
>>> even though it is only useful for IPv4.
>>>
>>> H
>>
>> Even though this was not Dave's intention, as a user I find it very
>> helpful to see what reference IP addresses (with an option to
>> convert to names) servers are using one level up.  Perhaps others
>> find it useful as well.
>>
>> David
>
> You can use dig to lookup names from addresses if you really need to
> know and since the value of the refid is not necessarily an IPv4
> address it's not something we should be doing anyway.
>
> Danny

Why use two tools when one would do?  Computers should be /reducing/ the 
amount of typing (or whatever), so I would rather see the option as part 
of NTPQ.

David 

I'd love to see discussion on this.

One place to do this would be http//ntp.isc.org/Dev .

H

Ronan Flood wrote:
> Serge Bets <serge.bets@NOSPAM.laposte.invalid> wrote:
> 
>> It seems you are right on the track: My system has no getaddrinfo(). So
>> ntpq 4.2.4 uses its own bundled replacement from libntp/ntp_rfc2553.c,
>> which doesn't seem to make use of AI_NUMERICHOST.
> 
> Ah, I hadn't spotted that: that is a bug in the ntpq code.
> I think it can be fixed in ntp_rfc2553.c/do_nodename(),
> something along these lines:
> 
> --- ntp_rfc2553.c.orig	Thu Dec 28 12:03:08 2006
> +++ ntp_rfc2553.c	Thu Feb  1 11:40:40 2007
> @@ -397,6 +397,9 @@
>  	 * Look for a name
>  	 */
>  
> +	if (hints && (hints->ai_flags & AI_NUMERICHOST))
> +		return (EAI_NONAME);
> +
>  	errval = DNSlookup_name(nodename, AF_INET, &hp);
>  
>  	if (hp == NULL) {
> 
> 
> There are probably more elegant alternatives ...
> 

This does indeed fix a problem in that code. It's not heavily exercised
since most systems are now running newer O/S's which have the
getaddrinfo() function in their libraries. I will get this into the next
release.

Thanks,

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Ronan Flood wrote:
> mayer@ntp.isc.org (Danny Mayer) wrote:
> 
>> What the code DOES do and should not do is the following:
>>
>> a) try and convert the refid into an intenet name for the address, ie a
>> DNS lookup;
>> b) if that fails and the length of the refid data is <= 4 assume it's a
>> refclock code (like GPS) and surrounds it with dots.
>>
>> It's a) which causes the problem and is completely unnecessary.
> 
> But a) shouldn't do that: decodenetnum() calling getaddrinfo() with
> AI_NUMERICHOST is effectively just a check that it is a syntactically
> valid IP address -- there should be no DNS lookups generated.
> 
> The original query seems to have come from someone with a broken OS,
> or perhaps using a different version of ntpq.
> 

Right, but the code is ordered incorrectly in the first place. First
test to see if the string is <= 4 and if so don't bother with a
decodenetnum() call. A  refid as an IPv4 address is always at least 7
characters so you can skip the step if it doesn't have enough
characters. I just fixed this code too.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Serge Bets wrote:
> Hello David,
> 
>  On Monday, January 29, 2007 at 7:17:07 +0000, David J Taylor wrote:
> 
>> I find it very helpful to see what reference IP addresses (with an
>> option to convert to names) servers are using one level up. Perhaps
>> others find it useful as well.
> 
> As option to convert IPv4 refids to names, try the following patch:
> Reverse resolves IPv4s by default, disabled by option -n just like the
> "remote" column. Displays nonsense when there is anything vaguely
> smelling like IPv6 in the neighborhood.
> 
> 
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> --- ntp-4.2.4/ntpq/ntpq-subs.c	Fri Dec 29 00:02:02 2006
> +++ ntp-4.2.4.mod/ntpq/ntpq-subs.c	Mon Jan 22 21:11:41 2007
> @@ -1425,7 +1425,7 @@ doprintpeers(
>  						    refnumtoa(&dstadr);
>  					else
>  						dstadr_refid =
> -						    stoa(&dstadr);
> +						    nntohost(&dstadr);
>  				} else if ((int)strlen(value) <= 4) {
>  					refid_string[0] = '.';
>  					(void) strcpy(&refid_string[1], value);
> = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> 
> 
> Serge.

We are not going to support this as it makes no sense to convert to
names. A refid has no meaning outside its value.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

> names. A refid has no meaning outside its value.

That's empirically clearly not the case.  It might not have a guaranteed
meaning, but it certainly has a useful one, e.g. in terms of helping
people here to diagnose problems after only telling people to run ntpq peers.

Serge Bets wrote:
>  On Thursday, February 1, 2007 at 0:34:10 +0100, Serge Bets wrote:
> 
>> It seems you are right on the track: My system has no getaddrinfo().
>> So ntpq 4.2.4 uses its own bundled replacement from
>> libntp/ntp_rfc2553.c, which doesn't seem to make use of
>> AI_NUMERICHOST.
> 
> Confirmed: libntp/ntp_rfc2553.c:getaddrinfo() calls do_nodename(), which
> calls DNSlookup_name(), regardless of AI_NUMERICHOST. To confirm it
> experimentaly I made the DNSlookup_name() call conditional. And then
> ntpq -p display becomes normally fast, and DNS logs show no more
> importune A queries. Problem solved: Bravo Ronan, thank you very much,
> and thanks to all contributors. :-)
> 
> Next step is to report this to bugzilla, I suppose. Could anyone suggest
> a proper fix? Mine works as proof but is probably inapropriate:
> 

I put a fix into the code which will have to be rolled into the
repository. We do need a bugzilla report.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

David J Taylor wrote:
> Danny Mayer wrote:
>> David J Taylor wrote:
>>> Harlan Stenn wrote:
>>> []
>>>> I want to stop doing this resolution altogether, but the last time I
>>>> asked Dave about this he said he wanted to keep the lookup in place,
>>>> even though it is only useful for IPv4.
>>>>
>>>> H
>>> Even though this was not Dave's intention, as a user I find it very
>>> helpful to see what reference IP addresses (with an option to
>>> convert to names) servers are using one level up.  Perhaps others
>>> find it useful as well.
>>>
>>> David
>> You can use dig to lookup names from addresses if you really need to
>> know and since the value of the refid is not necessarily an IPv4
>> address it's not something we should be doing anyway.
>>
>> Danny
> 
> Why use two tools when one would do?  Computers should be /reducing/ the 
> amount of typing (or whatever), so I would rather see the option as part 
> of NTPQ.
> 
> David 

It's called ntptrace.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny Mayer wrote:
> David J Taylor wrote:
>> Danny Mayer wrote:
>>> David J Taylor wrote:
>>>> Harlan Stenn wrote:
>>>> []
>>>>> I want to stop doing this resolution altogether, but the last
>>>>> time I asked Dave about this he said he wanted to keep the lookup
>>>>> in place, even though it is only useful for IPv4.
>>>>>
>>>>> H
>>>> Even though this was not Dave's intention, as a user I find it very
>>>> helpful to see what reference IP addresses (with an option to
>>>> convert to names) servers are using one level up.  Perhaps others
>>>> find it useful as well.
>>>>
>>>> David
>>> You can use dig to lookup names from addresses if you really need to
>>> know and since the value of the refid is not necessarily an IPv4
>>> address it's not something we should be doing anyway.
>>>
>>> Danny
>>
>> Why use two tools when one would do?  Computers should be /reducing/
>> the amount of typing (or whatever), so I would rather see the option
>> as part of NTPQ.
>>
>> David
>
> It's called ntptrace.
>
> Danny

Thanks, Danny.

Unfortunately, ntptrace.exe does not appear to be in the Meinberg 
distribution.

I did find one from 2003 (V4.1.2 from Terje Mathisen) which still seems to 
work, but it doesn't do the same job - it only shows the single selected 
sync source for a remote server, whereas ntpq lists all sources.

(BTW: there is no need to send me an e-mailed copy of your response.)

Cheers,
David 

Danny Mayer wrote:
> Serge Bets wrote:
>>  On Thursday, February 1, 2007 at 0:34:10 +0100, Serge Bets wrote:
>>
>>> It seems you are right on the track: My system has no getaddrinfo().
>>> So ntpq 4.2.4 uses its own bundled replacement from
>>> libntp/ntp_rfc2553.c, which doesn't seem to make use of
>>> AI_NUMERICHOST.
>>
>> Confirmed: libntp/ntp_rfc2553.c:getaddrinfo() calls do_nodename(),
>> which calls DNSlookup_name(), regardless of AI_NUMERICHOST. To
>> confirm it experimentaly I made the DNSlookup_name() call
>> conditional. And then ntpq -p display becomes normally fast, and DNS
>> logs show no more importune A queries. Problem solved: Bravo Ronan,
>> thank you very much, and thanks to all contributors. :-)
>>
>> Next step is to report this to bugzilla, I suppose. Could anyone
>> suggest a proper fix? Mine works as proof but is probably
>> inapropriate:
>>
>
> I put a fix into the code which will have to be rolled into the
> repository. We do need a bugzilla report.
>
> Danny

I reported slowness with ntpq -p  under certain circumstances quite some 
time back.  Bug number 586?

Cheers,
David 

David Woolley wrote:
>> names. A refid has no meaning outside its value.
> 
> That's empirically clearly not the case.  It might not have a guaranteed
> meaning, but it certainly has a useful one, e.g. in terms of helping
> people here to diagnose problems after only telling people to run ntpq peers.
> 

Then you are in a great deal of trouble trying to analyze problems since
this is emphatically not the case. With computers, especially servers
sporting 2-3 NIC's each refid is going to be different for each NIC and
that's just assuming you are running IPv4. With IPv6 all bets are off
anyway. If you want to diagnose problems use ntptrace. Futhermore we may
be changing the way that refids get created so you will have no clue in
the future what they mean. If you want the source of the server's
information you should make that a request but I don't think it's
possible to implement in ntpq, which is why ntptrace is so useful.

Danny
_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions

Danny,

I don't understand your problem. The reference ID for the server is 
unambiguous. As specified, it is the refetence ID of the reference clock 
(stratum 1) or source (remote) address/hash of the system peer (stratum 
 > 1), however that is determined. It has nothing to do with the 
destination (local) address, whichever NIC is involved. You might be 
concerned about which local address to use as a client, but that is not 
an NTP issue. That's why the Autokey is so picky about knowing which one 
to use before launching the first packet.

Dave

Danny Mayer wrote:

> David L. Mills wrote:
> 
>>Richard,
>>
>>Yes, you point out the second problem other than the IPv6 problem. The 
>>string you see usually applies to the local clock, or any other 
>>reference clock operated at a stratum other than one. Perhaps the most 
>>elegant solution is for the local clock driver to insert the IPv4 host 
>>address or IPv6 hash as the reference ID.
>>
> 
> 
> Which one? This has been one of my discussion issues over the years as
> it relates to refids. You can have multiple addresses per NIC and
> multiple NICs and then you have IPv4 and multiple IPv6 addresses. Which
> do you choose. My answer has been that a system has one and only one
> refid for all interfaces, packets, etc whether sent as a unicast
> response, a multicast packet or a broadcast packet, none of which should
> matter.
> 
> Danny
> _______________________________________________
> questions mailing list
> questions@lists.ntp.isc.org
> https://lists.ntp.isc.org/mailman/listinfo/questions

mills@udel.edu wrote:
> Danny,
> 
> I don't understand your problem. The reference ID for the server is 
> unambiguous.

My problem is that this is not really true or rather that the same
machine can have multiple refid's none of which may be an IPv4 address.
A reference ID may be unique (outside of refclocks which won't be) but
since each machine can have multiple refid's you end up with a situation
where you are not detecting loops which is contrary to the design goal
of refids. We would be far better off having each machine have exactly
one refid. Unfortunately that may not be simple to implement.

 As specified, it is the refetence ID of the reference clock
> (stratum 1) or source (remote) address/hash of the system peer (stratum 
>  > 1), however that is determined. It has nothing to do with the 
> destination (local) address, whichever NIC is involved. You might be 
> concerned about which local address to use as a client, but that is not 
> an NTP issue. That's why the Autokey is so picky about knowing which one 
> to use before launching the first packet.
> 

It's not picking which is the local address to use that I'm concerned
about but that there's more than one to choose from in the first place.

Danny

_______________________________________________
questions mailing list
questions@lists.ntp.isc.org
https://lists.ntp.isc.org/mailman/listinfo/questions