# MiniDLNA not discovered (multicast issue?)



## fwyKKCkQze2z (Mar 4, 2018)

Hi

I am trying to run minidlna (v1.2.1,1) on a FreeBSD 11.1-RELEASE system with a GENERIC kernel. I am not using jails.

The issue I am seeing is that clients do not see the server unless the server is restarted (or maybe a very high timeout is passed?). Once they "find" each other, everything seems to work properly.

My test client is VLC 2.2.8 on OS X.

I found several (very) similar reports on the web, most notably [1] where the explanation that the M-SEARCH messages are not received by MiniDNLA seems to be spot on.

Also, changing "notify_interval" in minidlna.conf (to 30 seconds for example) seems to have an effect (not tested with all clients). Still, the client does not connect "instantly" of course.

My question is: WHY are the messages not received by MiniDLNA?

I see the incoming UDP packets to 239.255.255.250 on port 1900 as well as IGMP packets (192.168.32.14 is my test client)


```
# tcpdump -n -i re1.32 not port 22 and not port 80 and not port 443
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on re1.32, link-type EN10MB (Ethernet), capture size 262144 bytes
23:12:42.655017 IP 192.168.32.14.49186 > 239.255.255.250.1900: UDP, length 127
23:12:42.756304 IP 192.168.32.14.49186 > 239.255.255.250.1900: UDP, length 127
23:12:43.251303 IP 192.168.32.14 > 224.0.0.22: igmp v3 report, 1 group record(s)
23:12:44.252514 IP 192.168.32.14 > 224.0.0.22: igmp v3 report, 1 group record(s)
```

I am 99.9% sure that the firewall (ipfw) does allow the traffic.

I ran MiniDLNA with ssdp=debug and see that M-SEARCH messages on another interface are rejected (which makes sense). There is no message about M-SEARCH from "my" interface though. The main difference between the two interfaces as far as I can see is that the non-working one is a VLAN interface whereas the other one is not. But to the best of my understanding, VLAN or not should not matter here?

The closest to an indicator of a problem I could get seems to be the output of `ifmcstat` that lacks (?) 239.255.255.250.


```
# ifmcstat -f inet -i re1.32
re1.32:
        inet 192.168.32.1
        igmpv3 rv 2 qi 125 qri 10 uri 3
                group 224.0.0.1 mode exclude
                        mcast-macaddr 01:00:5e:00:00:01
```

The question however is if 239.255.255.250 should be here to make it work or if it would be listed here if SSDP was working properly...

I stumbled upon [2] and [3] which both list 239.255.255.250 in the output of `ifmcstat`.

I am of course happy to provide more information to someone who might be able to help me debug this; I would just need to know what information.


Thanks!

[1] https://sourceforge.net/p/minidlna/bugs/94/#8c8f
[2] http://virtuallyhyper.com/2012/10/i...nnecting-to-it-with-xbmc-from-a-fedora-17-os/
[3] https://groups.google.com/forum/#!topic/mailing.freebsd.net/qDtZupt3yLg


----------



## Bobi B. (Mar 6, 2018)

Seems you have multiple network interfaces/VLANs. Are you _sure_ outbound multicast traffic is sent thru the correct interface/VLAN? Can you _verify_ this with `route get 239.255.255.250` (or whatever multicast address MiniDLNA is using to announce itself)? Maybe you're missing a routing table entry to direct multicast traffic to the LAN interface. For example, on my end, /etc/rc.conf.d/routing says

```
defaultrouter="192.168.1.1"
static_routes="mcast200 mcast201"
route_mcast200="-net 239.0.200.0/24 -iface vlan200"
route_mcast201="-net 239.0.0.0/21 -iface vlan201"
```


----------



## fwyKKCkQze2z (Mar 6, 2018)

Thank you for the hint. I am not 100% sure if I understand correctly.
I am sure that the client's "M-SEARCH" messages are received by the machine that is running MiniDLNA. The `tcpdump` that shows the traffic is from that machine. The announcements from MiniDLNA are also received by the client (when I restart MiniDLNA on the server the client immediately "sees" the server). I guess this is because the interfaces for MiniDLNA are configured in /usr/local/etc/minidlna.conf?
So I am pretty sure that this is not a routing issue.


----------



## Bobi B. (Mar 7, 2018)

Can you show your network configuration (`ifconfig`) and your routing table (`netstat -rn`)? Mask public addresses if you wish. Please also describe what network each interface is connected to and in which network your DLNA clients are.


----------



## fwyKKCkQze2z (Mar 7, 2018)

