Recently I've set up a new Ubuntu Server 10.04 and noticed my UDP server is no longer able to see any multicast data sent to the interface, even after joining the multicast group. I've got the exact same set up on two other Ubuntu 8.04.4 LTS machines and there is no problem receiving data after joining the same multicast group.

The ethernet card is a Broadcom netXtreme II BCM5709 and the driver used is:

b $ ethtool -i eth1
driver: bnx2
version: 2.0.2
firmware-version: 5.0.11 NCSI 2.0.5
bus-info: 0000:01:00.1

I'm using smcroute to manage my multicast registrations.

b$ smcroute -d
b$ smcroute -j eth1

After joining the group ip maddr shows the newly added registration.

b$ ip maddr

    1:  lo
        inet6 ff02::1
    2:  eth0
        link  33:33:ff:40:c6:ad
        link  01:00:5e:00:00:01
        link  33:33:00:00:00:01
        inet6 ff02::1:ff40:c6ad
        inet6 ff02::1
    3:  eth1
        link  01:00:5e:25:36:47
        link  01:00:5e:25:36:3e
        link  01:00:5e:25:36:3d
        link  33:33:ff:40:c6:af
        link  01:00:5e:00:00:01
        link  33:33:00:00:00:01
        inet <------- McastGroup.
        inet6 ff02::1:ff40:c6af
        inet6 ff02::1

So far so good, I can see that I'm receiving data for this multicast group.

b$ sudo tcpdump -i eth1 -s 65534 host
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 65534 bytes
09:30:09.924337 IP > UDP, length 212
09:30:09.947547 IP > UDP, length 212
09:30:10.108378 IP > UDP, length 268
09:30:10.196841 IP > UDP, length 212

I can also confirm that the interface is receiving mcast packets.

b $ ethtool -S eth1 | grep mcast_pack
rx_mcast_packets: 103998
tx_mcast_packets: 33

Now here's the problem. When I try to capture the traffic using a simple ruby UDP server I receive zero data! Here's a simple server that reads data send on port 15572 and prints the first two characters. This works on the two 8.04.4 Ubuntu Servers, but not the 10.04 server.

require 'socket'
s = UDPSocket.new
s.bind("", 15572)
5.times do
  text, sender = s.recvfrom(2)
  puts text

If I send a UDP packet crafted in ruby to localhost, the server receives it and prints out the first two characters. So I know that the server above is working correctly.

irb(main):001:0> require 'socket'
=> true
irb(main):002:0> s = UDPSocket.new
=> #<UDPSocket:0x7f3ccd6615f0>
irb(main):003:0> s.send("I2 XXX", 0, 'localhost', 15572)

When I check the protocol statistics I see that InMcastPkts is not increasing. While on the other 8.04 servers, on the same network, received a few thousands packets in 10 seconds.

b $ netstat -sgu ; sleep 10 ; netstat -sgu
    InType3: 11
    OutType3: 11
    446 packets received
    4 packets to unknown port received.
    0 packet receive errors
    461 packets sent
    InMcastPkts: 4654 <--------- Same as below
    OutMcastPkts: 3426
    InBcastPkts: 9854
    InOctets: -1691733021
    OutOctets: 51187936
    InMcastOctets: 145207
    OutMcastOctets: 109680
    InBcastOctets: 1246341
    InType3: 11
    OutType3: 11
    446 packets received
    4 packets to unknown port received.
    0 packet receive errors
    461 packets sent
    InMcastPkts: 4656  <-------------- Same as above
    OutMcastPkts: 3427
    InBcastPkts: 9854
    InOctets: -1690886265
    OutOctets: 51188788
    InMcastOctets: 145267
    OutMcastOctets: 109712
    InBcastOctets: 1246341

If I try forcing the interface into promisc mode nothing changes.

At this point I'm stuck. I've confirmed the kernel config has multicast enabled. Perhaps there are other config options I should be checking?

b $ grep CONFIG_IP_MULTICAST /boot/config-2.6.32-23-server

