Working DLNA routing example (basic)

RouterOS Beginner Basics
21

I have the same issue with timing. When I’m connected via VPN on Android or Windows, then there is a significant delay in DLNA discovery in 75% of cases I’d say. It takes from about 10 seconds up to 2 minutes or so. This is why I wanted you to check network packets, rather then just running “network discovery” and deciding that it doesn’t work. Because your PIM config is correct in general as I understand, but the devil hides in details.

I also notice that VLC for example can fail to discover DLNA, or may find it after several attempts. It could be related to the aforementioned delays in services polling. According to my humble experience, most reliable way to receive DLNA (via PIM I mean) on windows is standard Windows Media Player and Slick on Android that can later delegate playback to your favorite player.

I haven’t figured out a root cause so far. And I have more issues in my setup and wasn’t able to get any assistance here unfortunately, as well as many other PIM topics. But I assume that can be connected with certain interface settings, especially with those (and their effects) that aren’t very clear for me:

  • hello-holdtime, or rather the purpose and behavior of HELLO messages
  • hello-period, nice candidate just from the naming :slight_smile:
  • require-hello
  • tracking-support
  • override-interval

So I’m not sure whether my problem with “must be directly connected” and interval problem are connected, or one caused another. I need a second round of “inspiration” to continue. And study that Upnp device architecture and much closer.

So at this point you’re mastered more than me probably, because you say there are no warnings in log. I don’t have another router that I can bring to remote premises and have VPN tunnel for troubleshooting. And I’m quite tired of this PIM to rebuild my home setup again to the test lab, at least I still have about 6 month until this topic would become important again for me.

22

And the negative impact of decreasing polling periods (if that’s the deal) would lead to increasing traffic in your network that is quite unwanted in many cases. It shouldn’t be an issue when you have a small amount of devices, but is worth to mention.

23

Hi Chivere,
I understand what you say, and it is the same to me. Two months ago, I never heard about Mikrotik Router and I learnd ffrom scratch everthing about bridging, vlans and how to implemenz cAPs.
I found out how to move my sonos players into a separate subnet and how firewalling works.

My config is definitely not perfect but it is running and all my attempts of implementing new services( e.g.IPSEC-Lan2LAN with AVM FritzboxRouter) were performend in the “production” environment on my RB3011 with the 2 cAP ACs.

I think we need an “DLNA-Routing”-Expert , who can help us with new ideas to find out why some of the packages will not be transfered to the other vlans. I will also post the issue in annother forum and let you know if something happens!

@ all DLNA and Mikrotik Routing Experts:
Can anyone help with the DLNA Routing Issue ?

Regards,
Christian

24

An update from my side. I just was curious that we both face discovery delays with QNAP devices. Mine is an entry level TS-253A btw.

So I decided to postpone deep packet inspection and add another DLNA server on my network that is equivalent of your VLAN10. So I just enabled DLNA server on Win10 host (manual) and tried to check the situation on the other side of PIM setup using another Win10 machine (e.g. your VLAN40/60).

QNAP                                              windows media player on Win 10
\                                                /
 ------------------- R1 PIM-SM ------------------
/                                                \
W10-DLNA                                          Slick Upnp on Android

The results are quite interesting. My receiver shows both DLNA servers which is expected. But DLNA from Win10 appears within couple of seconds when I close and open WMP many times in a row. QNAP behaves as previously, and is available from couple to about 90 seconds since the player launch. Another issue is that Slick on Android detects QNAP device only when connected to my VPN network (or equivalent of your VLAN40/60).

This makes me think that the problem is rather with QNAP then with router and PIM setup. I made a traffic dump for further analysis of the case when 2 DLNAs are shown with a delay during 1 player launch, maybe I’ll take a look at it later. Cause I don’t even know what to write to QNAP support in this case. Just a general question “why QNAP appears later than another DLNA”?

25

Get ready for the next long read without the happy end :frowning: We’re stepping into the area where I’m really a noob. And the discussion doesn’t really match a Basic setup as mentioned in the topic. I didn’t expect this kind of details here.

We clarified how discovery is done, but I’ll repeat again briefly. Client (media player) sends data from 192.168.11.9:57047:

M-SEARCH * HTTP/1.1 
HOST: 239.255.255.250:1900 
MAN: "ssdp:discover" 
ST: urn:schemas-upnp-org:service:ContentDirectory:1 
USER-AGENT: OS/version UPnP/1.1 product/version
MX: 3

By saying that we’re sending a request to a multicast group 239.255.255.250 trying to get a reply from the available Media Server devices (device:ContentDirectory). And we’re expecting a reply to return any time within next 3 seconds due to MX value of 3 which is greater than 1 and less than 5. Seems compliant, except we didn’t sent a user agent because this header is optional. Search requests should be sent multiple times due to UDP protocol usage.

An expected reply from media server must be sent back to 192.168.11.9:57047, disregarding where the server is located (note ST header):

HTTP/1.1 200 OK
 CACHE-CONTROL: max-age = seconds until advertisement expires
 DATE: when response was generated
 EXT:
 LOCATION: URL for UPnP description for root device
 SERVER: OS/version UPnP/1.1 product/version
