DLNA over VLAN: A how (not?) to

[dnavas]

[A "common" if not "frequent" question I see asked is how to make DLNA work across VLANs. I'm not sure if this is a good place to create an answer for this -- feel free to delete or move as appropriate.]

The general advice for making DLNA work across vlans is to "give up" and hard-wire a link from the DLNA server into your network on the vlan that you want to receive the broadcast from. As a software guy, hardware solutions to software problems feel wrong. However, this IS often the best advice, depending on the situation you find yourself in. Here's a little info to help you figure out for yourself what your situation is.

DLNA relies on the SSDP protocol to operate. While you will need to open your firewall from the DLNA client to the DLNA server on whatever port DLNA content is being served from, that is insufficient to get the whole protocol to work across vlans. The DLNA client needs to be aware of the server's existence, and it does this by broadcasting (multicasting) to 239.255.255.250 port 1900 (SSDP) that it's looking for devices that are capable of ... whatever. The server will typically respond to the caller on the source packet's ip/port pair announcing its existence and its set of capabilities.

One possible solution is to setup pimd. PIMD can route UDP traffic across networks. The directions for configuring pimd are a little sparse and confusing. What I did was to set the Default Bind to "Bind to None" and then add the set of interfaces to the Interfaces tab (in my case "LAN" and "Media VLAN"). I added one entry to BSR Candidates and RP Candidates ("LAN" for both). Then I opened igmp on 224.0.0.0/4 (probably a tad broad) and udp on the SSDP ip/port above (setting the "Allow packets with IP options to pass" on as one should with multicast traffic). And, of course, I opened port 9000 to my DLNA server in my "MEDIA VLAN" ruleset. It kind of worked. If I waited on the client machine, the client eventually got wind of the server and I could play. The problem was that on restart, the client box "forgot" where the server was, and I had to wait for the client to learn about the server again.

A little packet capture explained why. In order to cast the widest net I knew how, I opened 224.0.0.0/4 and 240.0.0.0/4 to multicast traffic, hit capture packets and stared at the results in wireshark. The Client SEARCH SSDP packets all had a ttl of 1. So, the client packets went right up to the edge of the network and expired. The server SSDP broadcasts announcing the server's existence occurred every couple of minutes and had a ttl of 4 (which was nice, but an odd default choice given the server's subsequent behavior). That meant that the client couldn't verify the server's existence on restart, but when the server announcement went through, the client learned about it, and could proceed.

So, that was suboptimal. Next up was udpbroadcastrelay, which is both harder and simpler to setup. [Note: first turn off pimd!] There's no gui, but there is (blessedly) a package you can install from the shell. "pkg search udp" and then "pkg install udpbroadcastrelay-0.3.b" got the thing installed. Then it was a matter of running it in debug mode (replace ix0 and ix0.### with the interfaces you care about from the output of ifconfig):
/usr/local/sbin/udpbroadcastrelay -d --id 1 --port 1900 --dev ix0 --dev ix0.### --multicast 239.255.255.250

[There is information about how this is setup in other posts here, as well as on github where the source for this code resides.]

Fortunately, the relay preserves ttl, and using it also means you don't need to muck about with firewall rules. Unfortunately my dlna server was still not responding. Sadly, Twonky doesn't appear to be happy servicing requests across vlans. Running Twonky in debug mode and you can see that it is, indeed, receiving SSDP packets. It then notes that "192.168.XX.21" is not in the same network as it's listening on ("192.168.Y.21") and so, it ignores the request. Tears. Now, why it broadcasts with a ttl of 4, but doesn't expect non-local SEARCH requests is a mystery to me, but there you are. Perhaps it expects some kind of NAT? Sadly, the software is not open source, and I am but a humble novice in these parts.

So, what do we learn from all of this? First, it's possible that the DLNA client is not setup to handle routing SSDP across networks -- in my case my Oppo Bluray player was sending packets with a ttl of 1. Second, it's also possible that the DLNA server is not setup to respond to SSDP across networks -- in my case, Twonky had no way to specify that it should be allowed to respond to specific out-of-network SEARCH requests. And true, you can spoof the return address using udpbroadcastrelay, but that just ensures that the server's response is sent to your gateway, which I can assure you isn't paying attention :>

...and this is why there is the advice to just fix this problem with another ethernet connection from the server to the vlan in question! Wise advice for someone who is using this in a commercial setting. But I'm stubborn (and at home). In my case, I installed minidlna.

Your mileage will vary. Please feel free to offer other suggestions and questions. Note that I've never attempted any of this before -- packet capture, wireshark, multicast, SSDP, NAT, and all the rest of it is new ground for me, so go easy :) Hopefully this can help as a guide to the next hapless/hopeless adventurer.

[stephenw10]

@dnavas said in DLNA over VLAN: A how (not?) to:

Your mileage will vary

That is very true. I have seen users enable PIMD between the interfaces and do nothing else and it all immediately started working. I have seen other users spend weeks trying to make it work and fail. Implementations of clients and servers seem to vary significantly.

Steve