kdeconnect nicht erreichbar

[jochen02]

Hallo,

ich bräuchte mal Unterstützung. Einer meiner beiden PCs ist für kdeconnect nicht erreichbar.

Situation:
/24 Netz, in dem folgende Beteiligte vorhanden sind. Es sind 2x Debian testing und 1x Android Smartphone. Die Version von kdeconnect ist auf beiden PCs 22.12.3-1.

2 PCs
PC1 192.168.150.102 (LAN)
PC2 192.168.150.159 (WLAN)
Smartphone 192.168.150.12 (Android, WLAN)

Zwischen PC1 und Smartphone funktioniert kdeconnect hervorragend.
Zwischen PC2 und Smartphone funktioniert kdeconnect nicht.

Netzwerk-Infos PC1:

Code: Alles auswählen

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:7f brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.102/24 brd 192.168.150.255 scope global dynamic noprefixroute enp3s0
       valid_lft 85744sec preferred_lft 85744sec

# /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.150.1   0.0.0.0         UG    100    0        0 enp3s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 enp3s0
192.168.xxx.0   0.0.0.0         255.255.255.0   U     100    0        0 enp3s0

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Netzwerk-Infos PC2:

Code: Alles auswählen

# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: wlp6s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether xx:xx:xx:xx:xx:eb brd ff:ff:ff:ff:ff:ff
    inet 192.168.150.159/24 brd 192.168.xxx.255 scope global dynamic noprefixroute wlp6s0
       valid_lft 84282sec preferred_lft 84282sec

# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.150.1   0.0.0.0         UG    600    0        0 wlp6s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp6s0
192.168.150.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp6s0

# iptables -L -n
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Verbindungsversuche von PC1:

Code: Alles auswählen

$ nc -v 192.168.150.12 1716
smartphone [192.168.150.12] 1716 (?) open

$ nc -v 192.168.150.102 1716
PC1 [192.168.150.102] 1716 (?) open

$ nc -v 192.168.150.159 1716
PC2 [192.168.150.159] 1716 (?) : No route to host

"No route to host" ist ein echtes Problem. Ich bin sicher, es ist überall ein /24 Netz eingerichtet und die IPs sind auch alle aus diesem Netz.

Verbindungsversuche von PC2:

Code: Alles auswählen

