ntpq mru hang

[Hal Murray]

I've found an interesting problem.

A successful batch returns a new nonce.  ntpq asks for more using the old 
one.  Nothing comes back.

That seems broken-by-design.  If the response is lost, the server will have 
switched to the new nonce but the client only knows the old one.  It might 
work if the server remembers the old nonce until it gets a packet with the 
new one.

I haven't looked at the server code, but I don't see any mention of that in 
the mode6 doc.

mode6 doc says:
  === CTL_OP_REQ_NONCE ===
  This request is used to initialize an MRU-list conversation.
Does ntpd do anything other than return the nonce?

-------

I have some hacks in ntpq that setup a debugging file when debug is set 
non-zero.  I think they can be cleaned up a bit and committed.

--------

Thinking about the big picture of monitoring a server...

We need a way to get some info when the MRU list is getting updated faster 
than ntpq can retrieve it.  It never converges.

One possibility is to add an option to log a slot when it gets recycled.  
That would expose a DoS attack.

I think we need something like ntpmon that uses all the screen space for the 
MRU output.

I think we need an option to ntpq/mru to tell it how many slots to ask for, 
and/or to have an option that says give me all that fits in a batch, but 
start from the newest rather than oldest.  With something like that, we could 
script some useful collection.  It wouldn't get everything, but I think it 
would get a helpful sample.


-- 
These are my opinions.  I hate spam.