[ntp:questions] Re: NTP Multicast server/client?

Wilhelm Greiner wilhelm.greiner at web.de
Tue Oct 4 18:39:23 UTC 2005


Hi
* David L. Mills <mills at udel.edu> schrieb:
>  Danny Mayer wrote:
> > David Woolley wrote:
> >>>> Also i see when ntpd with debugging runs that it transmits any packets
> >>>> to find out is the way back reachable.
> >>> I don't understand what you mean here. Can you explain?

> >> When a broadcast client is starting it makes a normal access to the
> >> server to calibrate the round trip delay and therefore estimate the
> >> downstream delay.  It will fall back to the configured delay if this
> >> fails.

> > I'm not sure that it does send a packet if authentication is not 
> > enabled, but I'd have to check.

> >> Also, I believe that if you enable authentication, and that is strongly
> >> encouraged for broadcast, this exchange is mandatory to negotiate keys.
> >> (I vaguely remember that authentication is defaulted on for broadcast.)

> > When you authenticate that means that you are exchanging a bunch of NTP 
> > packets between broadcast/multicast client and server. It's described as 
> > the "key dance" in the documentation. I don't remember how many packets 
> > are exchanged, but it's more than two.

>  By default, to mobilize a broadcast client requires authentication using 
>  either symmetric or public key cryptography. Ordinarily, eight packets 
>  are exchanged with the server at two-second intervals. This is 
>  sufficient to both accurately calibrate the propagation delay and run 
>  the authentication protocol. This can be disabled with the novolley 
>  option in the broadcastclient command. If so or if the server does not 
>  respond, a default delay is assumed and life goes on.

Could not find this option in the man page.

when i try "multicastclient 224.6.2.1 novolley" or
"multicastclient novolley 224.6.2.1" in the config
it too transmit packets.
See the output.

The reason is that there can be a way back, but with other delay,
that falsified the resulting time.
Also this can trigger an unwanted dial in.

[root at ntpserver ntpd-4.1.2_build_20051004]# ./ntpd -d | grep transmit
transmit: at 10 0.0.0.0->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 25 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 26 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 30 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 34 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 35 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 36 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 37 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 110 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 128 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 130 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 132 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 135 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 139 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 142 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20
transmit: at 144 224.6.2.1->192.168.100.76 mode 3 keyid 00000001 len 68 mac 20


>  Dave

mfg Wilhelm




More information about the questions mailing list