[ntp:questions] nptq -p slowness

Danny Mayer mayer at ntp.isc.org
Tue Jan 30 02:43:21 UTC 2007


Ronan Flood wrote:
> Harlan Stenn <stenn at 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



More information about the questions mailing list