1

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.
2
  • What are you using for mDNS on Windows? Bonjour for Windows?
    – Spiff
    Commented Mar 7, 2017 at 0:43
  • @Spiff yes I am using Bonjour Print Services for Windows v2.0.2: support.apple.com/kb/DL999
    – mdns
    Commented Mar 7, 2017 at 5:21

1 Answer 1

0

Before doing this, you can validate if your Raspberry Pi has a firewall setup, by checking if sudo iptables -L contains entries. If so, then try to stop the firewall service and check if mDNS works again. If so, then this is a problem with firewall.

Specifically for the OP, you need to enable the ports on the firewall of your Raspberry Pi, not (or at least not only) on your Windows machine (or the host that you wish to use to connect to your Raspberry Pi).

Also, the post I found that helped me in a similar issue (see below) mentioned multiple ports (548, 5353, 5354). You might want to allow incoming connections/packets to all of them, incl. UDP and TCP. I did not debug deeper so maybe not all are mandatory.


Similar issue in CentOS 7

I landed here while trying to resolve exactly the same symptom with my CentOS 7 host: I installed avahi (sudo yum install avahi) and enabled avahi-daemon. However, I can only ping hostname.local from my Windows machine within a few minutes after my CentOS 7 host reboots or after I do sudo systemctl restart avahi-daemon.

After some research, I found the following 2 posts:

  1. Bug report that appears to be the same on RHEL 6, with several potential solutions in comments
  2. Firewall setup commands for CentOS 7

I debugged by sudo systemctl stop firewalld. After doing this, iptables entries are cleared, and my Windows machine can immediately regain access to the CentOS 7 host using its hostname.local.

Therefore, I decided that it was the firewall configuration that actually matters. So I enabled the ports mentioned in post 1, using the command from post 2. Specifically, as follows:

sudo firewall-cmd --zone=public --add-port=548/udp --permanent
sudo firewall-cmd --zone=public --add-port=548/tcp --permanent
sudo firewall-cmd --zone=public --add-port=5353/udp --permanent
sudo firewall-cmd --zone=public --add-port=5353/tcp --permanent
sudo firewall-cmd --zone=public --add-port=5354/udp --permanent
sudo firewall-cmd --zone=public --add-port=5354/tcp --permanent

In case your active zone of your connection is not "public", you can find out your active zone using:

firewall-cmd --get-active-zones

After making the above changes, reboot, restart the firewall (sudo systemctl restart firewalld), or simply reload the rules using

sudo firewall-cmd --reload

Hope this answer helps people who reached here also due to CentOS issues.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .