Bug 137143
Summary: | client fails to obtain ntp data from NTP server | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | TC <tcwan> | ||||||||||
Component: | ntp | Assignee: | Jiri Ryska <jryska> | ||||||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||||||
Severity: | medium | Docs Contact: | |||||||||||
Priority: | medium | ||||||||||||
Version: | 2 | CC: | mattdm | ||||||||||
Target Milestone: | --- | ||||||||||||
Target Release: | --- | ||||||||||||
Hardware: | i686 | ||||||||||||
OS: | Linux | ||||||||||||
Whiteboard: | |||||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||||
Doc Text: | Story Points: | --- | |||||||||||
Clone Of: | Environment: | ||||||||||||
Last Closed: | 2005-05-19 03:59:12 UTC | Type: | --- | ||||||||||
Regression: | --- | Mount Type: | --- | ||||||||||
Documentation: | --- | CRM: | |||||||||||
Verified Versions: | Category: | --- | |||||||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||||
Embargoed: | |||||||||||||
Attachments: |
|
Description
TC
2004-10-26 03:52:09 UTC
Created attachment 105769 [details]
NTP Server Configuration
Created attachment 105770 [details]
NTP Client configuration
Created attachment 105771 [details]
NTP Server config (for 4.2.0.a.20040617-4)
Created attachment 105772 [details]
NTP Client config (for 4.2.0.a.20040617-4)
Using the "-d" option will give us more output. Please provide: # ntpdate -d -q netmon.cs.usm.my [With iptables disabled (it had no effect on the results)] On the NTP server (161.142.8.104): [root@nrg tcwan]# ntpdate -d -q 161.142.8.104 11 Jan 09:23:07 ntpdate[8249]: ntpdate 4.2.0a Mon Oct 11 09:10:21 EDT 2004 (1) Looking for host 161.142.8.104 and service ntp host found : network2.cs.usm.my transmit(161.142.8.104) receive(161.142.8.104) transmit(161.142.8.104) receive(161.142.8.104) transmit(161.142.8.104) receive(161.142.8.104) transmit(161.142.8.104) receive(161.142.8.104) transmit(161.142.8.104) server 161.142.8.104, port 123 stratum 2, precision -18, leap 00, trust 000 refid [161.142.8.104], delay 0.02568, dispersion 0.00000 transmitted 4, in filter 4 reference time: c58da509.7fb82c2b Tue, Jan 11 2005 9:06:17.498 originate timestamp: c58da900.e06d1e10 Tue, Jan 11 2005 9:23:12.876 transmit timestamp: c58da900.e067cf1c Tue, Jan 11 2005 9:23:12.876 filter delay: 0.02574 0.02570 0.02568 0.02570 0.00000 0.00000 0.00000 0.00000 filter offset: 0.000018 0.000004 0.000002 0.000005 0.000000 0.000000 0.000000 0.000000 delay 0.02568, dispersion 0.00000 offset 0.000002 11 Jan 09:23:12 ntpdate[8249]: adjust time server 161.142.8.104 offset 0.000002 sec [Note: netmon.cs.usm.my is also nrg.cs.usm.my] On the NTP client (iptables disabled also): [root@cvs tcwan]# ntpdate -d -q 161.142.8.104 11 Jan 09:22:50 ntpdate[17553]: ntpdate 4.2.0a Mon Oct 11 09:10:21 EDT 2004 (1) Looking for host 161.142.8.104 and service ntp host found : nrg.cs.usm.my transmit(161.142.8.104) transmit(161.142.8.104) transmit(161.142.8.104) transmit(161.142.8.104) transmit(161.142.8.104) 161.142.8.104: Server dropped: no data server 161.142.8.104, port 123 stratum 0, precision 0, leap 00, trust 000 refid [161.142.8.104], delay 0.00000, dispersion 64.00000 transmitted 4, in filter 4 reference time: 00000000.00000000 Thu, Feb 7 2036 14:28:16.000 originate timestamp: 00000000.00000000 Thu, Feb 7 2036 14:28:16.000 transmit timestamp: c58da8ed.89fb6134 Tue, Jan 11 2005 9:22:53.538 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 11 Jan 09:22:54 ntpdate[17553]: no server suitable for synchronization found netstat -l on NTP server: [NTP server has several NIC/IP addresses. 161.142.8.104 == network2 == nrg == netmon] udp 0 0 219.93.2.104:ntp *:* udp 0 0 10.207.128.203:ntp *:* udp 0 0 network2.cs.usm.my:ntp *:* udp 0 0 localhost.localdoma:ntp *:* udp 0 0 *:ntp *:* udp 0 0 *:ntp *:* are you sure the firewall does not drop ntp udp packets? 161.142.8.104: Server dropped: no data As mentioned in the header of the two logs, the firewall was disabled via 'service iptables stop' on both the client and the server, to avoid interaction between the firewall and ntp. I just tried the following (with iptables enabled): It appears that the NTP server would only respond to requests from clients from the same subnet and not from a different subnet? i.e., client has IP, 10.207.128.200, can't query server using server IP 161.142.8.104, but works with server IP 10.207.128.203. /etc/ntp.conf on NTP server: restrict 161.142.8.0 mask 255.255.255.0 nomodify notrap restrict 10.207.128.0 mask 255.255.128.0 nomodify notrap ----- NTP client output log ------ [tcwan@cvs tcwan]$ ntpdate -d -q 10.207.128.203 12 Jan 13:51:47 ntpdate[18731]: ntpdate 4.2.0a Mon Oct 11 09:10:21 EDT 2004 (1) Looking for host 10.207.128.203 and service ntp host found : 10.207.128.203 transmit(10.207.128.203) receive(10.207.128.203) transmit(10.207.128.203) receive(10.207.128.203) transmit(10.207.128.203) receive(10.207.128.203) transmit(10.207.128.203) receive(10.207.128.203) transmit(10.207.128.203) server 10.207.128.203, port 123 stratum 2, precision -18, leap 00, trust 000 refid [10.207.128.203], delay 0.02597, dispersion 0.00011 transmitted 4, in filter 4 reference time: c58f2d98.4531550c Wed, Jan 12 2005 13:01:12.270 originate timestamp: c58f3973.4fa7c9de Wed, Jan 12 2005 13:51:47.311 transmit timestamp: c58f3973.4faebc40 Wed, Jan 12 2005 13:51:47.311 filter delay: 0.02664 0.02660 0.02602 0.02597 0.00000 0.00000 0.00000 0.00000 filter offset: -0.00064 -0.00060 -0.00030 -0.00032 0.000000 0.000000 0.000000 0.000000 delay 0.02597, dispersion 0.00011 offset -0.000322 12 Jan 13:51:47 ntpdate[18731]: adjust time server 10.207.128.203 offset -0.000322 sec [root@cvs tcwan]# ntpdc -p remote local st poll reach delay offset disp ======================================================================= =10.207.128.203 10.207.128.200 2 64 17 0.00044 -0.000589 0.96916 *LOCAL(0) 127.0.0.1 10 64 17 0.00000 0.000000 0.96858 =country.hexago. :: 16 64 0 0.00000 0.000000 0.00000 this may be a problem with the firewall that goes to the outside internet? to make sure this is not an ntp configuration error, just comment all "restrict" lines and restart the server. wait 5 minutes, then retry from the client. I commented out every restrict statement, and replaced it with 'restrict default' (no arguments). No difference. Incidentally, both 161.142.8.x and 10.207.128.x are internal to our network, and doesn't go through the Internet firewall. In any case, I can get NTP updates from external NTP servers just fine. It's not so critical now that I found a workaround, but I guess there's a bug where the server would respond on the 10.207.128.x IP address to a client with 10.207.128.x address, but not from the 161.142.8.x IP address. (A client with 161.142.8.x address works fine using either address for the NTP server though, AFAIK). [root@nrg tcwan]# ntpdc -p remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 10 64 1 0.00000 0.000000 2.81735 =65.75.183.220 161.142.8.104 2 64 1 0.19882 -0.001888 2.81735 =srnf0501.asplen 161.142.8.104 3 64 1 0.34096 -0.000911 2.81735 =ntp2c.jaring.my 161.142.8.104 2 64 1 0.00946 0.001862 2.81735 =mozart.musicbox 161.142.8.104 3 64 1 0.29881 0.019001 2.81735 =country.hexago. :: 1 64 1 0.79727 -0.009184 2.81735 Looks like a route problem to me. I suggest discussing this on the comp.protocols.time.ntp newsgroup, or you may prefer the mailing list gateway at questions.org. I don't think that this is anything particularly unique to Redhat. Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match. I think this issue can be closed and the workaround documented. |