6

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 ?

starfry
  • 7,302
  • 6
  • 47
  • 69
  • 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`? – xhienne Sep 11 '17 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. – starfry Sep 12 '17 at 09: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. – Hamish Moffatt Jan 17 '23 at 09:53

1 Answers1

7

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
Anthony Geoghegan
  • 12,605
  • 7
  • 59
  • 62
xhienne
  • 17,075
  • 2
  • 52
  • 68
  • 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. – starfry Sep 13 '17 at 09: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. – xhienne Sep 13 '17 at 12:49
  • I can see from [this comment](https://bugzilla.redhat.com/show_bug.cgi?id=880035#c15) on the Red Hat bug report that the [commit](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/commit/net/bridge/br_multicast.c?id=c5c23260594c5701af66ef754916775ba6a46bbc) 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... – starfry Sep 13 '17 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? – xhienne Sep 13 '17 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`. – starfry Sep 13 '17 at 17:16
  • OK, so IIUC, the `multicast_querier` is available with your 3.4 kernel? – xhienne Sep 13 '17 at 17:34
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/65579/discussion-between-starfry-and-xhienne). – starfry Sep 14 '17 at 07:46