Modify

Opened 5 years ago

Closed 5 years ago

#13042 closed defect (fixed)

DLNA servers slowly discovered

Reported by: spam@… Owned by: developers
Priority: normal Milestone: Chaos Calmer 15.05
Component: other Version: Trunk
Keywords: ddns slow discover wifi network Cc:

Description

Hi,

I own a TP-Link 4300 v3 and currently use Barrier Breaker trunk build 35473 (and just tried r35706). OpenWRT is awesome! ...however I noticed one issue.

I have two DLNA servers running in the network (Twonky and Plex).
When both servers are connected to the network via a network cable, other devices connected with a network cable are able to discover the DLNA servers instantly. However when a client is connected via WiFi it takes a lot of time to discover the DLNA servers (+60 secs).

When I connect the DLNA servers through WiFi instead, the problem appears the other way around. So connected devices via a network cable take a lot of time to discover the DLNA servers, but WiFi enabled client devices work fine.

  • WiFi (DLNA server)to WiFi (client) - OK
  • Cable (DLNA server) to Cable (client) - OK
  • Cable (DLNA server) to WiFi (Client) - NOK
  • WiFi (DLNA server) to Cable (Client) - NOK

I have tested the same thing with my old router (Draytek 2820n), and the issue doesn't exist then.
Also I don't have any VLANs and only use the out of the box firewall settings within OpenWRT.

Once the DLNA server has been discovered by a client the performance of DLNA is fine.

Cheers,
Xirixiz

Attachments (0)

Change History (8)

comment:1 Changed 5 years ago by anonymous

Ticket can be closed. This seems to be Plex related.
Without Plex Twonky is working fine. When only using Plex, strange behavior occurs.

Cheers

comment:2 Changed 5 years ago by anonymous

Sorry, didn't test it well. With my old Draytek everything is working fine.
The issue stil persists.

comment:3 Changed 5 years ago by anonymous

Hi,
I confirm same issue for r35572.
Problem is related to br-lan bridge, multicast packets are not forwarded between wlan0 and eth0. DLNA discovery uses multicast 239.255.255.250.

My test case:
Device on wlan0 segment produces these packets (searching for DLNA server on eth0 segment), but they are not forwarded to eth0. Seems like br-lan classified these packets as dropped (considering ifconfig output). Firewall is not blocking.

I tried to help myself with igmpproxy - not successfull. Igmpproxy can't be used for inbound/outbound on same bridge. Also parameter change net.bridge.bridge-nf-call-iptables=1 doesn't help me.
I saw people on openwrt forum with same problem; I guess this issue is seeded from some kernel update.

Regards
Tomas

comment:4 Changed 5 years ago by anonymous

I'm also seeing this with a TP-Link TL-WR1043ND, running Attitude Adjustment, r33883. I have DLNA servers running on the wired LAN which are not visible from clients running on wifi. The wireless clients sometimes see the servers after a long delay of several minutes but this is not deterministic and the also lose visibility after a while.

I've also tried igmpproxy but although I can get this to run proxying multicast between the WAN and the bridged wired/wireless LAN I can't get it to proxy multicast from the wired to wireless LANs.

comment:5 Changed 5 years ago by anonymous

Problem confirmed with OpenWrt Barrier Breaker r36312 on D-Link DIR-825 rev. C1 (Well, it's a DIR-835 A1, but Openwrt reports it as a 825 C1).
Clients from Wifi cannot see the DLNA server running on a wired port.
When using my other router in DD-wrt, the wireless client can see the DLNA router. The wireless client is on the DD-wrt, the DLNA server on the Openwrt router.

comment:6 follow-up: Changed 5 years ago by Gatak

Possible solution

I found that disabling multicast_snooping enables multicast forwarding with OpenWRT in WDS mode:

echo "0">/sys/devices/virtual/net/br-lan/bridge/multicast_snooping

br-lan is the bridge interface, often also called br0

This is tested on the following setup on a WR1043ND with VLAN disabled (option enable_vlan '0'):

[client A] <-wired-> [eth0-bridge-wlan0] <-wifi-> [wlan0-bridge-eth0] <-wired-> [client B]

comment:7 in reply to: ↑ 6 Changed 5 years ago by anonymous

Replying to Gatak:

Possible solution

I found that disabling multicast_snooping enables multicast forwarding with OpenWRT in WDS mode:

echo "0">/sys/devices/virtual/net/br-lan/bridge/multicast_snooping

br-lan is the bridge interface, often also called br0

This is tested on the following setup on a WR1043ND with VLAN disabled (option enable_vlan '0'):

[client A] <-wired-> [eth0-bridge-wlan0] <-wifi-> [wlan0-bridge-eth0] <-wired-> [client B]

This is worked for me. Thank you.

comment:8 Changed 5 years ago by jow

  • Resolution set to fixed
  • Status changed from new to closed

Fixed with r36463

Add Comment

Modify Ticket

Action
as closed .
The resolution will be deleted. Next status will be 'reopened'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.