Bug 127150 - ntpdate returns Server Dropped: no data
Summary: ntpdate returns Server Dropped: no data
Alias: None
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
(Show other bugs)
Version: 2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Harald Hoyer
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-07-02 18:44 UTC by Ben Lentz
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-08-25 12:20:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch for ntp.conf (835 bytes, patch)
2004-08-25 11:49 UTC, Paul Howarth
no flags Details | Diff

Description Ben Lentz 2004-07-02 18:44:53 UTC
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET 
CLR 1.1.4322)

Description of problem:
When using ntp-4.2.0-7, every query using 'ntpdate' returns 'no 
server suitable for synchonization found'. Running 'ntpdate -d' shows 
five 'transmit' attempts to the IP address of the NTP server with 
no 'receive' responses. Before you scream 'it's yer firewall', note 
that if I uninstall ntp-4.2.0-7 and reinstall ntp-4.1.2-5 from Fedora 
Core 1, and recycle the same configuration file, everything works 
perfectly without changing *anything* else about the system.

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

How reproducible:

Steps to Reproduce:
1. Install ntp-4.2.0-7
2. Configure a basic /etc/ntp.conf, syncing to an outside time source
3. Start the daemon (service ntpd start)
4. Observe that 'ntpq -c peers' output appears to be good
5. Run 'ntpdate -u localhost'.    

Actual Results:  The above described error was observed. No outside 
hosts can sync.

Expected Results:  ntpdate should be working, as it does with version 

Additional info:

Comment 1 Harald Hoyer 2004-07-13 13:45:05 UTC
cannot reproduce... ntpd needs a couple of minutes to sync, before it
allows clients to get the time... so maybe, you have to wait...

[harald@slash harald]$ sudo /usr/sbin/ntpdate -d localhost
13 Jul 15:41:20 ntpdate[4995]: ntpdate 4.2.0@1.1161-r Thu Mar 11
11:46:40 EST 2004 (1)
Looking for host localhost and service ntp
host found : localhost.localdomain
server, port 123
stratum 3, precision -20, leap 00, trust 000
refid [], delay 0.02565, dispersion 0.00000
transmitted 4, in filter 4
reference time:    c49e5fa0.ba5d28d0  Tue, Jul 13 2004 15:18:24.727
originate timestamp: c49e6500.f3817332  Tue, Jul 13 2004 15:41:20.951
transmit timestamp:  c49e6500.f37ec354  Tue, Jul 13 2004 15:41:20.951
filter delay:  0.02588  0.02567  0.02565  0.02565
         0.00000  0.00000  0.00000  0.00000
filter offset: 0.000104 0.000003 0.000002 0.000002
         0.000000 0.000000 0.000000 0.000000
delay 0.02565, dispersion 0.00000
offset 0.000002

13 Jul 15:41:20 ntpdate[4995]: adjust time server offset
0.000002 sec
[harald@slash harald]$ sudo /usr/sbin/ntpdate -u localhost
Looking for host localhost and service ntp
host found : localhost.localdomain
13 Jul 15:41:26 ntpdate[5000]: adjust time server offset
0.000004 sec
[harald@slash harald]$ rpm -q ntp
[harald@slash harald]$ /usr/sbin/ntpq -c peers
     remote           refid      st t when poll reach   delay   offset
*harryh.home  2 u  473 1024  377   58.467  -15.605
[harald@slash harald]$ sudo /sbin/service ntpd restart
ntpd herunterfahren:                                       [  OK  ]
ntpd: Mit Zeit-Server synchronisieren:                     [  OK  ]
ntpd starten:                                              [  OK  ]
[harald@slash harald]$ /usr/sbin/ntpq -c peers
     remote           refid      st t when poll reach   delay   offset
 harryh.home  2 u    4   64    1    3.663   -0.036

see the "*" in front of the ntp hostname?
This indicates, that your ntp server is synced and ready to serve!!

Comment 2 Miles Sabin 2004-08-01 11:18:47 UTC
I'm not completely clear on what the reporter means by "No outside
hosts can sync" ... but if he means that he has a server configuration
on his FC2 machine, and outside _clients_ can't sync, then there's a
change between ntpd 4.1 and 4.2 which might explain his problem.

It seems that the meaning of the 'notrust' option of restrict has
changed between 4.1 and 4.2 with the result that server configurations
that worked with 4.1 fail silently with 4.2. Details can be found in
the thread starting here,


It also seems as tho' the 'authenticate' keyword which is used in the
default client ntp.conf that's generated during installation has gone
away in 4.2 ... I'm now seeing lines like,

  ntpd[18362]: configure: keyword "authenticate" unknown, line ignored

in /var/log/messages when ntpd is started.


Comment 3 Ben Lentz 2004-08-02 13:40:21 UTC
That was *exactly* the problem. Removing 'authenticate yes' and all 
references of notrust from the config file is allowing things to work 
now, no more inexplicable dropped packets.

I'm not sure why, but I was still having this problem whilst 
connecting to localhost even though I had set "restrict localhost" 
(with nothing following it).

I'm utterly flabbergasted that such a change would be made in the 
interpretation of the config file silently. What ever happened to 
deprecating an old meaning in favor for a different, new meaning? I'm 
glad that setting "notrust" didn't suddenly mean "Remove all files 
from /var".

Comment 4 Paul Howarth 2004-08-25 11:49:29 UTC
Created attachment 103067 [details]
Patch for ntp.conf

This patch removes the "notrust" restriction from ntp clients; this restriction
is no longer needed as its meaning has changed since older versions, and in
fact may prevent clients from accessing the time server if present.

The old "authenticate" keyword is also commented out.

Comment 5 Harald Hoyer 2004-08-25 12:20:07 UTC
fixed in ntp-4.2.0.a.20040616-3

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