ntpq mru hang

[Hal Murray]

esr at thyrsus.com said:
> Wait, then I have failed to undersrtaand your bug report.  This can happen
> in a different, less odd way than the nonce update getting lost by packet
> drop? 

Yes.  The no-packet-lost case is broken if it needs a second batch.

Each batch gets a new nonce.  The code doesn't do anything with it.  So 
asking for the second batch is using a stale nonce.

My digression about recovering from lost packets was just a complication that 
I noticed.  We will run into it when we get that far.  I think we can duck 
that one by running ntpq on localhost.

---------

[generating test case]

> Or we could just write a script using the Python Mode 6 library to flood a
> running ntp with bogus Mode 6 packets.  That way we wouldn't have to add
> cruft in C. 

Just generating crap won't help.  You need to forge the source IP Address.  
(I think you could do it semi-cleanly by setting up a bazillion extra IP 
Addresses on your driver.  I forget what they are called.)


> Done. There is now an 'm' command that does what you want. That took me a
> *whole nine minutes* to implement, test, and document.  (See also: Why I
> Moved Stuff To Python.) 

Nice.  Thanks.



> Actually, we do.  You can pass name-value pairs as arguments to the mrulist
> command of ntpq.  I first tested the "recent" extension by typing 

Neat.  Thanks.  I'll start taking advantage of it after some sleep.

-------

> What is failing to work exactly?

Currently, ntpq dies as soon as it asks for the second batch.

I've seen it ask for a new nonce, but that didn't recover.  I didn't 
investigate since that was the same time I saw that it wasn't picking up the 
new nonce.

The old ntpq doesn't work either.  It used to work before the traffic jump.  
I assume something got pushed over the edge.  The obvious thing is slots 
getting updated faster then they can be retrieved.  I think we need to add a 
bunch of counters but I don't know where to put them.

-- 
These are my opinions.  I hate spam.