Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 50247 - ntp sees no broadcast or multicast
ntp sees no broadcast or multicast
Product: Red Hat Linux
Classification: Retired
Component: ntp (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2001-07-28 23:55 EDT by Marty Shannon
Modified: 2007-04-18 12:35 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-08-31 03:48:03 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 Marty Shannon 2001-07-28 23:55:20 EDT
Description of Problem:
4 machines on net, all RHL, all different versions, all
multicast servers and broadcast servers, bcast & mcast traffic observed
with tcpdump, but ntpq claims ntpd doesn't see it.

How Reproducible:

Steps to Reproduce:
1. config multicast client in /etc/ntp.conf
2. config "broadcast version 3" in /etc/ntp.conf
3. step 2, but on another machine

Actual Results:
ntpq reports no servers on either or

Expected Results: and should be marked with 'm' (multicast) instead
of 'u' (unicast), and all other servers bcasting/mcasting should appear
below mcast/ucast address marked with 'm'

Additional Information:
Didn't work in beta2, either, but I wasn't sure it wasn't my problem.
Comment 1 Glen Foster 2001-07-30 15:46:13 EDT
This defect is considered SHOULD-FIX for Fairfax
Comment 2 Tim Waugh 2001-08-10 10:47:25 EDT
'ipchains -n -L' output?
Comment 3 Marty Shannon 2001-08-13 18:44:16 EDT
There is no firewall configured at all on the 3 "client" machines: they should
all see each other, and tcpdump shows that both broadcast and multicast packets
appear on the wire.

In a nano-second of self-doubt, I rechecked the truth of the above statement,
and it is all true.
Comment 4 Alexandre Oliva 2001-08-29 21:51:58 EDT
Same problem here, after an upgrade to roswell, except that I have a firewall
configuration.  Downgrading to Seawolf's ntp-4.0.99k-15 fixed it.
Comment 5 Enrico Scholz 2001-08-30 06:33:35 EDT
It's definitively no firewall-issue. 'strace -p `pidof ntpd`' tells:

| ...
| select(7, [4 5 6], NULL, NULL, {0, 0}) = 1 (in [4], left {0, 0})
| recvfrom(4, "%\4\6\361"..., 500, 0, {sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("")}}, [16]) = 48
| select(7, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
| ...

which means the broadcast-msg is received by ntpd.

Comment 6 Pekka Savola 2001-08-30 15:27:02 EDT
First.. can you trace whether this was happening on RHL71, or before?  With older ntp package?

> recvfrom(4, "%\4\6\361"..., 500, 0, {sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("")}}, [16]) = 48 is way outside  What do you mean?

If this is something that started appearing during the beta cycle, I'd have wanted to bet that around beta1->beta2 DHCP set up
was changed from pump to dhcpcd.  Then, if DHCP is used, MULTICAST interface flag is not set.  This is something you might want to check
just in case.

Comment 7 Enrico Scholz 2001-08-30 15:53:44 EDT
I am not the original poster with the network. The ...5.0/24 is

The ntp-4.0.99k-15.i386.rpm (from 7.1) as broadcastclient works as expected (the
ntp-server is shown by ntpq/pe). 

AFAIR the broadcastclient-feature has *never* worked with ntp-4.0.99m. I do not
have archived versions of the ntp-package available to test when the bug occured
the first time, but I guess it happened at the 4.0.99k -> 4.0.99mrc switch.

Comment 8 Marty Shannon 2001-08-30 15:56:09 EDT
Pekka, note that there are 2 different contributors here, with different net

Anyway, I just checked ifconfig's output on all affected machines, and they all
have both BROADCAST and MULTICAST flags set.  As for RHL71, I see the same
misbehavior: neither broadcast nor multicast servers are reported as such.  I
had not paid ntp any mind during the 7.1 beta cycle, and didn't notice the
misbehavior on 7.1 until I noticed it on the 7.2 betas.
Comment 9 Pekka Savola 2001-08-30 15:58:23 EDT
Oh sorry for the confusion.

Droproot got enabled during that switch, too, I recall.  If ps axuw | grep ntpd shows the process 
owned by 'ntp', please try changing options line in /etc/sysconfig/ntpd to:

OPTIONS="-U root"

(just in case.. to see whether this is an upstream problem..)

