Multicast not working: Avahi shows no services

I just installed Manjaro on an ARM system. I’m already running it on two other machines (one ARM, one x86) with no issues. On this new system, avahi discover and browse return no results. My network is available (I’m typing this from that machine), but Avahi shows nothing, not even on the local machine. I ran sudo systemctl start avahi-daemon, and looked at the output of avahi-daemon --debug, which is as follows:

Found user 'avahi' (UID 974) and group 'avahi' (GID 974).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
chroot.c: chroot() helper started
Successfully called chroot().
Successfully dropped remaining capabilities.
chroot.c: chroot() helper got command 02
No service file found in /etc/avahi/services.
Joining mDNS multicast group on interface eth0.IPv6 with address fe80::4ea5:2615:e76:fc80.
New relevant interface eth0.IPv6 for mDNS.
Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.71.
New relevant interface eth0.IPv4 for mDNS.
Joining mDNS multicast group on interface lo.IPv6 with address ::1.
New relevant interface lo.IPv6 for mDNS.
Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
New relevant interface lo.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for fe80::4ea5:2615:e76:fc80 on eth0.*.
Registering new address record for 192.168.1.71 on eth0.IPv4.
Registering new address record for ::1 on lo.*.
Registering new address record for 127.0.0.1 on lo.IPv4.
sendmsg() to ff02::fb failed: Network is unreachable
sendmsg() to ff02::fb failed: Network is unreachable
sendmsg() to ff02::fb failed: Network is unreachable
Server startup complete. Host name is flere-imsaho.local. Local service cookie is 4111881056.
sendmsg() to ff02::fb failed: Network is unreachable
sendmsg() to ff02::fb failed: Network is unreachable
sendmsg() to ff02::fb failed: Network is unreachable

The results of avahi-browse -D are:

+  n/a  n/a fios-router.home

My /etc/avahi/avahi-daemon.conf is the default, which is the same across the other two machines.

The other two machines have no trouble browsing, showing all the results on the network. The new machine (if it’s relevant, it’s a Raspberry Pi) is plugged into the same router as one of the other machines.

How can I root cause this issue?

disable ipv6

Happy to try that. Sorry for the dumb question, but how do I do that? Also, why does that matter? I have ipv6 enabled on the other two boxes.

Thats why

Setup your network properly - don’t use invented networks like .lan or .home - more trouble than they are worth - and don’t use .local - this is avahi’s domain.

List the unit files for avahi - there is three of them

systemctl list-unit-files | grep avahi

Thanks for the quick reply.

I followed the instructions at that link and disabled ipv6 via sysctl, and verified this using ip a. Sure enough, no ipv6 addresses. Unfortunately, avahi-browse -a still returns no results

Here is the new output of avahi-daemon --debug

Found user 'avahi' (UID 974) and group 'avahi' (GID 974).
Successfully dropped root privileges.
avahi-daemon 0.8 starting up.
chroot.c: chroot() helper started
Successfully called chroot().
Successfully dropped remaining capabilities.
chroot.c: chroot() helper got command 02
No service file found in /etc/avahi/services.
Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.1.71.
New relevant interface eth0.IPv4 for mDNS.
Joining mDNS multicast group on interface lo.IPv4 with address 127.0.0.1.
New relevant interface lo.IPv4 for mDNS.
Network interface enumeration completed.
Registering new address record for 192.168.1.71 on eth0.IPv4.
Registering new address record for 127.0.0.1 on lo.IPv4.
Server startup complete. Host name is flere-imsaho.local. Local service cookie is 456009856.

Here are the unit files:

avahi-daemon.service                       enabled         disabled
avahi-dnsconfd.service                     disabled        disabled
avahi-daemon.socket                        enabled         disabled

This is the same result across my other machines as well.

Any ideas?

As an update, I’ve discovered that this is a multicast issue.

On the problem machine, I ran:

socat UDP4-RECVFROM:6666,ip-add-membership=224.1.0.1:192.168.1.71,fork EXEC:hostname

On a working machine, I ran:

socat STDIO UDP4-DATAGRAM:224.1.0.1:6666,range=192.168.1.1/24

I then typed some junk and sent it. Sure enough, the problem machine didn’t respond.

On the problem machine (the receiver), I ran tcpdump:

nate@flere-imsaho:~$ sudo tcpdump -i eth0 host 224.1.0.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

13:48:20.632215 IP hassipura-plyn-frie.fios-router.home.56318 > 224.1.0.1.6666: UDP, length 5

Whereas on a working machine (the sender):

nate@hassipura-plyn-frie:~$ sudo tcpdump -i wlan0 host 224.1.0.1
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

13:48:20.627910 IP hassipura-plyn-frie.56318 > 224.1.0.1.6666: UDP, length 5

Both see the packet sent at the same time, but there is no response. When I receive from my other working machine, tcpdump sees traffic in both directions, and the sender shows the receiver’s response. Presumably the problem machine did not register for the multicast address.

Where can I go from here?

To further complicate things, when I switch receiver sender roles between the problem machine and the working machine, it still doesn’t work. According to tcpdump, packets sent from the problem machine are received by the working machine, but the response is never received by the problem machine.

When on the problem machine I run

strace socat UDP4-RECVFROM:6666,ip-add-membership=224.1.0.1:192.168.1.71,fork EXEC:hostname

I see that it hangs on a call to pselect that never returns when the packet is received.

This implies that the kernel isn’t recognizing the multicast registration for that interface. How do I debug that one?

Have you checked this, what the Arch wiki says
about the contents of
/etc/nsswitch.conf

hosts: mymachines mdns_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns

within that wiki, this seems noteworthy:

if you experience slowdowns in resolving .local hosts try to use mdns4_minimal instead of mdns_minimal …

I did not check whether this is already what the file looks like.

That’s what my nsswitch.conf looks like. But I’m now sure this is not an mdns problem, but a multicast problem.

After messing around with this further, I’m confident that this has to be a bug in Manjaro. It works out of the box on Raspbian 64-bit.

Where do I report this as a bug? To be clear, this isn’t an avahi or a socat bug. This is a bug somewhere in the kernel configuration or the system configuration.

This turned out to be that firewalld is misconfigured.

To get this to work, I had to explicitly enable it:

firewall-cmd --zone public --add-service mdns --permanent
sudo systemctl restart firewalld

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.