mdns failng with current versions of libnss-mdns and avahi-daemon

[Jeremy Sequoia]

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.

[Jeremy Sequoia (jeremyhu)]

Also:

[659] /etc/avahi/services $ avahi-browse -a
+ lo IPv4 cid SSH Remote Terminal local
+ lo IPv4 cid SFTP File Transfer local

It's as if something is causing the network interface to not support mdns, but everyhing looks configured to me... what am I missing? It should really not be this difficult...

[Trent Lloyd (lathiat)]

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.

[Trent Lloyd (lathiat)]

There's a detail in the github issue that wasn't noted here:
I have Ubuntu Server 22.04.2 running in a VM (VMWare 13.0.2) on an Apple Silicon Mac running macOS 13.4.

That makes the network driver situation less likely but the firewall situation still possible.

A few extra questions:
What kind of network is fusion set to - bridged, nat, host-only, etc
+ If you are using bridged, but to your macs wireless adapter, I have also experienced this not working as expected. Try use ethernet via a USB-Ethernet or native ethernet if your machine has it - and see if it works then. That was the case for me. If you google "vmware fusion bridge wifi" there are lots of posts with slightly different setups and symptoms.
+ If you are using nat/host-only I would expect only to be able to resolve hostnames with the host Mac and not the rest of the network

Run tcpdump as directed, I am curious if you see any packets sent from any other node on your network. I am guessing not. If you are, it would be ideal to capture a pcap file (a copy of all the network packets on 5353) from both this linux VM, as well as another linux machine on the network that is not the host mac:L

tcpdump -i <interface> -s 65535 -w lp2021409-$(hostname).pcap port 5353

Then run a query from both the VM and external host, for the other machine. While the pcap is running. Then stop it. Upload both files and note the IP addresses and hostnames of both machines.

It's highly likely this is not a bug in avahi or nss-mdns but a network issue of some kind. Hopefully this will get you going in the right direction.

[Jeremy Sequoia (jeremyhu)]

Note that this system doesn't resolve itself either (unless I configure avahi to use lo as well)

The network is bridged to the Mac's wireless interface.

I'll give bridging to a wired interface a try.