This defect is considered SHOULD-FIX for Fairfax

'ipchains -n -L' output?

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.

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.

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("192.168.5.3")}}, [16]) = 48
| select(7, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
| ...

which means the broadcast-msg is received by ntpd.

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("192.168.5.3")}}, [16]) = 48

192.168.5.3 is way outside 192.168.0.0/24.  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.
  

I am not the original poster with the 192.168.0.0/24 network. The ...5.0/24 is
correct.

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.

Pekka, note that there are 2 different contributors here, with different net
configs.

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.

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

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.

Shouldn't you be using 'multicastclient'  for listening to multicasts?

Would using plain old 'broadcast 192.168.0.255 version 3" and broadcastclient work, no?

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 0.0.0.0<-192.168.5.3 restrict 00
| ...


In 99k it was:

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

tcpdump tells:
| 00:31:56.084761 192.168.5.3.ntp > 192.168.5.255.ntp:  v3 bcast strat 4 po


I do not know how I can change the rbufp->dstaddr.

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("0.0.0.0")}}, 16) = 0
bind() fd 6, family 2, port 123, addr 0.0.0.0, flags=1
setsockopt(6, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 8
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("127.0.0.1")}}, 16) = 0
bind() fd 8, family 2, port 123, addr 127.0.0.1, flags=0
socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 9
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("192.168.5.2")}}, 16) = 0
bind() fd 9, family 2, port 123, addr 192.168.5.2, flags=1
setsockopt(9, SOL_SOCKET, SO_BROADCAST, [1], 4) = 0
...


This means 0.0.0.0 and 192.168.5.2 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?

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))
                return;

in ntpd/ntpd.c. I can not imagine how a bcast-message can be received by an
other interface than IPADDR_ANY.

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.

(http://maccarony.ntp.org/cgi-bin/cvsweb.cgi/ntp/ntpd/ntp_proto.c)

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

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

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.

this check is valid, if the multicast bind works... but
bind(9, {sin_family=AF_INET, sin_port=htons(123), 
sin_addr=inet_addr("224.0.1.1")}}, 16) = -1 EADDRINUSE (Address already in use)

so, I removed rbufp->dstadr == any_interface

4.1.0-2

Thank you all very much!

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.

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