*** 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
comment #4 > Absolutely agreed. Make it depend on avahi. Or if we are feeling like > avoiding dependencies today, systemd-resolved. @Roberto comment #5 > I think kdeconnect package should require installation of avahi-daemon OR > systemd-resolved @ApertureUA Wouldn't it make more sense to have kdeconnect *optionally* depend on avahi or systemd-resolved, and otherwise disable mDNS features?
The same problem on Gentoo, confirming. Also, I'd like to note that kdeconnect already depend on kdnssd, which has Avahi as optional dependency. Probably direct dependency on Avahi or resolved is not really required for kdeconnect as it is already centralised for KDE apps in kdnssd? But if mDNS is handled already by kdnssd, why kdeconnectd uses 5353 port by its own?