e...@thyrsus.com said:
>> I think the ntpq retransmission logic is still broken.
> Urgh. Do you know any way to reproduce this?
I've had the reverse problem. It always strikes when I'm trying to get real
work done.
My test case is just the typical network dropping packets. Try mrulist on a
remote system with a big list.
I haven't looked at ntpq recently. If there is a single place where it reads
packets, you can hack that to randomly drop packets. That will let you test
things on a local LAN where the network doesn't drop packets.
Or get some flaky WiFi gear. Maybe move far enough away. Small USB WiFi
chips are not expensive. You can add one to a Raspberry Pi.
Plan B would be to hack the server side. I think the mode 6 responses all go
through a single place.
The restrict stuff has a +flake+ option. It's in docs/includes/access-command
s.txt
That will drop request packets arriving at the server. (I think, not tested)
That might be enough. Or maybe we need the case where ntpq gets a partial
answer.
+flake+;;
Discard received NTP packets with probability 0.1; that is, on
average drop one packet in ten. This is for testing and amusement.
The name comes from Bob Braden's _flakeway_, which once did a
similar thing for early Internet testing.
--------
https://tools.ietf.org/html/rfc1025
Some test are made more interesting by the use of a "flakeway". A
flakeway is a purposely flakey gateway. It should have control
parameters that can be adjusted while it is running to specify a
percentage of datagrams to be dropped, a percentage of datagrams to
be corrupted and passed on, and a percentage of datagrams to be
reordered so that they arrive in a different order than sent.
--
These are my opinions. I hate spam.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
