[ntp:questions] ntpd/refclock_local.c

Danny Mayer mayer at ntp.org
Sun Aug 8 02:37:51 UTC 2010

On 8/5/2010 5:53 PM, mval wrote:
> Upgrading ntp from 4.2.0 to 4.2.6p1.
> System receives time via broadcast over the wildcard interface.

That should not be happening. ntpd should be creating it's own receiving
interface for broadcast packets. The wildcard interface cannot be used
for autokey and under normal circumstances the code will not configure
the wildcard interface to receive broadcast packets. If you have
evidence that it is doing so, please file a bug report along with
details of the O/S you are using. As I recall only Windows NT 4.0 needed
to use the wildcard interface.

> Everything is working correctly after the upgrade; system first syncs
> with local clock, then receives broadcast and syncs with it.
> In version 4.2.0, if the broadcast server went down, ntpd would resync
> with the local time until the broadcast server came back up (the
> transition took approximately 6 minutes).  In 4.2.6p1, if the
> broadcast server goes down, ntpd never re-syncs with the local time.
> A ntpq -p reports that the LOCAL can still be seen, but ntpd does not
> report that it has synced with it.
> This is an issue because this client acts as a server for other
> systems that are downstream.
> I did some digging, and found that there are two lines of code that
> cause my issue and are located in ntpd/refclock_lcoal.c:
> /*
>  * Do no evil unless the house is dark or lit with our own lamp.
>  */
> if(!(sys_peer == NULL || sys_peer == peer))
>     return;
> If I comment these two lines of code out, 4.2.6p1 functions exactly
> the same as 4.2.0.  I was hoping someone could tell me if there is any
> documentation regarding when/why these lines of code were added and if
> commenting these two lines of code out effects the rest of NTP in an
> unfavorable way.

I would guess that it is the second part of the condition that is
causing the problem since it seems to say that if the local system that
is the peer, just keep it there which is not what you want.


> I appreciate any help.  Please let me know if there is any other
> information required.
> Regards,
> mval
> _______________________________________________
> questions mailing list
> questions at lists.ntp.org
> http://lists.ntp.org/listinfo/questions

More information about the questions mailing list