-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/03/2012 12:17 PM, Steve wrote: Please send me the /var/log/audit/audit.log, so I can look at what SELinux was blocking.

On 11/02/2012 04:23 PM, Konstantin Svist wrote: The problem was SELinux. I totally disabled it on the server and now everything works. nano /etc/selinux/config, change SELINUX=enforcing to SELINUX=disabled To reiterate, here is what I have - an F17 server set up to serve media files running minidlna, which is a UPnP server. - an Andrdoid tablet running Bubble UPnP, which is both a client for a UPnP server and/or a client to a UPnP renderer and/or a renderer itself. - an F17 box set up as an XBMC device. I enabled XBMC to be controllable by external devices (Settings->Network) and thus it is a UPnP renderer. Right now I can - play media files from the server on the tablet. This is UPnP server -> UPnP renderer. - stream media files from the server to the tablet and send them to the XBMC device. This is UPnP server-> UPnP Client | UPnP client -> UPnP renderer. - play media files from the server on the XBMC device. Everything works with the exception that I have the firewalls disabled on all my devices. UPnP didn't work on the clients with their firewalls enabled. All the PCs are, of course, behind the firewall in my router, so its not like they are directly exposed to the Internet. Its great that everything works because now I have complete access to all my media STORED IN ONE CENTRAL LOCATION from just about any device in the house. No more having to different files on every machine and never having things in sync. I have no idea why SELinux was messing things up on the server. The minidlna is running with root permissions. The media files have user permission for read/write and read permission for everything else. I'll tackle the firewall issue when I get time in the near future and report back when I get it figured out.

On 11/02/2012 03:06 PM, Steve wrote: Glad to hear :) No, sorry, I always configure the firewall with vim /etc/sysconfig/iptables In theory, sure -- but I haven't seen any working examples/configs when I last researched it. I had considered extending/copying the iptables' FTP plugin to work for upnp, but gave up since my workaround works for me. Like I said, since you can dedicate a special port on the server for the upnp server, it's reasonably secure - only that port is open. It's the client that's the problem :( If you find something interesting, please post here!

On 11/02/2012 08:01 AM, Steve wrote: The biggest problem with upnp on linux is the simple fact that it's a protocol that dynamically allocates ports, similar to FTP... but does it in a really annoying way. The initial connection is UDP/multicast to the entire network by the client, then each server sends the client a packet UDP/unicast with description of how to get to the server (usually TCP/unicast). Server-side problem: if the server picks a random port, both client and server firewalls won't know how to open that port (or, rather, when/why it should be opened). I've used Fuppes and Rygel - both allow me to specify a port instead of allocating one on the fly. For rygel, setting is port=... in ~/.config/rygel.conf (or /etc/rygel.conf for system-wide config - this makes less sense, since rygel is meant to be run by each user in parallel to share their own media... but who cares :). To automagically join eth0 interface to the multicast network 239.0.0.0 on startup, add a file /etc/sysconfig/network-scripts/route-eth0 with this contents: GATEWAY0=0.0.0.0 NETMASK0=255.0.0.0 ADDRESS0=239.0.0.0 Here are my server-side firewall rules (I use port 1085 to serve upnp, and 192.168.0.0/24 is my LAN; I'm being a bit paranoid about where I receive upnp requests from) -A INPUT -m state --state NEW -m udp -p udp -s 192.168.0.0/24 -d 239.255.255.250 --dport 1900 -j ACCEPT -A INPUT -m state --state NEW -m tcp -p tcp --dport 1085 -j ACCEPT This is reasonably secure, assuming your server always stays within your network (i.e. it's not a laptop that roams different networks). Devices that come bundled with upnp support (PS3, N900, TVs, etc.) should just work at this point (they work fine for me). On the linux client side, there's no good firewall config (as far as I can tell). Initial client request uses multicast network 239.0.0.0 and port 1900, but servers respond to it using port 1900 on the LAN network -- the packet is sent directly to the client instead of being multicast. Stateful inspection on the client firewall doesn't help us here, because the target (broadcast address) and source (server address) are technically different. The workaround (assuming your client won't leave your network and your network is reasonably secure!*) is to hardcode your upnp server's response packet paths. Off the top of my head: -A INPUT -m udp -p udp -s 192.168.0.123 --sport 1900 -j ACCEPT (assuming server has IP 192.168.0.123) * This is potentially dangerous, especially on any machine that sometimes connects to other networks (read: laptops!). The upnp client app (VLC, XBMC, etc.) will pick a random local port, so destination port can't be fixed ahead of time; and as already mentioned, the target of request and source of response are technically different, so firewall doesn't recognize the state. HTH

On 11/02/2012 01:54 AM, Steve wrote: I could not figure out howto make Rygel work on F17 with my Sony Bravia tv. I now use Serviio. Works fine streaming even 1080p mkv files and there is also an Android app which you can use to control Serviio. Plus: it works (once you get the firewall rules sorted. See Serviio FAQ) Minus: it's not Open Source, for extra functionality you need to pay and it needs ffmpeg (I installed the one from rpmfusion.org) http://www.serviio.org/ Regards, Patrick

On 11/01/2012 06:13 PM, Steve wrote: I didn't give any details because your question is pretty vague :P upnp can be used for serving media and for controlling various devices (firewall/NAT on your router, IP cam, etc) I'm mostly using Rygel to serve media to a bunch of devices that support it (XBMC, PS3, networked Samsung bluray player etc.) If that's similar to what you're trying to do, I can get you more specifics

On 11/01/2012 05:54 PM, Steve wrote: Yes, both It can be pretty annoying to set up (as far as the firewall goes), but otherwise works fine