ntpq mrulist, #547
hmurray at megapathdsl.net
Mon Oct 7 22:52:01 UTC 2019
I'm getting ready to work on this. It might help if some other eyes took a
look at the code.
Here is what I think is supposed to happen.
ntpd keeps a list of hosts that have sent it traffic. It's a doubly linked
list, sorted by time of last packet arrived from that IP Address. There is
also a hash table so it can find a slot without a linear search.
During the early parts of the receive packet processing, the hash table is
used to find the slot. If the slot doesn't exist, a new one is allocated or
an old one is recycled. If the slot is found, it is removed from it's current
position and inserted at the front of the list. The counter is bumped and the
time, mode, version, and remote port number are saved.
You can see the list with ntpq -c mru
You can see the allocation statistics with ntpq -c monstats
(They aren't very interesting unless you look at a busy server.)
Collecting the list is a bit tricky since the answer may not fit in a single
packet. The answers are sent oldest first. If multiple packets are needed, a
continuing request contains an array of where to start IP Address and
time-stamp from the last successful reply.
One glitch is that slots that have already been sent may get updated while
ntpq is collecting and moved to the head of the list where ntpq will see it
again. ntpq sorts the list and drops duplicates.
When processing a continuation request, ntpd uses the hash table to find the
slot, then checks the time stamp. If the time stamp matches, ntpq continues
with the next slot on the list. If it doesn't match, ntpd tries the next pair
from the continuation request.
On a busy server, slots can get updated faster than ntpq can read them. If
that happens, ntpq will not be able to finish collecting samples.
ntpq has a "direct" mode that doesn't sort the answers, just writes things
out. That avoids the memory requirements to hold the whole answer (and
There is an option to only send slots with more than N packets so you can look
for the piggy users without collecting the whole thing.
There may be bugs in the above description as well as in the code.
There is another quirk in this area. If a probe (and retries) times out, it
bails with an error message without printing what it has collected.
These are my opinions. I hate spam.
More information about the devel