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.
what is the ethernet driver that is used for this ethernet interface that the multicase didn't work?
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...
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?
No. Think I tried few others but results were the same.
How about non-Linux systems?
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.
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?
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.
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)?
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 :)
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.
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.
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.
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.