Starting with firewalld-0.6 there is a hybrid support for both nftables and iptables tools. Currently using firewalld-0.7.1, I was having issues with kdeconnect not having it's ports open despite being configured to have them open using the kdeconnect service enabled. (Firewalld ships with a service definition file for firewalld.) I found that after enabling the "xtables" use flag in nftables everything started working correctly again. I suspect there are other services that silently fail to open ports if nftables does not include xtables support.
Consider making nftables[xtables] a dependency for firewalld.
I'm not entirely sure, because it may be dependent on how a system is setup, but I think that when firewalld is using nftables, it does not have any runtime dependancy on iptables or ebtables and uses the *-nft compatibility tools from xtables instead.
I would like to avoid adding a depenceny on ftables[xtables] because this introduces a hard dependency on net-firewall/iptables and would be detrimental to changes that I am about to push for bug #709856.
- What excalty do you mean by "working correctly again" - do you mean working correctly through kdeconnect, or working correctly as a standalone package?(According to the upstream documentation, my own testing and bug #709856, the dependency on the xtables family should by now be entirely optional).
- I am a little bit surprised to hear about an interplay between kdeconnect and firewalld (that isn't an RDEPENDency of kdeconnect). Would you mind explaining in more detail how kdeconnect manages ports?
Pinging the KDE team for assistance.
If it indeed turns out that kdeconnect does handle ports by creating iptables rules, would you guys mind to add some meaningful RDEPEND on these packages?
kdeconnect is simply a service connecting smartphone and Plasma over bluetooth and/or WiFi, it is no more related to this issue than any other network enabled package.
The bug has been referenced in the following commit(s):
Author: Matthias Maier <firstname.lastname@example.org>
AuthorDate: 2020-03-17 18:44:53 +0000
Commit: Matthias Maier <email@example.com>
CommitDate: 2020-03-17 21:07:31 +0000
net-firewall/firewalld: version bump to 0.73
Also fix dependencies and add USE=+nftables
- The iptables (ip6tables, ebtables, ipset) backend for firewalld is
nowadays entirely optional. Thus add a use flags to control which
backend is used and configured at compile time.
This allows to drop iptables from the set of installed packages
- In case both, xtables and nftables are set also depend on
- install locales
Package-Manager: Portage-2.3.94, Repoman-2.3.21
Signed-off-by: Matthias Maier <firstname.lastname@example.org>
net-firewall/firewalld/Manifest | 1 +
net-firewall/firewalld/firewalld-0.7.3.ebuild | 111 ++++++++++++++++++++++++++
net-firewall/firewalld/metadata.xml | 4 +
3 files changed, 116 insertions(+)
Sorry if I was not articulate enough. This has nothing to do with kdeconnect itself, it was just an example of a listening service for which firewalld has a service file defined:
<?xml version="1.0" encoding="utf-8"?>
<description>KDE Connect is an application to connect your phone to your computer.</description>
<port port="1714-1764" protocol="tcp"/>
<port port="1714-1764" protocol="udp"/>
I just used this because it was what first caught my attention.
Firewalld was not behaving abnormally in any way, but none policy was being implemented that it was supposed to be administering. Once I built nftables with xtables enabled, everything started working as expected.