SOLVED - avahi Host name conflict, retrying with hostname-2

luser · 2023-03-07 06:15:48

During the last week or so, I've been having trouble with the avahi-daemon on my local network. Frequently, when a machine is rebooted or wakes from suspension, avahi starts publishing the hostname with a -2 appended. I didn't used to have this problem. I've edited the /etc/nsswitch.conf file to use only ipv4, as suggested by the wiki, but it's not solving the problem.

The problem is that I expect to be able to access a machine by its hostname with ".local" appended, say "epic6.local" for example, but for some reason, it's publishing as epic6-2.local, so it seems like epic6.local is not there. For now, my workaround has been to ssh into the machine by using its ip address and restarting the avahi-daemon which then, for some reason works.

If anyone knows how to get avahi-daemon working again without this issue, please chime in.

$ systemctl status avahi-daemon

 avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; preset: disabled)
     Active: active (running) since Mon 2023-03-06 21:12:05 PST; 2min 37s ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 10019 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 9252)
     Memory: 900.0K
        CPU: 37ms
     CGroup: /system.slice/avahi-daemon.service
             ├─10019 "avahi-daemon: running [epic6-2.local]"
             └─10021 "avahi-daemon: chroot helper"

Mar 06 21:14:13 epic6 avahi-daemon[10019]: Registering new address record for 192.168.1.14 on enp0s25.IPv4.
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Registering new address record for 2603:8000:d500:c2a9:f31b:f3a1:c113:c569 on enp0s25.*.
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Withdrawing address record for fe80::4ed1:4fe4:c9ac:a59d on enp0s25.
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Withdrawing address record for 192.168.1.14 on enp0s25.
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Host name conflict, retrying with epic6-2
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Registering new address record for 2603:8000:d500:c2a9:f31b:f3a1:c113:c569 on enp0s25.*.
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Registering new address record for 192.168.1.14 on enp0s25.IPv4.
Mar 06 21:14:16 epic6 avahi-daemon[10019]: Server startup complete. Host name is epic6-2.local. Local service cookie is 1196304330.
Mar 06 21:14:17 epic6 avahi-daemon[10019]: Service "epic6-2" (/services/ssh.service) successfully established.
Mar 06 21:14:17 epic6 avahi-daemon[10019]: Service "epic6-2" (/services/sftp-ssh.service) successfully established.

$ cat /etc/nsswitch.conf

# Name Service Switch configuration file.
# See nsswitch.conf(5) for details.

passwd: files systemd
group: files [SUCCESS=merge] systemd
shadow: files systemd
gshadow: files systemd

publickey: files

hosts: mymachines mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] files myhostname dns mdns4
networks: files

protocols: files
services: files
ethers: files
rpc: files

netgroup: files

cat /etc/avahi/avahi-daemon.conf

# This file is part of avahi.
#
# avahi is free software; you can redistribute it and/or modify it
# under the terms of the GNU Lesser General Public License as
# published by the Free Software Foundation; either version 2 of the
# License, or (at your option) any later version.
#
# avahi is distributed in the hope that it will be useful, but WITHOUT
# ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
# or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public
# License for more details.
#
# You should have received a copy of the GNU Lesser General Public
# License along with avahi; if not, write to the Free Software
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307
# USA.

# See avahi-daemon.conf(5) for more information on this configuration
# file!

[server]
#host-name=random6
#domain-name=local
#browse-domains=0pointer.de, zeroconf.org
use-ipv4=yes
use-ipv6=no
allow-interfaces=enp0s25
#deny-interfaces=eth1
#check-response-ttl=no
#use-iff-running=no
#enable-dbus=yes
#disallow-other-stacks=no
#allow-point-to-point=no
#cache-entries-max=4096
#clients-max=4096
#objects-per-client-max=1024
#entries-per-entry-group-max=32
ratelimit-interval-usec=1000000
ratelimit-burst=1000

[wide-area]
enable-wide-area=yes