ST: search target
USN: composite identifier for the advertisement

Now I’m done with preparations and I description of the test config. I start traffic sniffing on interface and wait until all my 2 DLNA servers (win 10 is 192.168.10.40 and QNAP is 192.168.10.58) appear in the app.

We can truly see 3 M-Search packets with repeat time about 3 seconds. The content of the messages is the same. Sample is shown and fully compliant.

We’re done with the client. Let’s see what servers reply within 3 seconds from our M-Search request. We can see a reply from DLNA on PC with proper HTTP/1.1 200 OK, ST header and resource location. So about 2 seconds after we sent a search request, I can spot one of my DLNA servers. Same picture appears with other 2 search/reply sequences.


Now let’s see a reply from QNAP. Check the Protocol column, it says just UDP instead of SSDP as on the previous capture. But the data inside looks like an expected content.


HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Fri, 06 Jul 2018 20:54:21 GMT
EXT:
LOCATION: http://192.168.10.58:8080/upnpd/583fe79aa7.xml
OPT: "http://schemas.upnp.org/upnp/1/0/"; ns=01
01-NLS: e155542e-809f-11e8-a4ce-934cd74f7952
SERVER: Linux/4.2.8, UPnP/1.0, Portable SDK for UPnP devices/1.6.22
X-User-Agent: redsonic
ST: urn:schemas-upnp-org:service:ContentDirectory:1
USN: 787120b7-481b-4e3b-8488-49170c28608c::urn:schemas-upnp-org:service:ContentDirectory:1

The same thing happens upon subsequent searches. QNAP DLNA is not yet shown so far in my player. If you take a look at the location, that is not a DLNA port 8200, it’s a WWW port in my setup. And thus QNAP DLNA is not discovered by M-Search request at all.

So how the hell QNAP finally appears in the list? Let’s check for the other M-Search messages in the capture. As you can see starting from the 85-th second QNAP starts to query for available media receivers (device:MediaRenderer) and does that twice (frames 842 and 844). A reply is expected within MX=5 seconds.


And voila. Our Little Engine That Could media player replies with I’m your renderer and completes the discovery.


So, to be able to use QNAP you should be lucky enough that you start your media player close enough to the time when QNAP will search for media players, and not the vice versa how it should be in theory. That kinda sucks.

But if you are looking a media server inside the same segment, Qnap replies immediately. I still have questions for the next round of investigation:

  • It looks like M-Search reaches the other end of PIM setup, because PC DLNA appears instantly
  • Disabling WWW service is not an option for me, although maybe it intercepts SSDP message and it could work properly with disabled web-service (maybe?)
  • Find out how to sniff traffic on QNAP
  • Clarify whether the problem is connected with QVS configuration on my QNAP, and would situation improve if I disable that QVS and try with regular port configuration
  • I doubt I would be able to investigate events on QNAP DLNA, but maybe there are some kind of logs there
  • Strange thing that Spartacus has similar symptoms, but he uses Twonky instead of native DLNA app, however ethernet configuration and device model is unknown. I would like to get a comment on that, maybe it could help a bit in the problem understanding

So far it looks like a QNAP problem

26

Hi,
thans for sharing your results!
I saw you are using the native DLNA-Server and not Twonky, so this issue seems to be qnap specific.

I will also do a test with VLC next week in order to check my Router Config.
https://www.administrator.de/content/detail.php?id=362413&token=462#comment-1259332

And one hint:
Please check your Multicast FW Rule:

 /ip firewall filter add action=passthrough chain=forward dst-address-type=multicast port=1900, 1080, 9080 protocol=udp

Because:

passthrough - if packet is matched by the rule, increase counter and go to next rule (useful for statistics).
accept - accept the packet. Packet is not passed to next firewall rule.

And I got the information, that changing the TTL is not the correct way. I saw in Wireshark that TTL is 4 and this is >1 and ok. So we do not need the rule . I changed it, but the result is the same. Timeing issues!
Next week I will try to setup Kodi on Fire TV Stick and try to map the network share of my qnap. If this works, I will disable the Twonky.

Christian

27

You’re right that that rule does nothing, except adding entries in the log. I added that to see whether mcast packets are actually hitting the forward chain and that’s all. That dirty solution is a bit easier that traffic sniffing and basically did what I wanted.

I tested VLC solution some time ago and it worked nice. The only problem there is that you know what stream you need to connect to in advance. While DLNA uses a bit different approach and discovers available servers and then you can navigate through the dynamically updated content on your NAS. E.g. if you sync some photos, videos from other devices into common folder it becomes immediately available. While in VLC you create your stream each time.

If you’re going to run test, try the same one I did. Place a windows DLNA in your VLAN10 and try to see whether it appears faster than QNAP in other VLANs.

28

Hi Chiverel,
I would like to give you a feedback.

I decided to disable Twonky on qnap. I installed Kodi on my amazon Fire TV Stick and the android devices, and everything works fine with an nfs share…and btw, it is very fast!
This is ok for me and I think I will not go back to Twonky.

But if you find a way, please let me know!
Good luck,
Christian