TL;DR: If you’re running a Plex Media Server in a guest domain on a KVM/QEMU/libvirt-based hypervisor platform, make sure that the bridge you use to provide network access to the guest domain (such as macvtap) is configured in the host OS such that the allmulti flag is enabled. Assuming your bridge is macvtap0, you would sign into the host and go about setting the appropriate flag as follows:
$ sudo ip link set dev macvtap0 allmulticast on
Without this configuration, not all multicast packets required for DLNA (particularly client discovery operations) will be sent over the bridge to the guest domain, and the guest domain will log no evidence of discovery attempts made against it despite being configured properly to receive those UDP multicast packets through port 1900.
Research and Diagnostic Conclusions
The reason this occurs is that the DLNA specification implements the SSDP (Simple Service Discovery Protocol) which is a UDP-based multicast protocol that allows devices to advertise and inquire after service information from all other devices on the network that have deemed these multicast packets worth hearing. So, when you attach your iPad to your wireless network at home and you use MediaConnect to scan for DLNA servers on your network (which it automatically does when started), it sends out a multicast inquiry which the server must be listening for.
So if you notice symptoms wherein your Plex Media Server service can be restarted and thereby discovered by listening devices (such as a PS3, waiting at the XMB menu), but it is soon lost if the listening device is restarted or the listening service (such as MediaConnect running on an iPad) is restarted, that is reasonably strong evidence to conclude that there is a problem with the Plex Media Server’s capability to receive multicast packets. The reason a service restart causes the listening devices to discover the Plex Media Server is that the server, when started, emits SSDP multicast packets announcing its presence. The traffic can be sent, but responses (of which none are required, at this point) and inquiries will fail to reach the system. The system will effectively be rendered deaf to inquiries, and thereby unannounced to clients on its subnet who missed or forgot the initial announcement, lest it be configured or compelled to emit another SSDP announcement.
Once the services locate one another using this UDP-based protocol, the data sought by the client is itself requested and transmitted over a TCP-based connection (TCP 32469). So, if you just get that one announcement packet via SSDP, you now know enough about the service to connect to it via TCP and thereby bypass any further problems based on multicast, so long as the client remembers the information and the server doesn’t undergo any critical changes.
So that’s how DLNA works. If you receive the following PS3 errors:
DLNA Protocol Error (501), DLNA Protocol Error (7531)
In my case, they were related to the server’s inability to receive UDP multicast packets. For the life of me, I cannot locate the specification to which those error numbers refer. If anyone knows where it is, let me know!
The reason this has happened in my case is that, under normal conditions, the Plex Media Server software will make use of its operating system’s kernel to set its NIC driver’s multicast list to include the addresses of interest to the software. This instructs the driver to send along the UDP multicast packets addressed to those subnets defined on the multicast list (such as the SSDP discovery packets described above), and it would ignore all those multicast addresses in which its OS is not interested.
Unfortunately for a guest domain making use of virtio drivers, it appears there is no mechanism by which the virtio driver’s multicast list is passed to the macvtap bridge created in the OS providing the KVM/QEMU/libvirt virtualization platform. So, while the guest domain’s NIC is properly configured, the bridge upon which it relies for its traffic is ignoring the UDP packets of interest and refusing to pass them along.
The workaround, therefore, lies in the three multicast options one may configure for NICs managed by the Linux kernel. A NIC may be instructed to be in a state of MULTICAST, ALLMULTI, or PROMISC.
The first, enabled by default for every NIC in most (all?) distros, instructs the device to accept only those UDP packets addressed to a subnet included in the list provided to the NIC by the kernel. That’s how I found my bridge, and that doesn’t help me because the bridge doesn’t receive a multicast list from the guest domain’s kernel. Therefore, it doesn’t (necessarily? I’m guessing it registers no subnets of interest by default..) pass along multicast packets of interest to the guest domain.
The second flag we could use is the ALLMULTI flag. This instructs the device (the macvtap bridge, in my case) to send along all multicast packets and let them be sorted out by the receiving kernel (or NIC, since it’s a bridge, in our case). This solves the problem in my case, since the NIC of the guest domain is now receiving all multicast packets, and it can decide what to do with them.
The third flag would instruct the NIC to pass along all traffic it receives, and this is just overkill for the job, though it would solve the problem (and potentially introduce others). The NIC would pass along every single packet going across the network and likely congest the guest domain’s bandwidth and CPU resources pretty quickly, especially if lots of clients are on the subnet.
So hopefully that demystifies DLNA a little bit. If you’re having DLNA problems, feel free to describe the situation in the comments and we’ll see if we can’t generate some solutions worth sharing. Finding the correct information on this subject matter was too burdensome.