Avahi seems to stop publishing/refreshing services after a while

Question

Firstable, I looked up to several Q/A, i can ensure that the following points are fullfiled:

• IGMP snooping isn't filtered by switch/router.

• Bonjour services (mDNSResponder.exe) is granted and allowed on the firewall as well as UDP port 5353 (windows side).

• Avahi config is correct (plus use of ipv6 is disabled) as well as nssitch.conf needed modifications have been done

  hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4

• Avahi-daemon is running as well as bonjour services.

• windows side ipv6 is disabled on active network interface, also avahi-daemon is configured not to use ipv6: use-ipv6=no.

Issue with Pi's mDNS

After a while the hostname .local corresponding to the raspberry pi isn't resolved anymore after issuing a ping pi.local from windows, note that on startup it responded perfectly, and a restart of avahi-daemon will fix it temporary before the issue starts again.

Just after the mdns resolve fail I executed the following on the rasp avahi-resolve -n pi.local it shows it ipv6 (fe80::xxaa:yybb:zzde:ee) which is weird because as I mentionned I have disabled ipv6 in avahi configs, right just after i reexecute the same command this time i get ipv4 as an answer

pi.local 192.168.1.7

also ping seems to respond again.

P.S.

• Running Linux pi 4.4.38-v7+ #938

• Using Bonjour Print Services for Windows v2.0.2: https://support.apple.com/kb/DL999, and it's running as service.

• Disabling ipv6 only the return of avahi-resolve -n pi.local command gives 192.168.1.7 instead of ipv6 but issue remains.

Nothing in /var/log/messages concerning Avahi.

Any thoughts about the root of the problem ?

syslog after a while from restarting avahi-daemon and sending resolve command above:

18:21:47 pi systemd[1]: Stopping Avahi mDNS/DNS-SD Stack...

18:21:47 pi avahi-daemon[427]: Got SIGTERM, quitting.

18:21:47 pi avahi-daemon[427]: Leaving mDNS multicast group on
interface wlan0.IPv4 with address 192.168.1.7.

18:21:47 pi avahi-daemon[427]: avahi-daemon 0.6.31 exiting. 
18:21:47 pi systemd[1]: Starting Avahi mDNS/DNS-SD Stack...

18:21:47 pi avahi-daemon[1143]: Process 427 died: No such process;
trying to remove PID file. (/var/run/avahi-daemon//pid)

18:21:47 pi avahi-daemon[1143]: Found user 'avahi' (UID 105) and group
'avahi' (GID 110).

18:21:47 pi avahi-daemon[1143]: Successfully dropped root privileges.

18:21:47 pi avahi-daemon[1143]: avahi-daemon 0.6.31 starting up.

18:21:47 pi avahi-daemon[1143]: Successfully called chroot(). 
18:21:47 pi avahi-daemon[1143]: Successfully dropped remaining
capabilities. 
18:21:47 pi avahi-daemon[1143]: Loading service file
/services/multiple.service.

18:21:47 pi avahi-daemon[1143]: Loading service file
/services/udisks.service.

18:21:47 pi avahi-daemon[1143]: Joining mDNS multicast group on
interface wlan0.IPv4 with address 192.168.1.7.

18:21:47 pi avahi-daemon[1143]: New relevant interface wlan0.IPv4 for
mDNS.

18:21:47 pi avahi-daemon[1143]: Network interface enumeration
completed.

18:21:47 pi avahi-daemon[1143]: Registering new address record for
fe80::f2f:3b5b:ab5b:35c1 on wlan0.*.

18:21:47 pi avahi-daemon[1143]: Registering new address record for
192.168.1.7 on wlan0.IPv4.

18:21:47 pi avahi-daemon[1143]: Registering HINFO record with values
'ARMV7L'/'LINUX'.

18:21:47 pi systemd[1]: Started Avahi mDNS/DNS-SD Stack.

18:21:48 pi avahi-daemon[1143]: Server startup complete. Host name is
pi.local. Local service cookie is 2501181696. 

18:21:49 pi avahi-daemon[1143]: Service "pi"
(/services/udisks.service) successfully established.
18:21:49 pi avahi-daemon[1143]: Service "pi"
(/services/multiple.service) successfully established.

Answer 1

I have the same issue, and while I have not been able to "fix" it, I have a hacky workaround: restart avahi-daemon before the records expire. They appear to have a TTL of 120s (according to dns-sd -G v4 pi.local on macOS)

sudo crontab -e

# Add the following line to the crontab
*/1 * * * * systemctl restart avahi-daemon.service

# Save and exit

Answer 2

For short, on the destination device (i.e., Raspberry Pi), first debug by temporarily stopping the firewall service. If this helps, then it means you have the same problem with me. Just allow TCP/UDP connections on the destination device to ports 548, 5353, 5354.

I answered the same question on Super User. Please check this for details.