From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Description of problem: Both systems (NTP client and NTP server) are running Fedora Core 2. Each system is able to synchronize with external NTP sources (e.g., ntp.hexago.com, etc.) Both systems have iptable rules to allow ntp via udp from all sources & destinations. However, when one system is configured as NTP server (netmon), the client (cvs) attempting to acquire ntp data from it fails to do so. [tcwan@cvs tcwan]$ ntpdc -p remote local st poll reach delay offset disp ======================================================================= =netmon.cs.usm.m 10.207.128.200 16 512 0 0.00000 0.000000 0.00000 =LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03049 *country.hexago. :: 1 256 377 0.96469 -0.005124 0.00488 [tcwan@cvs tcwan]$ ntpdate -q netmon.cs.usm.my server 161.142.8.104, stratum 0, offset 0.000000, delay 0.00000 26 Oct 11:44:59 ntpdate[19522]: no server suitable for synchronization found While on the server: [tcwan@netmon tcwan]$ ntpdate -q netmon.cs.usm.my server 161.142.8.104, stratum 2, offset -0.000002, delay 0.02568 26 Oct 11:46:57 ntpdate[3443]: adjust time server 161.142.8.104 offset -0.000002 sec Version-Release number of selected component (if applicable): 4.2.0-7, 4.2.0.a.20040617-4 How reproducible: Always Steps to Reproduce: 1. run ntpdate -q 2. 3. Expected Results: NTP client should be able to sync to NTP server running FC2 Additional info: Similar problem exist with FC3-rc version of ntp (4.2.0.a.20040617-4). Only difference is the format of the ntp.conf file.
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.