[publish]
#disable-publishing=no
#disable-user-service-publishing=no
#add-service-cookie=no
#publish-addresses=yes
publish-hinfo=no
publish-workstation=no
#publish-domain=yes
#publish-dns-servers=192.168.50.1, 192.168.50.2
#publish-resolv-conf-dns-servers=yes
#publish-aaaa-on-ipv4=yes
#publish-a-on-ipv6=no

[reflector]
#enable-reflector=no
#reflect-ipv=no
#reflect-filters=_airplay._tcp.local,_raop._tcp.local

[rlimits]
#rlimit-as=
#rlimit-core=0
#rlimit-data=8388608
#rlimit-fsize=0
#rlimit-nofile=768
#rlimit-stack=8388608
#rlimit-nproc=3

In case a look at the logs help. . .
$ sudo journalctl -b
http://ix.io/4q8P

Last edited by luser (2023-03-29 09:23:45)

seth · 2023-03-07 08:39:45

Mar 04 14:01:40 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 04 14:01:52 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 04 14:01:56 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 06 16:00:59 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 06 16:01:02 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 06 20:58:19 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 06 20:58:23 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 06 21:14:08 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
Mar 06 21:14:12 epic6 kernel: e1000e 0000:00:19.0 enp0s25: NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None

The link is bouncing.

Edit: that's probably not the problem, though. Let's tidy this a bit first

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

You've two mdns entries, both for IPv4, but avahi-daemon operates on IPv6 as well
https://man.archlinux.org/man/extra/ava … #use_ipv6=

=> Disable IPv6 for avahi-daemon and remove mdns4 (or replace mdns4_minimal w/ mdns4)

Last edited by seth (2023-03-07 12:29:14)

luser · 2023-03-08 01:02:13

Thanks for responding, Seth.

I'm not sure what you mean by the link "bouncing." http://ix.io/4q8P seems to work just fine for me. I see output from Mar 04 14:01:29 through Mar 06 21:49:30.
Perhaps that's not important.

=> Disable IPv6 for avahi-daemon and remove mdns4 (or replace mdns4_minimal w/ mdns4)

Doesn't the line in avahi-daemon.conf (use-ipv6=no, shown in my original post) disable IPv6? Is there more I need to do?

With regard to nsswitch.conf, I've tried:

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

But when that didn't seem to resolve things, I looked at the Arch Linux Avahi wiki https://wiki.archlinux.org/title/Avahi. It has a link labeled "activation notes" which points to https://github.com/lathiat/nss-mdns/blo … activation which shows

hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4

as the recommended hosts line in /etc/nsswitch.conf. Frankly, I'm confused by that, since my limited understanding is that mdns4 is more for users running in a domain. I'm not. It's just a peer to peer network. Anyway, the "activation notes" link was what made me include "mdns4" in the hosts line for nsswitch.conf.

So, I'll try again with the hosts line in nsswitch.conf set to

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

and see if it works any better. I'll have to do that later, but I'll come back and post whether it helps or not when I have had a chance to try it. Do let me know, if there's anything additional I need to do to disable IPv6 in Avahi.

seth · 2023-03-08 07:28:50

I'm not sure what you mean by the link "bouncing."

The link is set up twice within 4 seconds, it was the only thing I saw before I had to run, but might be a NM specific glitch.

Doesn't the line in avahi-daemon.conf (use-ipv6=no, shown in my original post) disable IPv6? Is there more I need to do?

It does not seem to apply to avahi-daemon in the journal

Mar 06 21:14:06 epic6 avahi-daemon[10019]: Registering new address record for fe80::4ed1:4fe4:c9ac:a59d on enp0s25.*.
Mar 06 21:14:14 epic6 avahi-daemon[10019]: Registering new address record for 2603:8000:d500:c2a9:f31b:f3a1:c113:c569 on enp0s25.*.

If you don't use IPv6, you could test to https://wiki.archlinux.org/title/IPv6#Disable_IPv6

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

the actual wiki wrote:

However, if the DNS query above fails to return NXDOMAIN for the "local" domain, you can use the full mdns NSS module instead of mdns_minimal and create /etc/mdns.allow to allow only the "local" domain.

If you've resolution problems w/ mdns_minimal, regardless of the context check the host -t SOA reply, https://wiki.archlinux.org/title/Avahi# … om_working
But it might also have been a previous symptom of the collision?

luser · 2023-03-09 03:54:27

Still not really resolved, unfortunately. I'll explain what I have done and why it's not satisfactory.

I think we both suspect that the problem I've seen is covered by https://wiki.archlinux.org/title/Avahi# … ng_numbers. It says:

This is a known bug that is caused by a hostname race condition. One possible workaround is disabling IPv6 to attempt to prevent the race condition.

While I don't need IPv6 in my local network until I have over 4 billion devices connected (which is never going to happen), it would be nice to have it work outside the local network. The link you provided, https://wiki.archlinux.org/title/IPv6#Disable_IPv6 states

Alternatively, adding ipv6.disable_ipv6=1 instead will keep the IPv6 stack functional but will not assign IPv6 addresses to any of your network devices.

So, I tried setting the kernel parameters for all 4 machines like that. I also had to set /etc/nsswitch.conf to include the line:

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

This seems to work inside my local network. After putting a machine to sleep and waking it up, I can access it using the name epic6.local. Unfortunately, this seems to disable the ability to use IPv6 addresses outside my network. I tried pinging google's dns server using an IPv4 address, 8.8.8.8 and it worked, but when I tried to ping 2001:4860:4860:0:0:0:0:8888, the response was:

ping: connect: Network is unreachable

I don't know how close we are to running out of IPv4 addresses globally, but at some point, if not already, I will need to be able to access IPv6 addresses.

Any further thoughts???

seth · 2023-03-10 08:53:34

The main purpose was to ensure that IPv6 is the cause for the conflict.
You could try https://man.archlinux.org/man/avahi-dae … nterfaces= w/ "enp0s25.IPv4"

luser · 2023-03-11 03:28:29

I tried removing the kernel parameter, ipv6.disable_ipv6=1 and setting allow-interfaces=enp0s25.IPv4 for epic6 and made the same sort of changes for the other machines.

It seemed to work, if you just look at:

$ systemctl status avahi-daemon

● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; preset: disabled)
     Active: active (running) since Fri 2023-03-10 18:43:45 PST; 5min ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 305 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 9252)
     Memory: 1.4M
        CPU: 16ms
     CGroup: /system.slice/avahi-daemon.service
             ├─305 "avahi-daemon: running [epic6.local]"
             └─314 "avahi-daemon: chroot helper"

Mar 10 18:43:45 epic6 avahi-daemon[305]: avahi-daemon 0.8 starting up.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Successfully called chroot().
Mar 10 18:43:45 epic6 avahi-daemon[305]: Successfully dropped remaining capabilities.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Loading service file /services/sftp-ssh.service.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Loading service file /services/ssh.service.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Network interface enumeration completed.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Server startup complete. Host name is epic6.local. Local service cookie is 3090625024.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Service "epic6" (/services/ssh.service) successfully established.
Mar 10 18:43:45 epic6 avahi-daemon[305]: Service "epic6" (/services/sftp-ssh.service) successfully established.
Mar 10 18:43:45 epic6 systemd[1]: Started Avahi mDNS/DNS-SD Stack.

However, when checking from another machine, the Avahi Discovery browser didn't see the machine. Neither was I able to ping epic6.local. So, this doesn't seem to help.

Using the kernel parameter ipv6.disable_ipv6=1 on all machines and using the following line in all /etc/nsswitch.conf files works with regard to IPv4:

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

However, I cannot ping or connect to an IPv6 address outside my local network. . . so, it's not really satisfactory. I'm considering removing avahi, and just using my etc/hosts file at this point.

seth · 2023-03-11 07:41:02

I'm considering removing avahi, and just using my etc/hosts file at this point.

