Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
Richard
--- Name and OpenPGP keys available from pgp key servers
On Wed, Jul 2, 2014 at 8:30 PM, Richard Z rz@linux-m68k.org wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself. Have you set your static ip to "192.168.2.0/8"?
Am 02.07.2014 17:10, schrieb Sudhir Khanger:
On Wed, Jul 2, 2014 at 8:30 PM, Richard Z rz@linux-m68k.org wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself. Have you set your static ip to "192.168.2.0/8"?
192.168.2.0/8 is a range, not a IP and the accepted *source* range above
network basics are needed to deal with firewalls :-)
http://jodies.de/ipcalc Address: 192.168.2.0 Netmask: 255.0.0.0 = 8 Wildcard: 0.255.255.255 Network: 192.0.0.0/8 Broadcast: 192.255.255.255 HostMin: 192.0.0.1 HostMax: 192.255.255.254 Hosts/Net: 16777214
whois:
NetRange: 192.168.0.0 - 192.168.255.255 CIDR: 192.168.0.0/16 OriginAS: NetName: PRIVATE-ADDRESS-CBLK-RFC1918-IANA-RESERVED NetHandle: NET-192-168-0-0-1 Parent: NET-192-0-0-0-0 NetType: IANA Special Use
and BTW the OP made *a terrible* mistake by specify 192.168.2.0/8 because it contains much more than private IP's (254 versus 16 Mio)
if the intention was the own used subnet 192.168.2.0/24 would be most likely what he really wanted or at least /16 to not contain the following subnet which is not a private one as a lot of others
NetRange: 192.255.128.0 - 192.255.255.255 CIDR: 192.255.128.0/17 OriginAS: AS54290 NetName: HOSTWINDS-17-2 NetHandle: NET-192-255-128-0-1 Parent: NET-192-0-0-0-0 NetType: Direct Allocation Comment: http://www.hostwinds.com
192.168.2.0/24 = private = 254 IP's 192.168.0.0/16 = private = 65534 IP's 192.168.2.0/8 = nonsense = 16000000 IP's
Am 02.07.2014 17:16, schrieb Reindl Harald:
Am 02.07.2014 17:10, schrieb Sudhir Khanger:
On Wed, Jul 2, 2014 at 8:30 PM, Richard Z rz@linux-m68k.org wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself. Have you set your static ip to "192.168.2.0/8"?
192.168.2.0/8 is a range, not a IP and the accepted *source* range above
network basics are needed to deal with firewalls :-)
http://jodies.de/ipcalc Address: 192.168.2.0 Netmask: 255.0.0.0 = 8 Wildcard: 0.255.255.255 Network: 192.0.0.0/8 Broadcast: 192.255.255.255 HostMin: 192.0.0.1 HostMax: 192.255.255.254 Hosts/Net: 16777214
whois:
NetRange: 192.168.0.0 - 192.168.255.255 CIDR: 192.168.0.0/16 OriginAS: NetName: PRIVATE-ADDRESS-CBLK-RFC1918-IANA-RESERVED NetHandle: NET-192-168-0-0-1 Parent: NET-192-0-0-0-0 NetType: IANA Special Use
On Wed, Jul 02, 2014 at 08:40:49PM +0530, Sudhir Khanger wrote:
On Wed, Jul 2, 2014 at 8:30 PM, Richard Z rz@linux-m68k.org wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself.
did it ever pair correctly? If so then you may be hitting Android powersaving/WIFI issues.
Richard
--- Name and OpenPGP keys available from pgp key servers
On Thursday, July 03, 2014 02:09:25 PM Richard Z wrote:
On Wed, Jul 02, 2014 at 08:40:49PM +0530, Sudhir Khanger wrote:
On Wed, Jul 2, 2014 at 8:30 PM, Richard Z rz@linux-m68k.org wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'>
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself.
did it ever pair correctly? If so then you may be hitting Android powersaving/WIFI issues.
I'm using the following kde-connect service template with great success. I have also created a my_internal zone which makes it easy to add services to that zone. That way, you don't need to add so many rich rules; just create new services and add them to your unique source-based zone.
# my_internal.xml (corrected for your source range) <?xml version="1.0" encoding="utf-8"?> <zone> <short>My Internal</short> <description>Only incoming connections from specified source IP address ranges to specified services are accepted.</description> <source address="192.168.2.0/24"/> <service name="ssh"/> </zone>
# kde-connect.xml <?xml version="1.0" encoding="utf-8"?> <service> <short>KDE Connect</short> <description>KDE Connect enables desktop integration with mobile devices.</description> <port protocol="tcp" port="1714-1764"/> <port protocol="udp" port="1714-1764"/> </service>
Then issue $ firewall-cmd --zone my_internal --service-add kde-connect [--permanent]
I have noticed that when I log out or restart the workstation, I need to re- pair the Android to KDE, but that's a different issue.
On Thu, Jul 03, 2014 at 07:43:50AM -0500, Anthony Messina wrote:
I'm using the following kde-connect service template with great success. I have also created a my_internal zone which makes it easy to add services to that zone. That way, you don't need to add so many rich rules; just create new services and add them to your unique source-based zone.
looks pretty good to me. Still not obvious how to package this so it would work out of the box with minimal hassle while retaining all the security?
Richard
--- Name and OpenPGP keys available from pgp key servers
On Thursday, July 03, 2014 11:51:33 PM Richard Z wrote:
On Thu, Jul 03, 2014 at 07:43:50AM -0500, Anthony Messina wrote:
I'm using the following kde-connect service template with great success. I have also created a my_internal zone which makes it easy to add services to that zone. That way, you don't need to add so many rich rules; just create new services and add them to your unique source-based zone.
looks pretty good to me. Still not obvious how to package this so it would work out of the box with minimal hassle while retaining all the security?
As for upstream, I'm not sure. They could at least package the kde-connect service xml template. For me, I maintain a "workstation" RPM package with all these little bits of configuration that are specific to hosts on my network.
On Thu, Jul 3, 2014 at 5:39 PM, Richard Z rz@linux-m68k.org wrote:
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself.
did it ever pair correctly? If so then you may be hitting Android powersaving/WIFI issues.
Richard
Yes, it pairs correctly. It constantly unpairs itself in kde settings. I am not of the same page with you on Android power saving wifi issues.
On Thu, Jul 03, 2014 at 11:34:50PM +0530, Sudhir Khanger wrote:
On Thu, Jul 3, 2014 at 5:39 PM, Richard Z rz@linux-m68k.org wrote:
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself.
did it ever pair correctly? If so then you may be hitting Android powersaving/WIFI issues.
Richard
Yes, it pairs correctly. It constantly unpairs itself in kde settings. I am not of the same page with you on Android power saving wifi issues.
some android devices have too aggressive default settings for powersaving. You would notice if thats your problem if it works as long as * screen of android device is on * KDE connect is in foreground on android device and fails as soon as either of this conditions is not met.
Alternatively it may be that for some weird reason UDP works but TCP doesn't in your WIFI.
Richard
--- Name and OpenPGP keys available from pgp key servers
Sudhir Khanger wrote:
I am waiting for kde-connect-0.7. In spite of disabling firewalld, kde-connect keeps unregistering itself.
Did you also disable the iptables service(*)? At least on my systems upgraded from earlier Fedora releases, disabling firewalld made the iptables service run again (which is actually what I wanted, but if you want to disable the firewall entirely, you need to disable that too).
(*) For those who care about the technical details: The "iptables service" is Red Hat's initscript wrapper around the default iptables userspace tools. Firewalld replaces both those userspace tools and the initscript wrapper. But both the "iptables service" (through the "iptables userspace") and firewalld share the kernel parts of iptables.
Kevin Kofler
On Fri, Jul 11, 2014 at 11:23 PM, Kevin Kofler kevin.kofler@chello.at wrote:
Did you also disable the iptables service(*)?
[donnie@fedora ~]$ systemctl status iptables iptables.service - IPv4 firewall with iptables Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled) Active: inactive (dead)
[donnie@fedora ~]$ systemctl status firewalld firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled) Active: inactive (dead)
I wasn't aware of iptables service. I neither activated it not disabled it.
The problem is it connects and works fine but after a while it would get unpaired and I will have to repair them again.
On Wed, Jul 02, 2014 at 05:00:11PM +0200, Richard Z wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
correction, needs to be once "tcp".
Richard
--- Name and OpenPGP keys available from pgp key servers
openSUSE ships firewall rules with their KDE Connect package https://build.opensuse.org/package/view_file/KDE:Extra/kdeconnect-kde/kdeconnect-kde.SuSEfirewall?expand=1
Is something like that possibe under Fedora as well?
On Wednesday 02 July 2014 17:00:11 Richard Z wrote:
Hi,
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
# firewall-cmd --permanent --add-rich-rule 'rule family="ipv4" source address="192.168.2.0/8" port port="1714-1764" protocol="udp" accept'
Richard
Name and OpenPGP keys available from pgp key servers
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Markus Slopianka wrote:
openSUSE ships firewall rules with their KDE Connect package https://build.opensuse.org/package/view_file/KDE:Extra/kdeconnect-kde/kdeconnect-kde.SuSEfirewall?expand=1
Is something like that possibe under Fedora as well?
As far as I know, it is against Fedora policies, so no.
Kevin Kofler
On 07/11/2014 12:57 PM, Kevin Kofler wrote:
Markus Slopianka wrote:
openSUSE ships firewall rules with their KDE Connect package https://build.opensuse.org/package/view_file/KDE:Extra/kdeconnect-kde/kdeconnect-kde.SuSEfirewall?expand=1
Is something like that possibe under Fedora as well?
As far as I know, it is against Fedora policies, so no.
Kevin Kofler
kde mailing list kde@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/kde New to KDE4? - get help from http://userbase.kde.org
Wait - you're saying that it's against Fedora Policies to ship firewall rules for applications that need network access? Somebody needs to let the Server Working Group know about that - they are working on the packaging of firewall rules for every role they're creating.
Dan Mossor wrote:
Wait - you're saying that it's against Fedora Policies to ship firewall rules for applications that need network access? Somebody needs to let the Server Working Group know about that - they are working on the packaging of firewall rules for every role they're creating.
At least in the days before "Fedora Next", the rule has always been that all ports must be firewalled by default except where FESCo decided that they should be open by default (which they did for sshd and mDNS), and that packages must not override those defaults.
Kevin Kofler
On 07/14/14 07:14, Kevin Kofler wrote:
Dan Mossor wrote:
Wait - you're saying that it's against Fedora Policies to ship firewall rules for applications that need network access? Somebody needs to let the Server Working Group know about that - they are working on the packaging of firewall rules for every role they're creating.
At least in the days before "Fedora Next", the rule has always been that all ports must be firewalled by default except where FESCo decided that they should be open by default (which they did for sshd and mDNS), and that packages must not override those defaults.
But, isn't there a difference between "ports open by default" and "supplying rules that *can* be enabled when needed"? Isn't that what is done for services such as "smtp"?
By default, port 25 is filtered. But, in firewalld there is a check box to open/enable "smtp" services. Isn't that the goal for KDE Connect?
On 7-2-14 17:00:11 Richard Z wrote:
perhaps these firewall rules are useful to someone, works for me when "192.168.2.0/8" is the local network where the Android device connects.
Well, 192.168.2.0/8 is *not* a network. If the prefix length of a network is eight, then no low-order bits in the last 24 can be one bits for that network address.
Technically 192.168.2.0/8 can be a *host* address. But it's doubtful that this could be correct either, since that means all addresses 192.0.0.0 through 192.255.255.255 are in that network and that encompasses non-homogeneous address ranges in the Internet.
No, 192.168.2.0/8 is plainly wrong.
("Works" is another thing altogether.)
Most probably, you meant 192.168.2.0/24, which is consistent with the IPv4 RFCs.
On Thu, Jul 03, 2014 at 11:32:49AM -0400, Garry T. Williams wrote:
Most probably, you meant 192.168.2.0/24, which is consistent with the IPv4 RFCs.
of course you are right, as was Harald R. Still slightly better than to open the relevant ports to all of the internet or disable firewall completely.
Richard
--- Name and OpenPGP keys available from pgp key servers
-
Anthony Joseph Messina -
Dan Mossor -
Ed Greshko -
Garry Williams -
Kevin Kofler -
Markus Slopianka -
Reindl Harald -
Richard Z -
Sudhir Khanger