Bug 892801 - no way to enable UPnP (SSDP)
no way to enable UPnP (SSDP)
Status: NEW
Product: Fedora
Classification: Fedora
Component: firewalld (Show other bugs)
25
All Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Thomas Woerner
Fedora Extras Quality Assurance
:
: 904336 1215266 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-07 16:31 EST by Aleksandar Kostadinov
Modified: 2016-07-26 01:10 EDT (History)
28 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Aleksandar Kostadinov 2013-01-07 16:31:06 EST
With firewalld I see no way to enable upnp. For upnp one needs to do --sport 1900 but this is not possible as far as I see. Custom rules are not persisted. What are the options? I think this is a major drawback.
Comment 1 Jiri Popelka 2013-01-30 09:12:09 EST
*** Bug 904336 has been marked as a duplicate of this bug. ***
Comment 2 Jiri Popelka 2013-01-30 10:04:00 EST
All I know is that UPnP/SSDP is something "Windows-related" so take my questions easy ;-)

Are you sure it's *source* port 1900 ?
I've read about UPnP and yes, all [1] the sources talk about 1900/udp & 2869/tcp but I can't see anything about source port. And the only iptables snippet [2] I found uses --dport 1900.

(just out of curiosity) What's your use case ?

[1]
http://en.wikipedia.org/wiki/Universal_Plug_and_Play#Protocol
http://support.microsoft.com/kb/886257#4
http://www.upnp-hacks.org/upnp.html

[2]
http://lists.fedoraproject.org/pipermail/users/2011-May/396236.html
http://www.gentoo-wiki.info/HOWTO_Setup_UPnP_with_IPTables
Comment 3 Aleksandar Kostadinov 2013-01-30 10:45:56 EST
upnp can be used for discovery of multimedia and other networked devices. It also can instruct a network gateway to open ports for particular machine behind NAT (e.g. home network). This avoids the need to statically map network ports for applications.

The upnp service is running on port 1900 multicast (on the machine advertising services). The tcp port I guess is windows specific. Being multicast there is no conntrack. So matching the server replies to the app trying to open port or discover devices is not currently possible using stateful firewall.

That leaves us with a rule like:
iptables -I INPUT -s <your network> -p udp --sport 1900 -j ACCEPT

This is assuming outgoing multicast traffic is already allowed (what is the default).

This is what I have found without reading the upnp standard document. I wont be surprised if the facts above are not entirely true.
Comment 4 Laurent Aguerreche 2013-03-07 17:37:03 EST
Instead of opening the firewall to all the local network I open it for data from a UPnP server (a NAS with IP 192.168.0.4). In this case, my computer reads data from the NAS thanks to the following rule:

firewall-cmd --direct --add-rule ipv4 filter IN_ZONE_home_allow 0 -p all --source 192.168.0.4 -j ACCEPT


I use the zone 'home' with IPv4.

But this solution has two problems:
1/ I need to use the switch '--direct' because Firewalld seems to be unable to allow all traffic from a given machine (or I didn't find how), hence this command relies very much on iptables instead of the abstraction from firewall-cmd,
2/ Because of '--direct', the result isn't persistent.
Comment 5 Arun Babu Neelicattu 2013-07-11 10:22:16 EDT
[bug 626188] talks about rygel and its specific to how to handle server side. The workaround for rygel - to set a fixed port via the rygel.conf is an acceptable and easy solution.

As a result of the issue highlighted in this bug (stating the obvious), is that UPnP clients like totem and vlc cannot identify, browse or play from UPnP servers.

I can reproduce this quite easily on F19. Totem discovers media shares quite easily when the firewall is turned off, or when one of the above rules are manually applied.

Having firewalld providing an option to enable UPnP clients like totem or vlc to use shares will be very helpful.
Comment 6 Konstantin Svist 2013-09-11 03:04:54 EDT
I have both upnp servers and clients

upnp protocol is pretty stupid and not firewall-friendly at all
From memory (so might be wrong): in discovery process, client sends a packet to 239.255.255.250 from a random port (let's say [12345]). Each server that listens on this broadcast IP (i.e. is upnp-enabled) sends a reply directly to the client's port [12345]. Since the reply doesn't come from 239.255.255.250 and doesn't come into a predetermined port, firewall (iptables, anyway) doesn't know how to process it, so it throws away the packet.
On server there's not much of a problem since the service can be bound to listen/reply on a specific port, as mentioned in comment 5

The only proper way I see of handling it on the client is to make an ftp-like handler -- scan all packets sent to 239.255.255.250/1900 (at least port 1900 is standard..) -- and temporarily open the source port to replies from any hosts on the network

How hard is it to implement this?
Comment 7 Konstantin Svist 2013-09-11 03:45:46 EDT
P.S. looks like firewalld is just an interface to netfilter.. so it would still need to be implemented as part of netfilter.. is that correct?
Comment 8 Thomas Woerner 2013-09-11 09:35:28 EDT
Yes, a netfilter based solution is needed.
Comment 9 Maciek Borzecki 2013-11-11 06:06:29 EST
Still valid in F20
Comment 10 Ash Hughes 2014-03-08 11:53:34 EST
I've started on a userspace helper for UPnP (SSDP), any help testing and tweaking it to get it merged would be appreciated. It works for me in it's current state, but may need more work :).

A full solution would require that firewalld be able to use conntrackd userspace helpers, not just the kernel helpers.

marc.info/?l=netfilter-devel&m=139429473308767&w=2
Comment 11 secondary 2014-08-24 22:55:38 EDT
Thanks, so much!

This target needs to updated to F20. Since the changes have been accepted to upstream conntrack-tools, one must simply wait for them to make a new release. Then backport that to F20... Overall, will probably take some time.

As for firewalld, the problem is that there is no dynamic configuration for conntrackd: step [3] of [http://conntrack-tools.netfilter.org/manual.html#helpers]. Fedora's firewall would have to [1] register a userspace conntrack helper (simple, pre-enable action like module loading) [2] add a netfilter rule (already possible) [3] update conntrackd configuration (not possible afaik).

I'm not sure of the exact process of [helper -> iptables/CT -> iptables/NFQUEUE -> conntrackd]. Some of the steps seem redundant, but I assume te process is like so:
1] enable/disable helpers dynamically (nfct helper add)
2] configure netfilter to send matching packets to CT target
3] CT target is magic kernel module (libnetfilter_queue) that dispatches packets to proper NFQUEUE per /etc/conntrackd/conntrackd.conf
4] conntrackd (userspace) consumes packets and creates expectations (dynamically modifies incoming netfilter rules based on outgoing traffic)
5] expectations somehow unregister themselves after having been met.

