try multicast client..

try

| enable bclient
| disable auth

execute 'sysstat' in 'ntpdc' to detect hints about failures, enable
monitoring and statistics...

Thank you Enrico, but I already had the above lines. I am now
investigating multicast; blindly replacing broadcastclient with
multicastclient got rid of the error message, but ntpq shows no peers
even after a few hours.

Davide are you running a firewall?

Yes, I am running lokkit and the problem is right there. I just had a
look with iptables -L -v and found no rule for listening on the
broadcast interface, port 123. When in "client" mode, the ntp daemon
initiates the UDP exchange which is then tracked by the firewall, I
guess (empirically: this works). So I can either use client mode with
lokkit-generated firewall and the DHCP-generated ntp.conf, or use
broadcast client mode with my own ntp.conf but without or with a
manually modified firewall.

I just tried to disable lokkit, verified using iptables -L that no
rule is in the way, but I still get the "Unable to listen for
broadcasts, no broadcast interfaces available" message in the log.

Is there anything in dmesg with regard to selinux and ntpd ?

Nothing beyond the message above, and it seems that the message itself
is spurious anyway: a grep of lsof output shows that ntpd is indeed
listening on the broadcast interface, and in due time ntpstat confirms
that synchronization occurs. So it seems that the lokkit generated
script is the culprit; I guess the nptd startup script should parse
the ntp configuration, detect the use of broadcast client mode and
attempt to tweak the lokkit-generated firewall rules accordingly.

I was just taking a look at system-config-date and there is an "Enable
NTP Broadcast" tickbox there. Unfortunately the documentation is out
of date and has screenshots of an old version of that tool so it is
not actually clear whether ticking that box sets this particular
machine to SEND broadcasts or whether it sets it to LISTEN to broadcasts.

However there is a wonderful warning at the bottom of the help page:
(from file:///usr/share/doc/system-config-date-1.7.11/time-date.html )

Warning

If you configured a medium or high security level during installation
or with Security Level Configuration Tool, the firewall rules will
block the connection to the NTP port.


I have no idea whether this warning is 100% accurate. As Davide
mentioned I was under the impression that so long as the computer was
initialiting the connection to another ntp server it was pass by the
firewall thanks to connectin tracking.

Either way the docs need overhauling to indicate under what
circumstances the firewall will intevene AND how to work around the
problem (e.g. add ntp:udp to system-config-security ). Perhaps I
should spin off the out of sync docs into another bug...

It seems to me that there are actually two separate problems here. First,
operation as broadcast client does not work. Second, albeit fairly minor, when
attempting to diagnose the first problem the unlucky admin is sent on the wrong
track by the "Unable to listen for broadcasts, no broadcast interfaces
available" message in the log. This second bug belongs squarely in the NTP
package; the first bug may apply to lokkit, and possibly system-config-date
(which did not enter into my picture as the host was supposed to replace aging
hardware, so I just migrated the configuration files without clickety-clicking
my way through configuration wizards).

In other words, I cannot see what changes to ntp would correct the problem with
lokkit not allowing NTP broadcast, except by having ntp parse iptables output,
recognize the problem, and fix it (in the /etc/init.d/ntp script). This kind of
defeats some of the purpose in lokkit, however, as what I see when configuring
lokkit is no longer what I get to happen and there is no warning about this.

Off the top of my head, I would say that lokkit might have to be revised in
order to have a list of well known daemons (or packages) which add their own
rules in well known chains.

Agreed on the firewall point.

Can't help  you on the firewall issues.  You're going to have to get those resolved through 
other channels.

This problem has since been fixed for Unix clients.  See <http://bugzilla.ntp.org/
show_bug.cgi?id=267>.

I am experiencing this problem in RHEL4 WS as well. My situation is exactly like
the opening comments in this bug.

My /etc/ntp.conf file contains:

broadcast client
disable auth

When I start ntpd, /var/log/messages contains: 

ntpd[11333]: Unable to listen for broadcasts, no broadcast interfaces available


This was confusing because at first, ntpd was not working at all as a broadcast
client. I upgraded this machine from RHEL 3 and it kept my old ntp.conf file.
That file contained: 'authenticate no' ... which is no longer understood by ntp
4.2.0.

After replacing 'authenticate no' with 'disable auth' in /etc/ntp.conf, the host
is working as a broadcast client but still logs that warning message to
/var/log/messages.

Sorry if it is not appropriate to put a RHEL 4 bug in the FC3 bug, when I
searched bugzilla.redhat.com, this is the bug that came up that included
'broadcast' in the summary.

Follow-up to what I previously said:

I tried to reproduce the problem (by putting the old/incorrect config back). I
couldn't reproduce it at first. With the incorrect config file in place, I was
getting the 'configure: keyword "authenticate" unknown' warning but not the
'Unable to listen for broadcasts, no broadcast interfaces available' error.

I even tried rebooting the computer to make sure it wasn't a case that ntpd
worked okay after it had been made to work once. Rebooting did not bring back
the 'no broadcast interfaces' message.

I decided to put the correct configuration file back and try to start two ntpd
daemons at this same time.
  service ntpd stop
  ntpd
  service ntpd start

Shutting down ntpd:                                        [  OK  ]
ntpd: Synchronizing with time server:                      [FAILED]
Starting ntpd:                                             [  OK  ]

  * This seems like an error in the RHEL 4 boot script, should it really say OK
for ntpd starting when another is already running?

# ps -ef|grep ntpd
root      3766     1  0 19:18 ?        00:00:00 ntpd
ntp       3812     1  0 19:19 ?        00:00:00 ntpd -u ntp:ntp -p
/var/run/ntpd.pid -g


With two ntpd's running, I was able to recreate the 'no broadcast interfaces'
error message. Perhaps part of the original problem was having an ntpd running
by accident...

On the other hand, in this latter case, the warning is now preceeded in the log
file by bind() warnings:

bind() fd 5, family 2, port 123, addr <censored>, in_classd=0 flags=8 fails:
Address already in use

* I checked back though my logs and when I was initially getting those 'no
broadcast interfaces available' messages, the were no bind() warnings near them
in my syslogs.

I'm thoroughly confused now  :-)  ... but ntpd is working. I hope this helps
someone out, wish I could've isolated it and reproduced it better.

I can't reproduce this. According to changelog this should be already fixed.
Reopen the bug if you manage to reproduce it.