Bug 137143 - client fails to obtain ntp data from NTP server
client fails to obtain ntp data from NTP server
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
2
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jiri Ryska
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-10-25 23:52 EDT by TC
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-18 23:59:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
NTP Server Configuration (3.29 KB, text/plain)
2004-10-26 00:04 EDT, TC
no flags Details
NTP Client configuration (2.94 KB, text/plain)
2004-10-26 00:05 EDT, TC
no flags Details
NTP Server config (for 4.2.0.a.20040617-4) (2.61 KB, text/plain)
2004-10-26 00:06 EDT, TC
no flags Details
NTP Client config (for 4.2.0.a.20040617-4) (2.35 KB, text/plain)
2004-10-26 00:06 EDT, TC
no flags Details

  None (edit)
Description TC 2004-10-25 23:52:09 EDT
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.
Comment 1 TC 2004-10-26 00:04:30 EDT
Created attachment 105769 [details]
NTP Server Configuration
Comment 2 TC 2004-10-26 00:05:00 EDT
Created attachment 105770 [details]
NTP Client configuration
Comment 3 TC 2004-10-26 00:06:19 EDT
Created attachment 105771 [details]
NTP Server config (for 4.2.0.a.20040617-4)
Comment 4 TC 2004-10-26 00:06:54 EDT
Created attachment 105772 [details]
NTP Client config (for 4.2.0.a.20040617-4)
Comment 5 Harald Hoyer 2005-01-10 09:54:28 EST
Using the "-d" option will give us more output. Please provide:

# ntpdate -d -q netmon.cs.usm.my
Comment 6 TC 2005-01-10 20:24:24 EST
[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@1.1190-r 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
Comment 7 TC 2005-01-10 20:26:18 EST
[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@1.1190-r 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
Comment 8 TC 2005-01-10 20:41:53 EST
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                   *:*
Comment 9 Harald Hoyer 2005-01-11 05:46:16 EST
are you sure the firewall does not drop ntp udp packets?
161.142.8.104: Server dropped: no data
Comment 10 TC 2005-01-12 00:22:16 EST
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.
Comment 11 TC 2005-01-12 01:09:51 EST
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@1.1190-r 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
Comment 12 Harald Hoyer 2005-01-12 04:24:20 EST
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.
Comment 13 TC 2005-01-12 23:41:46 EST
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
Comment 14 Brad Knowles 2005-02-09 05:18:12 EST
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@ntp.isc.org.

I don't think that this is anything particularly unique to Redhat.
Comment 15 Matthew Miller 2005-04-26 12:38:38 EDT
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.
Comment 16 TC 2005-05-18 23:59:12 EDT
I think this issue can be closed and the workaround documented.

Note You need to log in before you can comment on or make changes to this bug.