This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 50247 - ntp sees no broadcast or multicast
ntp sees no broadcast or multicast
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: ntp (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Brian Brock
:
Depends On:
Blocks:
  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:
Environment:
Last Closed: 2001-08-31 03:48:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Marty Shannon 2001-07-28 23:55:20 EDT
Description of Problem:
4 machines on net 192.168.0.0/24, 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:
100%

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

Actual Results:
ntpq reports no servers on either 224.0.1.1 or 192.168.0.255

Expected Results:
224.0.1.1 and 192.168.0.255 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("192.168.5.3")}}, [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("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.
  

Comment 7 Enrico Scholz 2001-08-30 15:53:44 EDT
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.

Comment 8 Marty Shannon 2001-08-30 15:56:09 EDT
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.
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 192.168.0.255 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 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.
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("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?
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))
                return;

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.

(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.
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("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!
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 (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.

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