Harlan Stenn <[EMAIL PROTECTED]> wrote:
> > and possibly also an oversight in refclock_shm not checking that
> > it has a sensible precision value before passing it upwards.
>
> Please open an issue at bugs.ntp.isc.org for the ntp product and the
> "refclock_shm" component if you believe this is a bug.
I don't think it's a bug as such: precision is a signed number
so values >= 0 are valid, I'm just not sure they're sensible;
especially in the light of the behaviour seen here.
> > This also exposes a long-standing bug in ntpq.c\decodeint(), where
>
> Please open an issue at bugs.ntp.isc.org for the NTP product and the
> "other" component for this.
Righto.
--
Ronan Flood <[EMAIL PROTECTED]>
working for but not speaking for
Network Services, University of London Computer Centre
(which means: don't bother ULCC if I've said something you don't like)
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.isc.org/mailman/listinfo/questions
