[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