Multicast not appearing to work

I am running FC4 on the 2.6 kernel, multicast is enabled in the build,
yet it doesn't seem to be working. If I add the route to 224.0.0.0
with netmask 240.0.0.0 it shows up in the routing table. I've also
tried using "ip route add multicast 224.0.0.0/4 dev eth0" and that also
shows up. When I ping to 224.0.0.1 it never responds. I found some
other stuff to try, nsdr, it seems fine, but finds nothing running, but
that may be something with our firewalls. I have no firewalls running
on my machine. Other machines on the network do respond to the ping.
If I do an "ifconfig eth0" it shows up with MULTICAST.

If anyone has any ideas, I would love to try them.

Thanks.

Debbie wrote:
> I am running FC4 on the 2.6 kernel, multicast is enabled in the build,
> yet it doesn't seem to be working. If I add the route to 224.0.0.0
> with netmask 240.0.0.0 it shows up in the routing table. I've also
> tried using "ip route add multicast 224.0.0.0/4 dev eth0" and that also
> shows up. When I ping to 224.0.0.1 it never responds. I found some
> other stuff to try, nsdr, it seems fine, but finds nothing running, but
> that may be something with our firewalls. I have no firewalls running
> on my machine. Other machines on the network do respond to the ping.
> If I do an "ifconfig eth0" it shows up with MULTICAST.
>
> If anyone has any ideas, I would love to try them.

Multicast addresses are not assigned to individual machines, so you
can't ping them. Multicast addresses are "groups" to which individual
machines "subscribe."

If one machine is multicasting to a certain group on a local network
segment, then other machines which have joined that group pick up the
traffic. What the subscribers do with the packets depends on the
application that did the subscribing.

If you have a multicaster on a different network segment from the
subscribers, then the routers in between need to be multicast-aware. In
either situation, you probably also need something to be a multicast
querier. The querier asks everything that subscribes to a group to
state its subscriptions at regular intervals, otherwise they time out.

I think your first step (after understanding multicast better) would be
to get an actual multicast client and an associated streamer. Compiling
a kernel with multicast enabled just means it supports multicast clients
and streamers.

Allen Kistler wrote:
> Debbie wrote:
> > I am running FC4 on the 2.6 kernel, multicast is enabled in the build,
> > yet it doesn't seem to be working. If I add the route to 224.0.0.0
> > with netmask 240.0.0.0 it shows up in the routing table. I've also
> > tried using "ip route add multicast 224.0.0.0/4 dev eth0" and that also
> > shows up. When I ping to 224.0.0.1 it never responds. I found some
> > other stuff to try, nsdr, it seems fine, but finds nothing running, but
> > that may be something with our firewalls. I have no firewalls running
> > on my machine. Other machines on the network do respond to the ping.
> > If I do an "ifconfig eth0" it shows up with MULTICAST.
> >
> > If anyone has any ideas, I would love to try them.
>
> Multicast addresses are not assigned to individual machines, so you
> can't ping them. Multicast addresses are "groups" to which individual
> machines "subscribe."
>
> If one machine is multicasting to a certain group on a local network
> segment, then other machines which have joined that group pick up the
> traffic. What the subscribers do with the packets depends on the
> application that did the subscribing.
>
> If you have a multicaster on a different network segment from the
> subscribers, then the routers in between need to be multicast-aware. In
> either situation, you probably also need something to be a multicast
> querier. The querier asks everything that subscribes to a group to
> state its subscriptions at regular intervals, otherwise they time out.
>
> I think your first step (after understanding multicast better) would be
> to get an actual multicast client and an associated streamer. Compiling
> a kernel with multicast enabled just means it supports multicast clients
> and streamers.

I thought that if a system is "multicast enabled" that it would reply
to pings on 224.0.0.1? The machines are on the same network, it sees
the ping request, yet it does not respond. Other machines on the
network do respond to the ping request.