$ nc -v 192.168.150.12 1716
Connection to 192.168.150.12 1716 port [tcp/*] succeeded!

$ nc -v 192.168.150.159 1716
Connection to 192.168.150.159 1716 port [tcp/*] succeeded!

$ nc -v 192.168.150.102 1716
Connection to 192.168.150.102 1716 port [tcp/*] succeeded!

Irgendwie stehe ich anscheinend auf der Leitung. Es ist sicher nur eine Kleinigkeit, auf die ich aber nicht komme. Sollten noch Infos fehlen, versuche ich, nachzuliefern.
Daher hier meine Bitte um Hilfe.

Viele Grüße,
Jochen

[chrbr]

Hallo Jochen,

$ nc -v 192.168.146.159 1716
PC2 [192.168.150.159] 1716 (?) : No route to host

Woher kommt denn die 146? Sollte das nicht 192.168.150.159 sein? Auch wenn das nur den Test betrifft.
Viele Grüße,
Christoph

[jochen02]

Hallo Christoph,

Hoppla, ist ein Kopierfehler. Habe ich im Original-Beitrag jetzt korrigiert.

Danke für den Hinweis.

[chrbr]

Hallo Jochen,

Hoppla, ist ein Kopierfehler.

Hast Du das wirklich abgetippt? Das ist zwar off-topic, aber egal. Mit script kannst Du sowas mitschreiben lassen. Ein Beispiel:

Code: Alles auswählen

chris@lenovo ~> script scr.txt
Script started, output log file is 'scr.txt'.
Willkommen zu fish, der freundlichen interaktiven Shell

Ab hier wird geloggt. Als Beipiel ein ping, den ich kurz nach dem Aufruf mit CTRL-C abbreche.

Code: Alles auswählen

chris@lenovo ~> ping 192.168.0.32
PING 192.168.0.32 (192.168.0.32) 56(84) bytes of data.
64 bytes from 192.168.0.32: icmp_seq=1 ttl=64 time=2.34 ms
64 bytes from 192.168.0.32: icmp_seq=2 ttl=64 time=2.64 ms
64 bytes from 192.168.0.32: icmp_seq=3 ttl=64 time=2.75 ms
^C
--- 192.168.0.32 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 2.342/2.575/2.745/0.170 ms

Danach breche ich script mit CTRL-D ab. Das Ergebnis ist

Code: Alles auswählen

chris@lenovo ~> cat scr.txt
Script started on 2023-04-13 22:12:14+02:00 [TERM="st-256color" TTY="/dev/pts/0" COLUMNS="147" LINES="39"]
Willkommen zu fish, der freundlichen interaktiven Shell
chris@lenovo ~> ping 192.168.0.32
PING 192.168.0.32 (192.168.0.32) 56(84) bytes of data.
64 bytes from 192.168.0.32: icmp_seq=1 ttl=64 time=2.34 ms
64 bytes from 192.168.0.32: icmp_seq=2 ttl=64 time=2.64 ms
64 bytes from 192.168.0.32: icmp_seq=3 ttl=64 time=2.75 ms
^C
--- 192.168.0.32 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2004ms
rtt min/avg/max/mdev = 2.342/2.575/2.745/0.170 ms
chris@lenovo ~>

Script done on 2023-04-13 22:12:23+02:00 [COMMAND_EXIT_CODE="0"]

Manchmal oder bei manchen Terminalprogrammen tauchen im scr.txt noch Codes für Steuerzeichen auf. Die Infos hat man trotzdem . Insgesamt ist script ein sehr nützliches Programm.

On-Topic: Bist Du mit dem Problem weiter gekommen?

Viele Grüße,
Christoph

[chrbr]

Hoppla, ist ein Kopierfehler.

Eines habe ich noch vergessen. Man kann bei den meisten Terminals auch zurück scrollen und per Maus Auswahl die interessanten Teile selektieren und kopieren. Wie viel möglich ist hängt von der Konfiguration ab. Und wenn man das Terminal schließt ist natürlich auch die Ausgabe weg. Bei wenigen Zeilen verwende ich auch die Maus.

[jochen02]

Hast Du das wirklich abgetippt?

Nee, natürlich nicht.
script kenne ich seit SCO Unix. Da war es v.a. bei ASCII-Terminals eine Hilfe. Heutzutage kopiert man kürzere Text-Teile schneller mit der Maus.

Ich musste den Kram nur sauber-editieren, dabei ist das passiert.

On-Topic: Bist Du mit dem Problem weiter gekommen?

Nein, leider nicht. Ich hoffe, du hast ein paar Ideen?

Mich verwirrt, dass von PC1 nach PC2 keine Verbindung auf Port 1716 zustandekommt, lokal auf PC2 aber schon:

PC1 --> PC2

Code: Alles auswählen

$ nc -v 192.168.150.159 1716
PC2 [192.168.150.159] 1716 (?) : No route to host

PC1 --> PC1 (lokal)

Code: Alles auswählen

$ nc -v 192.168.150.159 1716
Connection to 192.168.150.159 1716 port [tcp/*] succeeded!

iptables ist ja auf "Durchzug" (policy accept, keine Regeln).

kdeconnect horcht auf Interface 192.168.150.159 Port 1716, aber nicht, wenn es "von draussen" versucht wird.

[chrbr]

Nee, natürlich nicht.
script kenne ich seit SCO Unix.

Ok, dann kennst du dich sicher besser aus als ich. Hier im Forum gibt es halt eine extreme Bandbreite an Nutzern was natürlich auch gut ist. Bitte entschuldige meine Unterstellung .

PC1 und PC2 sehen sich mit ping und eine andere Kommunikation, zB per ssh funktioniert?

Wenn ja würde erst einmal mit

Code: Alles auswählen

ss -pants

kontrollieren, ob wirklich überall gelauscht wird. Netcat zum Testen von offenen Ports habe ich bisher nie verwendet. Das würde ich mit nmap nochmal probieren. Wenn das passt könntest du kdeconnect abschalten und mit netcat die Verbindungen PC1->PC2 und umgekehrt testen. Besteht im Extremfall die Möglichkeit, PC2 statt mit WLAN mit LAN anzuschließen?

Kann es einen Unterschied machen, dass PC1 auf englisch und PC2 auf deutsch konfiguriert ist?

[jochen02]

Ok, dann kennst du dich sicher besser aus als ich. Hier im Forum gibt es halt eine extreme Bandbreite an Nutzern was natürlich auch gut ist. Bitte entschuldige meine Unterstellung

Welche Unterstellung? Alles gut.

Ja, PC1 und PC2 sehen einander. Sowohl ping, als auch ssh. Das verwende ich oft, wenn ich zu faul bin, vom Notebook zum Tower oder umgekehrt zu laufen.

ss -pants
kontrollieren, ob wirklich überall gelauscht wird.

Auf PC2 (auf dem kdeconnect nicht funktioniert):

Code: Alles auswählen

LISTEN     0      50                   *:1716                *:*    users:(("kdeconnectd",pid=3202,fd=19))

Lauscht also auf Port 1716 -- so weit o.k.

Das würde ich mit nmap nochmal probieren.

Nun, nmap -PU1716 192.168.150.159 zeigt keine Spur von 1716, das selbe auf 192.168.150.102. Hast du eine sinnvollere Kombination von Parametern?

netcat bei auf beiden PCs nicht laufenden kdeconnectd gibt statt "succeeded" dann "Connection refused" aus -- wie erwartet.
Der Verbindungsversuch von PC1 nach PC2 gibt in diesem Fall noch immer "No route to host". Genau hier scheint das Problem zu liegen. Warum um alles in der Welt diese Behauptung?

Besteht im Extremfall die Möglichkeit, PC2 statt mit WLAN mit LAN anzuschließen?

Klar.
nc -v 192.168.150.169 (LAN-IP von PC2) bringt auch nur "No route to host".

Noch als Ergänzung: nmap gibt aus:
PC1 nach PC2

Code: Alles auswählen

PORT     STATE    SERVICE
1716/tcp filtered xmsg

PC2 nach PC1

Code: Alles auswählen

PORT     STATE SERVICE
1716/tcp open  xmsg

Ist für UDP genauso.

[chrbr]

Kann es möglicherweise an den Unterschiedlichen Werten für Metric bei PC1 und PC2 liegen? Kann es sein, dass der Router selbst das Problem ist? Wenn du für PC2 den PC1 als default route setzt sollte der eigentliche Router nicht mehr dazwischen liegen.

Was mir noch einfällt, du schreibst ssh und ping funktionieren zwischen PC1 und PC2. Wie geht denn das ohne route? Läuft das dann über die IP4ALL Adresse 169.254.0.0 - falls das überhaupt geht? Oder funktioniert ssh mittlerweile auch nicht mehr?

[jochen02]

Ich bin ziemlich sicher, dass die Fehlermeldung "No route to host" irreführend ist.
Natürlich gibt es eine Route von PC1 zu PC2 und umgekehrt.

Um die Frage zu beantworten: Sowohl ping, als auch ssh funktionieren in beide Richtungen.

Code: Alles auswählen

# route -n
Kernel-IP-Routentabelle
Ziel            Router          Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.150.1   0.0.0.0         UG    600    0        0 wlp6s0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlp6s0
192.168.150.0   0.0.0.0         255.255.255.0   U     600    0        0 wlp6s0

Das lässt eine Verbindung zu allen hosts innerhalb des Class-C-Netzes 192.168.150.0/24 zu.Die Erfahrungen abgesehen von kdeconnect bestätigen das auch. Hier ständig genutzte Verbindungen sind: ssh, nfs, http, https, smb. Das Notebook (PC2) wird allerdings nur für ssh als Server genutzt. Und natürlich gern auch als kdeconnect(d) auf Port 1716.

[jochen02]

Was mir noch einfällt, du schreibst ssh und ping funktionieren zwischen PC1 und PC2. Wie geht denn das ohne route? Läuft das dann über die IP4ALL Adresse 169.254.0.0

Du meinst also, dass von Interface 192.168.150.102 von PC1 auf Interface 192.168.150.159 von PC2 irgendwas über Route mit Ziel 169.254.0.0 läuft?
Das glaube ich nicht.

Ich habe aud PC2 mal netcat gestartet mit:

Code: Alles auswählen

netcat -l -s 192.168.150.159 -p 1716

und von PC1

Code: Alles auswählen

netcat -v 192.168.150.159 1716

Das selbe Ergebnis.
Es läuft also irgendwie darauf hinaus, festzustellen, was auf PC2 den Port 1716 sperrt, also hierzu führt:

Code: Alles auswählen

# nmap -p 1716 -sT -v 
(...)
PORT     STATE    SERVICE
1716/tcp filtered xmsg

[chrbr]

Ist vielleicht eine andere Firewall außer iptables aktiv?

Mit netcat könnte man auch die Übertragung an sich testen. Auf einem Rechner lauscht netcat auf einem Port.

Code: Alles auswählen

nc -l -p 1716

Auf dem zweiten Rechner wird ein freundliches Hallo gesendet.

Code: Alles auswählen

echo "hallo"|nc 127.0.0.1 1716

Der erste Rechner sollte das Hallo dann anzeigen.

[jochen02]

Ist vielleicht eine andere Firewall außer iptables aktiv?

Das war auch schon mein Gedanke. Ich wüsste aber nicht, welche. Vor allem kenne ich nichts, was nicht Regeln für iptables schreiben würde. Hast du eine Idee?

Code: Alles auswählen

$ PC2 > nc -l -p 1716

$ PC1 > echo "hallo"|nc 192.168.150.159 1716
(UNKNOWN) [192.168.150.159] 1716 (?) : No route to host
 

Vorher habe ich den laufenden kdeconnectd Prozess auf PC2 gekillt.

EDIT: Ich habe inzwischen tatsächlich mal traceroute bemüht.
PC1 --> PC2:

Code: Alles auswählen

traceroute 192.168.150.159
traceroute to 192.168.150.159 (192.168.150.159), 64 hops max
  1   192.168.150.159  2,899ms !X  3,917ms !X  3,143ms !X 

Umgekehrt (PC2 --> PC1) ist es völlig unauffällig:

Code: Alles auswählen

traceroute 192.168.150.102
traceroute to 192.168.150.102 (192.168.150.102), 30 hops max, 60 byte packets
 1  192.168.150.102  1.379 ms  3.649 ms  3.712 ms

!X heisst "communication administratively prohibited"

Ich habe die Kommunikation nicht bewusst verboten.

[chrbr]

Wie sieht das Ergebnis bei anderen Ports wie 1715 aus?

In https://unix.stackexchange.com/question ... e-the-port steht etwas dubioses über eine Firewall UFW. Ich verwende nft. Werkelt bei dir systemd? Dann könntest du mit

Code: Alles auswählen

systemctl

nach verdächtigen Kandidaten suchen.

[jochen02]

Code: Alles auswählen

# ufw status
Status: inactive

systemctl sagt dazu:

Code: Alles auswählen

  ufw.service                                                                                                              loaded active exited    Uncomplicated firewall

ufw läuft also nicht.

Ich habe es dann trotzdem mal aktiviert und von

Code: Alles auswählen

# ufw status verbose
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)

auf

Code: Alles auswählen

# ufw status verbose
Status: active
Logging: on (low)
Default: allow (incoming), allow (outgoing), disabled (routed)

Brachte aber auch nichts. Ich habe ufw jetzt wieder deaktiviert.

[jochen02]

Tadaaa!

Inzwischen habe ich den Port wiedergewonnen. Verbindungen sind jetzt möglich, KDEConnect funktioniert auch.
Der Grund war firewalld. Das war, warum auch immer, installiert. PC1 hatte die policy "public" verpasst bekommen. Wenn ich das auf "trusted" umgestellt habe, war eine Verbindung möglich.

firewalld habe ich jetzt deinstalliert. Mir reicht die Sicherheit, nur ssh und kdeconnect nach außen anzubieten. Falls ich mehr brauche, nehme ich iptables.

Danke vielmals für deine Hinweise und deine Geduld.