Anyone doing UPNP on Fedora ?

Fri Nov 2 19:00:02 UTC 2012

On 11/02/2012 08:01 AM, Steve wrote:
> On 11/01/2012 07:58 PM, Konstantin Svist 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'd like to make a hard drive containing various media files available 
> to various devices around my house.
>
> The various devices include 2 Samsung TVs, an iPhone, an N900 phone, 
> an Asus Infinity Android tablet, a couple Windows laptops and a few 
> Linux laptops and PCs.
>
> I'd like the files to be served from a Linux (Fedora 17) server.
>
> Right now I am trying to share the media drive using uShare or XBMC.  
> I get the same results with both.
>
> On the Android tablet I can see the shared folders using the Bubble 
> UPNP  player, but they appear empty.   On a Fedora laptop I can mount 
> the server using djmount and can see the folders as well, but they 
> appear empty as well.  If I attempt to ls the folders, I get an 
> "endpoint disconnected" error.
>
> Upnp-Inspector displays the server as a valid UPNP server running both 
> server packages.
>
> I have the firewalls disabled on all devices, except the Android tablet.
>
> Several forum posts indicate that one must add a route to the server's 
> iptables to allow UPNP multicasting as follows.
>
> route add -net 239.0.0.0 netmask 255.0.0.0 eth0
>
> How do I add this to my system when using system-config-firewall and 
> system-config-network with devices managed by NetworkManager ?
>
>> 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
> Please do.   I was going to try minidlna next, but it doesn't seem 
> like the UPNP server software is the problem.
>
> FYI, I am very disappointed to find that KDE as shipped in Fedora 
> doesn't directly support UPNP sharing and that none of the popular 
> Linux media players (VLC, Totem, Amarok, etc) have UPNP support built 
> into them via plug ins from a Fedora repository.  It takes much 
> mucking around to add UPNP functionality to these applications.
>
> Thanks
>

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