I'd use a local DNS (your routermodemswitch combo might actually provide that) - and actually would always do that over avahi, whether the letter works or not.

But since "allow-interfaces=enp0s25.IPv4" seems to avoid the collision, what does the system journal for that look like?
Also is there any response from avahi-browse anywhere?
https://wiki.archlinux.org/title/Avahi#Tools (don't --ignore-local)

Finally: do you get better results w/ this setup and the full mdns4 resolver instead of mdns4_minimal?

luser · 2023-03-12 03:27:13

[edited due to new information]

I thought my issues were resolved, but . . . I was able put 3 machines to sleep, to wake them up using WOL, and was still able access them without -2 being appended to the machine name. However, subsequent testing proved me wrong, so I removed "SOLVED" from the first post. I will test more thoroughly before concluding all is well.

"allow-interfaces=enp0s25.IPv4" in avahi-daemon.conf did not work for me. It was weird; the status of avahi-daemon.service looked as though it was OK on epic6, but I couldn't see epic6.local from another machine.

Here's what I am testing now:

Edit avahi-daemon.conf to:

use-ipv4=yes
use-ipv6=no

Use kernel parameter ipv6.disable_ipv6=1
Set /etc/nsswitch.conf hosts line to:

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

I have resolved the issue of being able to access IPv6 addresses outside my local network. It turned out that replacing my cable modem (my modem and router are separate components) was required to get IPv6 working correctly outside my network. Now pinging google with IPv6 produces good results:

ping -6 -c 4 google.com

PING google.com(lax17s51-in-x0e.1e100.net (2607:f8b0:4007:809::200e)) 56 data bytes
64 bytes from lax02s21-in-x0e.1e100.net (2607:f8b0:4007:809::200e): icmp_seq=1 ttl=116 time=13.7 ms
64 bytes from lax17s51-in-x0e.1e100.net (2607:f8b0:4007:809::200e): icmp_seq=2 ttl=116 time=12.6 ms
64 bytes from lax17s51-in-x0e.1e100.net (2607:f8b0:4007:809::200e): icmp_seq=3 ttl=116 time=11.4 ms
64 bytes from lax17s51-in-x0e.1e100.net (2607:f8b0:4007:809::200e): icmp_seq=4 ttl=116 time=11.9 ms

--- google.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 11.446/12.417/13.729/0.863 ms

I need to test repeatedly before concluding that my current configuration is reliable without having -2 appended to the host name. If I get another result with -2 appended, I'll post the log.

Last edited by luser (2023-03-12 05:29:19)

luser · 2023-03-12 09:02:57

With the above configuration, avahi-daemon doesn't suffer from a race condition (causing the "-2" renaming), because it isn't assigning IPv6 addresses to PCs on my network. Also, the kernel parameter "ipv6.disable_ipv6=1" keeps the IPv6 stack working but prevents it from assigning addresses to local devices. Testing IPv6 at https://test-ipv6.com/ produces a 9 out of 10 IPv6 connectivity score. The only test it missed was "Test if your ISP's DNS server uses IPv6", but so far, it doesn't seem to matter. I have google's IPv6 DN Servers entered in my router. (Oddly, if I use my ISP's IPv6 DN servers, the test results are 0 out of 10.)

I've tested 3 machines 4 times now, and every time when they wake up, they do not append "-2" to the name, so I'm marking this solved.

luser · 2023-03-17 22:59:03

OK, unfortunately, the problem is NOT resolved. I only tested for putting server machines asleep, then waking them to see if hostname-2.local was being published instead of hostname.local. I did not test by rebooting the machines. Two days later, and i have found that when booting a machine that has been fully shut down, the hostname-2.local problem is back, even when configured as I have outlined above. I have removed the prepended "SOLVED" from the first post, 'cause I am back to scratching my head over this one.

The "fixes" I applied still do seem to have resolved the issue for a sleeping machine being awakened, but not when starting from a cold boot. Even from a cold boot, things work normally about 2 out of 3 times.

Using the avahi browser does reveal when a machine has "-2" appended; it's just that I don't normally need to look before using ssh to access the machine.

Restarting the avahi-daemon always fixes the problem, but that's like closing the barn after the horses have escaped.

$ systemctl status avahi-daemon

$ systemctl status avahi-daemon
● avahi-daemon.service - Avahi mDNS/DNS-SD Stack
     Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled; preset: disabled)
     Active: active (running) since Fri 2023-03-17 20:46:31 PDT; 3min 1s ago
TriggeredBy: ● avahi-daemon.socket
   Main PID: 469 (avahi-daemon)
     Status: "avahi-daemon 0.8 starting up."
      Tasks: 2 (limit: 38068)
     Memory: 1.4M
        CPU: 51ms
     CGroup: /system.slice/avahi-daemon.service
             ├─469 "avahi-daemon: running [epic9-2.local]"
             └─478 "avahi-daemon: chroot helper"

Mar 17 20:46:40 epic9 avahi-daemon[469]: Withdrawing address record for ::1 on lo.
Mar 17 20:46:40 epic9 avahi-daemon[469]: Withdrawing address record for 127.0.0.1 on lo.
Mar 17 20:46:40 epic9 avahi-daemon[469]: Host name conflict, retrying with epic9-2
Mar 17 20:46:40 epic9 avahi-daemon[469]: Registering new address record for 2603:8000:d500:959:ac93:731c:9ebb:89f1 on eno1.*.
Mar 17 20:46:40 epic9 avahi-daemon[469]: Registering new address record for 192.168.1.93 on eno1.IPv4.
Mar 17 20:46:40 epic9 avahi-daemon[469]: Registering new address record for ::1 on lo.*.
Mar 17 20:46:40 epic9 avahi-daemon[469]: Registering new address record for 127.0.0.1 on lo.IPv4.
Mar 17 20:46:42 epic9 avahi-daemon[469]: Server startup complete. Host name is epic9-2.local. Local service cookie is 4137923506.
Mar 17 20:46:43 epic9 avahi-daemon[469]: Service "epic9-2" (/services/ssh.service) successfully established.
Mar 17 20:46:43 epic9 avahi-daemon[469]: Service "epic9-2" (/services/sftp-ssh.service) successfully established.

# journalctl -b
http://ix.io/3ZgP

Last edited by luser (2023-03-18 04:22:02)

seth · 2023-03-18 06:57:33

Mar 17 20:46:40 epic9 avahi-daemon[469]: Registering new address record for 2603:8000:d500:959:ac93:731c:9ebb:89f1 on eno1.*.

Mar 06 21:14:14 epic6 avahi-daemon[10019]: Registering new address record for 2603:8000:d500:c2a9:f31b:f3a1:c113:c569 on enp0s25.*.

The "predictable-my-ass" interface name changed, to disable this nonsense see https://wiki.archlinux.org/title/Networ … face_names

seth wrote:

since "allow-interfaces=enp0s25.IPv4" seems to avoid the collision, what does the system journal for that look like?

Edit: or "epic9" - different machine?
Still post a journal for the allow-interfaces approach.

Last edited by seth (2023-03-18 07:05:21)

luser · 2023-03-19 07:08:43

Hi, Seth,

epic6 and epic9 are two different machines. I'm running 4 total, with one acting as a client. When I last rebooted the 3 machines, epic6 didn't suffer from having "-2" appended to its name, but epic9 did. So, as you suspect, the allegedly predictable interface name didn't spontaneously change.

However, on epic9, ip a reveals that the ethernet adapter is assigned an alternate name of enp0s31f6:

 eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 54:cf:65:92:c7:38 brd ff:ff:ff:ff:ff:ff
    altname enp0s31f6

My current /etc/avahi/avahi-daemon.conf files have "allow interfaces" commented out, but allegedly control the IPv settings with:

use-ipv4=yes
use-ipv6=no

