Maarten Wiltink wrote: > "Richard B. Gilbert" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] >> Harlan Stenn wrote: >>> In article <[EMAIL PROTECTED]>, "Richard B. > Gilbert" <[EMAIL PROTECTED]> 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 [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
