ntpq mru hang
hmurray at megapathdsl.net
Mon Dec 19 12:40:20 UTC 2016
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
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.)
> 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
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.
More information about the devel