Debbie wrote:
> Allen Kistler wrote:
>> Debbie wrote:
>>> I am running FC4 on the 2.6 kernel, multicast is enabled in the build,
>>> yet it doesn't seem to be working. If I add the route to 224.0.0.0
>>> with netmask 240.0.0.0 it shows up in the routing table. I've also
>>> tried using "ip route add multicast 224.0.0.0/4 dev eth0" and that also
>>> shows up. When I ping to 224.0.0.1 it never responds. I found some
>>> other stuff to try, nsdr, it seems fine, but finds nothing running, but
>>> that may be something with our firewalls. I have no firewalls running
>>> on my machine. Other machines on the network do respond to the ping.
>>> If I do an "ifconfig eth0" it shows up with MULTICAST.
>>>
>>> If anyone has any ideas, I would love to try them.
>> Multicast addresses are not assigned to individual machines, so you
>> can't ping them. Multicast addresses are "groups" to which individual
>> machines "subscribe."
>>
>> If one machine is multicasting to a certain group on a local network
>> segment, then other machines which have joined that group pick up the
>> traffic. What the subscribers do with the packets depends on the
>> application that did the subscribing.
>>
>> If you have a multicaster on a different network segment from the
>> subscribers, then the routers in between need to be multicast-aware. In
>> either situation, you probably also need something to be a multicast
>> querier. The querier asks everything that subscribes to a group to
>> state its subscriptions at regular intervals, otherwise they time out.
>>
>> I think your first step (after understanding multicast better) would be
>> to get an actual multicast client and an associated streamer. Compiling
>> a kernel with multicast enabled just means it supports multicast clients
>> and streamers.
>
> I thought that if a system is "multicast enabled" that it would reply
> to pings on 224.0.0.1? The machines are on the same network, it sees
> the ping request, yet it does not respond. Other machines on the
> network do respond to the ping request.

Hmm, I've worked with multicast a bit for streaming video, so I'd say
I'm at least multicast-skilled, but not multicast-god, so I could be
wrong, but ...

I'd never heard that pinging a multicast address _should_ produce
replies. The ping executable isn't likely set up to handle them,
anyway, even if they occurred. There is a trick you can do to that
other OS to ping a _broadcast_ address and capture all the replies with,
say, tcpdump. (FWIW spoofing the source addr of a ping to a bcast addr
is one way to DOS a machine, so it's a bad thing when machines reply to
bcast pings. The same should apply to mcast.)

When you say other machines reply, are they replying to a multicast
ping? How does ping display the results? What OS are they?

Allen Kistler wrote:
> Debbie wrote:
> > Allen Kistler wrote:
> >> Debbie wrote:
> >>> I am running FC4 on the 2.6 kernel, multicast is enabled in the build,
> >>> yet it doesn't seem to be working. If I add the route to 224.0.0.0
> >>> with netmask 240.0.0.0 it shows up in the routing table. I've also
> >>> tried using "ip route add multicast 224.0.0.0/4 dev eth0" and that also
> >>> shows up. When I ping to 224.0.0.1 it never responds. I found some
> >>> other stuff to try, nsdr, it seems fine, but finds nothing running, but
> >>> that may be something with our firewalls. I have no firewalls running
> >>> on my machine. Other machines on the network do respond to the ping.
> >>> If I do an "ifconfig eth0" it shows up with MULTICAST.
> >>>
> >>> If anyone has any ideas, I would love to try them.
> >> Multicast addresses are not assigned to individual machines, so you
> >> can't ping them. Multicast addresses are "groups" to which individual
> >> machines "subscribe."
> >>
> >> If one machine is multicasting to a certain group on a local network
> >> segment, then other machines which have joined that group pick up the
> >> traffic. What the subscribers do with the packets depends on the
> >> application that did the subscribing.
> >>
> >> If you have a multicaster on a different network segment from the
> >> subscribers, then the routers in between need to be multicast-aware. In
> >> either situation, you probably also need something to be a multicast
> >> querier. The querier asks everything that subscribes to a group to
> >> state its subscriptions at regular intervals, otherwise they time out.
> >>
> >> I think your first step (after understanding multicast better) would be
> >> to get an actual multicast client and an associated streamer. Compiling
> >> a kernel with multicast enabled just means it supports multicast clients
> >> and streamers.
> >
> > I thought that if a system is "multicast enabled" that it would reply
> > to pings on 224.0.0.1? The machines are on the same network, it sees
> > the ping request, yet it does not respond. Other machines on the
> > network do respond to the ping request.
>
> Hmm, I've worked with multicast a bit for streaming video, so I'd say
> I'm at least multicast-skilled, but not multicast-god, so I could be
> wrong, but ...
>
> I'd never heard that pinging a multicast address _should_ produce
> replies. The ping executable isn't likely set up to handle them,
> anyway, even if they occurred. There is a trick you can do to that
> other OS to ping a _broadcast_ address and capture all the replies with,
> say, tcpdump. (FWIW spoofing the source addr of a ping to a bcast addr
> is one way to DOS a machine, so it's a bad thing when machines reply to
> bcast pings. The same should apply to mcast.)
>
> When you say other machines reply, are they replying to a multicast
> ping? How does ping display the results? What OS are they?