Comment 10 Enrico Scholz 2001-08-30 16:29:45 EDT
I have compiled the original 4.0.99k, 4.0.99m-rc2 and 4.1.0 tarball (only at
4.0.99k the glibc22 patch was applied; else I made a ./configure && make).

4.0.99k was the only version handling the broadcastclient-option correctly; the
other two ignore it.
Comment 11 Pekka Savola 2001-08-30 17:15:12 EDT
Shouldn't you be using 'multicastclient'  for listening to multicasts?

Would using plain old 'broadcast version 3" and broadcastclient work, no?
Comment 12 Enrico Scholz 2001-08-30 18:23:50 EDT
The important place seems to be at ntpd/ntp_proto.c:358:

|        if (PKT_MODE(pkt->li_vn_mode) == MODE_BROADCAST &&
|            (rbufp->dstadr == any_interface || !sys_bclient))
|                return;

There `rbufp->dstaddr' is `any_interface':

| $ ntpd -dddd
| ...
| receive: at 47<- restrict 00
| ...

In 99k it was:

|        if ((PKT_MODE(pkt->li_vn_mode) == MODE_BROADCAST &&
|            !sys_bclient))
|                return;

tcpdump tells:
| 00:31:56.084761 >  v3 bcast strat 4 po

I do not know how I can change the rbufp->dstaddr.
Comment 13 Enrico Scholz 2001-08-30 19:11:37 EDT
ntpd bind()s itself to

$ strace -e bind,connect,socket,setsockopt ./ntpd -d
bind(6, {sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("")}}, 16) = 0
bind() fd 6, family 2, port 123, addr, flags=1
setsockopt(6, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
setsockopt(8, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(8, SOL_IP, IP_TOS, [16], 4)  = 0
bind(8, {sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("")}}, 16) = 0
bind() fd 8, family 2, port 123, addr, flags=0
setsockopt(9, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(9, SOL_IP, IP_TOS, [16], 4)  = 0
bind(9, {sin_family=AF_INET, sin_port=htons(123), sin_addr=inet_addr("")}}, 16) = 0
bind() fd 9, family 2, port 123, addr, flags=1
setsockopt(9, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0

This means and are listening on the broadcast
address. Is it somewhere specified which fd will be returned by a
`select(... [6 8 9], ...)' when a broadcast arrives?
Comment 14 Enrico Scholz 2001-08-30 21:52:47 EDT
Reported upstream.

Until I get an answer, I suggest to

        if (PKT_MODE(pkt->li_vn_mode) == MODE_BROADCAST &&
-           (rbufp->dstadr == any_interface || !sys_bclient))
+           (rbufp->dstadr != any_interface || !sys_bclient))

in ntpd/ntpd.c. I can not imagine how a bcast-message can be received by an
other interface than IPADDR_ANY.
Comment 15 Pekka Savola 2001-08-31 03:47:58 EDT
This appears to be broken by 1.54 commit at  
Sun Dec 10 10:19:41 2000 UTC with (partial message):

* ntpd/ntp_proto.c (transmit): Broadcast/manycast cleanup.


I think the idea here was to be able to restrict on which interface broadcast
traffic is accepted from; however, at least the documentation does not reveal
for 'broadcastclient' to accomplish this.

It appears to me (not tested) that multicast would work as-is if you only 
specified it with 'multicastclient'.

I didn't look at this in detail, but I think just removing 'rbufp->dstadr ==
any_interface' check (the same behaviour as before) rather than reversing it,
might be a better intermediate solution.
Comment 16 Harald Hoyer 2001-08-31 03:55:51 EDT
this check is valid, if the multicast bind works... but
bind(9, {sin_family=AF_INET, sin_port=htons(123), 
sin_addr=inet_addr("")}}, 16) = -1 EADDRINUSE (Address already in use)

so, I removed rbufp->dstadr == any_interface


Thank you all very much!
Comment 17 Enrico Scholz 2001-08-31 05:56:29 EDT
FYI, I received the following answer from the authors:

The somewhat fascist restriction was originally to make sure autokey
works as expected, but Linux has different sensibilities than every
other system we can test. I changed the code to be more lenient in the
development code branch.
Comment 18 Tomasz Kepczynski 2003-06-01 11:16:29 EDT
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 ( and on
ntpq -c peers on client machine still returns "No association ID's returned" and
therefore this bug should be reopened.
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.

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