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 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:
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 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
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.