If I ping to 224.0.0.1 the reply is sent to my host. I am able to see
it with wireshark/ethereal. I have a client and server using multicast
and they seem to work fine. But from what I've read, if I have the
route enabled for 224.0.0.0 that should be enough to be considered
multicast enabled, even if no specific application is listening with
any multicast enabled sockets. I thought that was the standard test to
see if there are any machines that are multicast enabled. Then again,
if you read enough web pages you'll believe anything is true.

Here is a link to one of multiple different web pages that talk about
pinging with multicast.

http://hmyblog.vmmatrix.net/lna/0131...7lev1sec2.html

I guess it just doesn't work the way that I understood it should.

The machines answering the pings are running various versions of linux.

On 5 Oct 2006, in the Usenet newsgroup comp.os.linux.misc, in article
<(E-Mail Removed) .com>, Debbie wrote:

>I did post this on comp.os.linu.net, so sorry for the duplicate, but
>I'm still lost.

If you look at the charters for the newsgroups, "comp.os.linux.misc" is
for postings that _don't_ belong in one of the other sixteen regular
comp.os.linux.* newsgroups. It clearly is a networking question, and thus
shouldn't be here.

>When I ping to 224.0.0.1 it never responds.

1122 Requirements for Internet Hosts - Communication Layers. R.
Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated by
RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)

RFC1122 section 3.2.2.6 Echo Request/Reply: RFC-792

An ICMP Echo Request destined to an IP broadcast or IP
multicast address MAY be silently discarded.

DISCUSSION:
This neutral provision results from a passionate debate
between those who feel that ICMP Echo to a broadcast
address provides a valuable diagnostic capability and
those who feel that misuse of this feature can too
easily create packet storms.

You may also want to look at RFC1112 and RFC1301,

1112 Host extensions for IP multicasting. S.E. Deering. August 1989.
(Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by
RFC2236) (Also STD0005) (Status: STANDARD)

1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K.
Marzullo. February 1992. (Format: TXT=91976 bytes) (Status:
INFORMATIONAL)

Old guy

On Wed, 04 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in
article <uMTUg.9740$(E-Mail Removed)>, Allen Kistler wrote:

>I'd never heard that pinging a multicast address _should_ produce
>replies.

RFC1122 section 3.2.2.6 - (see my reply to her post to comp.os.linux.misc
as "Subject: Multicast enabled but not responding to Pings")

>The ping executable isn't likely set up to handle them, anyway, even if
>they occurred. There is a trick you can do to that other OS to ping a
>_broadcast_ address and capture all the replies with, say, tcpdump.

Not needed. The ICMP Echo request is sent to (destination) the broadcast
or multicast address, but the _source_ is the host that is pinging - thus
each host (if so enabled) will respond with a unicast ICMP Echo Reply.
The ping application merely reports each reply, and the stats might say

