If the primary issue is that other devices can only resolve your hostname after restarting avahi-daemon for a short time, plus, this machine doesn't see anything else on the network, it means that for one reason or another mDNS packets on port 5353 are not making it back to this host.
The overwhelming majority of such cases are due to a bug in the driver for that network interface, almost always its a wireless interface or some kind - it's rare in wired ethernet drivers but not impossible. Very often setting the interface to promiscuous mode will fix this, because it tells the NIC to receive all packets (by default NICs filter out packets not intended for the host). You can try this command to set it: ip link set ens160 promisc on If this solves the issue, then it's 100% a buggy driver and I cannot do anything about that at the avahi level. You'll need to look at getting the driver fixed. This is common with bad wifi drivers, very rare with ethernet. If that doesn't help, it could be the driver also doesn't support promiscuous but I've not really seen that before. I would then check - Firewall on this machine, - Any features of your wireless network such as "multicast dns optimisation", etc If you run tcpdump for port 5353 you'll see packets coming and going. I suspect most likely your machine never receives any query packets from another host. So you can try run this command and then running a query from another host: sudo tcpdump -ni ens160 --no-promiscuous-mode port 5353 You can also try this without "--no-promiscuous-mode" (by default tcpdump puts the interface in promiscious mode, same as the above command). As a final note the resolvectl/resolved mdns support is totally independent of avahi, having it enabled could cause mDNS to fail in some cases - particularly with a network that performs 'multicast dns optimisation' where the packets are converted from multicast to unicast. Only a single process can bind to port 5353 for unicast packets and the packets will randomly get sent to resolved, avahi, chrome.. or any other process listening on port 5353. So disabling it (and anything else listening on 5353) could help in some specific circumstances though usually not necessary in most cases. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to avahi in Ubuntu. https://bugs.launchpad.net/bugs/2021409 Title: mdns failng with current versions of libnss-mdns and avahi-daemon Status in Avahi: New Status in avahi package in Ubuntu: New Status in nss-mdns package in Ubuntu: New Bug description: I have Ubuntu Server 22.04.2 I have installed avahi-daemon and libnss-mdns, but mdns resolution is not occurring over my primary network interface: Note that this is with `allow-interfaces=ens160` set /etc/avahi/avahi- daemon.conf. (22:25:17 Sat May 27 2023 jeremy@cid pts/0 aarch64) [648] ~ $ sudo resolvectl mdns ens160 1 (22:25:22 Sat May 27 2023 jeremy@cid pts/0 aarch64) [649] ~ $ resolvectl status Global Protocols: -LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf mode: stub Link 2 (ens160) Current Scopes: DNS mDNS/IPv4 mDNS/IPv6 Protocols: +DefaultRoute +LLMNR +mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 2601:647:6680:4b95::1 DNS Servers: 10.1.30.1 2601:647:6680:4b95::1 DNS Domain: localdomain (22:25:27 Sat May 27 2023 jeremy@cid pts/0 aarch64) [650] ~ $ avahi-resolve -n cid.local Failed to resolve host name 'cid.local': Timeout reached (22:26:03 Sat May 27 2023 jeremy@cid pts/0 aarch64) [651] ~ $ avahi-resolve -a 10.0.30.1 Failed to resolve address '10.0.30.1': Timeout reached (22:26:13 Sat May 27 2023 jeremy@cid pts/0 aarch64) [652] ~ $ sudo systemctl status avahi-daemon ● avahi-daemon.service - Avahi mDNS/DNS-SD Stack Loaded: loaded (/lib/systemd/system/avahi-daemon.service; enabled; vendor preset: enabled) Active: active (running) since Sat 2023-05-27 22:22:29 UTC; 3min 51s ago TriggeredBy: ● avahi-daemon.socket Main PID: 850 (avahi-daemon) Status: "avahi-daemon 0.8 starting up." Tasks: 2 (limit: 4523) Memory: 1.5M CPU: 15ms CGroup: /system.slice/avahi-daemon.service ├─850 "avahi-daemon: running [cid.local]" └─891 "avahi-daemon: chroot helper" May 27 22:22:29 cid avahi-daemon[850]: No service file found in /etc/avahi/services. May 27 22:22:29 cid avahi-daemon[850]: Joining mDNS multicast group on interface ens160.IPv6 with address 2601:647:6680:4b95:20c:29ff:fe42:f399. May 27 22:22:29 cid avahi-daemon[850]: New relevant interface ens160.IPv6 for mDNS. May 27 22:22:29 cid avahi-daemon[850]: Joining mDNS multicast group on interface ens160.IPv4 with address 10.1.30.2. May 27 22:22:29 cid avahi-daemon[850]: New relevant interface ens160.IPv4 for mDNS. May 27 22:22:29 cid avahi-daemon[850]: Network interface enumeration completed. May 27 22:22:29 cid avahi-daemon[850]: Registering new address record for 2601:647:6680:4b95:20c:29ff:fe42:f399 on ens160.*. May 27 22:22:29 cid avahi-daemon[850]: Registering new address record for 10.1.30.2 on ens160.IPv4. May 27 22:22:30 cid avahi-daemon[850]: Server startup complete. Host name is cid.local. Local service cookie is 2371061072. May 27 22:26:11 cid avahi-daemon[850]: wide-area.c: Query timed out. (22:27:14 Sat May 27 2023 jeremy@cid pts/0 aarch64) [657] ~ $ grep hosts /etc/nsswitch.conf hosts: files mdns4_minimal [NOTFOUND=return] dns --- If I set 'allow-interfaces=ens160,lo`, we are able to resolve cid.local to localhost: $ avahi-resolve -n cid.local cid.local 127.0.0.1 but I cannot lookup anything else on my network via the ens160 interface. I *can* resolve cid.local (10.1.30.2) from other devices on my network for a brief moment after I restart avahi-daemon. To manage notifications about this bug go to: https://bugs.launchpad.net/avahi/+bug/2021409/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
