Bug 82686 - NTP wont allow client access
Summary: NTP wont allow client access
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ntp (Show other bugs)
(Show other bugs)
Version: 8.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-24 21:26 UTC by Alex Weeks
Modified: 2007-04-18 16:50 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-01-27 14:45:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Alex Weeks 2003-01-24 21:26:46 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020830

Description of problem:
I am trying to setup an NTP server on my network.  The server appears to be
connecting and syncing with a remote server (ntp0.cornell.edu).  

I then modified the ntp.conf file to allow other systems on my lan to sync up to
this server.  When I try to sync them to this server they return an error "no
server suitable for syncronization found."  When I do an nmap on this system
port 123 does not come up, even when I specifically scan that port (nmap -p123) is says "closed".  I have confirmed that my firewall has
port 123 open.

What have I done wrong?  Is this a Bug?  Was there somethig in xinetd that I
need to configure?


Here is my ntp.conf file:

# Prohibit general access to this service.
#restrict default ignore

# Permit all access over the loopback interface.  This could
# be tightened as well, but to do so would effect some of
# the administrative functions.

# -- CLIENT NETWORK -------
# Permit systems on this network to synchronize with this
# time service.  Do not permit those systems to modify the
# configuration of this service.  Also, do not use those
# systems as peers for synchronization.
restrict mask notrust nomodify notrap

# or remove the default restrict line
# Permit time synchronization with our time source, but do not
# permit the source to query or modify the service on this system.

# restrict mytrustedtimeserverip mask nomodify notrap noquery
server ntp0.cornell.edu

# multicastclient                       # listen on default
# restrict mask notrust nomodify notrap
# restrict mask notrust nomodify notrap

# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available. The
# default stratum is usually 3, but in this case we elect to use stratum
# 0. Since the server line does not have the prefer keyword, this driver
# is never used for synchronization, unless no other other
# synchronization source is available. In case the local host is
# controlled by some external source, such as an external oscillator or
# another protocol, the prefer keyword would cause the local host to
# disregard all other synchronization sources, unless the kernel
# modifications are in use and declare an unsynchronized condition.
server     # local clock
fudge stratum 10

# Drift file.  Put this in a directory which the daemon can write to.
# No symbolic links allowed, either, since the daemon updates the file
# by creating a temporary in the same directory and then rename()'ing
# it to the file.
driftfile /etc/ntp/drift
broadcastdelay  0.008

# Authentication delay.  If you use, or plan to use someday, the
# authentication facility you should make the programs in the auth_stuff
# directory and figure out what this number should be on your machine.
#authenticate yes
authenticate no

# Keys file.  If you want to diddle your server at run time, make a
# keys file (mode 600 for sure) and define the key number to be
# used for making requests.
# systems might be able to reset your clock at will. Note also that
# ntpd is started with a -A flag, disabling authentication, that
# will have to be removed as well.
keys            /etc/ntp/keys

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.setup ntp.conf file
2.start ntpd 
3.try to sync from client

Additional info:

Comment 1 Harald Hoyer 2003-01-27 11:49:28 UTC
is this line correct?
restrict mask notrust nomodify notrap
means you have as your local LAN?

Comment 2 Alex Weeks 2003-01-27 13:29:15 UTC
That is correct.

Comment 3 Harald Hoyer 2003-01-27 13:39:18 UTC
oh... you have forgotten:

Comment 4 Alex Weeks 2003-01-27 14:29:43 UTC
Nope, that didn't fix it.

Here is a copy of my log after I started ntpd:

27 Jan 09:20:35 ntpd[2159]: frequency initialized -102.166 from /etc/ntp/drift
27 Jan 09:20:35 ntpd[2159]: running as uid(38)/gid(38) euid(38)/egid(38).
27 Jan 09:20:35 ntpd[2159]: system event 'event_restart' (0x01) status
'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
27 Jan 09:20:35 ntpd[2162]: signal_no_reset: signal 17 had flags 4000000
27 Jan 09:20:44 ntpd[2159]: peer event 'event_reach' (0x84)
status 'unreach, conf, 1 event, event_reach' (0x8014)
27 Jan 09:20:51 ntpd[2159]: peer LOCAL(0) event 'event_reach' (0x84) status
'unreach, conf, 1 event, event_reach' (0x8014)

I even tried shutting down my firewall and leaving everything open.

Comment 5 Harald Hoyer 2003-01-27 14:45:50 UTC
well... read the documentation in /usr/share/doc/ntp-*/

Comment 6 Mehdi FARHAT 2003-02-04 00:51:05 UTC
I have the same "bug?"
so i searched a bit and found something interesting....

1/ my conf (grep -v -e '^[[:blank:]]*#' -e '^$' /etc/ntp.conf)
restrict default ignore
restrict mask notrust nomodify notrap
restrict ntp.obspm.fr mask nomodify notrap noquery
server ntp.obspm.fr
server     # local clock
fudge stratum 10
driftfile /etc/ntp/drift
broadcastdelay  0.008
authenticate yes
keys            /etc/ntp/keys

2/ my port is open (Alex Weeks forget to use udp with nmap)
[root@mars root]# nmap -sU -p123
Port       State       Service
123/udp    open        ntp

3/ ntp sync work fine in local
[root@mars root]# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
*   2 u   33  128  377   54.228  -33.370  29.775     LOCAL(0)        10 l   28   64  377    0.000    0.000   0.002

4/ tcpdump
[root@mars root]# tcpdump -n -i any port 123
tcpdump: listening on any
01:36:04.447293 >  v3 sym_act strat 3 poll 
10 prec -6

its very interesting cuz my client a poor window$ XP use NTPv3 and not NTPv4
the server never respond to the query.
after an install of YATS32 (a NTPv4 client for XP) i retry to sync time.

[root@mars root]# tcpdump -n -i any port 123
tcpdump: listening on any
01:39:24.188188 >  v4 client strat 0 poll 0 
prec 0
01:39:24.188576 >  v4 server strat 3 poll 0 
prec -19 (DF) [tos 0x10] 

All work fine !!! The client take a responce from server :)

now the query is ... It's a bug? or How activate the NTPv3 compatibility ?
NB: Extract from ntp doc >>> "it continues the tradition of retaining backwards 
compatibility with older versions, including NTPv3"

Have a nice day :)

Comment 7 Mark Cornick 2003-02-06 04:42:52 UTC
The default setting in /etc/sysconfig/ntpd makes ntpd run as user "ntp". I can
reproduce this error exactly with this configuration. Removing "-U ntp" from
OPTIONS in /etc/sysconfig/ntpd, causing ntpd to run as root, fixes the behavior
described above.

Comment 8 Harald Hoyer 2003-02-07 10:01:41 UTC
Mark Cornick wrote:
> On Thu, Feb 06, 2003 at 06:19:41PM +0100, Harald Hoyer wrote:
>>hmm, you have to wait at least 3 minutes until ntpd gets synced with the 
>>  real time server..
> yeah, that makes sense. ntpdate is now working from to
>, after the ntpd has been running for a while. I don't think
> that's mentioned anywhere in the public bug report, maybe you ought to
> suggest that to the other people who reported this.
> Thanks for your help,
> --mark

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