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
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: ntp
Version: 8.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
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:
Environment:
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 (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
192.168.0.80 -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?

thanks


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.
#restrict 127.0.0.1

# -- 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 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap

# --- OUR TIMESERVERS -----
# 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 255.255.255.255 nomodify notrap noquery
server ntp0.cornell.edu

# --- NTP MULTICASTCLIENT ---
# multicastclient                       # listen on default 224.0.1.1
# restrict 224.0.1.1 mask 255.255.255.255 notrust nomodify notrap
# restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap

# --- GENERAL CONFIGURATION ---
#
# 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  127.127.1.0     # local clock
fudge   127.127.1.0 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.
#
# PLEASE DO NOT USE THE DEFAULT VALUES HERE. Pick your own, or remote
# 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:
Always

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 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
means you have 192.168.0.1-254 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:
broadcast 192.168.0.0


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 132.236.56.250 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 127.0.0.1 
restrict 192.168.0.0 mask 255.255.255.0 notrust nomodify notrap
restrict ntp.obspm.fr mask 255.255.255.255 nomodify notrap noquery
server ntp.obspm.fr
server  127.127.1.0     # local clock
fudge   127.127.1.0 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 127.0.0.1
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
==============================================================================
*145.238.110.68  145.238.110.49   2 u   33  128  377   54.228  -33.370  29.775
 127.127.1.0     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 192.168.0.200.ntp > 192.168.0.1.ntp:  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 192.168.0.200.3442 > 192.168.0.1.ntp:  v4 client strat 0 poll 0 
prec 0
01:39:24.188576 192.168.0.1.ntp > 192.168.0.200.3442:  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 192.168.2.2 to
> 192.168.2.1, 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.