*** If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** SUMMARY kdeconnect listens to the mdns port and runs an mdns server, which conflicts with avahi-daemon -- whenever I run both, and come up from sleep, my hostname becomes hostname-2.local, due to a "Host name conflict, retrying with myhostname-2" STEPS TO REPRODUCE 1. Install kdeconnect 2. Install avahi daemon 3. Put computer to sleep and back up (I suspect I can just turn networking on and off) OBSERVED RESULT avahi-daemon freaks out about having multiple mdns stacks on the same machine: May 28 19:13:55 kelvie-lws avahi-daemon[441170]: *** WARNING: Detected another IPv4 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. *** May 28 19:13:55 kelvie-lws avahi-daemon[441170]: *** WARNING: Detected another IPv6 mDNS stack running on this host. This makes mDNS unreliable and is thus not recommended. *** kdeconnect also has these log lines, not sure if they're related: May 28 19:14:38 kelvie-lws kdeconnectd[418933]: 2024-05-28T19:14:38 kdeconnect.core: Error sending MDNS query response May 28 19:14:38 kelvie-lws kdeconnectd[418933]: 2024-05-28T19:14:38 kdeconnect.core: Error sending MDNS query response May 28 19:14:38 kelvie-lws kdeconnectd[418933]: 2024-05-28T19:14:38 kdeconnect.core: Error sending MDNS query response EXPECTED RESULT To be able to use kdeconnect without losing my original mdns name from avahi-daemon SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.2.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION
Turns out you can disable MDNS from the build, for arch users I made a pkgbuild here: https://aur.archlinux.org/packages/kdeconnect-no-mdns I also updated the avahi wiki page.
Also experiencing a situation where my machine is no longer reachable via `machine.local` because kdeconnect breaks avahi. Seems wrong to have an mdns responder in kdeconnect that is totally not configurable: - it confuses other responders and mainly avahi; - you cannot control on which interfaces it will respond; - probably it will even get confused if you have more than a single interface (I've been under the impression that it can end up broadcasting on the local network the ip address of a private virtualbox network). Incidentally, I understand that avahi, and probably other mdns responders have a dbus interface to be instructed on which services to publish. Wouldn't that be a better way to go?
I also found that kdeconnect breaks avahi-daemon on my desktop: ````` dic 19 19:57:10 darkgoo avahi-daemon[1390]: Joining mDNS multicast group on interface enp7s0.IPv6 with address fe80::e510:a7e9:19ec:39e. dic 19 19:57:10 darkgoo avahi-daemon[1390]: Registering new address record for fe80::e510:a7e9:19ec:39e on enp7s0.*. dic 19 19:57:10 darkgoo avahi-daemon[1390]: Withdrawing address record for fe80::e510:a7e9:19ec:39e on enp7s0. dic 19 19:57:10 darkgoo avahi-daemon[1390]: Leaving mDNS multicast group on interface enp7s0.IPv6 with address fe80::e510:a7e9:19ec:39e. dic 19 19:57:10 darkgoo avahi-daemon[1390]: Interface enp7s0.IPv6 no longer relevant for mDNS. dic 19 19:57:10 darkgoo kdeconnectd[6157]: 2024-12-19T19:57:10 default: Error sending UDP packet: QAbstractSocket::NetworkError dic 19 19:57:10 darkgoo kdeconnectd[6157]: 2024-12-19T19:57:10 kdeconnect.core: Failed to open any MDNS server sockets dic 19 19:57:14 darkgoo avahi-daemon[1390]: Joining mDNS multicast group on interface enp7s0.IPv6 with address fe80::e510:a7e9:19ec:39e. dic 19 19:57:14 darkgoo avahi-daemon[1390]: New relevant interface enp7s0.IPv6 for mDNS. dic 19 19:57:14 darkgoo avahi-daemon[1390]: Registering new address record for fe80::e510:a7e9:19ec:39e on enp7s0.*. dic 19 19:57:18 darkgoo avahi-daemon[1390]: Joining mDNS multicast group on interface enp7s0.IPv4 with address 192.168.9.1. dic 19 19:57:18 darkgoo avahi-daemon[1390]: New relevant interface enp7s0.IPv4 for mDNS. dic 19 19:57:18 darkgoo avahi-daemon[1390]: Registering new address record for 192.168.9.1 on enp7s0.IPv4. dic 19 19:57:18 darkgoo kdeconnectd[6157]: 2024-12-19T19:57:18 kdeconnect.core: Failed to send mDNS query: Cannot assign requested address dic 19 19:57:19 darkgoo avahi-daemon[1390]: Leaving mDNS multicast group on interface enp7s0.IPv6 with address fe80::e510:a7e9:19ec:39e. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Joining mDNS multicast group on interface enp7s0.IPv6 with address fd45:4214:bc68:0:768f:b639:4e22:6605. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Registering new address record for fd45:4214:bc68:0:768f:b639:4e22:6605 on enp7s0.*. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Withdrawing address record for fe80::e510:a7e9:19ec:39e on enp7s0. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Registering new address record for fd45:4214:bc68::e88 on enp7s0.*. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Withdrawing address record for fd45:4214:bc68:0:768f:b639:4e22:6605 on enp7s0. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Withdrawing address record for 192.168.9.1 on enp7s0. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Withdrawing address record for ::1 on lo. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Withdrawing address record for 127.0.0.1 on lo. dic 19 19:57:19 darkgoo avahi-daemon[1390]: Host name conflict, retrying with darkgoo-3 ```` IMHO I really don't think that this is the way to go for kdeconnect to implement mdns functionality which should be instead a system service responsability. Wouldn't be better if kdeconnect could provide mdns by the means of a package dependency and let your distribution package manager installing avahi-daemon or a similar service?
Absolutely agreed. Make it depend on avahi. Or if we are feeling like avoiding dependencies today, systemd-resolved.
@ApertureUA systemd-resolved would be a dependency as well, I don't have it installed. I think kdeconnect package should require installation of avahi-daemon OR systemd-resolved
@Roberto, not sure what distro you use but on Arch it's apart of the base systemd package
systemd-resolved generally sucks compared to avahi in every way but there might be people relying on that, just sayin'
@ApertureUA I use debian and void