The state of NTPsec as I see it

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> 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.

I fear we dropped this on the floor.  If it's still an issue, please
file a bug on the tracker.  Be as specific as possible; it might be Ian
rather than me working on it.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.