<phr...@gmail.com> wrote in message news:bef5f066-1c61-4ff4-8cc0-c0cfad9ec...@n33g2000pri.googlegroups.com... [...] > So other than using ntptrace to see if the refclock is reported as an > upstream server (an unlikely stratum 0) or something else, there's > really no way to know what the heck it is in reality. I can't say > that idea gives me a warm, fuzzy feeling.
And you are totally right. Trust is hard on the Internet. It is often best established out-of-band. Ntptrace can help, though. > Correct me if I'm wrong, but > my non-caffeinated brain is telling me someone driven by a budget > could set up a server using nothing but it's LCL clock as a source but > fudge the ID to be something else. On an isolated network, there'd be > no way to detect this (assuming for this academic argument you don't > wear a reasonably accurate watch). I can imagine a group of such > servers peering with each other endlessly hunting around themselves. Again, you're completely right. (You were already told you look decidedly non-stupid, right?) However, if you're caught in such an isolated network, you're probably close enough that (a) you _can_ detect your situation, and (b) you know who to walk up to and throw The Book[0] at. > If ntpd came with a "fixStupidNtpConf.ss" script, I'd feel better > about this. That's actually very easy. Configure three Pool servers. It's really hard to do worse with that than with any recogniseably stupid configuration. On the other hand, if you have the intelligence to recognise your configuration as stupid, you can probably also do better than the Pool. Groetjes, Maarten Wiltink [0] The NTP Book, that is. There is one. His Timeliness Dave Mills wrote it. _______________________________________________ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions