KDE Connect requires ports 1714-1764 open. Either make a hole (semi-)automatically or at least provide instructions how to do it. When the local interface is "192.168.2.0/8", something like this will work and cause the minimal required opening: # firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="tcp" accept' # firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept' success
Looks like an xml snippet dropped into /usr/lib/firewalld/services is one approach (like what cockpit packaging currently does). I queried -devel list for advice on best practices wrt packaging: https://lists.fedoraproject.org/pipermail/devel/2014-July/200790.html
(In reply to Rex Dieter from comment #1) > Looks like an xml snippet dropped into /usr/lib/firewalld/services is one > approach (like what cockpit packaging currently does). > > I queried -devel list for advice on best practices wrt packaging: > https://lists.fedoraproject.org/pipermail/devel/2014-July/200790.html Seems that /usr/lib/firewalld/services doesn't provide any easy way to limit the access to a particular network. Having devices from all over the world trying to pair with my workstation may be too permissive. From my /etc/firewalld/zones/public.xml : <rule family="ipv4"> <source address="192.168.2.0/8"/> <port protocol="udp" port="1714-1764"/> <accept/> </rule> - this is safe enough for me. However other routers will have other private networks which needs to be configured based on local setup. One way to do that would be to call a script from /etc/NetworkManager/dispatcher.d/ - get IP/Netmask from there ip=`/sbin/ifconfig | grep -A 4 $1 | awk '/inet / { print $2 } ' | sed -e s/addr://` netmask=`/sbin/ifconfig | grep -A 4 $1 | awk '/inet / { print $4 } ' | sed -e s/addr://` and configure the firewall as needed.
(In reply to Richard Zidlicky from comment #2) > Seems that /usr/lib/firewalld/services doesn't provide any easy way to limit > the access to a particular network. If <source address="192.168.2.0/8"/> isn't easy enough, how would you imagine such 'easy way' ? > ip=`/sbin/ifconfig | grep -A 4 $1 | awk '/inet / { print $2 } ' | sed -e > s/addr://` Please don't use ifconfig (bug #687920), something like ip -4 -o addr show $1 | awk '{ print $4 }' should do the trick too.
(In reply to Jiri Popelka from comment #3) > (In reply to Richard Zidlicky from comment #2) > > Seems that /usr/lib/firewalld/services doesn't provide any easy way to limit > > the access to a particular network. > > If <source address="192.168.2.0/8"/> isn't easy enough, how would you > imagine such 'easy way' ? the problem is that not all routers use the 192.168.2.* address range, some routers or repeaters use something in the 10.xx range, some computers may have more interfaces that could be used. There is no way to know that at packagaing time so it seems a purely static rule can't do that. Given that some computers will have more than one interfaces and it may be not desirable to allow pairing and firewall punching for all local networks completely unattended there probably should be some user interaction - selecting the network(s) that should be allowed for kde connect operation.
(In reply to Richard Zidlicky from comment #4) > the problem is that not all routers use the 192.168.2.* address range, some > routers or repeaters use something in the 10.xx range, some computers may > have more interfaces that could be used. The local area subnets are still well known, that's not a problem. What I see as problematic is when you are on a nontrusted network. I know there are zones in firewalld but I have no idea how they are set/switched.
(In reply to Martin Bříza from comment #5) > The local area subnets are still well known, that's not a problem. known at runtime yes, but not at packaging time so I don't see how prepackaged /usr/lib/firewalld/services rules could be used (other than opening a hole larger than necessary) - am I missing something? > What I see as problematic is when you are on a nontrusted network. I know > there are zones in firewalld but I have no idea how they are set/switched. Switching zones works but at this time I don't see how the firewalld zones and rules could do what is needed here with prepackaged rules alone. The alternative approach - when a network comes up ask user if KDE connect should bind on the network and punch a fitting hole into the firewall at the same time.
Opened upstream report to query about the trusted/untrusted networks issue and clarify how to integrate with distribution specific firewalls. https://bugs.kde.org/show_bug.cgi?id=337250
(In reply to Richard Zidlicky from comment #6) > (In reply to Martin Bříza from comment #5) > > > The local area subnets are still well known, that's not a problem. > > known at runtime yes, but not at packaging time so I don't see how > prepackaged /usr/lib/firewalld/services rules could be used (other than > opening a hole larger than necessary) - am I missing something? Reserved local area subnets are defined by RFC1918, so they are known at packaging time...
(In reply to Martin Bříza from comment #8) > Reserved local area subnets are defined by RFC1918, so they are known at > packaging time... that would work. The firewall hole could be a lot tighter though using only the specific link-local subnet.
Is it not against Fedora policies to open up the firewall that way by default?
updating summary (to at least document what is required)
> 192.168.2.0/8 It was pointed out on #fedora-kde IRC that that is NOT what you want, you want /24, not /8 here. The number is the length of the prefix, not of the suffix.
fyi, for documentation purposes, here's where the port range comes from, https://community.kde.org/KDEConnect#Troubleshooting
kde-connect-0.8-9.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16512
kde-connect-0.8-9.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-16514
kde-connect-0.8-9.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update kde-connect' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16512
kde-connect-0.8-9.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with $ su -c 'dnf --enablerepo=updates-testing update kde-connect' You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-16514
kde-connect-0.8-9.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.
kde-connect-0.8-9.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.