Bug 97472 – ntp sees no broadcast or multicast

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 97472 - ntp sees no broadcast or multicast

Summary:	ntp sees no broadcast or multicast

Status:	CLOSED CURRENTRELEASE

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	ntp (Show other bugs)
Sub Component:
Version:	9
Hardware:	i686 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Harald Hoyer
QA Contact:	Brian Brock
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2003-06-16 10:06 EDT by Tomasz Kepczynski
Modified:	2007-04-18 12:54 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2004-07-28 09:50:21 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
ntp server config (3.07 KB, text/plain) 2003-06-16 13:02 EDT, Tomasz Kepczynski	no flags	Details
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description Tomasz Kepczynski 2003-06-16 10:06:32 EDT

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)

Description of problem:
Redhat 9.0, ntp 4.1.2-0.rc1.2 setup as broadcast client (ntp.conf contains only 
broadcastclient directive). Ntp server is running on Redhat 7.3 with ntp 4.1.1-
1 and broadcasts on local network broadcast address (192.168.253.255) and on 
multicast 224.0.1.1.
ntpq -c peers on client machine returns "No association ID's returned".
I can also see from tcpdump output that client machine after the reception of 
the first broadcast packet is not initiating "training" exchange to calculate 
needed parameters as described in ntp documentation.
See also bug #50247.

Version-Release number of selected component (if applicable):
4.1.2-0.rc1.2

How reproducible:
Always

Steps to Reproduce:
1. Setup ntp broadcast server
2.  Setup ntp broadcast client
3. Run the two and check ntpq -c peers on client machine.
    

Actual Results:  ntp client is not synchronizing to broadcast/multicast ntp 
server.

Additional info:

Comment 1 Harald Hoyer 2003-06-16 10:45:26 EDT

please attach the ntp.conf

Comment 2 Tomasz Kepczynski 2003-06-16 13:02:21 EDT

Created attachment 92434 [details]
ntp server config

ntp server is in an atachment. ntp client was setup in two ways, both single
line:
1. broadcastclient
2. multicastclient 224.0.1.1
I may be wrong with the client setup as I am off site. If there are any
problems please let me know, I'll try to recreate it over weekend.

Tomek

Comment 3 Harald Hoyer 2003-07-01 05:03:50 EDT

How about this? Please read the comments!

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

Comment 4 Tomasz Kepczynski 2003-07-25 02:47:23 EDT

You missed one important note in the original report. According to ntp 
documentation, ntp on reception of the first broadcast/multicast packet will 
initiate training exchange with the server (this is normal ntp exchange where 
peers sends request to server and awaits response). This is not happening and I 
can confirm this using ethereal and ntp debug mode as well.
And just to be on a safe side - at this moment I have RH9 ntp client (as in the 
original report) on a LAN with server where no restrict statements are used 
(RH7.3). It doesn't work.
I suggest this bug is reopened and investigated.

Comment 5 Harald Hoyer 2003-07-25 04:33:27 EDT

please remove all lines starting with restrict from the server and client
configuration and retry

Comment 6 Tomasz Kepczynski 2003-07-25 05:23:53 EDT

I've already done this on both client and server. No luck.
If this makes a difference - I am on a subnet (172.17.30.0/25) with broadcast
address being 172.17.30.127.

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