Score:1

Kubuntu 20.04 not resolving .local names any more all of a sudden

br flag

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?

user.dz avatar
ng flag
Could you edit the question and add contents of `/etc/nsswitch.conf` . Do you use IPv6 or IPv4 in local subnet? The you have 2 or more net interfaces active? How about `ping <ip>` without hostname, does it work (firewall, may be)? Could you make a look on [these avahi debug hints](https://askubuntu.com/q/460371/26246).
Mauro Molinari avatar
br flag
Thanks @user.dz, but it seems like it was some kind of hardware fault, though. Unplugging and re-plugging the docking station from the AC outlet fixed the problem. Really strange, it's the first time it ever happened since years.
Score:1
br flag

It turned out it was some kind of temporary hardware failure on my docking station. By the way, it's an i-tec USB 3.0 Docking Station, featuring a DisplayLink DL-3900 chipset.

Unplugging the docking station from the AC outlet and plugging it back in fixed the problem. This explains why a system restore with Timeshift did not solve the problem, confirming that nothing had changed on my system. It was probably due to a couple of blackouts that occurred during the last weeks, one of which probably temporarily screwed up something in the docking station running behaviour.

Nevertheless, it's a really strange problem, never happened so far during several years of use: apart from this problem with mDNS, networking was working fine, as well as all the docking station USB ports or even the USB-to-HDMI video feature.

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.