The state of NTPsec as I see it

[Hal Murray]

esr at 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.