7

I have a server which, amongst other things, serves media over DLNA (UPnP) using mediatomb. Clients use Simple Service Discovery Protocol (SSDP) to locate the server on the network.

I found that the SSDP discovery M-SEARCH queries were not being responded to and eventually tracked the problem down to the fact that the server was using a bridged interface which had multicast snooping enabled (because bridges have this enabled by default).

I fixed my problem with

echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping 

However, although this works in my situation, I don't understand what it's doing and if there are any implications that I am unaware of. Hence the question....

What is multicast snooping, why does it break SSDP, why it would be wanted and why it is enabled by default on a bridge, and what problems may be caused by disabling it because It's presumably enabled by default with good reason ?

3
  • 1
    Snooping should preferably be activated. Is your problem fixed by putting 1 in /sys/devices/virtual/net/br0/bridge/multicast_querier instead of putting 0 in multicast_snooping? Commented Sep 11, 2017 at 21:51
  • The box this is on does not appear to have multicast_querier. It does have a multicast_quierier_interval, however. Kernel is 3.4.103; it has CONFIG_IP_MULTICAST=y. Other boxes with more recent kernel versions do have it though. Commented Sep 12, 2017 at 9:13
  • I have this same experience with a TP-Link "Easy Smart" switch. With IGMP snooping enabled (which it is by default), UPnP advertisements are mostly dropped. Commented Jan 17, 2023 at 9:53

1 Answer 1

9

Multicast may represent a heavy load for switch-routers (not mentioning the security aspect with potential DoS attacks). On a switch (or a Linux bridge), Multicast snooping sits at network layer 2.5 and is intended to alleviate the load by:

  • snooping the network traffic
  • identifying the multicast channels that each switch port is subscribed to
  • filtering out other multicast traffic

As it sounds, this is always a desirable feature (unless you want to debug multicast traffic). So why disable multicast snooping?

Because you are facing is a bug I encountered some years ago with Corosync and two VMs on two different hosts: traffic is OK until a certain point where all incoming multicast traffic seems to be dropped by the host (although its iptable tables are completely empty). AFAIK, this was a bug in a 3.x kernel and I had to disable multicast snooping the same way as you. If my memory serves me, I was using Debian (Wheezy or Jessie) at the time, but this RedHat bug report describes exactly the issue I had.

As explained in this bug report, if you have the possibility, it is preferable to:

echo 1 > /sys/devices/virtual/net/br0/bridge/multicast_querier 

than:

echo 0 > /sys/devices/virtual/net/br0/bridge/multicast_snooping 
7
  • For whatever reason the muticast_querier option isn't available to me. I don't know why - perhaps it's because it an ARM board. The only reason the bridge is there is to support a vpn tap which I've just checked is no longer used. So I might just remove the bridge. Commented Sep 13, 2017 at 9:32
  • As I understand it muticast_querier is software only, so not related at all with ARM. I bet the reason is that your kernel does not implement it. Commented Sep 13, 2017 at 12:49
  • I can see from this comment on the Red Hat bug report that the commit that introduced multicast_querier happened in v3.5-rc1 which explains why I haven't got it. But it also suggests that the behaviour was previously enabled by default which would imply that it would make no difference to my problem... Commented Sep 13, 2017 at 15:05
  • You mean the multicast snooping behaviour? Yes I believe it's enabled by default and my understanding is that it isn't a pb anymore once the querier is enabled. Or did I get you wrong? Commented Sep 13, 2017 at 15:51
  • No I mean the multicast_querier is turned on with no way to turn it off before that commit. After that commit it is off unless explicitly enabled. So I meant that I implied that my problem would not be fixed by setting multicast_querier to 1 because it's effectively 1 already due to the pre 3.5 kernel. So I still have to disable (echo 0) the multicast_snooping. Commented Sep 13, 2017 at 17:16

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.