On Aug 7, 11:22 am, Steve Kostecke <koste...@ntp.org> wrote: > On 2010-08-07, Cindy Huyser <chuy...@io.com> wrote: > > > [---=| Quote block shrinked by t-prot: 32 lines snipped |=---] > >> My configuration file is very simple: > > >> driftfile "C:\Windows\Temp\ntp.drift" > >> broadcastdelay 0.008 > > This has nothing to do with your IPv6 issue ... but: > > The broadcastdelay line is only necessary for configurations where a > broadcast client is not able to calculate the delay during the temporary > unicast phase of a broadcast association (e.g. over one way links). > > In your case this ntpd is not even configured as a broadcastclient, so > that line has no effect. > > >> logfile "C:\Windows\Temp\ntp.log" > > >> server -6 fe80::290:fbff:fe80:6aff%4 minpoll 4 maxpoll 5 iburst prefer > > Why the "%4" at the end of the address? Can you retry your configuration > without it? > > > After all this, with all due respect I wonder how much testing of this > > functionality has gone on with Windows XP? > > Such testing would require developer access to a Windows XP machine. > > -- > Steve Kostecke <koste...@ntp.org> > NTP Public Services Project -http://support.ntp.org/
Thanks fro the note re: the broadcastdelay line. The %4 is the scopeID -- I actually tested with and without this, the results being the same in both cases. For command line ipv6 addressing, Windows requires the scopeID to in order to resolve the link local address. I have a Linux client that had to be configured similarly (%eth0). Cindy _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
