[ntp:hackers] [Bug 1378] Unnecessary resetting of peers during interface update

Dave Hart davehart at gmail.com
Sun Nov 15 00:07:42 UTC 2009


On Sat, Nov 14, 2009 at 8:59 PM, Frank Kardel <kardel at ntp.org> wrote:
> You mention broadcast as being problematic here. This is where I do not
> get you. The code in ntp_peer.c:peer_refresh_interface() reads:
>   ...
>    set_peerdstadr(peer, niface);
>    if (peer->dstadr) {
>        /*
>         * clear crypto if we change the local address
>         */
>        if (peer->dstadr != piface && !(peer->cast_flags &
>            (MDF_ACAST | MDF_BCLNT)))
>            peer_clear(peer, "XFAC");
>   ...
>
> broadcast clients are mobilized with the MDF_BCLNT flag - why, then are
> you seeing peer-resets when MDF_BCLNT is set? Ohh, wait -  I just found
> in ntp_proto.c a section that clears MDF_BCLNT when peer->pmode ==
> MODE_BROADCAST - so the assumption this being a stable config flag is
> false - it may have been true in another time - nowadays it seems to be
> a calibration flag.
>
> So would it be safer to use peer->pmode == MODE_BROADCAST as safeguard
> against peer_clears() ?

Let's find out.  Steve and Danny, in my psp-deb1 home directory is

psp-deb1.ntp.org:/home/hart/ntp-4.2.5p245-RC.tar.gz
MD5 (ntp-4.2.5p245-RC.tar.gz) = 66e0bf4bf71440b645bf5c0eb03721cc

which is p245 plus Frank's suggested change to ntp_peer.c:

		/*
		 * clear crypto if we change the local address
		 */
		if (peer->dstadr != piface && !(peer->cast_flags &
		    MDF_ACAST) && peer->pmode != MODE_BROADCAST)
			peer_clear(peer, "XFAC");

If one or both of you give it a try on the hosts where you've
experienced unstable broadcast/multicast clients, we may find this
restores the original design behavior while preserving the desired
behavior when addresses haven't changed but the routes have.

Cheers,
Dave Hart


More information about the hackers mailing list