Hi * David L. Mills <[EMAIL PROTECTED]> 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. [EMAIL PROTECTED] 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 _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