Amending avahi-daemon.conf to also include (in the case of epic9, for example:

allow-interfaces=enp0s25.IPv4, wlp2s0.IPv4

results in epic9 failing to publish the hostname.local. The other machines also produced the same result. I could include the network interfaces in the allow-interfaces section, but I could not append .IPv4 and see the names published in Avahi Discovery. Removing the .IPv4 and restarting avahi-daemon resulted in their immediate appearance in Avahi Discovery.

Restarting all machines again after removing the .IPv4 resulted in two machines publishing their hostnames correctly, but epic9 failed with the following log:
http://ix.io/4rfN

Lines that seem relevant include:

Mar 19 01:33:00 epic9 avahi-daemon[469]: Registering new address record for fe80::c2cd:461f:100a:df78 on eno1.*.

Mar 19 01:33:06 epic9 avahi-daemon[469]: Joining mDNS multicast group on interface eno1.IPv4 with address 192.168.1.93.
Mar 19 01:33:06 epic9 avahi-daemon[469]: New relevant interface eno1.IPv4 for mDNS.
Mar 19 01:33:06 epic9 avahi-daemon[469]: Registering new address record for 192.168.1.93 on eno1.IPv4.
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.1056] device (eno1): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'managed')
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.1079] device (eno1): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'managed')
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.1081] device (eno1): state change: secondaries -> activated (reason 'none', sys-iface-state: 'managed')
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.1084] manager: NetworkManager state is now CONNECTED_SITE
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.1088] device (eno1): Activation: successful, device activated.
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.1101] manager: startup complete

Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.3179] dhcp6 (eno1): activation: beginning transaction (timeout in 45 seconds)
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.3190] policy: set 'wired1' (eno1) as default for IPv6 routing and DNS
Mar 19 01:33:06 epic9 avahi-daemon[469]: Registering new address record for 2603:8000:d500:959:ac93:731c:9ebb:89f1 on eno1.*.
Mar 19 01:33:06 epic9 avahi-daemon[469]: Withdrawing address record for fe80::c2cd:461f:100a:df78 on eno1.
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.3215] dhcp6 (eno1): state changed new lease
Mar 19 01:33:06 epic9 avahi-daemon[469]: Withdrawing address record for 192.168.1.93 on eno1.
Mar 19 01:33:06 epic9 avahi-daemon[469]: Host name conflict, retrying with epic9-2
Mar 19 01:33:06 epic9 avahi-daemon[469]: Registering new address record for 2603:8000:d500:959:ac93:731c:9ebb:89f1 on eno1.*.
Mar 19 01:33:06 epic9 avahi-daemon[469]: Registering new address record for 192.168.1.93 on eno1.IPv4.
Mar 19 01:33:06 epic9 NetworkManager[520]: <info>  [1679214786.4975] manager: NetworkManager state is now CONNECTED_GLOBAL
Mar 19 01:33:07 epic9 systemd[1]: NetworkManager-dispatcher.service: Deactivated successfully.
Mar 19 01:33:08 epic9 avahi-daemon[469]: Server startup complete. Host name is epic9-2.local. Local service cookie is 3323615746.
Mar 19 01:33:09 epic9 avahi-daemon[469]: Service "epic9-2" (/services/ssh.service) successfully established.
Mar 19 01:33:09 epic9 avahi-daemon[469]: Service "epic9-2" (/services/sftp-ssh.service) successfully established.

It initially sets up sn IPv6 and an IPv4 address correctly, but then NetworkManager gets involved and then avahi-daemon registers a new IPv6 address and a new IPv4 address and withdraws the original address records, and then registers the address records again, but there's a conflict and you get the -2 appended.

I have tried disabling IPv6 using NetworkManager on the server machines, using

nmcli connection modify wired ipv6.method "disabled"
systemctl restart NetworkManager
nmcli connection up wired

and this does seem to prevent the problem.

