Hal Murray via devel <devel@ntpsec.org>:
> Where is that documented?
The page that covers differences from Classic - docs/ntpsec.txt. It's under
Security.
> Context is I'm working on documentation. Often, I'm removing stuff that is
> no longer relevant. Sometimes that requires checking the code. Some of the
> code needs cleaning up too. I think - maybe I just don't understand it yet.
Good, somebody needs to do this. And it needs to be somone with a not-Eric
perspective. Can't think of a better fit than you.
> We treat peer in ntp.conf as an alias for server.
> So we don't send MODE_ACTIVE.
> It looks like we respond to MODE_ACTIVE with MODE_PASSIVE.
>
> It looks like we can send MODE_BROADCAST.
Yes, but not be a client for it.
> I assume that's for compatibility.
> Has anybody tried it?
No, and that worries me just a little. Daniel probably left that code
working but there's some chance it might have bit-rotted since.
> I assume we ignore received MODE_BROADCAST packets, but I haven't confirmed
> that by reading the code.
I have not either. That doesn't worry me, it's not the kind of thing Daniel
would foo up and not likely to bit-rot either.
All the things you say are congruent with my understanding, but you should
check with Daniel because the protocol-engine rewrite was him.
> The question that got me here is the nopeer restrict option. Do we need it
> any more? I think we no longer setup any unsolicited peers. The pool code
> used to do that, but not any more. I think the peer command on another
> server used to do that, but I'm pretty sure we don't do that any more.
>
> Related, there is a table or two that used to be needed to handle received
> packets. I think we can simplify things by bypassing them, but that depends
> on understanding what packets we allow.
You are probably right about all of this, but it edges into areas where my
grasp of the operation of the code is weak.
I think it is a *very* good thing you are turning over these rocks and
encourage you to pursue. I rate the odds that no actual pooches have
been screwed pretty high, but due diligence by someone who isn't
carrying my assumptions - or Daniel's - is definitely called for.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
