I have a Raspberry Pi server called bigbrain. Normally I can reach this machine on my local network using:

bigbrain.local

This works using mDNS (Multicast DNS). Addresses ending with .local are handled specially. Rather than asking an outside world name server to resolve a name to an address, when a device sees an address ending .local it will use a local service that listens for devices that broadcast addressing information on the local network. On a Raspberry Pi, mDNS is normally provided by a service called Avahi. Avahi announces the name of the machine on the local network so that other devices can find it without needing an entry in a conventional DNS server.

This morning I noticed that bigbrain.local didn’t work any more. This was a bit worrying, it’s the machine that hosts the custard cream server, among other things. I logged in using the Raspberry Pi Connect service and was pleased to discover that the machine was still working. The first thing to I needed to check was whether or not the Avahi service was running. I opened a terminal window and typed:

systemctl status avahi-daemon

Avahi was running, but the output contained an important clue:

Host name conflict, retrying with bigbrain-2

and:

Server startup complete. Host name is bigbrain-2.local.

This explained why bigbrain.local wasn't working. Avahi thought that another machine on the network was already using that name. Rather than create a conflict, it had renamed its mDNS identity to:

bigbrain-2.local

Was there another Bigbrain?

My first thought was that I might have booted another Raspberry Pi containing an old copy of the bigbrain system. If two machines both have the hostname bigbrain, they will both attempt to advertise themselves as bigbrain.local.

But I wasn't certain that I'd actually done this, which raised a slightly less comfortable question: was an unknown device appearing on my network?

Fortunately, the system log provided some more information.

The conflict had occurred at 02:55 on 22 September:

Sep 22 02:55:17 bigbrain avahi-daemon[585]:
Host name conflict, retrying with bigbrain-2

Looking at the Avahi journal around this time showed something interesting. For several minutes before the conflict, Avahi had been repeatedly registering and withdrawing network addresses.

At 02:55:17 it withdrew the addresses associated with both network interfaces and then registered them again. Five seconds later NetworkManager reported:

dhcp4 (eth0): state changed new lease, address=192.168.7.107

So something was definitely happening to the network at the same time that Avahi decided there was another bigbrain.

The missing piece

I use a system called eero to provide Wi-Fi access at home. It turned out that the eero network had automatically updated its software earlier that morning. The update caused the network infrastructure to restart. At 02:19 on 22nd September. That provided a much more convincing explanation.

As the network came back, DHCP leases, IPv6 addresses, multicast groups and mDNS advertisements all had to be re-established. The Avahi logs showed exactly this kind of activity.

There was another complication. bigbrain was connected to the same local network in two different ways:

              bigbrain
             /        \
          WiFi       Ethernet
           |             |
    192.168.7.22   192.168.7.107
           \             /
            local network

Both interfaces were therefore participating in mDNS on the same network and both represented the same machine with the same hostname.

Normally this works. But during the disruption caused by the network restart, Avahi apparently saw enough conflicting information to conclude that somebody else was already advertising bigbrain.local.

It did the safe thing and changed its advertised name to bigbrain-2.local.

Once the network had settled, restarting Avahi:

sudo systemctl restart avahi-daemon

allowed it to register bigbrain.local normally again.There was no evidence here of an unknown machine or a security compromise (which was nice). The hostname conflict occurred during a period of substantial network reconfiguration following an eero software update. But the incident did expose an unnecessary complication in the server configuration.

The Raspberry Pi was connected to the same LAN using both Ethernet and Wi-Fi.

There are situations where having multiple network interfaces is useful, but a fixed server generally isn't one of them. Two connections to the same network mean two IP addresses, two routes onto the LAN and two interfaces participating in multicast protocols such as mDNS. Most of the time the networking software sorts everything out. When the network is being restarted or reconfigured, however, things can get more interesting.

For a Raspberry Pi being used as a server, the simplest rule is therefore:

If you have a wired Ethernet connection, use Ethernet and turn WiFi off. If you need WiFi, use WiFi and leave Ethernet disconnected. Don't routinely use both to connect the server to the same local network.

I’m going to disable the Wi-Fi on bigbrain. Networking is complicated enough without giving the packets a choice of doors.