# Bridge not letting DLNA multicasts through

## LubosD

Hello,

I have a network bridge br0 that joins interfaces eth0 and wlan0 (master mode). I have a minidlna daemon that sends multicasts on br0 to let DLNA-compatible devices know about itself.

I can see the packets leave br0:

```
# tshark -i br0 | grep 255

Running as user "root" and group "root". This could be dangerous.

Capturing on br0

  1.132010   10.10.10.3 -> 239.255.255.250 SSDP 329 NOTIFY * HTTP/1.1 

  1.132019   10.10.10.3 -> 239.255.255.250 SSDP 320 NOTIFY * HTTP/1.1 

  1.132024   10.10.10.3 -> 239.255.255.250 SSDP 372 NOTIFY * HTTP/1.1 

  1.132029   10.10.10.3 -> 239.255.255.250 SSDP 384 NOTIFY * HTTP/1.1 

  1.132033   10.10.10.3 -> 239.255.255.250 SSDP 386 NOTIFY * HTTP/1.1 

  1.132037   10.10.10.3 -> 239.255.255.250 SSDP 400 NOTIFY * HTTP/1.1 

```

But these packets are not being actually sent anywhere. When I run tshark -i eth0, I can't see any of them. TVs are having big problems seeing the DLNA server, the server shows up only occasionally.

What do I do to stop Linux from filtering these packets?

----------

## swanson

Good question as I have exactly the same problem that I've been flummoxed by for a while. Tried variations of network routes, firewall, sysctl settings and kernel options but no joy. Suspect most people aren't using a bridge with minidlna.

----------

## LubosD

My idea was to use ebtables. It has stuff like "-d Multicast", so I wanted to do:

```
ebtables -A FORWARD -o eth0 -d Multicast -j ACCEPT
```

But it changed nothing.

----------

## LubosD

The problem has already been brought up with kernel bridge devs, but to no avail.

So I created an ugly hack that fixes the problem for me.

```
--- linux/net/bridge/br_device.c.orig   2012-06-13 16:52:14.557429094 +0200

+++ linux/net/bridge/br_device.c   2012-06-05 15:26:17.340602795 +0200

@@ -52,7 +52,7 @@

    if (is_broadcast_ether_addr(dest))

       br_flood_deliver(br, skb);

    else if (is_multicast_ether_addr(dest)) {

-      if (unlikely(netpoll_tx_running(dev))) {

+      if (unlikely(netpoll_tx_running(dev)) || true) {

          br_flood_deliver(br, skb);

          goto out;

       }

```

This *does* have other implications, but in my use case, it is just fine.

----------

## BT

I previously had the same issue where my TV would only occasionally see MiniDLNA. I'm now successfully using MiniDLNA with a bridge. Turns out I was building my kernel without IP multicasting enabled (CONFIG_IP_MULTICAST). I also have IGMP/MLD snooping (CONFIG_BRIDGE_IGMP_SNOOPING) enabled but have yet to determine if that makes any difference.

----------

## LubosD

 *BT wrote:*   

> I previously had the same issue where my TV would only occasionally see MiniDLNA. I'm now successfully using MiniDLNA with a bridge. Turns out I was building my kernel without IP multicasting enabled (CONFIG_IP_MULTICAST). I also have IGMP/MLD snooping (CONFIG_BRIDGE_IGMP_SNOOPING) enabled but have yet to determine if that makes any difference.

 

I have both enabled and it doesn't work as expected.

----------

## joe82

Hey,

seems I have the same problem. Recently MediaTomb stopped working (PS3 didn't discover the media server).

At first, I supposed it had something to do with the ebuild removal, but after trying out rygel and minidlna, both of which worked only occasionally, I'm pretty much stucked.

Both kernel options are built in, is there any solution yet?

Greets

Jörg

----------

## joe82

In some other forums there are possible solutions by activating promiscious mode for the bridge.

I don't know what PROMISC actually does...

command (for br0 as your bridge):

```
ifconfig br0 allmulti promisc
```

Original suggestion:

http://forums.plexapp.com/index.php/topic/48306-possible-solution-for-ps3-or-xbox-cant-see-dlna-server/

----------

## joe82

Seems that the upgrade to hardened-sources 3.5.4 was responsible for those problems.

Booting hardened-sources 3.4.5, everything is working as expected.

uname -a:

```
Linux **** 3.4.5-hardened #1 SMP Sun Aug 12 16:59:10 CEST 2012 x86_64 AMD Athlon(tm) II X2 240e Processor AuthenticAMD GNU/Linux
```

----------

## Hu

 *joe82 wrote:*   

> Seems that the upgrade to hardened-sources 3.5.4 was responsible for those problems.
> 
> Booting hardened-sources 3.4.5, everything is working as expected.

 Is the problem with the v3.5 kernel series in general or with the hardened patches in particular?

----------

## joe82

 *Hu wrote:*   

> Is the problem with the v3.5 kernel series in general or with the hardened patches in particular?

 

Seems the problems are not related to the hardened patches.

I compiled gentoo-sources-3.5.7 with the same options as my hardened version, and my DLNA clients (PS3 and Android phone) still have problems discovering the miniDLNA-server.

----------

## joe82

As far as I can tell, the problems are gone with hardened-sources-3.7.0

That's good news, finally...

----------

## Robert S

Don't know if this has anything to do with it but I purchased a new router (Netgear DGND3700v2) and I had no problems with DLNA.  I did the recommended firmware upgrade and it stopped working.  Since I downgraded the firmware to the original version (V1.1.00.08_1.00.08 ) everything has been fine.

----------

