halmurray at sonic.net
Mon Apr 10 01:41:17 UTC 2023
>> For a small project, I think we should make mode6/ntpq require the cookie on
>> everything but getting the cookie, and we should make sure that there is no
>> amplification when getting the cookie.
> That would break compatibility with ntpq from classic NTP.
There are 2 areas I'm interested in.
First is to make sure there is no way to get amplification on reflection. I'm
willing to break compatibility to get that.
The second would be a big cleanup. I'd like to do something like split the
current daemon into several parts, for example:
server, client, refclocks, ntpq-server, NTS-KE server
Splitting out ntpq-server would be a good start. Again, I'm willing, even
expecting, to break compatibility.
Using TCP rather than UDP avoids reflection problems.
Most of ntpq would work fine if we put all the counters info read only SHM.
We don't need a lock. The results may be slightly inconsistent.
The mru list stuff won't work in simple read-only SHM, at least with the
current approach of scanning the list in chronological order. It almost
doesn't work as is. If the list is big enough to be interesting for busy
servers, it takes a long time to scan it. Too long to be useful.
Or maybe we should shift to SNMP. I hate that level of obfuscatiion, but if
somebody likes it and is willing to run with it, I'll put things in SHM.
But suppose we scan it in physical order, and sort things out at the client?
That also solves the problem of the current approach never finishing on a busy
server because the data changes faster than it can be retrieved.
The other tool in the mru area would be to log interesting stuff. But I
haven't worked out a simple/clean version of "interesting".
Putting things in SHM introduces version control issues. I think they are not
a problem as long as the stuff on the wire is text rather than offsets. Then
all we have to keep in sync is the ntpq-server and ntp-server and ntp-client.
These are my opinions. I hate spam.
More information about the devel