Bug 139510 - Does not function as broadcast client, unable to listen for broadcasts
Does not function as broadcast client, unable to listen for broadcasts
Product: Fedora
Classification: Fedora
Component: ntp (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Miroslav Lichvar
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2004-11-16 09:42 EST by Davide Bolcioni
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-06-26 10:21:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Davide Bolcioni 2004-11-16 09:42:07 EST
Description of problem:
The log says ...

Nov 16 15:35:22 host ntpd[2386]: Unable to listen for broadcasts, no
broadcast interfaces available

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. service ntp start
2. grep ntp /var/log/messages
Actual results:
The above message.

Expected results:
No such message (and synchronization to broadcast working).

Additional info:
A workaround is to configure the NTP servers DHCP option, or otherwise
configure the client to use the server directly. Googling for the
error message seems to imply that the problem is upstream, but I may
be wrong.
Comment 1 Harald Hoyer 2004-11-16 09:56:12 EST
try multicast client..
Comment 2 Enrico Scholz 2004-11-17 07:36:11 EST

| enable bclient
| disable auth

execute 'sysstat' in 'ntpdc' to detect hints about failures, enable
monitoring and statistics...
Comment 3 Davide Bolcioni 2004-11-17 13:09:41 EST
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.
Comment 4 Sitsofe Wheeler 2004-11-20 09:32:13 EST
Davide are you running a firewall?
Comment 5 Davide Bolcioni 2004-11-22 04:21:22 EST
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.
Comment 6 Davide Bolcioni 2004-11-22 04:26:35 EST
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.
Comment 7 Sitsofe Wheeler 2004-11-22 04:38:29 EST
Is there anything in dmesg with regard to selinux and ntpd ?
Comment 8 Davide Bolcioni 2004-11-22 04:46:11 EST
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.
Comment 9 Sitsofe Wheeler 2004-11-22 05:30:57 EST
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 )


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...
Comment 10 Davide Bolcioni 2004-12-09 05:55:28 EST
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.
Comment 11 Harald Hoyer 2004-12-09 08:51:06 EST
Agreed on the firewall point.
Comment 12 Brad Knowles 2005-02-09 05:25:30 EST
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/
Comment 13 Brian McEntire 2005-08-12 16:50:39 EDT
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

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

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.
Comment 14 Brian McEntire 2005-08-12 19:37:52 EDT
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
  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.
Comment 15 Miroslav Lichvar 2006-06-26 10:21:26 EDT
I can't reproduce this. According to changelog this should be already fixed.
Reopen the bug if you manage to reproduce it.

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