[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