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 [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
