Bug 97472

Summary: ntp sees no broadcast or multicast
Product: [Retired] Red Hat Linux Reporter: Tomasz Kepczynski <tomek>
Component: ntpAssignee: Harald Hoyer <harald>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9   
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-07-28 13:50:21 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:
Attachments:
Description Flags
ntp server config none

Description Tomasz Kepczynski 2003-06-16 14:06:32 UTC 
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 14:45:26 UTC 
please attach the ntp.conf
Comment 2 Tomasz Kepczynski 2003-06-16 17:02:21 UTC 
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 09:03:50 UTC 
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 06:47:23 UTC 
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 08:33:27 UTC 
please remove all lines starting with restrict from the server and client
configuration and retry
Comment 6 Tomasz Kepczynski 2003-07-25 09:23:53 UTC 
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.