
Am Montag, 12. Februar 2024, 12:16:31 CET schrieb Eric Schirra:
Am Montag, 12. Februar 2024, 10:05:37 CET schrieb Herbert Albert:
Am Montag, 12. Februar 2024, 05:34:17 CET schrieb Manfred Haertel, DB3HM:
Herbert Albert schrieb:
viele Jahre hat mir KDE Connect gute Dienste geleistet um schnell Fotos vom Smartphone auf den Rechner zu kopieren. Seit ein paar Wochen bricht die Übertragung meist ab, wenn ich mehr als eine Datei anwähle. Danach ist die Verbindung nicht mehr möglich.
Genau dieses Problem hatte ich vor einiger Zeit (ca. 2021 oder 2022) plötzlich ohne erkennbare Ursache auf meinem PC und die Ursache nicht gefunden. Ich habe dann auf andere "Krücken" gesetzt, um Daten auszutauschen.
Irgendwann letztes Jahr habe ich dann meinen PC verschrottet und auch stationär zuhause nur noch mit meinem Laptop gearbeitet. Da hat KDEconnect überhaupt noch nie funktioniert (der Connect kam nie zustande).
Als ich dann aus ganz anderen Gründen die iptables-Regeln des Laptops überarbeiten wollte, fiel mir auf, dass dort die iptables-Regeln für KDEconnect nie korrekt waren (warum auch immer ich das vorher übersehen habe). Also habe ich das nachgebessert und siehe da, KDEconnect funktioniert nicht nur überhaupt, sondern auch einwandfrei - und das obwohl ich meine Arbeits-VM 1:1 vom PC auf den Laptop umgezogen habe, sprich an irgendwelchen KDE-*Einstellungen* kann das Problem auf dem PC auch nicht gelegen haben, denn die sind mit umgezogen.
Dennoch meine ich, dass das Problem "irgendwie" im KDE liegen muss, also irgendwo bei diesen KIO-Daemonen. Denn letztendlich macht KDEconnect für den Datei-Transfer nichts anderes als einen Mount per sshfs - und der sollte funktionieren.
Hallo Manfred,
weißt Du noch was Du wie an den iptables-Regeln angepasst hast? Bei mir läuft der firewalld. Und da habe ich kdeconnect eingetragen. Doch wie ich nun sehe gibt es auch ein kdeconnect-kde.
Hallo Herbert,
ich habe mir mal das spec kde-connect angesehen. Dort gibt es ein veraltetes suse kdeconnect-kde.SuSEfirewall mit dem Inhalt:
## Name: KDE Connect ## Description: Opens port range 1714:1764 on tcp/udp/broadcast in order to let KDE Connect to work.
# space separated list of allowed TCP ports TCP="1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764"
# space separated list of allowed UDP ports UDP="1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764"
# space separated list of allowed UDP ports that accept broadcasts BROADCAST="1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764"
Im spec selbst wird dann ein kdeconnect-kde Eintrag in firewalld zu kdeconnect migriert. Das enthaltene kdeconnect vom aktuellen firewalld von Tumbleweed hat den Inhalt:
<?xml version="1.0" encoding="utf-8"?> <service> <short>KDE Connect</short> <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"/> </service>
Wenn ich aber bei unter /usr/lib/firewalld/services nachschaue, dann liegen dort kdeconnect und kedconnect-kde mit Inhalten:
<?xml version="1.0" encoding="utf-8"?> <service> <short>KDE Connect</short> <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"/> </service>
und
<?xml version="1.0" encoding="utf-8"?> <service> <short>KDE Connect</short> <description>KDE Connect is a project that aims to communicate all your devices.</description> <port protocol="tcp" port="1714-1764"/> <port protocol="udp" port="1714-1764"/> </service>
Ich würde mal behaupten, das das kdeconnect-kde ein Überbleibsel des wohl etwas missglückten Migrationsscriptes im spec-file von kdeconnect-kde. Und ich denke das kdeconnect-kde kann man einfach löschen. Außer im spec von Leap wäre das andere drinn. Das habe ich aber nun nicht mehr überprft. Kannst ja mal ein Bugreport aufmachen.
Wie man broadcast sperrt oder freigibt in firewalld habe ich aber noch nicht nachgeschaut.
Bei mir läuft das kdeconnect schon seit einer Ewigkeit ohne Fehler. Benutze es aber nicht für Dateitransfer.
Gruß Eric
Nochmal die rpms kdeconnect-kde und firewalld angeschaut. Im kdeconnect-kde ist der firewall-service kdeconnect-kde drin. Und im firewalld paket selbst isd kdeconnect drin. Also entweder gehört das service file aus kdeconnect-kde entfernt oder aus firewalld. Gruß Eric