Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#77 Allowing SSDP M-SEARCH from other subnets

open
5
2015-03-18
2012-02-29
Fredrik Svensson
No

This patch was in response to the Help I got regarding :
https://sourceforge.net/projects/minidlna/forums/forum/879957/topic/5062120

It is only active when one interface is configured : n_lan_addr == 1
I have tested the code here, and I can play a movie over the network.
The patch was created against the debian package minidlna-1.0.23+dfsg, but I think
it should be easy enough to apply in CVS.

If there is anything I can do to improve the patch let me know.

Thanks

Discussion

  • pasdVn
    pasdVn
    2013-11-18

    I tried to implement a more clean sollution of this issue.
    The wrong assumption in the current code is, that the tcp/ip stack of the kernel does not a correct filtering of udp multicasts, but is does. The socket only provides datagramms from that interfaces, we added a ip multicast membership for.
    Additionally, when we receive a datagramm, we can ask the kernel which interface received it, so that we dont't have to rely on the current same-subnet-hack for getting the interface adress we need to put in to the ssdp-response.

    Maybe somebody should try it on other platforms, but for me it works at least with linux kernel.

    Additional hint:
    I also noticed, that the current feature of limiting minidlna to certain interfaces is only implemented for ssdp, but (at least) not for http (the socket for media transport). So if this really should be someting like a security feature the http (and all other) server-sockets should be splitted by interface!?

     
  • Hi there,
    this is my really first contribution to a sf project.
    Since a long time, I've tried to found a way to enable minidlna to work between networks. So the patch dated from 2012-02-29 was integrated and was worked for me by chance (indeed, the client was aware how to communicate with my 192.168.x.x subnet).

    But now I've changed my network with a first unsecured LAN in 192.168.x.x, and another behind a firewall router in 192.168.y.x.

    igmpproxy seems to be quite good to forward request from LAN to WAN, but after a bit wiresharking, I've found that client on x network doesn't know how to reach the server on y network, and I can't change client's route.

    The main idea behind this patch is to add a configuration option 'fake_lan' in minidlna.conf. If a SSDP muticast comes from another subnet, the host returned to the client is the fake_lan. You should set in fake_lan the address of the router in the WAN side and enable forwarding TCP requests on miniDLNA port from WAN to the server, and it should work, at least for me.

    What can be improved is a well integration of multiple network interfaces answer, with a different fake_lan per interface.

    Please note the patch is based on next git sha:
    commit f18c3cee6f9aa85337452648a79c2d13ff815685

     
    Attachments