Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I’m attempting to get my Linux sever synced with a time source. So far this has proven to be impossible. I’m running ‘Red Hat Enterprise Linux ES Release 3 (Taroon)’.
The Linux server exists as part of a Windows 2000 Domain. After some research I found that syncing off the Domain Controller wouldn’t be viable, due to Windows’ broken time service. I found that there was already an NTP daemon running and configured it to query a pool server:
‘server 0.us.pool.ntp.org’
But this had no effect. When I attempted to manually update the time with ‘ntpdate –u’, I received the message 'no server suitable for synchronization found'. When I checked for issues with ‘ntpdate –d’ I found that I was receiving no packets from the server after several requests.
Code:
ntpdate -d 132.239.1.6
26 Sep 09:24:52 ntpdate[13105]: ntpdate 4.1.2@1.892 Thu Sep 11 05:38:17 EDT 2003 (1)
transmit(132.239.1.6)
transmit(132.239.1.6)
transmit(132.239.1.6)
transmit(132.239.1.6)
transmit(132.239.1.6)
132.239.1.6: Server dropped: no data
server 132.239.1.6, port 123
stratum 0, precision 0, leap 00, trust 000
refid [0.0.0.0], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Wed, Feb 6 2036 22:27:53.000
originate timestamp: 00000000.00000000 Wed, Feb 6 2036 22:27:53.000
transmit timestamp: caa5066e.8249906c Wed, Sep 26 2007 9:24:55.508
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
26 Sep 09:24:56 ntpdate[13105]: no server suitable for synchronization found
I then followed a guide for configuring Red Hat NTP (http://www.halley.cc/ed/linux/howto/ntp.html) which did nothing to change my issue. I then reverted to the original Red Hat Config:
Code:
restrict default ignore
restrict 155.97.17.169 mask 255.255.255.255 nomodify notrap noquery
restrict 127.0.0.1
#test sever
server 192.168.20.8
restrict 192.168.20.8
# stratum two server
#server 132.239.1.6 #ntp.ucsd.edu
#restrict 132.239.1.6 nomodify
#server 192.83.249.28 #ntp1.sf-bay.org
#restrict 192.83.249.28 nomodify
# pool server
#server 66.250.45.2 #0.us.pool.ntp.org
#restrict 66.250.45.2 nomodify
# stratum one server
#server 128.9.176.30 #timekeeper.isi.edu
#restrict 128.9.176.30 nomodify
fudge 127.127.1.0 stratum 10
driftfile /var/lib/ntp/drift
broadcastdelay 0.008
authenticate yes
keys /etc/ntp/keys
Here also is the output of an ‘ntpq –p’ ran on the external servers:
Code:
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
bigben.ucsd.edu 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
zorro.sf-bay.or 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
ntp.pbx.org 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
timekeeper.isi. 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
I then established that the firewall on the Linux box was off (I turned it off and re-tested, no change) and then attempted to make a hole in the external firewall at UDP 123 for NTP traffic. Neither of which solved the problem or made any difference.
I wasn’t able to contact any external NTP server, so I had the bright idea of using an internal Windows NTP compliant server. I downloaded the package (http://www.meinberg.de/english/sw/ntp.htm) followed the instructions and got it functioning on our test server. I then was able to sync from the Windows NTP server.
We did some testing and found that the ntp client on the Linux box was functioning perfectly. We then attempted to deploy the Windows solution on a more permanent server; The 20.8 address in the file above.
This failed because the “strata” was too high to sync:
I did some research and found a thread (http://lists.freebsd.org/pipermail/f...er/107815.html) which suggested that the issue might resolve itself given some time. I let the server continue to sync overnight and I was still unable to achieve a time sync.
First of all, thank you for replying. I was beginning to despair of anyone answering my thread.
I did a bit of reading on tcpdump, and I belive I've crafted a filter to catch everything we're interested in here. Feel free to suggest revisions if I'm missing something.
The following are NTP commands and their output as well as the output of the associated TCPDump. I tried to do a 'ntpdate' three different ways, I wanted to be thorough:
Code:
[root@ptce ptce]# ntpdate 128.9.176.30
1 Oct 09:48:00 ntpdate[28572]: no server suitable for synchronization found
So in short, TCPDump shows no packets returning. As I said in my post we had made made a hole in our firewall specifically for this machine and this type of communication (e.g. UDP:123).
I'm not sure if this behavior is a product of the Windows network / Firewall. Theoretically the firewall should be just allowing these packets through, but obviously not.
If we were to pursue this line of thought, we'd have to get logs associated with this communication. That will take a few days if you think its worth pursuing. I would prefer to focus on getting the linux synced with the NTP server I've installed on our Windows server, as it does work in some cases and is only failing to sync times because of strata.
I see the same behavior with the stratum one server:
Code:
# ntpdate -d 128.9.176.30
1 Oct 09:47:41 ntpdate[28520]: ntpdate 4.1.2@1.892 Thu Sep 11 05:38:17 EDT 2003 (1)
transmit(128.9.176.30)
transmit(128.9.176.30)
transmit(128.9.176.30)
transmit(128.9.176.30)
transmit(128.9.176.30)
128.9.176.30: Server dropped: no data
server 128.9.176.30, port 123
stratum 0, precision 0, leap 00, trust 000
refid [0.0.0.0], delay 0.00000, dispersion 64.00000
transmitted 4, in filter 4
reference time: 00000000.00000000 Wed, Feb 6 2036 22:27:53.000
originate timestamp: 00000000.00000000 Wed, Feb 6 2036 22:27:53.000
transmit timestamp: caaba347.6b410731 Mon, Oct 1 2007 9:47:44.418
filter delay: 0.00000 0.00000 0.00000 0.00000
0.00000 0.00000 0.00000 0.00000
filter offset: 0.000000 0.000000 0.000000 0.000000
0.000000 0.000000 0.000000 0.000000
delay 0.00000, dispersion 64.00000
offset 0.000000
I see similar behavior with the local time server:
Code:
# ntpdate -d 192.168.20.8
2 Oct 08:06:21 ntpdate[24638]: ntpdate 4.1.2@1.892 Thu Sep 11 05:38:17 EDT 2003 (1)
transmit(192.168.20.8)
receive(192.168.20.8)
transmit(192.168.20.8)
receive(192.168.20.8)
transmit(192.168.20.8)
receive(192.168.20.8)
transmit(192.168.20.8)
receive(192.168.20.8)
transmit(192.168.20.8)
192.168.20.8: Server dropped: strata too high
server 192.168.20.8, port 123
stratum 16, precision -20, leap 11, trust 000
refid [73.78.73.84], delay 0.02588, dispersion 0.00063
transmitted 4, in filter 4
reference time: 00000000.00000000 Wed, Feb 6 2036 22:27:53.000
originate timestamp: caacdd1a.9ba0e842 Tue, Oct 2 2007 8:06:43.607
transmit timestamp: caacdd04.4cd8fd5c Tue, Oct 2 2007 8:06:21.300
filter delay: 0.03586 0.02611 0.02588 0.02588
0.00000 0.00000 0.00000 0.00000
filter offset: 22.31254 22.30750 22.30758 22.30758
0.000000 0.000000 0.000000 0.000000
delay 0.02588, dispersion 0.00063
offset 22.307589
2 Oct 08:06:21 ntpdate[24638]: no server suitable for synchronization found
Code:
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
192.168.20.8 0.0.0.0 16 u 3 64 0 0.000 0.000 4000.00
bigben.ucsd.edu 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
zorro.sf-bay.or 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
ntp.pbx.org 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
timekeeper.isi. 0.0.0.0 16 u - 64 0 0.000 0.000 4000.00
I'm tempted to use a port scanner to see if there's a hole in the firewall on my side; I'll post that later. Is there an easy, secure and reliable way to scan from the outside? I can google for a plethora of port scanners to scan the externals of the ISA, but I'd rather have one that's recommended and doesn't appear to be an easy way for script kiddies to harvest active IP's!
well my original responses are still unanswered... the stratum 1 server never responds, the second is too low... there's next to no other debugging you could possibly want IMHO...
well my original responses are still unanswered...
Your responses haven't been addressed?
Quote:
well in the first instance, you simply appear to be getting no repsonses back from ntp.org.
That does seem to be the case, as per the tcpdump output.
Quote:
firewall?
Yes, from my original post:
Quote:
I then established that the firewall on the Linux box was off (I turned it off and re-tested, no change) and then attempted to make a hole in the external firewall at UDP 123 for NTP traffic.
I've made sure that both firewalls are allowing packets through.
Quote:
does tcpdump show packets coming back?
No, not for external time sources. And yes for the internal time source.
Quote:
the second is too low...
Right, I'd like to force the use of this server somehow, as I don't really care that the Windows server is imprecise in this instance.
Quote:
there's next to no other debugging you could possibly want IMHO...
True, I've exhausted the tools I can use to try to diagnose this issue. I just want to get the NTP client to pay attention to the Windows server.
--Peter
Edit: Spelling.
P.S. Note to any moderator: The spell checker does not pick up the word 'impresise' as a misspelled.
Last edited by Gold_Country; 10-03-2007 at 10:29 AM.
ok well for a firewall... clearly you've missed somethign otherwise they would be responding. you need to check the rest of the network. having a proper NTP presence it's really great, i really do recommend spending the time to have a couple of boxes, or even just one going out watching some online strata 1 or 2 boxes to spread that time around.
ok well for a firewall... clearly you've missed somethign otherwise they would be responding.
Well sure, it could be the firewall. Our network admin swears up and down that he's done it right so, nothing I can do about that.
Quote:
having a proper NTP presence it's really great, i really do recommend spending the time to have a couple of boxes, or even just one going out watching some online strata 1 or 2 boxes to spread that time around.
Sure, the domain controller for our network is getting authoritative time syncs from somewhere, but I can't sync off it except through the Windows NTP server I mentioned before.
i don't *think* that it's possible to ignore a strata from the client side. if you are running an ntp server on linux then your ntp.conf does allow you to "fudge" an incorrect strata, so that a client will see it as a valid strata. how your windows service handles this (or not) i couldn't comment on.
i don't *think* that it's possible to ignore a strata from the client side. if you are running an ntp server on linux then your ntp.conf does allow you to "fudge" an incorrect strata, so that a client will see it as a valid strata.
As in this line from the conf file?
Code:
fudge 127.127.1.0 stratum 10
From a brief search:
Quote:
The fudge command is used to provide additional information for individual clock drivers and normally follows immediately after the server command. The address argument specifies the clock address. The refid and stratum options can be used to override the defaults for the device. There are two optional device-dependent time offsets and four flags that can be included in the fudge command as well.
Which is tantalizing, but not very helpful.
Also:
Quote:
LAN Server
You can set up your system's hardware clock as a reference clock by using the fudge command. This will allow your system to always return a stratum 10 result. However before a Windows XP system will synchronize to this server, the server must synchronize to gain a lower stratum result (e.g. stratum 1). This will be acknowledged by /var/log/ntp.log in the following form. The synchronization can take a few minutes.
File: /var/log/ntp.log
3 May 19:46:05 ntpd[24616]: synchronized to LOCAL(1), stratum=10
3 May 19:46:06 ntpd[24616]: synchronized to 1.2.3.4, stratum=1
3 May 19:51:31 ntpd[24616]: synchronized to 2.3.4.5, stratum=1
3 May 20:21:44 ntpd[24616]: synchronized to 3.4.5.6, stratum=1
Also note the restriction on the LAN in /etc/ntp.conf. This must be done to stop your NTP server synchronizing to your LAN.
So it looks like the server I'm running has a stratum of 16 (for some reason), because the server has not synced itself with a time server of high enough "quality"? The ntp_server should be syncing off the Domain Controller (it's been configured as such), then the DC is syncing off something more authoritative. As I'm using a hack to get things "working", Windows is probably not properly reporting its correct strata. There must be a way to modify the strata manually from the server side.
But on the other hand, if I set the hardware clock to a lower strata (with fudge there), I might be able to convince the client to sync with the "non-authoritative" ntp_server.
Also, the last line has me concerned as any LAN syncing may be assigned a lower value automatically depending on the configuration.
Quote:
how your windows service handles this (or not) i couldn't comment on.
Just to be clear the NTP server I'm using (http://www.meinberg.de/english/sw/ntp.htm) is not a default Windows Time Service. The setup will actually disable the default Windows Time Service and replace it with its own. The NTP server is a service, but not the broken Windows service.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
