[ntp:questions] Re: Broadcast client question (no reverse link)

David L. Mills mills at udel.edu
Sat Jan 29 01:27:59 UTC 2005


Be,

If novolley is set the client should never send anything. Can you 
confirm that? I've tested it here and it has always worked for me.

Tinker the panic threshold to something like 34 years. Tinker the step 
threshold to something nonzero but small, like one microsecond, and the 
clock will always be stepped no matter what the initial offset. Tinker 
the stepout threshold to zero to avoid waiting for the step to be made. 
Recompile with the MAXDISTANCE defined at something big, like one day.

Having done this, you have systematically defeated all the NTP sanity 
checks, mitigation algorithms and security features. I have probably 
missed something and the victim might not work anyway. Why not give up 
and run one of the many SNTP clients now available. If you have the 
nanokernel, you can compute the systematic frequency offset and inject 
the value in the kernel using ntptime.

Dave

Ben Gamsa wrote:
> I've asked a variant on this before, but so far I've not suceeded in finding
> quite what I'm looking for, or in modifying the ntp source to do what I'd
> like.
> 
> Essentially, what I'd like is an ntp client that uses a broadcast ntp server,
> without ever trying to communicate with the server, without waiting for a
> dozen broadcasts to trust the time server, and without second-guessing the
> server if the server's time is hours, days, or even years off of the client time.
> Essentially, I'm looking for a way to get ntpd to do the intelligent 
> frequency correction work that avoids the need for time adjustments,  but that 
> will blindly use the time it gets from the server, no matter what.
> 
> I've tried variants with the novolley change and other modifications, but
> ntpd can still get into a state where it will stop listening to the server,
> either due to the time being too far off, or communication problems when it
> later decided it needs to exchange messages with the server.
> 
> Any pointers or suggestions would be much appreciated.



More information about the questions mailing list