Any thoughts on where to go from here?

  • Go figure. I go to enter a new question, the related algorithm happily shows me this question exists, but it has no meaningful answers. Boo :(.
    – VxJasonxV
    Commented Dec 20, 2010 at 10:04
  • I'm not sure how exactly I'm going to award the bounty. A co-worker found the problem, and I figured out WHY it happened how it happened. I'm more than willing to entertain suggestions for how to award the bounty.
    – VxJasonxV
    Commented Dec 21, 2010 at 21:28
  • you still around? I have some questions for you.
    – VxJasonxV
    Commented Dec 26, 2010 at 5:21
  • I have this problem too. Dear buecking, do you solve it?
    – user242029
    Commented Sep 12, 2014 at 3:40
  • To others who had this problem - read all the answers on this question, because there are 2-3 O/S settings that need to be fixed. We resolved this problem by changing rp_filter and /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts and then it started working. Commented Jun 29, 2017 at 18:42

6 Answers 6


In our instance, our problem was solved by sysctl parameters, one different from Maciej.

Please note that I do not speak for the OP (buecking), I came on this post due to the problem being related by the basic detail (no multicast traffic in userland).

We have an application that reads data sent to four multicast addresses, and a unique port per multicast address, from an appliance that is (usually) connected directly to an interface on the receiving server.

We were attempting to deploy this software on a customer site when it mysteriously failed with no known reason. Attempts at debugging this software resulted in inspecting every system call, ultimately they all told us the same thing:

Our software asks for data, and the OS never provides any.

The multicast packet counter incremented, tcpdump showed the traffic reaching the box/specific interface, yet we couldn't do anything with it. SELinux was disabled, iptables was running but had no rules in any of the tables.

Stumped, we were.

In randomly poking around, we started thinking about the kernel parameters that sysctl handles, but none of the documented features was either particularly relevant, or if they had to do with multicast traffic, they were enabled. Oh, and ifconfig did list "MULTICAST" in the feature line (up, broadcast, running, multicast). Out of curiosity we looked at /etc/sysctl.conf. 'lo and behold, this customer's base image had a couple of extra lines added to it at the bottom.

In our case, the customer had set net.ipv4.all.rp_filter = 1. rp_filter is the Route Path filter, which (as I understand it) rejects all traffic that could not have possibly reached this box. Network subnet hopping, the thought being that the source IP is being spoofed.

Well, this server was on a 192.168.1/24 subnet and the appliance's source IP address for the multicast traffic was somewhere in the 10.* network. Thus, the filter was preventing the server from doing anything meaningful with the traffic.

A couple of tweaks approved by the customer; net.ipv4.eth0.rp_filter = 1 and net.ipv4.eth1.rp_filter = 0 and we were running happily.

  • 2
    This worked! The rp_filter for our 10 Gb network interface was dumping all of our UDP multicast packets. Shutting off the filter let everything flow through. Commented Jul 24, 2012 at 14:14
  • We were having issues when setting up streaming over AMT multicast over the tun device on an Ubuntu receiver, and we could see packets getting delivered to the device via tcpdump, but application just doesn't want to stream. This post saved us! Commented Jul 16, 2013 at 21:55
  • 2
    Running on Ubuntu 14.04, this only worked for me after I also set net.ipv4.all.rp_filter = 0. Specifically, with the multicast data arriving on eth2, I had to set both net.ipv4.eth2.rp_filter = 0 and net.ipv4.all.rp_filter = 0.
    – T-Hawk
    Commented Nov 28, 2018 at 16:10
  • Rather than removing rp_filter, couldn't you also add a route to the source subnet of the udp traffic? i.e. ip route add 10.*/24 dev eth1, then rp_filter wouldn't filter out the multicast traffic
    – Josh Jobin
    Commented May 15, 2020 at 13:46
  • Sure, either would have worked.
    – VxJasonxV
    Commented May 15, 2020 at 16:45

TL/DR Also make sure your multicast doesn't come from a vlan. tcpdump -e would help determine if they do.

In all fairness, somebody ought to build a page with a checklist of things that can prevent multicast from reaching the userland. I've been struggling with that for a couple of days, and naturally nothing I could find on the web helped.

Not only I could see the packets in the tcpdump, I could actually receive other multicast packets, for other producers, just on a different interface. The command I ended up using for testing whether I can receive multicast was:

$ GRP=224.x.x.x # set me to the group
$ PORT=yyyy # set me to the receiving port
$ IFACE=mmmm # set me to the name or IP address of the interface
$ strace -f socat -  UDP4-DATAGRAM:$GRP:$PORT,ip-add-membership=$GRP:$IFACE,bind=$PORT,multicast-loop=0

The reason for strace here is that I actually couldn't make socat print out the packets to the stdout, but in strace output you can clearly see if socat is receiving actual data from the bound socket (it'll be mute otherwise after a couple of initial select calls)

  • rp_filter sysctl - doesn't apply, the systems are on the same IP network (I set them to 0 all the same, seems that 1 is a default setting now, at least for Ubuntu).
  • firewalls/etc - the receiving system is firewall free (I don't think packets will show up in tcpdump if they were firewalled, but I guess it's possible if the firewall is funny)
  • IP/Multicast routing and multiple interfaces - I explicitly joined the group on the correct interface
  • Wacky network hardware - this was my last resort, but changing some laptop to an Intel NUC didn't help. This is about where I started chewing my elbows and perpetrating posting this to SE.
  • The problem in my case was use of VLANs by the specialized hardware that was producing those multicast packets. To see if this is your issue, make sure to include -e flag to tcpdump, and check for vlan tags. It will be required to configure an interface into the correct vlan before userland will be able to get those packets. The giveaway for me actually was that the multicast producers won't ping, but won't even get into the ARP cache, though I could clearly see ARP replies.