The downside to this is that I can't use IPv6 at all. Isn't there a way to make IPv6 work outside the local network, but not cause the "-2" problem? Basically, I'd like IPv6 to work, but NOT as regards avahi-daemon. I don't need avahi-daemon to assign a hostname.local name for IPv6 addresses, but I'd like it to work for IPv4. I thought avahi-daemon.conf would allow me to configure it that way, but it doesn't seem to work as I expected, and it seems like I must disable IPv6 completely in order to avoid the "-2" naming issue. This doesn't really seem right, and the problem didn't seem to exist until about a month ago.

Last edited by luser (2023-03-21 08:53:48)

luser · 2023-03-22 01:28:59

Since I'm not aware of another solution, and no one else is offering one, I'm working around this issue by disabling my wifi adapters and disabling IPv6 on the ethernet adapters for my 3 "server" machines. On the "client" machine, I've set avahi-daemon.conf to use only the ethernet adapter.

Servers:
Disable wifi:

# nmcli radio wifi off

/etc/avahi/avahi-daemon.conf

use-ipv4=yes
use-ipv6=no
allow-interfaces= wlp2s0, enp0s31f6

Disable IPv6 on ethernet adapter:

nmcli connection modify enp0s31f6 ipv6.method "disabled"
systemctl restart NetworkManager
nmcli connection up enp0s31f6

This prevents the server machines from publishing hostname-2.local instead of hostname.local, and if I need to reach outside the local network to reach an IPv6 address, I can enable the wifi adapter which will have IPv6 functionality.

# nmcli radio wifi on

Running with wifi off and only IPv4 enabled on ethernet, the hostname-2 problem is eliminated. If I turn on wifi, I can access IPv6 addresses outside my network. Whether that results in the "-2" hostname appendage is a good question, but in limited (you can call it inadequate) testing, it hasn't happened yet. Most of the time, I won't have wifi on anyway, so these days, there could only possibly be a problem rarely, and this may effectively solve the "hostname-2" problem. Unless IPv6 (or wifi, for some other reason) proves to be required regularly, then I may never need to revisit the issue.

On the other hand, I must admit that frankly, this solution seems overly complicated. The main reason I began running avahi-daemon was so that whether I'm using wifi or alternatively ethernet, I don't need to know which IP to use for ssh; I can simply into user@hostname.local. If I wind up using IPv6 or wifi much, then I fear that the hostname-2.local problem may return. For now, I guess I'll try working with what I've got and see whether I run into any issues. If I don't see any issues for a few days, Ill mark this solved.

Last edited by luser (2023-03-22 01:41:39)

luser · 2023-03-29 09:23:09

Something has changed, and it's no longer necessary to use the kernel parameter 'ipv6.disable_ipv6=1' nor is it necessary to use nmcli to disable IPv6. I update regularly, and with over 130 apps being updated in the last 10 days, I'm not sure what was causing the issue nor what relieved it. I did keep avahi-daemon.conf settings:

use-ipv4=yes
use-ipv6=no

And nsswitch.conf set to:

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

I've tried rebooting and suspending repeatedly with no more '-2' appendage. I can reach IPv6 addresses outside my network, too.
It's not particularly surprising that an update would change things, since I didn't have the issue at all till late February or early March.

I'm marking this solved.

Arch Linux

#1 2023-03-07 06:15:48

SOLVED - avahi Host name conflict, retrying with hostname-2

#2 2023-03-07 08:39:45

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#3 2023-03-08 01:02:13

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#4 2023-03-08 07:28:50

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#5 2023-03-09 03:54:27

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#6 2023-03-10 08:53:34

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#7 2023-03-11 03:28:29

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#8 2023-03-11 07:41:02

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#9 2023-03-12 03:27:13

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#10 2023-03-12 09:02:57

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#11 2023-03-17 22:59:03

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#12 2023-03-18 06:57:33

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#13 2023-03-19 07:08:43

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#14 2023-03-22 01:28:59

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

#15 2023-03-29 09:23:09

Re: SOLVED - avahi Host name conflict, retrying with hostname-2

Board footer