Red Hat Bugzilla – Bug 97472
ntp sees no broadcast or multicast
Last modified: 2007-04-18 12:54:51 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
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):
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
please attach the ntp.conf
Created attachment 92434 [details]
ntp server config
ntp server is in an atachment. ntp client was setup in two ways, both single
2. multicastclient 220.127.116.11
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.
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
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.
please remove all lines starting with restrict from the server and client
configuration and retry
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.