After upgrading from 0.9.4 to the latest Version in Repo, my PC can not be added in KDE-Connect. My Firewalld-Service has all the required Ports activated (TCP/UDP(1714-1764)). When I type in "netstat -tulpen" I only see: tcp6 0 0 :::1716 :::* LISTEN 1000 28755 2071/kdeconnectd udp6 0 0 :::1716 :::* 1000 28754 2071/kdeconnectd udp 0 0 0.0.0.0:5353 0.0.0.0:* 1000 166361 32754/KDEConnect udp 0 0 0.0.0.0:5353 0.0.0.0:* 1000 166211 32754/KDEConnect udp 0 0 0.0.0.0:5353 0.0.0.0:* 1000 166210 32754/KDEConnect udp 0 0 0.0.0.0:5353 0.0.0.0:* 1000 166209 32754/KDEConnect That does not seem to be correct to me. Why is there a listener only on TCPv6 and UDPv6? When I intercept the traffic with wireshark, I see a Request on UDP(1714) from my mobile and an "ICMP: Destination Unreachable (Port Unreachable)" from my Workstation. If I deactivate the Firewall the problem perisists. Any suggestions? Reproducible: Always Steps to Reproduce: 1. Power on your Workstation and Log in 2. Open the Application on your Android Device and scan for Devices Actual Results: No Devices Found Expected Results: My Workstation should appear in the list
I'm not able to reproduce it. Have you checked if other Fedora users are experiencing the same issue? It might be distro-specific.
Same problem in gentoo. Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 11182/krfb tcp6 0 0 [::]:1716 [::]:* LISTEN 11031/kdeconnectd tcp6 0 0 localhost:ipp [::]:* LISTEN - tcp6 0 0 [::]:5900 [::]:* LISTEN 11182/krfb udp 0 0 0.0.0.0:47934 0.0.0.0:* - udp 0 0 0.0.0.0:bootpc 0.0.0.0:* - udp 0 0 0.0.0.0:bootpc 0.0.0.0:* - udp6 0 0 [::]:1716 [::]:* 11031/kdeconnectd udp6 0 0 [::]:44685 [::]:* - https://forums.gentoo.org/viewtopic-p-7999976.html#7999976
another user, in my system, identical result
Can you confirm if this happens to every gentoo user, or is it setup-specific?
(In reply to Albert Vaca from comment #4) > Can you confirm if this happens to every gentoo user, or is it > setup-specific? Not all Gentoo users. I confirmed that 1.0.1 was OK, updated to 1.0.3 which is the latest in Portage and rebooted my laptop. I had to re-pair my Samsung S6 but apart from that, no problems. I also have an Arch laptop (wife's) and a separate phone at home, and a Gentoo desktop at work, to which I have to route through a firewall from one VLAN to another. The firewall has an allow rule for TCP/UDP 1714-1764 allowed to the desktop. None of these combinations has ever failed to work for me. In response to: "Why is there a listener only on TCPv6 and UDPv6?" - that will include IPv4 as well. To prove it, if you have CUPS installed locally then point your browser at 127.0.0.1:631 and verify it listens on ::1:631/tcp6. Failing that, install a webserver like Apache or nginx and do a similar experiment. The ICMP response is "destination port unreachable" I'm pretty sure either the kdeconnect daemon is not listening for some reason or a firewall is in the way.
1.0.3 also works on Arch. Like JG mentioned in comment 5, I had to unpair and pair my devices again, but no problems apart from that.
Created attachment 102984 [details] Android see the port open
There is no firewall running on the system. kavra # /etc/init.d/iptables status * Executing: /lib64/rc/sh/openrc-run.sh /lib64/rc/sh/openrc-run.sh /etc/init.d/iptables status * status: stopped kavra # /etc/init.d/ufw status * Executing: /lib64/rc/sh/openrc-run.sh /lib64/rc/sh/openrc-run.sh /etc/init.d/ufw status * status: stopped The client and server are on the same local network segment, they do not cross any firewall or layer 3 element. Server: 192.168.0.50 Client:192.168.0.2 Android shows port 1716 open but does not connect. I have renamed the computer and the device and the pairing continues to fail. I have reinstalled kdeconect on the phone and on the computer and the pairing continues to fail. I have deleted .config/kdeconnect on the computer and the pairing fails. I have removed the apk, deleted /stored/emulated/0/kdeconnect from the phone, reinstalled the apk and still failed to pair.
Another phone Huawey G7 (android 4.4.4) matches well. Phone Motorola motoG 2ªG (android 6) failed to pair.
@kavra: JG here == gerdesj on the Gentoo forums. I'll post there against https://forums.gentoo.org/viewtopic-t-1052798.html I don't think this is an upstream bug (yet) 8)
I have changed the mac address on the two devices, the problem continues. I returned to version 0.9g and everything works perfectly again. In version 0.9g everything worked correctly, in version >0.9g stopped working.
My fresh install desktop running Gentoo and my phone cannot see each other. kdeconnect version 1.0.3. Phone is ping-reachable. The desktop and my laptop can see each other in kdeconnect, and my laptop and my phone can see each other. Laptop was running kdeconnect 1.0.1. I upgraded the laptop version to 1.0.3 and it is still working. netstat outputs look identical. The two computers are set up nearly identical. No ufw. Ports are open as far as I can tell.
Hello @Allan, what version of android and phone model do you have?
Blackberry Priv. 6.0.1 On December 29, 2016 3:33:18 AM EST, kavra <bugzilla_noreply@kde.org> wrote: >https://bugs.kde.org/show_bug.cgi?id=371539 > >--- Comment #13 from kavra <kavra.kavra@gmail.com> --- >Hello @Allan, what version of android and phone model do you have?
Hi @Sascha, what version of android and phone model do you have?
I don't think anything related to IP version has changed since 0.9... the biggest thing that differs between 0.9 and 1.0 is the kind of encryption used. Can you post the "netstat -tulpen" output on both 1.0 and 0.9 to see if there is actually a difference? This way we will be sure it's a IPv6-related problem and not something related to the encryption like a cipher suites mismatch. Since I can't reproduce this issue, I will need your help guys to solve the problem :)
(In reply to Albert Vaca from comment #16) > I don't think anything related to IP version has changed since 0.9... the > biggest thing that differs between 0.9 and 1.0 is the kind of encryption > used. > > Can you post the "netstat -tulpen" output on both 1.0 and 0.9 to see if > there is actually a difference? This way we will be sure it's a IPv6-related > problem and not something related to the encryption like a cipher suites > mismatch. > > > Since I can't reproduce this issue, I will need your help guys to solve the > problem :) of course ;) Version 0.9g: (Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 12602/krfb tcp6 0 0 ::1:631 :::* LISTEN - tcp6 0 0 :::5900 :::* LISTEN 12602/krfb tcp6 0 0 :::1714 :::* LISTEN 24925/kdeconnectd udp 0 0 0.0.0.0:68 0.0.0.0:* - udp6 0 0 :::47392 :::* 24925/kdeconnectd udp6 0 0 :::1714 :::* 24925/kdeconnectd Version 1.x Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 localhost:ipp 0.0.0.0:* LISTEN - tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN 11182/krfb tcp6 0 0 [::]:1716 [::]:* LISTEN 11031/kdeconnectd tcp6 0 0 localhost:ipp [::]:* LISTEN - tcp6 0 0 [::]:5900 [::]:* LISTEN 11182/krfb udp 0 0 0.0.0.0:47934 0.0.0.0:* - udp 0 0 0.0.0.0:bootpc 0.0.0.0:* - udp 0 0 0.0.0.0:bootpc 0.0.0.0:* - udp6 0 0 [::]:1716 [::]:* 11031/kdeconnectd udp6 0 0 [::]:44685 [::]:* - According to this thread and the one of gentoo that I follow in parallel(https://forums.gentoo.org/viewtopic-p-7999976.html#7999976), the problem happens with different models of telephone and operating system. In the gentoo thread there are tcpdump outputs, in case they can help. Copy a piece: # tcpdump portrange 1716-1730 -vv dropped privs to tcpdump tcpdump: listening on enp5s0f2, link-type EN10MB (Ethernet), capture size 262144 bytes 19:03:57.222116 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 854) 192.168.0.2.43542 > 255.255.255.255.1716: [udp sum ok] UDP, length 826 19:03:57.222379 IP (tos 0x0, ttl 64, id 24029, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.50.34846 > 192.168.0.2.1716: Flags [S], cksum 0x9a35 (correct), seq 3441841316, win 29200, options [mss 1460,sackOK,TS val 2034041 ecr 0,nop,wscale 7], length 0 19:03:57.223751 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60) 192.168.0.2.1716 > 192.168.0.50.34846: Flags [S.], cksum 0xf4a4 (correct), seq 1635920093, ack 3441841317, win 65535, options [mss 1460,sackOK,TS val 8228018 ecr 2034041,nop,wscale 8], length 0 19:03:57.223791 IP (tos 0x0, ttl 64, id 24030, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.50.34846 > 192.168.0.2.1716: Flags [.], cksum 0x228b (correct), seq 1, ack 1, win 229, options [nop,nop,TS val 2034043 ecr 8228018], length 0 19:03:57.224061 IP (tos 0x0, ttl 64, id 24031, offset 0, flags [DF], proto TCP (6), length 1141) 192.168.0.50.34846 > 192.168.0.2.1716: Flags [P.], cksum 0x0bf7 (correct), seq 1:1090, ack 1, win 229, options [nop,nop,TS val 2034043 ecr 8228018], length 1089 19:03:57.225568 IP (tos 0x0, ttl 64, id 42092, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.1716 > 192.168.0.50.34846: Flags [.], cksum 0x1dd3 (correct), seq 1, ack 1090, win 348, options [nop,nop,TS val 8228018 ecr 2034043], length 0 19:03:57.343945 IP (tos 0x0, ttl 64, id 42093, offset 0, flags [DF], proto TCP (6), length 128) 192.168.0.2.1716 > 192.168.0.50.34846: Flags [P.], cksum 0x7240 (correct), seq 1:77, ack 1090, win 348, options [nop,nop,TS val 8228030 ecr 2034043], length 76 19:03:57.343982 IP (tos 0x0, ttl 64, id 24032, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.50.34846 > 192.168.0.2.1716: Flags [.], cksum 0x1d7a (correct), seq 1090, ack 77, win 229, options [nop,nop,TS val 2034163 ecr 8228030], length 0 19:03:57.344135 IP (tos 0x0, ttl 64, id 24033, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.50.34846 > 192.168.0.2.1716: Flags [F.], cksum 0x1d79 (correct), seq 1090, ack 77, win 229, options [nop,nop,TS val 2034163 ecr 8228030], length 0 19:03:57.345986 IP (tos 0x0, ttl 64, id 42094, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.2.1716 > 192.168.0.50.34846: Flags [F.], cksum 0x1d01 (correct), seq 77, ack 1091, win 348, options [nop,nop,TS val 8228030 ecr 2034163], length 0 19:03:57.346030 IP (tos 0x0, ttl 64, id 24034, offset 0, flags [DF], proto TCP (6), length 52) 192.168.0.50.34846 > 192.168.0.2.1716: Flags [.], cksum 0x1d76 (correct), seq 1091, ack 78, win 229, options [nop,nop,TS val 2034165 ecr 8228030], length 0 Regards
Information about active ciphering in the kernel: # cat /usr/src/linux/.config | grep CRYPTO | grep -v '#' CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_ALGAPI2=y CONFIG_CRYPTO_AEAD=y CONFIG_CRYPTO_AEAD2=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_BLKCIPHER2=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG=y CONFIG_CRYPTO_RNG2=y CONFIG_CRYPTO_RNG_DEFAULT=y CONFIG_CRYPTO_AKCIPHER2=y CONFIG_CRYPTO_AKCIPHER=y CONFIG_CRYPTO_KPP2=y CONFIG_CRYPTO_KPP=y CONFIG_CRYPTO_RSA=y CONFIG_CRYPTO_DH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_MANAGER2=y CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_NULL=y CONFIG_CRYPTO_NULL2=y CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=y CONFIG_CRYPTO_AUTHENC=y CONFIG_CRYPTO_ABLK_HELPER=y CONFIG_CRYPTO_GLUE_HELPER_X86=y CONFIG_CRYPTO_CCM=y CONFIG_CRYPTO_GCM=y CONFIG_CRYPTO_CHACHA20POLY1305=y CONFIG_CRYPTO_SEQIV=y CONFIG_CRYPTO_ECHAINIV=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_CTR=y CONFIG_CRYPTO_CTS=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_LRW=y CONFIG_CRYPTO_PCBC=y CONFIG_CRYPTO_XTS=y CONFIG_CRYPTO_KEYWRAP=y CONFIG_CRYPTO_CMAC=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_CRC32C=y CONFIG_CRYPTO_CRC32C_INTEL=y CONFIG_CRYPTO_CRCT10DIF=y CONFIG_CRYPTO_GHASH=y CONFIG_CRYPTO_POLY1305=y CONFIG_CRYPTO_POLY1305_X86_64=y CONFIG_CRYPTO_MD4=y CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_MICHAEL_MIC=y CONFIG_CRYPTO_RMD128=y CONFIG_CRYPTO_RMD160=y CONFIG_CRYPTO_RMD256=y CONFIG_CRYPTO_RMD320=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA1_SSSE3=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_TGR192=y CONFIG_CRYPTO_WP512=y CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=y CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_X86_64=y CONFIG_CRYPTO_AES_NI_INTEL=y CONFIG_CRYPTO_ANUBIS=y CONFIG_CRYPTO_ARC4=y CONFIG_CRYPTO_BLOWFISH=y CONFIG_CRYPTO_BLOWFISH_COMMON=y CONFIG_CRYPTO_BLOWFISH_X86_64=y CONFIG_CRYPTO_CAMELLIA=y CONFIG_CRYPTO_CAST_COMMON=y CONFIG_CRYPTO_CAST5=y CONFIG_CRYPTO_CAST5_AVX_X86_64=y CONFIG_CRYPTO_CAST6=y CONFIG_CRYPTO_CAST6_AVX_X86_64=y CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_DES3_EDE_X86_64=y CONFIG_CRYPTO_FCRYPT=y CONFIG_CRYPTO_KHAZAD=y CONFIG_CRYPTO_SALSA20=y CONFIG_CRYPTO_SALSA20_X86_64=y CONFIG_CRYPTO_CHACHA20=y CONFIG_CRYPTO_CHACHA20_X86_64=y CONFIG_CRYPTO_SEED=y CONFIG_CRYPTO_SERPENT=y CONFIG_CRYPTO_SERPENT_SSE2_X86_64=y CONFIG_CRYPTO_TEA=y CONFIG_CRYPTO_TWOFISH=y CONFIG_CRYPTO_TWOFISH_COMMON=y CONFIG_CRYPTO_TWOFISH_X86_64=y CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=y CONFIG_CRYPTO_LZO=y CONFIG_CRYPTO_842=y CONFIG_CRYPTO_DRBG_MENU=y CONFIG_CRYPTO_DRBG_HMAC=y CONFIG_CRYPTO_DRBG_HASH=y CONFIG_CRYPTO_DRBG_CTR=y CONFIG_CRYPTO_DRBG=y CONFIG_CRYPTO_JITTERENTROPY=y CONFIG_CRYPTO_USER_API=y CONFIG_CRYPTO_USER_API_HASH=y CONFIG_CRYPTO_USER_API_SKCIPHER=y CONFIG_CRYPTO_USER_API_AEAD=y CONFIG_CRYPTO_HASH_INFO=y CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_QAT=y CONFIG_CRYPTO_DEV_QAT_DH895xCCVF=y
I just tried today and it started working. I don't recall doing anything different. I'm chalking it up to the home network. On Gentoo, kdeconnect v1.0.3.
The same is happening to me at 1.0.3 and 1.5: sudo netstat -tunlp | grep kdeconnect tcp6 0 0 :::1716 :::* LISTEN 4250/kdeconnectd udp6 0 0 :::1716 :::* 4250/kdeconnectd
I also have the same problem and I'm using Kubuntu 16.04. I had the same problem with the following versions: kdeconnect (0.8-0ubuntu5) kdeconnect-plasma (0.9 + git20160315-0ubuntu1) I upgraded using Backports, ppa: kubuntu-ppa / backports, to version: 1.0.1-1ubuntu1~ubuntu16.04-ppa1. Unfortunately, the problem still exists. I do not have firewalls that block ports and run a netstat I get this: netstat -anp Proto CodaRic CodaInv Indirizzo locale Indirizzo remoto Stato PID/Program name tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN 2057/dnsmasq tcp6 0 0 :::1716 :::* LISTEN 1610/kdeconnectd udp 0 0 0.0.0.0:34303 0.0.0.0:* 1181/avahi-daemon: udp 0 0 0.0.0.0:5353 0.0.0.0:* 1181/avahi-daemon: udp 0 0 127.0.1.1:53 0.0.0.0:* 2057/dnsmasq udp 0 0 0.0.0.0:68 0.0.0.0:* 2047/dhclient udp 0 0 0.0.0.0:631 0.0.0.0:* 1247/cups-browsed udp6 0 0 :::1716 :::* 1610/kdeconnectd I also tried to disable IPv6: more /proc/sys/net/ipv6/conf/all/disable_ipv6 1 But the problem is not resolved, the output of the netstat is equal.
I agree with this bug. I have installed Linux Mint 18.0 KDE and my mobile phone does not create successfuly connection to PC. Netstat shows that kdeconnect listens only on IPV6 protocol. After yesterdays update anything changed.
(In reply to Makumb8 from comment #21) > I also have the same problem and I'm using Kubuntu 16.04. > I had the same problem with the following versions: > kdeconnect (0.8-0ubuntu5) > kdeconnect-plasma (0.9 + git20160315-0ubuntu1) > I upgraded using Backports, ppa: kubuntu-ppa / backports, to version: > 1.0.1-1ubuntu1~ubuntu16.04-ppa1. > Unfortunately, the problem still exists. > I do not have firewalls that block ports and run a netstat I get this: > netstat -anp > > Proto CodaRic CodaInv Indirizzo locale Indirizzo remoto Stato > PID/Program name > tcp 0 0 127.0.1.1:53 0.0.0.0:* LISTEN > 2057/dnsmasq > tcp6 0 0 :::1716 :::* LISTEN > 1610/kdeconnectd > udp 0 0 0.0.0.0:34303 0.0.0.0:* > 1181/avahi-daemon: > udp 0 0 0.0.0.0:5353 0.0.0.0:* > 1181/avahi-daemon: > udp 0 0 127.0.1.1:53 0.0.0.0:* > 2057/dnsmasq > udp 0 0 0.0.0.0:68 0.0.0.0:* > 2047/dhclient > udp 0 0 0.0.0.0:631 0.0.0.0:* > 1247/cups-browsed > udp6 0 0 :::1716 :::* > 1610/kdeconnectd > > I also tried to disable IPv6: > more /proc/sys/net/ipv6/conf/all/disable_ipv6 > 1 > But the problem is not resolved, the output of the netstat is equal. The problem has been solved!! I updated the version to kdeconnect 1.0.3-0ubuntu1~ubuntu16.04~ppa1, and everything started to work properly. However I have verified network connectivity with netstat and the situation is always the same: netstat -anp | grep kdeconnect Proto CodaRic CodaInv Indirizzo locale Indirizzo remoto Stato PID/Program name tcp6 0 0 :::1716 :::* LISTEN 1846/kdeconnectd udp6 0 0 :::1716 :::* 1846/kdeconnectd Proto RefCnt Flags Type State I-Node PID/Program name unix 3 [ ] STREAM CONNESSO 24276 1846/kdeconnectd unix 3 [ ] STREAM CONNESSO 26681 1846/kdeconnectd unix 3 [ ] STREAM CONNESSO 20381 1846/kdeconnectd unix 3 [ ] STREAM CONNESSO 20888 1846/kdeconnectd unix 3 [ ] STREAM CONNESSO 20368 1846/kdeconnectd I honestly do not know at this point what happened, the fact is that with this version now works all over again.
The problem continues with me
I also have this problem. 1. Xiaomi Mi4i (MIUI Global 8.1.7.0 Stable, Android 5.0.2) + KDE Connect 1.5 (from F-Droid) 2. Nokia X2 DS (CM 12.1, Android 5.1.1) + KDE Connect 1.5 (from Play Market) 3. Laptop (Gentoo Linux) + KDE Connect 1.0.3 (USE flags: +app, +handbook, +wayland, -debug, -test) (FROM Mi4i [!]) $ netstat -nlpu udp6 0 0 ::::1714 :::* CLOSE udp6 0 0 ::::1716 :::* CLOSE $ netstat -nlpt tcp6 0 0 ::::1716 :::* LISTEN (FROM notebook [!]) $ netstat -anlpt tcp6 0 0 ::::1716 :::* LISTEN 10292/kdeconnectd $ netstat -anlpu udp6 0 0 ::::1716 :::* 10292/kdeconnectd In my LAN not using IPv6, cos my router not support it. In /etc/sysctl.conf on laptop also: net.ipv6.conf.all.disable_ipv6 = 1 net.ipv6.conf.default.disable_ipv6 = 1 Mobile devices see/pairing each other (I don`t know exactly how, really), but not see the laptop (and laptop doesn't see them too). I don't have firewalls / selinux / smth else. Kernel and system profile not hardened. P.S. Sorry for my english.
(In reply to LanMan from comment #25) > I also have this problem. Solved by myself. I don't know what exactly helped, but in sysctl.conf I had commented that strings: net.ipv6.conf.all.disable_ipv6 = 0 net.ipv6.conf.default.disable_ipv6 = 0 And had reboot laptop (exec <# sysctl -p> wasn't help).
Can everyone else experiencing this bug confirm if the same fix works for you? It would be really helpful :)
On Gentoo the problem seems to be solved with disabling the "bindist" use flag for openssl and qtnetwork. (https://forums.gentoo.org/viewtopic-t-1052798.html) After reemerging these packages without "bindist" and relogin everything went fine... :-)
I was able to make kdeconnect listen on IPv4 only by changing QHostAddress::Any to QHostAddress::AnyIPv4 in core/backends/lan/lanlinkprovider.cpp and core/backends/lan/uploadjob.cpp and recompiling. netstat -tulpen | grep kdeconnectd tcp 0 0 0.0.0.0:1716 0.0.0.0:* LISTEN 1000 19330 1492/kdeconnectd udp 0 0 0.0.0.0:1716 0.0.0.0:* 1000 19329 1492/kdeconnectd This doesn't seem to break anything (well, probably IPv6 connectivity), but I haven't tested many things. My phone-desktop connection at home was already working before and it's still working after recompiling. Unfortunately, this didn't fix my phone-laptop connection at work, which is what I was trying to fix. There must be something else going on there. I don't think it's a firewall or SSL problem. From another computer: openssl s_client -cipher ECDHE-ECDSA-AES256-GCM-SHA384 -connect <my_laptop_ip>:1716 CONNECTED(00000003) Running 1.0.3 on Arch and 1.6.5 on my phone.
Oh wait, I should be getting more info from the openssl s_client command, maybe it is an encryption issue.
Thank you for kdeconnect, it's a killer app. I was able to confirm this affects kdeconnect-1.0.1 in Debian 9 (stretch) which is supported until June 2022, and here is the Debian bug report I've linked to this one: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877807 Many months ago, when I personally ran into this issue, I locally backported 1.0.3 (the newest version that will compile against the QT and Plasma version in Stretch), and it seems to work fine (exception of Android power saving aside, but we all know that's a separate issue). Also, it sounds other people were also able to get around this IPV4 issue by installing 1.0.3. If 1.0.3 truly solved this "only listens on IPV6" issue then I think this bug can be closed, and the Debian package can either backport the fix (hint please? ;-)) or I can look into filing for a stable-updates exception from the release team. Cheers, Nicholas
Still broken in kdeconnect 1.4.0 $ netstat -tulpan | grep kdecon tcp6 0 0 :::1716 :::* LISTEN 32047/kdeconnectd udp6 0 0 :::1716 :::* 32047/kdeconnectd judging by strace it does not even attempt to listen on ipv4. It loads libraries in /usr/lib64/qt5/plugins/bearer/, then reads active interfaces, and binds on ipv6 despite several ipv4 interfaces are available. Possibly it is a bug in libQt5Network5. OS: openSUSE Leap 15.2 kdeconnect-kde-20.04.2-lp152.2.6.1.x86_64 Qt: 5.12.7 KDE: 5.71.0 kdeconnect.daemon 1.4.0
I confirm that changing QHostAddress::Any to QHostAddress::AnyIPv4 in core/backends/lan/lanlinkprovider.cpp and core/backends/lan/compositeuploadjob.cpp does fix the issue - kdeconnectd successfully binds to IPv4 UDP 0.0.0.0:1716, thanks to NewmanIsaac for providing the fix.
Also for me I have only ipv6 connection netstat -tulpen | grep kdeconnectd tcp6 0 0 :::1716 :::* LISTEN 1000 45539 3799/kdeconnectd udp6 0 0 :::1716 :::* 1000 45538 3799/kdeconnectd Package: kdeconnect Version: 1.4-0ubuntu5 OS: Linux Mint 20.2 x86_64 Kernel: 5.4.0-88-generic DE: Xfce
Did those who claim that kdeconnectd listens only on IPv6 port actually checked the same opened IPv4 port? Take a look at this comment: https://bugs.kde.org/show_bug.cgi?id=417615#c3 According to it if netstat shows open IPv6 port then it automatically listens on the respective IPv4 port. Obviously, disabling IPv6 leaves the only opened IPv4 port which now properly shows in netstat output.
(#metoo:) my desktop (kubuntu) can't connect to/can't see mobiles (android), while andoroid-to-android (several versions) are working. My systems and the whole network is ipv4 only(!) / no further restrictions/no FW: (desktop:) # ip r default via 10.99.52.254 dev wlp3s0 proto dhcp metric 600 10.99.0.0/18 dev wlp3s0 proto kernel scope link src 10.99.52.157 metric 600 169.254.0.0/16 dev wlp3s0 scope link metric 1000 ___ ...but, kdeconnect runs in ipv6 only mode: # netstat -tunelp | grep -i kdeconnectd tcp6 0 0 :::1716 :::* LISTEN 1001 32542 4995/kdeconnectd tcp6 0 0 :::1717 :::* LISTEN 0 8650926 3704683/kdeconnectd udp6 0 0 :::1716 :::* 0 8650924 3704683/kdeconnectd udp6 0 0 :::1716 :::* 1001 32541 4995/kdeconnectd ___ The issue seemed not to begin on a specific time(/update), since it got worse (=more often) from ~mid 2022 to start of 2023. Then there was no successful connection possible after another (cannonical) update of "a bunch" of system and application components... (hth)