If this is the case, fedora should provide conntrack-tools with all userspace helpers pre-configured in /etc/conntrackd/conntrackd.conf. Then firewalld simply adds/removes userspace helpers (nfct helper add/remove) under the assumption they are properly configured.

However I'm sure this proposal is bound to upset some people.
Comment 12 secondary 2014-08-24 22:56:39 EDT
Needs input.
Comment 13 Fedora End Of Life 2015-01-09 12:33:50 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 14 Aleksandar Kostadinov 2015-01-09 14:06:39 EST
I think it has not been fixed.
Comment 15 Jiri Popelka 2015-04-27 03:58:00 EDT
*** Bug 1215266 has been marked as a duplicate of this bug. ***
Comment 16 Thomas Woerner 2015-08-17 07:17:13 EDT
(In reply to Laurent Aguerreche from comment #4)
> Instead of opening the firewall to all the local network I open it for data
> from a UPnP server (a NAS with IP 192.168.0.4). In this case, my computer
> reads data from the NAS thanks to the following rule:
> 
> firewall-cmd --direct --add-rule ipv4 filter IN_ZONE_home_allow 0 -p all
> --source 192.168.0.4 -j ACCEPT
> 

You can use source addresses in rich rules:

firewall-cmd --add-rich-rule="rule family=ipv4 source address=192.168.0.4 accept"
You can also add rich rules to the permanent environment with the --permanent option.
Please remember that you need to add the rule with and without the --permanent option to have it active immediately and also in the future after a reboot for example.

> 
> I use the zone 'home' with IPv4.
> 
> But this solution has two problems:
> 1/ I need to use the switch '--direct' because Firewalld seems to be unable
> to allow all traffic from a given machine (or I didn't find how), hence this
> command relies very much on iptables instead of the abstraction from
> firewall-cmd,
> 2/ Because of '--direct', the result isn't persistent.
You can also add direct rules to the permanent environment with the --permanent option.
Comment 17 Aleksandar Kostadinov 2015-08-17 07:26:02 EDT
This is still suboptimal as you allow all traffic instead of particular traffic type.
Comment 18 Fedora End Of Life 2015-11-04 04:52:27 EST
This message is a reminder that Fedora 21 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 21. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '21'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 21 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 19 Otto Sabart 2015-11-06 10:38:03 EST
If think still not fixed in Fedora 22
Comment 20 Ermanno Scaglione 2015-11-28 02:39:21 EST
minidlna works perfectly for me using this:

firewall-cmd --permanent --zone=home --add-source=239.255.255.250
firewall-cmd --permanent --zone=home --add-source=192.168.1.0/24
firewall-cmd --permanent --zone=home --add-service=minidlna

/etc/firewalld/services/minidlna.xml 
<?xml version="1.0" encoding="utf-8"?>
<service>
  <short>minidlna server</short>
  <description>ReadyMedia is server software with the aim of being fully compliant with DLNA/UPnP clients. </description>
  <port protocol="tcp" port="8200"/>
  <port protocol="udp" port="1900"/>
</service>
Comment 21 Perry Myers 2016-04-09 14:42:41 EDT
This is definitely not fixed yet. On Fedora 23, running Kodi from RPMFusion and using that as a UPnP client for various home media devices (including an HDHomeRun cable box)

I've searched a bit and tried some of the suggestions in this bz, but as long as firewalld is enabled I simply cannot get the UPnP client to see any traffic and devices. As soon as I disable firewalld, everything just works.

In fact, the Kodi guides for installing on Fedora 23 explicitly say to disable firewalld because there's no way to get this working otherwise. This is a shame, since it means I'll need to basically have no firewall at all running which seems like a security risk.

http://kodi.wiki/view/HOW-TO:Install_Kodi_on_Fedora_23_using_RPMFusion_packages

/me goes to disable firewalld on his machines
Comment 22 Aleksandar Kostadinov 2016-05-02 10:28:21 EDT
I'm really frustrated, how many years are needed to have at least source port support in firewalld rich rules so that one can have a working UPnP client?
Comment 23 Thomas Woerner 2016-05-02 11:00:54 EDT
This will be available in some days now.
Comment 24 Jan Kurik 2016-07-26 01:10:02 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Note You need to log in before you can comment on or make changes to this bug.