Bug 32659

Summary:	ntpdate fails to operate, issues false error msg
Product:	[Retired] Red Hat Linux	Reporter:	Neal Pollack <neal>
Component:	ntp	Assignee:	Preston Brown <pbrown>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	7.1	CC:	jakub
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2001-03-26 15:46:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Neal Pollack 2001-03-22 06:33:36 UTC

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.2-0.1.19 i686; Nav)


ntpdate fails to operate as expected, preventing xntpd from
being used.  Fails to sync time, and issues bogus error message about
"ntpdate[11466]: no server suitable for synchronization found"

Reproducible: Always
Steps to Reproduce:
1.become root
2. issue command for ntpdate to sync to public time server.
3.  error is issued.

Compared to systems on net running RH7.0, RH6.2, and Suse 7.0
All others, with same command, sync time to the public server.
	

Actual Results:  [root@localhost /root]# ntpdate ntp.saard.net
21 Mar 21:49:59 ntpdate[11427]: no server suitable for synchronization
found

[root@localhost /root]# ntpdate -v -o version3 ntp.saard.net
21 Mar 21:50:53 ntpdate[11432]: ntpdate 4.0.99k Mon Mar  5 12:08:05 EST
2001 (1)21 Mar 21:50:57 ntpdate[11432]: no server suitable for
synchronization found
[root@localhost /root]# ntpdate ntp.saard.net
21 Mar 21:54:02 ntpdate[11466]: no server suitable for synchronization
found

Expected Results:  using another system NOT running wolverine;
utility:/etc/rc.d # ntpdate ntp.saard.net
21 Mar 21:53:27 ntpdate[10080]: step time server 203.21.37.18 offset
165.845911
sec
utility:/etc/rc.d #

Comment 1 Brian Brock 2001-03-25 23:55:23 UTC

reproducible in our test lab against public ntp servers, and I can't find an
explanation in the package documentation.

Comment 2 Neal Pollack 2001-03-26 00:10:47 UTC

I have noticed on previous versions and systems
that port 123 MUST be open for return traffic,
else NTP will fail.

Could this be a case where default security on
Wolverine with 2.4 kernel and iptables is
blocking this port by default?  I am going to try
to investigate the deafult security settings tonight.

Comment 3 Brian Brock 2001-03-26 00:25:09 UTC

Possibly, yes.  Network configuration of the test machine can be the source of
my error as well, will confirm with a different network config.

Comment 4 Preston Brown 2001-03-26 15:46:52 UTC

This seems to be a glibc issue.  4.0.99k (the 7.0 version) works fine on 7.0, 
but is broken on Wolverine and rawhide, with glibc 2.2.2-7 at least.

Comment 5 Preston Brown 2001-03-26 16:04:24 UTC

further investigation indicates this to be a firewall issue.  "Medium" and 
"High" security firewall settings in the betas/rawhide will result in the 
return port for ntpdate being closed off, thuse the error.  Your firewall will 
have to be adjusted (partially opened) to allow ntpdate to operate properly.