#317 minidlna can only bind to at most 4 network interfaces

[Bernhard Trummer]

Hi.

I recently opened a Debian bug with the following description:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=885014

Package: minidlna
Version: 1.1.6+dfsg-1
Severity: normal

Dear Maintainer,

I have a Soekris net6501 box having 4 ethernet ports plus an additional network card with 2 ports and a USB wireless stick providing one more interface. Initially I configured minidlna.conf's
network_interface option to all interfaces except the uplink port (5 ethernet and 1 wireless interfaces in total). Then I wondered, why minidlna wasn't accessible via the wireless interface.

After playing around with the config and reducing the number of network_interface options to 4 in total (3 ethernet and 1 wireless), the wireless access was working fine. Also the debug log showed that it now binds to the wireless address.

After taking a short look into the source code, I found the "culprit" in minidlnatypes.h: #define MAX_LAN_ADDR 4

In total I see two bugs here:
1.) In minidlna.c there's a log for "Too many interfaces (max: %d), ignoring %s\n" in case the maximum is reached. However, when more than 4 interfaces are defined in the config file, I don't see this error in the log file.

2.) I admit that my setup and the amount of network interfaces is quite "unusal" for a typical home network. But nevertheless, a MAX_LAN_ADDR of 4 is an "artificial" restriction for my case and therefore this is a bug for me.

Thanks.

---

The maintainer's answer was:

Hello Bernhard,

Thanks for your research.

There are several points here:

1. It would be better to report the issue upstream because the problem itself is not Debian-related and you have more information then me and reproducible setup.
   https://sourceforge.net/p/minidlna/_list/tickets?source=navbar
   (But please drop here a link to discussion, so I could follow the topic.)

2. The best way would be to provide patch upstream with some sort of dynamic allocation of ifaces[] array. If you're familiar with C you are welcome.

3. I could increase MAX_LAN_ADDR define in Debian package, but what number should we choose? Is 16 enough? Should we really do this (see 4)?

4. The issue could be solved with iptables (or any other firewall): just bind to all ifaces and block any packets from interfaces you don't want to allow with "-i eth?" switch.

5. Anyway this bug would not be fixed in Stretch because of low severity.

6. I'll take a look at the problem with no error message displayed.

[Shrimpkin]

1) Workaround, use one interface per line. Ex:

network_interface=lo
network_interface=foo1
network_interface=foo2
network_interface=foo3
network_interface=foo4

Or patch for debug log issue:

diff --git a/minidlna.c b/minidlna.c
index f82cd89..c1afcc5 100644
--- a/minidlna.c
+++ b/minidlna.c
@@ -557,14 +557,14 @@ init(int argc, char **argv)
        case UPNPIFNAME:
            for (string = ary_options[i].value; (word = strtok(string, ",")); string = NULL)
            {
+               while (isspace(*word))
+                   word++;
                if (ifaces >= MAX_LAN_ADDR)
                {
                    DPRINTF(E_ERROR, L_GENERAL, "Too many interfaces (max: %d), ignoring %s\n",
                        MAX_LAN_ADDR, word);
-                   break;
+                   continue;
                }
-               while (isspace(*word))
-                   word++;
                runtime_vars.ifaces[ifaces++] = word;
            }
            break;

Note: minidlna does not verify the interface(s) during config parsing. Only one interface actually exists but all ifaces slots have been filled by foo*. Ex:

network_interface=foo1,foo2,foo3,foo4,lo

2) Not a bug but feature request. Most feature requests have to be applied downstream, by the user.

FYI, this is not my project.

[Justin Maggard]

I bumped this up to 8 for next release.