Description of problem: Firewall blocks Rygel Version-Release number of selected component (if applicable): How reproducible: Install rygel, try to use it, fail. Steps to Reproduce: 1. 2. 3. Actual results: No button in the firewall preferences to enable Rygel. Expected results: I expected to be able to check a button in the firewall configuration to enable Rygel. Additional info:
The problem isn't with rygel but rather the firewall config tool
This bug has been awaiting a long time and is pretty critical since rygel just can't work without the fix for this. I always get angry users who tell me that rygel doesn't work for them and its always because of default firewall rules not allowing UPnP ports. Can this be fixed anytime soon please?
I second Zeeshan, it would be great to make it easier for users to share media through UPnP without having to deal with his firewall configuration.
Yes, please. This is really annoying.
Do you have information on ports and rules, that are needed for this? The documentation of rygel does not cover firewall settings at all. This is the only information I could find in a mailing list, but it also says that the 34567 port is dynamic and that this has not been tested at all: 239.255.255.250:1900/UDP localhost:1900/UDP localhost:34567/TCP
(In reply to comment #5) > Do you have information on ports and rules, that are needed for this? > > The documentation of rygel does not cover firewall settings at all. Thats because user doesn't need to know that, in fact we don't even want him/her to know about existence of rygel. :) > This is the only information I could find in a mailing list, but it also says > that the 34567 port is dynamic and that this has not been tested at all: > > 239.255.255.250:1900/UDP > localhost:1900/UDP This is correct, except for the localhost part, you want to allow 1900 port on every address/iface. If you don't want this port to be open by default, I suggest creating a special config for "UPnP" (Its SSDP actually but nobody uses the protocol without UPnP) that opens these ports. AFAIK, Windows does that. Its still very annoying for users but its still better than asking users to disable their firewalls completely. > localhost:34567/TCP This one is pretty much dynamic and is decided by libsoup (SoupServer) for us but afaik there is no issues with these (user) ports?
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 WONTFIX if it remains open with a Fedora 'version' of '13'. 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 prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 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 please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Still not working out of the box? With Zeeshan now working for Red Hat even? Bummer :)
Maybe attaching a patch would help get this going. git clone git://git.fedorahosted.org/git/system-config-firewall edit src/fw_services.py, add whatever services you want create a patch with "git diff > rygel.patch" Apply it to your test machine, verify option shows up and rygel works when it is checked you could attach the patch to the fedorahosted trac, but might as well just attach it here and Thomas will probably pull it in.
Created attachment 533617 [details] Add option to permit 'UPnP' discovery protocol
Forgot to mention that I didn't get to test this patch.
(In reply to comment #11) > Created attachment 533617 [details] > Add option to permit 'UPnP' discovery protocol I'm not sure that's enough. It's sufficient for the announcement case (device on the network sends the alive beacons) but not for active searching: Fedora host sends SSDP mcast package from some random port (say 12345) → 1900, as per standard the reply has to go to port 12345 _and_ should not originate from port 1900 but another random port on the sending machine.
This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached 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 to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. 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. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
(moving to rawhide to keep it open..)
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
The patch in comment 11 should be correct for UPnP servers if the assumption about user ports in comment 6 is true. There might be an issue with UPnP clients, though.
We replaced iptables with firewalld by default several cycles back. It may not be a good idea to repurpose this bug as iptables and s-c-f still exist and haven't been officially obsoleted yet, but it would probably be a good idea to also file a bug against firewalld , if it doesn't already handle this (from a quick look at /usr/lib/firewalld/services/ , I don't see anything relating to Rygel or UPnP). Given how firewalld works, Rygel could actually request a hole in the firewall interactively; that's one of the things firewalld is intended to enable. So the app could be enhanced here as well.
CCing Jiri, who is active in firewalld maintenance ATM (along with Thomas).
It's been a while since I was able to test this, but I don't think opening port 1900 is sufficient. I'm not in a position to be able to test this at the moment. As I recall, though, the client (eg a TV or a network-streaming amplifier) connects to the uPnP server on a port supplied as part of the exchange that was happening on port 1900 and that port was blocked. As I say, this was a little while ago, but what seems to be needed is a conntrack module (in the kernel) that knows enough about the uPnP protocol to be able to mark the new connection as "related". This isn't an iptables or a firewalld issue. Obviously this hypothesis needs testing.
Only opening the 1900 port isn't enough. There's another port that needs to be opened, like Jens mentioned. This port is a dynamic port that libsoup uses, and is a user port. Are user ports open by default in the firewall? I don't think so. I manually specify a port for rygel to use via the configuration file and then open this up from firewalld to get rygel to work completely. I was wondering how firewalld would know what this other port was, if it were dynamic.
(In reply to comment #21) > Only opening the 1900 port isn't enough. > > There's another port that needs to > be opened, like Jens mentioned. This port is a dynamic port that libsoup > uses, and is a user port. Are user ports open by default in the firewall? I > don't think so. They really should be, no? > I manually specify a port for rygel to use via the configuration file and > then open this up from firewalld to get rygel to work completely. So you are saying that you have tested that after you open port 1900, you still can't get rygel to work w/o the above? > I was wondering how firewalld would know what this other port was, if it > were dynamic. I guess it wouldn't but as pointed out in comment#18, rygel could also be modified to punch holes in the firewall. Although I wonder if its a good idea for rygel to do that w/o asking or informing the user/admin. Maybe rygel should choose a specific port by default in the configuration rather than using dynamic port?
(In reply to comment #22) > (In reply to comment #21) > > Only opening the 1900 port isn't enough. > > > > There's another port that needs to > > be opened, like Jens mentioned. This port is a dynamic port that libsoup > > uses, and is a user port. Are user ports open by default in the firewall? I > > don't think so. > > They really should be, no? No clue. We'll need the firewalld folks to clarify this one. > > > I manually specify a port for rygel to use via the configuration file and > > then open this up from firewalld to get rygel to work completely. > > So you are saying that you have tested that after you open port 1900, you > still can't get rygel to work w/o the above? Yep. As far as I can tell. I'll re-test this and confirm over the weekend though. I don't want to open any ports here when I'm on university wifi. > > > I was wondering how firewalld would know what this other port was, if it > > were dynamic. > > I guess it wouldn't but as pointed out in comment#18, rygel could also be > modified to punch holes in the firewall. Although I wonder if its a good > idea for rygel to do that w/o asking or informing the user/admin. Maybe > rygel should choose a specific port by default in the configuration rather > than using dynamic port? Any changes to firewall configurations need admin privileges. s-c-printer for example asks for permission before it opens ports to detect network printers. Rygel could use a specific port. That should make it slightly easier, yes. Warm regards, Ankur
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #21) > > > Only opening the 1900 port isn't enough. > > > > > > There's another port that needs to > > > be opened, like Jens mentioned. This port is a dynamic port that libsoup > > > uses, and is a user port. Are user ports open by default in the firewall? I > > > don't think so. > > > > They really should be, no? > > No clue. We'll need the firewalld folks to clarify this one. > No, user ports are not open by default in the firewall. > > > > > I manually specify a port for rygel to use via the configuration file and > > > then open this up from firewalld to get rygel to work completely. > > > > So you are saying that you have tested that after you open port 1900, you > > still can't get rygel to work w/o the above? > > Yep. As far as I can tell. I'll re-test this and confirm over the weekend > though. I don't want to open any ports here when I'm on university wifi. > > > > > > I was wondering how firewalld would know what this other port was, if it > > > were dynamic. > > > > I guess it wouldn't but as pointed out in comment#18, rygel could also be > > modified to punch holes in the firewall. Although I wonder if its a good > > idea for rygel to do that w/o asking or informing the user/admin. Maybe > > rygel should choose a specific port by default in the configuration rather > > than using dynamic port? > > Any changes to firewall configurations need admin privileges. s-c-printer > for example asks for permission before it opens ports to detect network > printers. Rygel could use a specific port. That should make it slightly > easier, yes. > Any firewall change needs admin privileges. If Rygel could use a specific port instead of a dynamic port, then this could be easily added to a new Rygel service entry. With a dynamic port on the other hand there needs to be some mechanism in Rygel that tells firewalld to open this port. But still admin privileges are needed for this. I thought also about a database to store information about applications that are allowed to open additional ports, but this does not exist, yet. This needs application policy support in firewalld. > Warm regards, > Ankur Thomas
> If Rygel could use a specific port instead of a dynamic port, then this could > be easily added to a new Rygel service entry. That would certainly make things easier. > With a dynamic port on the other hand there needs to be some mechanism in Rygel > that tells firewalld to open this port. But still admin privileges are needed > for this. Don't forget that Rygel isn't the only uPnP server. A solution that would help *all* uPnP servers would be a conntrack helper: there are already conntrack helpers for various other protocols, adding a uPnP helper would, well, help everyone.
(In reply to comment #25) > > If Rygel could use a specific port instead of a dynamic port, then this could > > be easily added to a new Rygel service entry. > > That would certainly make things easier. > > > With a dynamic port on the other hand there needs to be some mechanism in Rygel > > that tells firewalld to open this port. But still admin privileges are needed > > for this. > > Don't forget that Rygel isn't the only uPnP server. A solution that would > help *all* uPnP servers would be a conntrack helper: there are already > conntrack helpers for various other protocols, adding a uPnP helper would, > well, help everyone. Yes, that would be the best solution. But it would surely take some time to have an upnp helper in netfilter.
(In reply to comment #18) > it would probably be a good idea to also file a bug against firewalld bug #892801 (and its duplicate bug #904336)
Is uPnP working over NAT? I thought it is only a local network protocol. And if it is only local network, then isn't it easier to have a layer 7 iptables match module that recognizes uPnP and can allow that kind of traffic to particular local ports?
It can't work over NAT: uPnP clients discover servers by broadcasting and there is no way you can do that with NAT. Also, an iptables conntrack helper does not imply NAT, merely the tracking of related packets.
@John, I don't know how upnp exactly works but I can't see how a mere con tracking can help. Are all connections initiated locally so contrack can be used to allow that traffic? So in the first place I htink an iptables module would be needed to match upnp packets. Wouldn't the plain UDP contrack do the job once connections are established?
No, plain udp conntrack isn't sufficient. The protocol includes URLs for various resources: album covers, audio streams, etc. I'm going from shaky memory of a few months back when I was looking more closely at this, but the URLs all have IP addresses instead of hostnames and it was not immediately obvious that the port could be specified in some configuration. A conntrack helper needs to identify those URLs so that incoming connections can be allowed on the local subnet. I'm not sure that this is possible, but some investigation is called for. My local solution was simply to allow access from the various (fixed) IP addresses of the clients I have. It's just around the house so it's a reasonably constrained environment. Unfortunately uPnP was not designed with any sort of firewall in mind.
For what it's worth, coherence has a good and useful uPnP browser.
@John, do you mean that a multicast packet specifies URLs? In this case I can't see how contrack can help because sending out a multicast packet doesn't mean any client will ever connect back even less it tells which one client. Instead I think the firewall needs to recognize the incoming packets are upnp and destined to correct local ports. I am thinking that perhaps without modification of iptables, if upnp server listen ports can be fixed, then packets to these ports can be send to userspace and perhaps that can be a daemon that allows packets based on announcements made by upnp server. Or perhaps that daemon can have an iptables chain to manage and based on upnp announcements from local upnp servers and clients, it can enable/disable different local machine ports. This way no modification to contrack, iptables and upnp server/client would be needed. WDYT?
You seem to be suggesting that the server sends multicast packets. That's not the case. The service listens for broadcast/multicast packets on port 1900: that's a fixed port. It sends a response out to the client that sent the broadcast packet. From that initial response, the client can now make further requests to discover what the server is offering. This is the point at which things usually fail: the new connections are completely new to iptables and so they are blocked. A conntrack helper would be able to recognise the URLs in initial reply and open the corresponding port(s) for the client to continue its discovery. If, and it's a big if, there are only two ports involved: 1900 and some fixed configurable port, then we don't need conntrack. The problem seems to be that this is not the case.
@John, if server sends unicast UDP to client and client replies with unicast udp, then why is not regular UDP conntrack not working? I'm running a VPN over UDP over the whole internet from NAT-ed machines with no problems, so it can't be the lack UDP conntracking.
Because the payload in the response contains the URL telling the client where to connect to next. Conntrack has absolutely no knowledge of this so iptables does not know that the next packet coming from the client is related to the original request and it blocks it. The original request to port 1900 (which must be open) is not a problem. It's the subsequent requests to a completely unrelated port that cause the issue. I'm currently playing a track from a uPnP server on my hi-fi. There is a TCP connection to the server on port 8200 (this isn't, as it happens, Rygel). There is no way for UDP conntrack to work out that this is related. You need a conntrack helper that understands enough of the protocol payload to recognise ports that need to be opened from the payload (the FTP conntrack helper does something similar). In this particular case it might be enough to open 1900/udp and 8200/tcp but I'm not sure if that is true in the general case or if there are other ports that are needed.
(In reply to comment #34) > You seem to be suggesting that the server sends multicast packets. That's > not the case. The service listens for broadcast/multicast packets on port > 1900: that's a fixed port. It sends a response out to the client that sent > the broadcast packet. From that initial response, the client can now make > further requests to discover what the server is offering. > > This is the point at which things usually fail: the new connections are > completely new to iptables and so they are blocked. A conntrack helper > would be able to recognise the URLs in initial reply and open the > corresponding port(s) for the client to continue its discovery. > > If, and it's a big if, there are only two ports involved: 1900 and some > fixed configurable port, Its not. That is the only other incoming port. Its the port rygel runs its HTTP server on and it uses this port for *all* HTTP, including media transfer etc. > then we don't need conntrack. The problem seems > to be that this is not the case. I think to solve this issue w/o getting into too much trouble, we can choose a specific port in rygel's default configuration.
(In reply to comment #37) > (In reply to comment #34) > > You seem to be suggesting that the server sends multicast packets. That's > > not the case. The service listens for broadcast/multicast packets on port > > 1900: that's a fixed port. It sends a response out to the client that sent > > the broadcast packet. From that initial response, the client can now make > > further requests to discover what the server is offering. > > > > This is the point at which things usually fail: the new connections are > > completely new to iptables and so they are blocked. A conntrack helper > > would be able to recognise the URLs in initial reply and open the > > corresponding port(s) for the client to continue its discovery. > > > > If, and it's a big if, there are only two ports involved: 1900 and some > > fixed configurable port, > > Its not. That is the only other incoming port. Its the port rygel runs its > HTTP server on and it uses this port for *all* HTTP, including media > transfer etc. * Its not -> Its not an 'if :) * only other incoming port -> only other incoming port other than the port 1900
(In reply to Zeeshan Ali from comment #37) > (In reply to comment #34) > > You seem to be suggesting that the server sends multicast packets. That's > > not the case. The service listens for broadcast/multicast packets on port > > 1900: that's a fixed port. It sends a response out to the client that sent > > the broadcast packet. From that initial response, the client can now make > > further requests to discover what the server is offering. > > > > This is the point at which things usually fail: the new connections are > > completely new to iptables and so they are blocked. A conntrack helper > > would be able to recognise the URLs in initial reply and open the > > corresponding port(s) for the client to continue its discovery. > > > > If, and it's a big if, there are only two ports involved: 1900 and some > > fixed configurable port, > > Its not. That is the only other incoming port. Its the port rygel runs its > HTTP server on and it uses this port for *all* HTTP, including media > transfer etc. > > > then we don't need conntrack. The problem seems > > to be that this is not the case. > > I think to solve this issue w/o getting into too much trouble, we can choose > a specific port in rygel's default configuration. Sorry, that is not going to be easy. Rygel service/process runs per-session (should actually be per-user instead but that is not currently possible) so that is why the incoming HTTP port is set to be dynamic. i-e each rygel instance runs on a separate port allocated dynamically. Unless we can assign a port range to rygel, this is not going to work.
I am enabling Rygel indirectly via the Media Sharing switch in the Gnome 3 settings. My expectation was that, by turning things on there and not starting Rygel manually at system start-up, the firewall rules would have been authorized and mangled appropriately for things to work out-of-the-box. I was a bit disappointed that with firewalld, manual intervention was required for things to work across the local network. Right now, to get around having to use 'lsof -i' to figure out the ports Rygel is currently using and reconfigure the firewall after each reboot, I am following the instructions on: http://ankursinha.in/blog/2013/05/12/setting-up-rygel-on-your-fedora-system/ to set a static port for Rygel. Then I can manually open a permanent port in firewalld and not have to deal with it any more. That is not out-of-the-box working though. I would assume that if "Media Sharing" requires firewall fiddling then so will the DAV-based "Personal File Sharing" and the VNC-based "Screen Sharing" but I investigated those options yet. Perhaps this firewalld fiddling should be handled at the GNOME 3 settings level and the ports to use can be passed to firewalld and the appropriate services on start-up. Then everything can "just work".
(In reply to Thomas Woerner from comment #24) > I thought also about a database to store information about applications that > are allowed to open additional ports, but this does not exist, yet. This > needs application policy support in firewalld. Not only in firewalld; this requires a (currently completely non-existent) way to reliably identify and isolate applications. It's being worked on, but it will take a _long_ time.
I had a discussion of this with some people who understand networking better than I do, thought I'd post here for comments. First wrapping up the situation: * control messages go through standard SSDP port 1900 as UDP messages that are "http-ish" (basically just a few of headers) * one of the headers includes the port to be used as the actual data channel (which is http over TCP). This port is variable. Possible solutions: 1. rygel (or gupnp) talks to firewalld and asks it to open ports when it starts a service (and there's a mechanism for rygel to have permission to do that). This probably works but only for firewalld. 2. John Haxby suggested a conntrack helper. The idea here seems to be that the helper watches the traffic on port 1900, and when it sees outgoing messages with the right header, it marks the mentioned port as "related" for some amount of time. There may be additional complexities here -- as an example I'm not sure if this solution is meant to scale to the time lengths needed -- but it seems like a viable idea. It seems this would really need to be in the kernel (and not just user space using the conntrack api) because of the need to inspect the control messages for the port. Looking at the similar ftp helper for conntrack, it looks like a fairly simple job -- messages being UDP helps a lot. I might have time to try this but maybe someone could first comment on whether solution #2 sounds acceptable (from Fedora and/or RH point of view)? After all, any app that is allowed to send things through 1900 can then "open ports" as they want.
From a portability standpoint I would say solution 2. From a security stand point I would say solution 1. If you are allowing uPNP, then the behaviour of solution 2 would be most likely expected.
What about user-space conntrack helper [1][2]? [1] https://lkml.org/lkml/2013/5/7/830 [2] http://post-office.corp.redhat.com/archives/tech-list/2013-December/msg00151.html
(In reply to Aleksandar Kostadinov from comment #44) > What about user-space conntrack helper [1][2]? > > [1] https://lkml.org/lkml/2013/5/7/830 > [2] > http://post-office.corp.redhat.com/archives/tech-list/2013-December/msg00151. > html I'm certainly not an expert on conntrack, but I believe that does not work in this case: we need to look at the contents ("headers") of the UDP message to figure out which port we mark as related. I think this is not possible from a userspace helper. The second link is not live -- internal site perhaps?
Hi, I've used in the past mediatomb (from EPEL or manually backported from fedora) and it used to work for me: # SSDP for mediatomb -A INPUT -m state --state NEW -p udp --dport 1900 -j ACCEPT # allow IGMP for UPnP/SSDP on wlan0 -A INPUT -i wlan0 -p igmp -j ACCEPT so I guess that iptables has opened data port as a RELATED connection. mediatomb has run as a system service however but that shouldn't matter, should it?
(In reply to David Jaša from comment #46) > Hi, I've used in the past mediatomb (from EPEL or manually backported from > fedora) and it used to work for me: > # SSDP for mediatomb > -A INPUT -m state --state NEW -p udp --dport 1900 -j ACCEPT > # allow IGMP for UPnP/SSDP on wlan0 > -A INPUT -i wlan0 -p igmp -j ACCEPT > Scratch that, mediatomb also used a fixed tcp port for HTTP UI which apparently was used for DLNA traffic as well...
I've found a way (good or bad) to get Rygel's served media to been seen by my Roku3. I'm running Fedora 19. I've enabled "Share media through DLNA" and specified my primary interface in the Rygel Preferences dialog. I'm using a stock rygel.conf file with its "dynamic port" feature. I've added the ssdp service (UDP port 1900) to the firewall and reloaded the firewall. ...finally... I've had to add a Rich Rule to the firewall, ipv4 accept tcp src 192.168.10.x (address of Roku) dest 192.168.10.y (address of Rygel server) Now finally the Roku sees and plays all music, pictures and videos.
(In reply to Jussi Kukkonen from comment #45) > (In reply to Aleksandar Kostadinov from comment #44) > > What about user-space conntrack helper [1][2]? > > > > [1] https://lkml.org/lkml/2013/5/7/830 > > [2] > > http://post-office.corp.redhat.com/archives/tech-list/2013-December/msg00151. > > html > > I'm certainly not an expert on conntrack, but I believe that does not work > in this case: we need to look at the contents ("headers") of the UDP message > to figure out which port we mark as related. I think this is not possible > from a userspace helper. > > The second link is not live -- internal site perhaps? I've started on a userspace helper for 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 conntrack userspace helpers, not just the kernel helpers. marc.info/?l=netfilter-devel&m=139429473308767&w=2
(In reply to Ash Hughes from comment #49) > I've started on a userspace helper for 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 conntrack > userspace helpers, not just the kernel helpers. > > marc.info/?l=netfilter-devel&m=139429473308767&w=2 This is cool, thanks. I assume "works for me" means it makes client side UPnP apps (like media players) work by allowing all connections to their SSDP port? I believe what I said in comment 45 about session specific services still stands: If we can't hard code the rygel http port, then we have to peek into the UDP messages to figure out the data port, and that's not possible with userspace helpers. Or have I misunderstood something?
Yes, this patch, now merged, lets systems using firewalld (or similar) act as UPnP clients to find UPnP services. I think what's actually needed for configuring rygel server firewalls might be another, similar, conntrack helper which understands the reply to the M-SEARCH packet. I think this reply is the packet which contains the port of the control point - the port rygel uses - which is dynamically decided by default. I think you should be able to peek at the UDP packets in the way you want. My helper can see source and destination ip and ports (header items) as well as the string "M-SEARCH" within the packet, so I don't think this will be a problem.(?) It uses conntracks expect mechanism (we expect replies on this port from different address than the one we sent the search packet to). The expect mechanism asks for a timeout - so the port accepts related connections for a time after the the search was sent. In rygels case, I think that along with a new conntrack module, you could have a long-ish timout and then send out SSDP discovery packets yourself to refresh the firewall - which also allows it to close the port if rygel is stopped. This would mean that rygel depends on conntrackd to do its firewall management, which has its own portability problems. Could rygel pick a default port from the IANA unassigned list to perhaps fall back on, and then if that fails too, inform the user that they need to pick a different port? Sorry if I posted in the wrong place initially. I was having my own SSDP problems, which I solved, and this thread pointed me towards the cause of the problem, and therefore the fix. I posted hoping it would be helpful!
(In reply to Ash Hughes from comment #51) > I think you should be able to peek at the UDP packets in the way you want. > My helper can see source and destination ip and ports (header items) as well > as the string "M-SEARCH" within the packet, so I don't think this will be a > problem.(?) Oh, I was under impression that wouldn't be possible. I'll look into that. > It uses conntracks expect mechanism (we expect replies on this > port from different address than the one we sent the search packet to). The > expect mechanism asks for a timeout - so the port accepts related > connections for a time after the the search was sent. In rygels case, I > think that along with a new conntrack module, you could have a long-ish > timout and then send out SSDP discovery packets yourself to refresh the > firewall - which also allows it to close the port if rygel is stopped. UPnP services send NOTIFYs periodically so we can look at those and open the specified port for the specified timeout... This is basically a way for any application to open any incoming port they want which sounds a bit wrong though... Nevertheless your example should make testing this very easy: I'll try to do it next week, we'll see if it's good enough for anyone. > This > would mean that rygel depends on conntrackd to do its firewall management, > which has its own portability problems. Could rygel pick a default port from > the IANA unassigned list to perhaps fall back on, and then if that fails > too, inform the user that they need to pick a different port? See comment 39: rygel is logically a per-user service so that is not a perfect solution. > Sorry if I posted in the wrong place initially. I was having my own SSDP > problems, which I solved, and this thread pointed me towards the cause of > the problem, and therefore the fix. I posted hoping it would be helpful! Info and patch were very useful, thanks!
This will be fixed in Fedora 21, with the default firewall (and firewalld) configuration not blocking any non-root ports. See also: http://www.hadess.net/2014/06/firewalls-and-per-network-sharing.html and also: http://article.gmane.org/gmane.linux.redhat.fedora.desktop/9883/
Hi. I'm opening this bug again. Did a upgrade to Fedora 24 from v23 yesterday and I thought I'd give rygel a spin. Before I used minidlna. When I stop firewalld service I can browse and play my shared content from my TV and if I start firewalld again, my device does not appear in my TV.
(In reply to Mihkel Vain from comment #54) > Hi. > > I'm opening this bug again. Did a upgrade to Fedora 24 from v23 yesterday > and I thought I'd give rygel a spin. Before I used minidlna. When I stop > firewalld service I can browse and play my shared content from my TV and if > I start firewalld again, my device does not appear in my TV. Don't reopen bugs 2 years afterwards. Please, file your own bug, this is likely a misconfiguration (and read the blog post to see how we solved the problem as well).