Until some days ago, my Kubuntu 20.04 system could resolve .local device names on my local network without problems, as other Linux systems still do (on the same network).
However, all of a sudden this stopped to work. If I type ping otherpc.local
(being otherpc
the name of another system in my local network) I get otherpc.local: name or service unknown
. Samba connections, mount points, etc. all stopped working, of course, because of this reason.
avahi-browse -arvt
shows no device at all.
I read around some hints about trying to mess with /etc/nsswitch.conf
and/or /etc/systemd/resolved.conf
(like this one or this one), but what I can't explain is that I never touched those files after performing a clean install of Kubuntu 20.04, yet this problem started to happen all of a sudden.
I suspect it could have been caused by some recent system update, but I'm not skilled enough to try to determine which one exactly caused this.
ADDITIONAL INFORMATION
While trying to diagnose the problems, I determined that:
- restoring a previous system snapshot with Timeshift does NOT solve the problem; this is totally unexpected, because I have clues that this worked fine on 2021-12-07, yet restoring a snapshot of that day (or of the previous day) does not fix the problem
- I've determined that the problem occurs ONLY when I'm connecting with a specific ethernet interface
In particular, with regards to the last point:
- if I use my laptop wireless card, .local names are resolved
- if I use my laptop ethernet card, .local names are resolved
- if I use the ethernet interface of the USB docking station I usually use to connect all my devices (including mouse, keyboard, display, etc.), .local names are NOT resolved
So it seems like there's a problem with that docking station network interface. However, this worked until some days ago and I didn't change anything related to this docking station (driver or such). Even the USB port I use is always the same.
This network interface is identified as enx0050b6166946 and I also see this in syslog:
Dec 20 19:01:29 hppb avahi-daemon[1378]: Joining mDNS multicast group on interface enx0050b6166946.IPv6 with address fe80::26ab:82a1:62ce:734e.
Dec 20 19:01:29 hppb avahi-daemon[1378]: New relevant interface enx0050b6166946.IPv6 for mDNS.
Dec 20 19:01:29 hppb avahi-daemon[1378]: Registering new address record for fe80::26ab:82a1:62ce:734e on enx0050b6166946.*.
[...]
Dec 20 19:01:31 hppb avahi-daemon[1378]: Joining mDNS multicast group on interface enx0050b6166946.IPv4 with address 192.168.1.4.
[...]
So, it seems like avahi is correctly "registering" on this interface as well, both for IPv6 and IPv4.
Any idea?