Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 82686 - NTP wont allow client access
Summary: NTP wont allow client access
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ntp
Version: 8.0
Hardware: i386
OS: 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:
Clone Of:
Last Closed: 2003-01-27 14:45:50 UTC

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 (  

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

# 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 mask nomodify notrap noquery
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.