I have put together another prototype with refinements and fixes to
the "monlist" or most-recently-seen client addresses list. There are
two new ntpq commands, modeled on ntpdc's sysstats and monlist
commands.
h...@psp-fb1> ntpdc -c sysstats
time since restart: 38493
time since reset: 38493
packets received: 502593
packets processed: 5112
current version: 281246
previous version: 194715
declined: 0
access denied: 75
bad length or format: 26930
bad authentication: 272
rate exceeded: 115690
h...@psp-fb1> ntpq -c sysstats
uptime: 38496
sysstats reset: 38496
packets received: 502619
current version: 281262
older version: 194723
bad length or format: 26931
authentication failed: 272
declined: 0
restricted: 75
rate limited: 115697
KOD responses: 3384
processed for time: 5114
Other than the editorializing in terms of order and description, the
only functional difference is ntpq's sysstats adds the count of KoDs
sent. The same information is available individually via ntpq queries
such as "rv 0 ss_received ss_limited ss_kod". The implementation is
via a table that shows the mapping of ntpq-accessible "system
variables" and the descriptive text:
{ "ss_uptime", "uptime: ", NTP_STR },
{ "ss_reset", "sysstats reset: ", NTP_STR },
{ "ss_received", "packets received: ", NTP_STR },
{ "ss_thisver", "current version: ", NTP_STR },
{ "ss_oldver", "older version: ", NTP_STR },
{ "ss_badformat", "bad length or format: ", NTP_STR },
{ "ss_badauth", "authentication failed:", NTP_STR },
{ "ss_declined", "declined: ", NTP_STR },
{ "ss_restricted", "restricted: ", NTP_STR },
{ "ss_limited", "rate limited: ", NTP_STR },
{ "ss_kodsent", "KoD responses: ", NTP_STR },
{ "ss_processed", "processed for time: ", NTP_STR },
{ NULL, NULL, 0 }
The second new command is much more interesting: mrulist Like ntpq -p
and similar peer billboards commands, it involves a series of request/
response interactions with the remote ntpd. The resulting output is
very similar to ntpdc's monlist, but monlist is restricted to a single
request and response (though the response is typically spread over
tens of packets). Internally, the implementation is very different
and enables arbitrarily large numbers of 'rows' (that is, monlist
entries representing correspondent IPs). The protocol is entirely
text-based like most of the mode 6 (ntpq) control protocol.
Here are a couple of sample commands to give a flavor, from a server
participating in us.pool.ntp.org. There are some magic numbers that
should be replaced with keywords, but for now keep in mind the
"restrict ... limited" bit has value 0x20, and the "restrict ... kod"
bit is 0x400. Both of these bits, unlike the rest of the restrict
bits shown in monlist/mrulist, should be lit only if the last packet
from the associated IP address triggered rate limiting (0x20) and if
so, occasionally KoD (0x400). My impression is this is wrong in
recent ntpd's ntpdc -c monlist output before my changes regarding
0x400 -- it is shown in monlist if the remote address is eligible for
KoD handling but there is no way to tell if the most recent packet
from the client triggered a KoD response. With these changes, the KoD
bit in monlist, like the limited bit, reflects only the handling of
the last packet from the particular IP address.
h...@psp-fb1> ntpq -nc "mru laddr=149.20.54.226"
2 4 8
lstint avgint rstr m v count rport remote address
==============================================================================
4 68 100 4 4 580 123 204.123.2.5
11 68 100 4 4 579 123 216.218.192.202
[... more rows, but only ten or so total]
The "2 4 8" is temporary debugging output and means "attempting to
fetch the next # entries". There is a lot more debug output to be
seen by the curious with -d or -dd. Note the "laddr=" option to
mru[list] results in a small number of correspondents (in this case
upstream servers) using psp-fb1's primary IP address. The pool
service is on an alias IP address.
h...@psp-fb1> ntpq -nc "mrulist mincount=1000 resany=0x20"
2 4
lstint avgint rstr m v count rport remote address
==============================================================================
1 0 1a0 1 3 103662 5262 67.100.158.66
26 12 5a0 3 4 3349 49189 74.131.27.7
h...@psp-fb1> ntpq -nc "mrulist resall=0x400"
2 4 8 16 32
lstint avgint rstr m v count rport remote address
==============================================================================
50 12 5a0 3 4 3349 49189 74.131.27.7
231 0 5a0 3 3 12 38606 113.8.98.232
427 0 5a0 3 4 12 123 213.149.120.20
3131 0 5a0 3 4 12 58935 69.50.47.132
3917 0 5a0 3 3 12 6266 121.10.222.35
[... about 40 or 50 rows]
Finally, the results can be sorted by lstint, avgint, count, or addr,
or any of those four prefixed by "-" to reverse the sort order:
h...@psp-fb1> ntpq -nc "mrulist resall=0x20 mincount=300 sort=-count"
2 4
lstint avgint rstr m v count rport remote address
==============================================================================
0 0 1a0 1 3 104246 5273 67.100.158.66
301 12 5a0 3 4 3349 49189 74.131.27.7
7846 47 1a0 3 4 664 46763 216.143.37.5
8826 81 1a0 3 4 336 10351 64.92.219.196
9702 4 1a0 3 4 313 33485 208.92.36.18
h...@psp-fb1>
81ed9b9b24fb5ddef19f9de602fbbeb4 ntp-4.2.7p20-mrulist-0309.tar.gz
bbdc4645e9677eb7c2b7136fbb89e5ac ntp-4.2.7p20-mrulist-0309-win-x86-
bin.zip
351cbd50c2e19278a1863195e2eceb61 ntp-4.2.7p20-mrulist-0309-win-x86-
debug-bin.zip
sizes respectively: 4290598 831763 1417850
http://davehart.net/ntp/pool/
http://davehart.net/ntp/pool/ntp-4.2.7p20-mrulist-0309.tar.gz
http://davehart.net/ntp/pool/ntp-4.2.7p20-mrulist-0309-win-x86-bin.zip
http://davehart.net/ntp/pool/ntp-4.2.7p20-mrulist-0309-win-x86-debug-bin.zip
Your testing and feedback is welcome.
Cheers,
Dave Hart
_______________________________________________
timekeepers mailing list
[email protected]
https://fortytwo.ch/mailman/cgi-bin/listinfo/timekeepers
