Hi.  I can't seem to get the minidlna.conf "network_interface" or the
minidlnad -i parameter to work.  It just seems to be ignored.

For example, if /etc/default/minidlna contains:

DAEMON_OPTS="-v -i eth1"

and after restart, I can confirm that the parameter is passed correctly:

root@kanin:~# ps auxww|grep minid
minidlna  4987  0.0  0.4 201224 19768 ?        Ssl  23:04   0:00 /usr/bin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -v -i eth1
root      5392  0.0  0.0  12720  2032 pts/0    S+   23:07   0:00 grep minid
root@kanin:~#

However it still listens to all interfaces:

root@kanin:~# netstat -na|grep LIST|grep 8200
tcp        0      0 0.0.0.0:8200            0.0.0.0:*               LISTEN
root@kanin:~#

Despire -v syslog does not contain anything useful except the startup
message:

<30>1 2015-05-26T23:04:12.083111+02:00 kanin minidlna 4979 - -
Starting DLNA/UPnP-AV media server : minidlna.

Is this a bug, or am I missing something?

Thanks,
/Simon

Hi Simon,
http://sourceforge.net/p/minidlna/bugs/218/

The -i cmdline and network_interface config options appear to be
unrelated to the HTTP listening socket. Maybe related to SSDP? I don't
really understand the code in getifaddr.c after taking a quick look at it.

The HTTP listening socket is bound to INADDR_ANY in minidlna.c, line
128. Have you tested to see if connections from other interfaces than
the ones specified in -i or network_interface succeed? Maybe there is
some check for the correct interface when accepting incoming
connections, and "bad" connections are dropped right away?

Still, it would probably be better to only listen on interfaces
specified in the options.

Best Regards,
Florian

Hello Florian and Simon,
It really listen on *:<port> to support dynamic interfaces, but as I
can see, it do some filtering on connection attempts and multicast
interactions.
It initialize lan_addr[] array, which is used later in upnphttp.c and
various SSDP related places.
I believe there is, Simon, feel free to check.
Well, you're right in common, but this particular codebase is
complicated enough (and is _working_ in many unexpected (for me)
installation) to spend our time to fix this.

...

root@kanin:~# ps auxww|grep minidlna|head -1
minidlna  1396  0.0  0.4 201356 19972 ?        Ssl  May26 0:01 /usr/bin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid -v -i eth1
root@kanin:~# telnet 127.0.0.1 8200
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
HEAD /

HTTP/1.1 200 OK
Content-Type: text/html
Connection: close
Content-Length: 790
Server: 3.2.0-4-amd64 DLNADOC/1.50 UPnP/1.0 MiniDLNA/1.1.2
Date: Tue, 26 May 2015 23:14:48 GMT
EXT:

Connection closed by foreign host.
root@kanin:~#

For the record, the workaround is to setup iptables to firewall away
minidlna.  Still, most network servers are possible to configure to
only listen to particular interfaces, so maybe make this a feature
request if the current behaviour is not considered a bug.

/Simon