To get it running with VLAN this link might be helpful to configure multicast routing. (Sadly I'm new to this so Reputation does not allow me to add an answer. Hence this edit.)

Here is what I did (use sudo if needed):

ip link add link eth0 name eth0_100 type vlan id 100
ip addr add brd dev eth0_100
ip link set dev eth0_100 up
ip maddr add 01:00:5e:01:01:01 dev eth0_100
route -n add -net netmask dev eth0_100

This way an additional interface if created for the vlan traffic with vlan id 100. The vlan ip might be unnecessary. Then a multicast address is configured for the new interface (01:00:5e:01:01:01 is the link layer address for and all incoming multicast traffic is bound to eth0_100. I also did all the possible steps in the answers above (check iptables, rp_filter etc).

  • @Gero: Adding multicast route sets up outgoing multicast, not incoming multicast. You shouldn't be binding multicast IP addresses to interfaces directly, unless you're doing something funky, it's normally application's job. Commented Aug 29, 2016 at 17:17

You might want to try and look at these settings:


echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts


sed -i -e 's|^net.ipv4.icmp_echo_ignore_broadcasts =.*|net.ipv4.icmp_echo_ignore_broadcasts = 0|g' /etc/sysctl.conf

These have been used to enable multicasting in RHEL.

You might want to make sure that your firewall is allowing the mutlicast traffic; again with RHEL I've enabled the following:

# allow anything in on multicast addresses
-A INPUT -p igmp -d -j ACCEPT
# needed for multicast ping responses
-A INPUT -p icmp --icmp-type 0 -j ACCEPT
  • "broadcast" options apply to "multicast" too?
    – Raedwald
    Commented Jun 4, 2016 at 15:39

Are you using a managed switch? Some have options to prevent 'broadcast storms' or other multicast issues, that would cause them to prevent certain types of packets. I'd suggest taking a look at your switch documentation.

s.bind("", 15572)

Sure about ""? Why not using the multicast IP-address to bind to?

  • empty host addresses commonly means "all interfaces".
    – VxJasonxV
    Commented Dec 7, 2015 at 18:26

I encountered similar behavior to this while attempting to perform an SSDP query of my local network. My Ubuntu 22.04 (Kernel 5.17) host was not propagating the multicast reply back up to my userland program. Configuring the systemctls as mentioned in other replies did not address the issue in this case. The network interfaces in question were already 'multicast' aware as well.

This UFW firewall rule allowed my system to receive SSDP/multicast replies on UDP port 1900:

Policy:    Allow
Direction: In
Interface: All Interfaces
Log:       Do not log
Protocol:  UDP
From:      Port 1900

enter image description here

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .