Bug 239563 - can't disable multicast
Summary: can't disable multicast
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.4
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Andy Gospodarek
QA Contact: Martin Jenner
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-05-09 14:57 UTC by Aleksandar Kostadinov
Modified: 2014-06-29 22:58 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-04-07 15:29:51 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Test program for multicast (4.60 KB, text/plain)
2007-10-03 16:40 UTC, Jay Fenlason
no flags Details

Description Aleksandar Kostadinov 2007-05-09 14:57:38 UTC
Description of problem:
Can't disable multicast on a specific ethernet interface.

How reproducible:
always

Steps to Reproduce:
1.1. ifconfig eth0 -multicast
or
1.2. ip link set eth0 multicast off
2. netstat -g
3. ifconfig
  
Actual results:
ifconfig lists the interface showing no multicast capabilities
netstat shows the interface listening for multicast packets

Expected results:
netstat doesn't show the interface at all

Additional info:
* if down && if up doesn't help
* multicast does work actually. not that netstat doesn't show what expected.

Comment 1 Linda Wang 2007-05-22 03:08:46 UTC
what is the ethernet driver that is used for this ethernet interface that the
multicase didn't work?

Comment 2 Aleksandar Kostadinov 2007-05-22 11:15:22 UTC
Multicast *does* work. It cannot be *disabled* on an interface. Let me know if
this is not the way it should be done.

The above steps should show the same for:
e1000
vmware eth driver
local loopback (lo interface)
dummy (dummy0)

I don't care about lo and dummy though...

Comment 3 Jay Fenlason 2007-10-03 16:40:30 UTC
Created attachment 214811 [details]
Test program for multicast

I've reproduced this problem on Rawhide using the attached test program, so
it's not RHEL-4 specific.  Do you know of any version of Linux which does work
the way you expect?

Comment 4 Aleksandar Kostadinov 2007-10-03 16:52:18 UTC
No.

Think I tried few others but results were the same.

Comment 5 Jay Fenlason 2007-10-03 16:56:41 UTC
How about non-Linux systems?

Comment 6 Aleksandar Kostadinov 2007-10-16 16:29:06 UTC
What about other systems? 

HP-UX and Solaris don't have such a switch by ifconfig. As well these don't have
iproute. No need to say about windows...

I don't know if it is possible to disable multicast on an interface on non-linux
systems if you ask that. At least I couldn't find one with google.

Anyway it's odd that interface is not shown as multicast capable but can receive
multicast frames.

Comment 8 Andy Gospodarek 2008-02-26 21:11:50 UTC
No driver focuses on ignoring multicast frames.  There are a few older drivers
that manually disable the multicast flag (since their hardware can't 'support'
it, but most new hardware seems to work just fine with multicast traffic.

The difficult part is that at the point at which hardware multicast tables are
full, all multicast traffic is just broadcast.  That mode can also be forced by
setting the IFF_ALLMULTI flag on the interface or using the 'allmulti' option
for ifconfig (as well as the 'multicast' flag).

The better thing to do would probably be to have the system ignore multicast
traffic that comes up through the hardware when the flag is not set since you
cannot guarantee that all hardware will behave the same.

Another option if you want to restrict the flow of multicast traffic to your
system would be to use iptables and/or ebtables to restrict the required traffic.

Can you try using iptables to restrict the flow of multicast traffic?

Comment 9 Aleksandar Kostadinov 2008-02-27 05:40:53 UTC
Yes, one can use iptables to restrict multicast traffic. I hoped for a more
lightweight approach since ifconfig/ip claimed to be able to disable multicast
traffic.

Btw win2k has a registry key to set multicast mode:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\tcpip\Parameters
IGMPLevel (DWORD Value)= 0, 1 or 2 (2 default)

0: no support
1: support for sending but not receiving
2: full support

Anyway this issue becomes less relevant to me since RHEL4U5 as setting multicast
route there seems to not allow mcast traffic to reach other interfaces. What I
wanted to achieve is having multicast working locally but not go or come from
other computers in the same LAN. 

Comment 10 Andy Gospodarek 2008-02-27 15:38:54 UTC
So you desired multicast traffic on one interface, but did not want the traffic
to flow from that interface to the other interface(s) on the box and possibly to
other hosts on the same lan as the alternate interface(s)?

Comment 11 Aleksandar Kostadinov 2008-02-27 17:43:25 UTC
No, I wanted to ensure all multicast traffic is local to the box no matter where
the application has it's sockets bound and to have application send and receive
mcast traffic.
I'm testing multicasting with more than one application on the same host. And
there are many test boxes in the LAN so things between them can interfere.
Anyway I needed to apply various workarounds so things are working almost
without issues. 

Anyway I vote for to have switching on/off work :)

Comment 12 Andy Gospodarek 2008-02-28 14:29:16 UTC
I'm not sure how we actually want to address this -- the complaint here is that
some ancient ifconfig flag isn't really honored by the kernel like the customer
wants.

Comment 14 Andy Gospodarek 2008-02-28 15:05:33 UTC
It's used inconsistently throughout the kernel -- there are some places where
it's checked and other places where it's assigned regardless of what it had
before.  When I think of the interface multicast flags I think about completely
filtering all mac addresses that are in the multicast range.  The reasonable
solution to this would probably be to add something in netif_receive_skb to
check for a multicast mac address and then also allow drivers to pay attention
to those flags as well and allow them to filter if they can.  Some hardware will
be able to do it and others will not, so we need a solution to fix it in both
places.

Comment 15 Andy Gospodarek 2008-04-07 15:29:51 UTC
Aleksandar,  If you want to open an upstream bugzilla to try and resolve this
that's fine with me, but as you've stated there are workarounds for this
available, so I don't see myself fixing it anytime soon.  Sorry.

Comment 16 Neil Horman 2008-04-07 15:50:09 UTC
as a follow up, if the goal here is to restrict the forwarding of multicast
traffic outside of the box, the correct, up to date solution would be to use the
routing table to suppress forwarding of these packets.  For instance, if you
want to make sure that no multicast traffic is fowarded out of the box, you can
do something like this:
ip route add blackhole 224.0.0.0/24 dev eth0
that will silently drop any multicast packets sent out of eth0.  Repeat this for
any other external interface.  Be sure to skip lo in the list though, in the
event that you want multicast traffic to be looped back locally.  Alternatively,
you can add one rule, that applies to all interfaces, and set the IP_MULTI_LOOP
bit on all multicast sockets with setsockopt.


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