.local domain look ups do not trigger name publication

[Dan Kortschak]

On my local network I find that with 18.04 network name lookups using .local domains no not work unless stimulated by a non-18.04 machine first. This is observed for ssh, http, https and ping, but probably not limited to those.

To demonstrate this here is a ping example.

~ $ ping pi.local
ping: pi.local: Name or service not known
~ $ ping pi.local
ping: pi.local: Name or service not known

# At this point head to another machine running 16.04.6 and execute ping pi.local.
# This is immediately successful. Then head back to the 18.04 machine.

~ $ ping pi.local
PING pi.local (192.168.108.28) 56(84) bytes of data.
64 bytes from pi.this.domain (192.168.108.28): icmp_seq=1 ttl=64 time=4.43 ms
64 bytes from pi.this.domain (192.168.108.28): icmp_seq=2 ttl=64 time=5.64 ms
64 bytes from pi.this.domain (192.168.108.28): icmp_seq=3 ttl=64 time=5.98 ms
64 bytes from pi.this.domain (192.168.108.28): icmp_seq=4 ttl=64 time=5.84 ms
^C
--- pi.local ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 7018ms
rtt min/avg/max/mdev = 4.435/5.476/5.986/0.613 ms

After a couple of minutes, the name resolution fails again, but can be brought back again by following the procedure above.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: avahi-daemon 0.7-3.1ubuntu1.2
ProcVersionSignature: Ubuntu 4.18.0-20.21~18.04.1-generic 4.18.20
Uname: Linux 4.18.0-20-generic x86_64
NonfreeKernelModules: nvidia_modeset nvidia
ApportVersion: 2.20.9-0ubuntu7.6
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Sun May 26 20:04:58 2019
InstallationDate: Installed on 2019-05-22 (4 days ago)
InstallationMedia: Ubuntu 18.04.2 LTS "Bionic Beaver" - Release amd64 (20190210)
SourcePackage: avahi
UpgradeStatus: No upgrade log present (probably fresh install)

[Dan Kortschak (dan-kortschak)]

~ $ lsb_release -rd
Description: Ubuntu 18.04.2 LTS
Release: 18.04

[Trent Lloyd (lathiat)]

The most likely cause for this is that you have packets outbound on port 5353 firewalled either locally or on your network device. When another host pings the address, the responses are sent via multicast and Avahi caches that response, and so can then use it without having to transmit a packet.

Until someone else looks it up, the cache is empty and the query packet is blocked, so no resolution happens.

To confirm this, other than checking and clearing both iptables and nftables, you could try run tcpdump on your host and then on another host to see if you can see the packet generated locally, and then if it actually arrives on the network.

Note that once avahi has the address in its cache, when it queries the network for it, it includes that address in the packet as "Known Answer" and the other host won't respond. So when testing this you are likely best to restart the local avahi daemon to clear it's cache before each test. You can see those "Known Answers" in the tcpdump though.

Best viewed with wireshark as it makes decoding the DNS part easy.

As a secondary test, I would suggest trying a different network adapter (possibly wired instead of wireless, or vica-versa) - you can also get these problems from weird drivers in some cases. Though usually broken drivers prevent you from RECEIVING multicast, and so manifests that this never works, so that seems unlikely in your case, but perhaps not impossible.

As a third test try 'avahi-resolve-host-name' instead of ping, to isolate if "avahi" / multicast is the issue, as opposed to the nss-mdns layer.

Going to mark this Invalid for now, however, if you can show from the packet dumps that the query packets are really not being sent at all even locally feel free to set the status back to New for further investigation.

[Dan Kortschak (dan-kortschak)]

Before I get a chance to look into this later today, I'd like to note that the network device is not firewalling those packets since a few days ago before I installed 18.04 on this machine it was behaving as expected and the 16.04 machine mentioned in the OP is not being blocked (it is on a slightly more restrictive policy than this one, but neither block that port). As for the possibility of blocking outbound packets from the machine itself, this seems most likely, however, as mentioned, this is a new install and I have not added any firewalling policy that would block them, suggesting that it's an out of the box setting.

I'll report back on these and the other tests when I am at that location.

[Dan Kortschak (dan-kortschak)]

I have checked iptables and there are no rules.

# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

Looking at the the network traffic leaves me bewildered. There is too much variability to be able to make any sense of what is going on. Sometimes ping works and sometimes not. Restarting avahi-daemon does not appear to make any difference to this apart from the obvious flurry of packets when it does.

avahi-resolve-host-name does not behave significantly differently to ping (it does sometimes work, but then so does ping).

I'm lost with trying to sort this out though.

[Dan Kortschak (dan-kortschak)]

I don't claim that the packets are not being sent, but rather that the system does not work as expected out of the box when it did in a previous LTR. I don't really care what package is the cause except to help get the problem fixed. I have done as much debugging of this as I am capable since networking is not my area. If additional specific question need addressing, I can follow up.