Ping 224.0.0.2 ping: sendmsg: Operation not permitted

When I try: ping 224.0.0.2
I receive: ping: sendmsg: Operation not permitted
Does anyone know a possible reason for this behaviour?
I'm using Ubuntu 5.10 on switched LAN. Is it possible that my LAN
router doesn't support multicast?

-- mario

It works for me. With Ethereal, I can see the packets going out 
(Ethernet to a 4-port switch). Oddly, I can see my router 
answering (in Ethereal) but the ping command says timeout. This 
is also on Ubuntu 5.10, so I don't know why you can't do it. Are 
you running a firewall?

Probably because the computers/routers know that this makes _no_sense_
whatsoever.

The multicast address space is used to assign IPs to multicast
_groups_, ie., that's how a particular multicast stream is identified.
It is _not_ assigned_ to any particular _host_, so just what would you
expect from pinging such an address?

The _source_ of a multicast stream retains the _unicast_ (assigned)
host address of the host originating the stream.  If you are trying to
ping that host, you will need to ping its unicast IP address, _not_ the
group address.  BTW, it is bad form to burden multicast sources with
unnecessary traffic.  Even ping -c1 should be used with discretion and
for good reason.

prg

Why not?

How is this different to pinging a broadcast address?

Paul

I confess to being a bit over dramatic :-)  And harried and hurried
these past two weeks.

I'm pretty sure the OP was trying to _find_ a multicast router and this
method is very unreliable in my experience.  It depends on the router
_joining_ the multicast group 224.0.0.2 (all routers) but that is not a
requirement of the spec.  In fact, it is one of the weakest "shoulds"
that you'll run across.  Especially on larger switched networks, it is
not uncommon for the _switch_ to drop such pings.  IGMP and the
multicast routing protocols have a much better discovery/query
mechanism anyway.  So no ping response to 224.0.0.2 is not conclusive
unless you know _beforehand_ that it should/will respond.

In the OP's case, the returned message is from a firewall rule or acl
perhaps.  Multicast does not send back these sorts of messages.

Since you can't get beyond your local link without a multicast router
on the link, you just try to join the group you're interested in, and
if you think you're not having luck, then contact your sysadmin.  Many
places have pretty strict requirments for joining multicast groups
beyond a few simple ones like NTP.  Many only allow local lan or wan
multicasting and block all outside sources.  So you might find you have
a mulicast router on your link, but it does not forward the group
you're interested in.

You also bring up a point about broadcast pings and, indeed, they are
similar/related.  In fact the mish mash variety of broadcast pings
combined with the use of multicast pings is why some places just
drop/ignore/block and otherwise hinder the use of pings.  And we won't
mention some of the OS peculiarities/quirks/bugs surrounding
broadcast/multicast pings.

But, if everyone implemented a requirement that multicast routers join
224.0.0.2 then we would have different story perhaps.  BTW, even hosts
joining 224.0.01 (all hosts) is not a requirement but at least it is a
convention that just about all nic drivers/OSes observe, IME.

Multicast is a bear and I hope I've not confused what is already a
confusing pile of incomplete specs.  That's why the fans of
multicasting push so hard for ipv6 -- it clears/solves many of the
present ipv4 ambiguities.

cheers,
prg