I assume you are referring to the machine that is running MiniDLNA, not the machine that is running the test client (OS X), right?

Yes, I can post my interface config; there are 19 interfaces however... The most important ones are

re0.7: the Internet facing interface (default route)
re1.32: the interface where traffic from my test client (VLC on OS X) is coming in, wired
re1.38: my WLAN
re1.20: WLAN where the "non test client" is (a HEOS system)
Except re0.7 these are also the interfaces listed in /usr/local/etc/minidlna.conf ("network_interface=...")

Here is the complete list of interfaces:

```
# ifconfig | egrep "^[^[:space:]]"
re0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
re2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
gif0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1280
re0.7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re0.168: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.4: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.8: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.9: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.20: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.32: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.33: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.34: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.35: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.36: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.38: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
re1.39: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
tun0: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1500
```

Here is the network config for the mentioned interfaces (I have changed the IP of re0.7 to RFC5737)

```
# ifconfig re0.7
re0.7: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=80003<RXCSUM,TXCSUM,LINKSTATE>
    ether 00:0d:b9:3c:bd:8c
    inet6 fe80::20d:b9ff:fe3c:bd8c%re0.7 prefixlen 64 scopeid 0x6
    inet6 2001:0db8::20d:b9ff:fe3c:bd8c prefixlen 64 autoconf
    inet6 2001:0db8::8bf7:709b:1cab:30f prefixlen 128
    inet 192.0.2.48 netmask 0xffffff00 broadcast 192.0.2.255
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 7 vlanpcp: 0 parent interface: re0
    groups: vlan
```


```
# ifconfig re1.20
re1.20: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=80003<RXCSUM,TXCSUM,LINKSTATE>
    ether 00:0d:b9:3c:bd:8d
    inet 192.168.16.1 netmask 0xffffff00 broadcast 192.168.16.255
    nd6 options=69<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL,NO_RADR>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 20 vlanpcp: 0 parent interface: re1
    groups: vlan
```


```
# ifconfig re1.32
re1.32: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=80003<RXCSUM,TXCSUM,LINKSTATE>
    ether 00:0d:b9:3c:bd:8d
    inet 192.168.32.1 netmask 0xffffff00 broadcast 192.168.32.255
    inet6 fe80::20d:b9ff:fe3c:bd8d%re1.32 prefixlen 64 scopeid 0xc
    inet6 fd04:3379:a517:460::1 prefixlen 64
    inet6 2a02:168:681c:460:20d:b9ff:fe3c:bd8d prefixlen 64
    nd6 options=61<PERFORMNUD,AUTO_LINKLOCAL,NO_RADR>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 32 vlanpcp: 0 parent interface: re1
    groups: vlan
```


```
# ifconfig re1.38
re1.38: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=80003<RXCSUM,TXCSUM,LINKSTATE>
    ether 00:0d:b9:3c:bd:8d
    inet 192.168.38.1 netmask 0xffffff00 broadcast 192.168.38.255
    inet6 fe80::20d:b9ff:fe3c:bd8d%re1.38 prefixlen 64 scopeid 0x11
    inet6 fd04:3379:a517:468::1 prefixlen 64
    inet6 2a02:168:681c:468:20d:b9ff:fe3c:bd8d prefixlen 64
    nd6 options=61<PERFORMNUD,AUTO_LINKLOCAL,NO_RADR>
    media: Ethernet autoselect (1000baseT <full-duplex>)
    status: active
    vlan: 38 vlanpcp: 0 parent interface: re1
    groups: vlan
```

And here is the routing table:

```
# netstat -rn
Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            192.0.2.1       UGS       re0.7
10.101.0.0/25      10.101.0.2         UGS        tun0
10.101.0.1         link#19            UHS         lo0
10.101.0.2         link#19            UH         tun0
127.0.0.1          link#4             UH          lo0
192.168.1.0/24     link#9             U         re1.8
192.168.1.1        link#9             UHS         lo0
192.168.2.1        link#5             UHS         lo0
192.168.2.2        link#5             UH         gif0
192.168.4.0/28     link#8             U         re1.4
192.168.4.1        link#8             UHS         lo0
192.168.8.0/24     link#3             U           re2
192.168.8.1        link#3             UHS         lo0
192.168.12.0/24    link#3             U           re2
192.168.12.1       link#3             UHS         lo0
192.168.16.0/24    link#11            U        re1.20
192.168.16.1       link#11            UHS         lo0
192.168.32.0/24    link#12            U        re1.32
192.168.32.1       link#12            UHS         lo0
192.168.33.0/24    link#13            U        re1.33
192.168.33.1       link#13            UHS         lo0
192.168.34.0/24    link#14            U        re1.34
192.168.34.1       link#14            UHS         lo0
192.168.35.0/24    link#15            U        re1.35
192.168.35.1       link#15            UHS         lo0
192.168.36.0/24    link#16            U        re1.36
192.168.36.1       link#16            UHS         lo0
192.168.38.0/24    link#17            U        re1.38
192.168.38.1       link#17            UHS         lo0
192.168.39.0/24    link#18            U        re1.39
192.168.39.1       link#18            UHS         lo0
192.168.96.0/24    192.168.2.2        UGS        gif0
192.168.128.0/24   link#10            U         re1.9
192.168.128.1      link#10            UHS         lo0
192.168.168.0/24   link#7             U       re0.168
192.168.168.4      link#7             UHS         lo0
192.0.2.0/24    link#6             U         re0.7
192.0.2.48     link#6             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::/96                             ::1                           UGRS        lo0
default                           fe80::c671:feff:fef4:d0ff%re0.7 UG      re0.7
::1                               link#4                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2001:0db8::/64             link#6                        U         re0.7
2001:0db8::20d:b9ff:fe3c:bd8c link#6                      UHS         lo0
2001:0db8::8bf7:709b:1cab:30f link#6                      UHS         lo0
2001:0db8:20::/64             link#3                        U           re2
2001:0db8:20:20d:b9ff:fe3c:bd8e link#3                      UHS         lo0
2001:0db8:48::/64             link#8                        U         re1.4
2001:0db8:48::1               link#8                        UHS         lo0
2001:0db8:60::/64             link#9                        U         re1.8
2001:0db8:60::1               link#9                        UHS         lo0
2001:0db8:460::/64            link#12                       U        re1.32
2001:0db8:460:20d:b9ff:fe3c:bd8d link#12                    UHS         lo0
2001:0db8:464::/64            link#19                       U          tun0
2001:0db8:464::1              link#19                       UHS         lo0
2001:0db8:468::/64            link#17                       U        re1.38
2001:0db8:468:20d:b9ff:fe3c:bd8d link#17                    UHS         lo0
2001:0db8:480::/64            link#13                       U        re1.33
2001:0db8:480:20d:b9ff:fe3c:bd8d link#13                    UHS         lo0
fd04:3379:a517:40::/64            link#4                        U           lo0
fd04:3379:a517:40::1              link#4                        UHS         lo0
fd04:3379:a517:48::/64            link#8                        U         re1.4
fd04:3379:a517:48::1              link#8                        UHS         lo0
fd04:3379:a517:60::/64            link#9                        U         re1.8
fd04:3379:a517:60::1              link#9                        UHS         lo0
fd04:3379:a517:460::/64           link#12                       U        re1.32
fd04:3379:a517:460::1             link#12                       UHS         lo0
fd04:3379:a517:468::/64           link#17                       U        re1.38
fd04:3379:a517:468::1             link#17                       UHS         lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%re2/64                     link#3                        U           re2
fe80::20d:b9ff:fe3c:bd8e%re2      link#3                        UHS         lo0
fe80::%lo0/64                     link#4                        U           lo0
fe80::1%lo0                       link#4                        UHS         lo0
fe80::%re0.7/64                   link#6                        U         re0.7
fe80::20d:b9ff:fe3c:bd8c%re0.7    link#6                        UHS         lo0
fe80::%re1.4/64                   link#8                        U         re1.4
fe80::20d:b9ff:fe3c:bd8d%re1.4    link#8                        UHS         lo0
fe80::%re1.8/64                   link#9                        U         re1.8
fe80::20d:b9ff:fe3c:bd8d%re1.8    link#9                        UHS         lo0
fe80::%re1.32/64                  link#12                       U        re1.32
fe80::20d:b9ff:fe3c:bd8d%re1.32   link#12                       UHS         lo0
fe80::%re1.33/64                  link#13                       U        re1.33
fe80::20d:b9ff:fe3c:bd8d%re1.33   link#13                       UHS         lo0
fe80::%re1.38/64                  link#17                       U        re1.38
fe80::20d:b9ff:fe3c:bd8d%re1.38   link#17                       UHS         lo0
fe80::20d:b9ff:fe3c:bd8c%tun0     link#19                       UHS         lo0
ff02::/16                         ::1                           UGRS        lo0
```


----------



## Bobi B. (Mar 8, 2018)

Well, quite a set-up you have there. Why so many discrete VLANs?