1 packets transmitted, 250 packets received, 0% packet loss

Note however that not all operating systems will respond to a broadcast
or multicast ping, and ping itself may be disabled on the individual
systems - either by firewall or by a kernel variable in /proc/net/

>(FWIW spoofing the source addr of a ping to a bcast addr is one way to
>DOS a machine, so it's a bad thing when machines reply to bcast pings.
>The same should apply to mcast.)

Hence the Discussion paragraph in RFC1122 section 3.2.2.6. None of our
systems respond to a broadcast ping, and our routers drop packets to
the subnet, network, and global broadcast addresses. I must admit I've
never tried to ping a multicast address, but a quicky test here also
gets no responses.

Old guy

Moe Trin wrote:
> On 5 Oct 2006, in the Usenet newsgroup comp.os.linux.misc, in article
> <(E-Mail Removed) .com>, Debbie wrote:
>
> >I did post this on comp.os.linu.net, so sorry for the duplicate, but
> >I'm still lost.
>
> If you look at the charters for the newsgroups, "comp.os.linux.misc" is
> for postings that _don't_ belong in one of the other sixteen regular
> comp.os.linux.* newsgroups. It clearly is a networking question, and thus
> shouldn't be here.
>
> >When I ping to 224.0.0.1 it never responds.
>
> 1122 Requirements for Internet Hosts - Communication Layers. R.
> Braden, Ed.. October 1989. (Format: TXT=295992 bytes) (Updated by
> RFC1349, RFC4379) (Also STD0003) (Status: STANDARD)
>
> RFC1122 section 3.2.2.6 Echo Request/Reply: RFC-792
>
> An ICMP Echo Request destined to an IP broadcast or IP
> multicast address MAY be silently discarded.
>
> DISCUSSION:
> This neutral provision results from a passionate debate
> between those who feel that ICMP Echo to a broadcast
> address provides a valuable diagnostic capability and
> those who feel that misuse of this feature can too
> easily create packet storms.
>
> You may also want to look at RFC1112 and RFC1301,
>
> 1112 Host extensions for IP multicasting. S.E. Deering. August 1989.
> (Format: TXT=39904 bytes) (Obsoletes RFC0988, RFC1054) (Updated by
> RFC2236) (Also STD0005) (Status: STANDARD)
>
> 1301 Multicast Transport Protocol. S. Armstrong, A. Freier, K.
> Marzullo. February 1992. (Format: TXT=91976 bytes) (Status:
> INFORMATIONAL)
>
> Old guy

OK, maybe a better question would be how come my machine does not
respond to pings on 224.0.0.1 I have no firewalls set, iptables is
empty. Is that a kernel configuration command, or is it generally
disabled with iptables? I know that it is multicast enabled and the
routes are set correctly.

On 6 Oct 2006, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) om>, Debbie wrote:

>OK, maybe a better question would be how come my machine does not
>respond to pings on 224.0.0.1 I have no firewalls set, iptables is
>empty. Is that a kernel configuration command, or is it generally
>disabled with iptables? I know that it is multicast enabled and the
>routes are set correctly.

Lessee, you said you were using FC4, right? That would be a 2.6.11-1.1369_FC4
out of box, and 2.6.17-1.2142_FC4 if you are keeping it up to date. Or are you
rolling your own? If so, which kernnel and what options did you choose? I'm
not running Fedora on any of the boxes I have access to, and none of my systems
respond to a Multicast ping, even if they are subscribed to a multicast
service. Looking at the /proc/ filesystem on several 2.6.1x kernels, the
only thing I can see that _might_ be related is
/proc/sys/net/ipv4/icmp_echo_ignore_broadcasts (though it seems to have
no effect on the two boxes I tried).

Google does show some interesting things on multicast-ping related to
keep-alives on Apache/Tomcat - but that isn't applicable to us.

I get confused by RFC1112 section 7.2 relating to IGMP, but you may also
want to check /proc/net/igmp/ to see if you belong to that group. It's not
required, and that could mess up reception of multicast.

Old guy