Re: NTP Client synchronization with a Windows 2003/2008
If I may pipe up... Can you not set the clock manually, then let ntpd take it from there? Seems like your clock would become synced a lot faster if it started out close. Sorry if I'm being naive, but this seemed like the obvious thing to do. Don't apologize! Any input is valuable! But I don't quite understand what you meant about let ntpd take it from here or if it started out close... (I am French and maybe you're using a figure of language I don't understand...) Are you running with an elevated securelevel? No the Secure Level is -1... But I've found the beginning of a solution... It doesn't come from ntpd but from the Windows Time Server. When configured to sync with its internal clock, the NTP Server IP packets that goes to the client contain strange values (rootdispersion, etc.) that are higher than expected. Thus, ntpd doesn't consider the Windows Server as a reliable source. But once the windows server configured to sync with an external source, it works! The IP packets generated from the windows server begin to look like real and reliable answer to ntpd... I'm working now on a correct configuration of the Windows Server. Thanks again to all! ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: NTP Client synchronization with a Windows 2003/2008
The 19 minutes between when I sent my suggestions and you responded is hardly enough time to see if ntpd was slewing the time. Slewing 587 seconds takes days. The thing is that ntpd is not slewing the time at all, even after several hours!! Are you sure that -x in there, telling ntpd to not step unless the offset is over 600 sec, doesn't override what you're trying to do with the -q? How about you try simple: ntpdate the_windows_server and see what that does? After that look in /var/log/messages. I don't have that command on my system... Alternatively, from the commandline try ntpd -g -q -c /etc/ntp.conf The -g flag allows ntpd to set the clock once regardless of the offset and the -q causes it to quit after setting the time. I tried this command without success... I can see the NTP packets (client and server) but the clock is never set with the debugging option enabled (-D 3), at the end I get: ... ... poll_update: at 15 172.30.1.5 flags 0201 poll 6 burst 1 last 1 next 17 read_network_packet: fd=22 length 48 from ac1e0105 172.30.1.5 receive: at 15 172.30.1.250-172.30.1.5 flags 19 restrict 080 receive: at 15 172.30.1.250-172.30.1.5 mode 4 code 1 auth 0 packet: flash header 0040 addto_syslog: no reply; clock not set ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
NTP Client synchronization with a Windows 2003/2008
Hello, I am using a System based on FreeBSD 6.3. On this System an automatically generated ntpd.conf file is generated in order to synchronize the System clock with a NTP Server. I want to use a Windows 2003 or 2008 Server to act as the NTP Server. On the Windows System the NTP Server (Windows Time Service) is *correctly* running. The thing is that even if there are NTP traffic between the client and the Server (NTP Client and Server IP packet), My FreeBSD is not synchronizing at all: freebsd-clientntpq -p 127.0.0.1 remote refid st t when poll reach delay offset jitter === NTP_server 192.168.10.6 2 u 103 102411.037 -587367 0.002 As you can see the offset is huge and never decreases as in a normal way... My ntpd.conf file looks like: --- # File is automatically generated # Do not edit tinker panic 1 tinker step 1 # ntp servers list server 172.30.1.5 # files informations driftfile /etc/ntp.drift # restriction informations restrict default ignore # do not allow request by default restrict 127.0.0.1 # allow localhost for debugging restrict 172.30.1.5 nomodify my ntp.drift file -101.101 I know that maybe the Microsoft NTP/SNTP implementation is not RFC-compliant, but is there a way to configure my NTP client in a more compatible (less strict) way to adjust its time with a Windows Server? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
NTP Client synchronization with a Windows 2003/2008
Hello, I am using a System based on FreeBSD 6.3. On this System an automatically generated ntpd.conf file is generated in order to synchronize the System clock with a NTP Server. I want to use a Windows 2003 or 2008 Server to act as the NTP Server. On the Windows System the NTP Server (Windows Time Service) is *correctly* running. The thing is that even if there are NTP traffic between the client and the Server (NTP Client and Server IP packet), My FreeBSD is not synchronizing at all: freebsd-clientntpq -p 127.0.0.1 remote refid st t when poll reach delay offset jitter === NTP_server 192.168.10.6 2 u 103 102411.037 -587367 0.002 As you can see the offset is huge and never decreases as in a normal way... My ntpd.conf file looks like: --- # File is automatically generated # Do not edit tinker panic 1 tinker step 1 # ntp servers list server 172.30.1.5 # files informations driftfile /etc/ntp.drift # restriction informations restrict default ignore # do not allow request by default restrict 127.0.0.1 # allow localhost for debugging restrict 172.30.1.5 nomodify my ntp.drift file -101.101 I know that maybe the Microsoft NTP/SNTP implementation is not RFC-compliant, but is there a way to configure my NTP client in a more compatible (less strict) way to adjust its time with a Windows Server? Thanks ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
RE: NTP Client synchronization with a Windows 2003/2008
ntpd wont resync if the time difference is to big, as it assumes something is wrong as you would have set the system clock roughly correct. To fix stop ntpd, then do an ntpdate against the server. This should set the time. Now run ntpd again also set the following variables to a server of your choosing to make sure ntpdate is run 1st on boot $ grep ntp /etc/rc.conf* /etc/rc.conf:ntpdate_flags=uk.pool.ntp.org /etc/rc.conf:ntpdate_enable=YES /etc/rc.conf:ntpd_enable=YES I cannot do that because I have no Internet access... so the very first thing you might want to try is to comment out the tinker commands, in particular the panic one. I'm not sure that after you set the panic threshold to 1 second you should expect your ntpd to pay any attention to servers with an offset of 587 seconds. If that fails, consider setting ntpdate_enable=YES ntpdate_hosts=NTP_server in your /etc/rc.conf and simply stepping to the correct time at boot time. In short, I don't think this has anything with a Windows server being involved, and everything to do with starting off almost 10 minutes off and a config file that says to never make a step correction larger than 1 second and to panic if you see an offset of over 1 second. I commented the commands involved and nothing changed... (with only 10 minutes of time difference) I even tried to force the sync: U450XA0A0800650nstop ntp U450XA0A0800650ntpd -x -n -q -c /var/ntp.conf U450XA0A0800650nstart ntp In fact I am still quite convinced that the MS implementation isn't totally compliant with the client... ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