It seems that multicast traffic will "flow" towards the Internet (`re0.7`). Maybe we should try to fix that first. Try with `route add -net 224.0.0.0/4 -iface re1.32` and see if MiniDLNA will appear on the Mac OS.


----------



## fwyKKCkQze2z (Mar 8, 2018)

The VLANs are there for several reasons. Basically it is a firewall which is connecting a few networks that host IoT stuff which must be quite tightly controlled.

I tried with `route add -net 224.0.0.0/4 -iface re1.32` to no avail 

But then I am still not sure if this is a routing issue (I never saw packets that should go out re1.32 on re0.7 for example). Also, as mentioned, when I restart MiniDLNA after the test client is running everything works as expected. Outgoing multicast should be controlled by the "network_interface=..." statement in /usr/local/etc/minidlna.conf, no? Also when I have clients behind re1.32 AND re1.20 (the HEOS system and my test client for example), adding a route for 224.0.0.0/4 does not work any more, no?

The problem really rather seems to be that MiniDLNA (or FreeBSD?) does not accept the incoming M-SEARCH messages for some reason.


----------



## Bobi B. (Mar 9, 2018)

Try to truss(1) minidlna: get its pid (`service minidlna status`) then start a `truss -s 64 -p <pid>` and you'll see if minidlna receives this traffic. Here is what it writes on my end:

```
...
recvfrom(5,"M-SEARCH * HTTP/1.1\r\nHOST: 239.255.255.250:1900\r\nMAN: "ssdp:"...,1499,0x0,{ AF_INET 192.168.1.44:64767 },0x7fffffffae2c) = 127 (0x7f)
...
recvfrom(5,"M-SEARCH * HTTP/1.1\r\nMX: 5\r\nST: upnp:rootdevice\r\nMAN: "ssd"...,1499,0x0,{ AF_INET 192.168.1.132:4366 },0x7fffffffae2c) = 160 (0xa0)
...
```
You can see the address of device issuing `M-SEARCH` command, as well.


----------



## fwyKKCkQze2z (Mar 9, 2018)

This is *sooo* cool (truss(1))! Thanks. And I have more - hmm - things I do not understand now 

To my surprise, the test client immediately found MiniDLNA when I `truss`ed it. So I first thought that the command did "something good" to the process, but when I tried without `truss`ing, the client _still_ immediately found MiniDLNA. I have double and triple checked the config (e.g. notify_interval) but all values were the same as before.

So finally I removed the route for 224.0.0.0/4 via re1.32 again. And sure enough, it stopped working! `ifmcstat` even shows the membership for 239.255.255.250 for re1.32 now!

It seems that despite my previous negative test(s), the route _does change something_. I just do not really understand what. And why my tests were negative before?

I am especially irritated by the fact that `truss` seems to indicate that MiniDLNA stops _receiving_ the M-SEARCH messages when the route is gone. But routing does not have anything to do with reception of network traffic, no?

Anyway: assuming that I need the route, it can only point to one interface, right (`route` does not allow to add a second route: "route already in table")? Is it correct that I therefore I cannot have clients in several subnets/behind several interfaces?


----------



## Bobi B. (Mar 10, 2018)

Regarding routes: I'm not a network guy, but as far as my understanding goes (the following might just be plain wrong), the OS needs to know which network goes thru which interface. This is easy when you have a single network interface -- all the traffic goes through it. Gets more interesting with several interfaces, then the OS implicitly fills the routing table from networks assigned to different interfaces (like `192.168.0.99/24` on `igb0` means, that all of `192.168.0.0/24` goes thru `igb0`) and you usually explicitly declare which the default route is (where your gateway is). However neither interface has an explicit address in `224.0.0.0/4`, therefore this/multicast traffic usually flows towards default router/gateway, or the internet, when you have a public IP, unless you declare a explicit route. I believe the OS also uses routing table when a program binds to a multicast address, because the OS have to send an IGMP join message on the network interface responsible for this multicast network.

About your case, if you wish to have same network on multiple interfaces, the only way that I can think of is some way of network bridging. Speaking of which, why you have sliced your network on so many segments? I ran a server at home and have just two VLANs -- one for WAN (firewalled) and another for LAN/wireless.

Edit: few more ideas: see if you can bind `minidlnad` to a specific network interface; if that is possible you can run several instances in parallel. Or you might be able to bind it to several addresses simultaneously. Or you might declare several routing tables (one for each LAN/WiFi interface forwarding `224.0.0.0/4` thru it) and start several minidlnad instances using setfib(1).


----------



## fwyKKCkQze2z (Mar 23, 2018)

There is a BR now: PR 226884


----------

