INFORMACIÓN ADICIONAL

INFORMACIÓN ADICIONAL

Hasta hace unos días, mi sistema Kubuntu 20.04 podía resolver nombres de dispositivos .local en mi red local sin problemas, como todavía lo hacen otros sistemas Linux (en la misma red).

Sin embargo, de repente esto dejó de funcionar. Si escribo ping otherpc.local(siendo otherpcel nombre de otro sistema en mi red local) obtengo otherpc.local: name or service unknown. Las conexiones Samba, los puntos de montaje, etc. dejaron de funcionar, por supuesto, por esta razón.

avahi-browse -arvtno muestra ningún dispositivo.

Leí por ahí algunos consejos sobre cómo tratar de meterse con /etc/nsswitch.confy/o /etc/systemd/resolved.conf(comoÉsteoÉste), pero lo que no puedo explicar es que nunca toqué esos archivos después de realizar una instalación limpia de Kubuntu 20.04, sin embargo, este problema comenzó a ocurrir de repente.

Sospecho que podría haber sido causado por alguna actualización reciente del sistema, pero no tengo la habilidad suficiente para tratar de determinar cuál causó exactamente esto.

INFORMACIÓN ADICIONAL

Mientras intentaba diagnosticar los problemas, determiné que:

  • restaurar una instantánea anterior del sistema con Timeshift NO resuelve el problema; Esto es totalmente inesperado, porque tengo pistas de que funcionó bien el 7 de diciembre de 2021, pero restaurar una instantánea de ese día (o del día anterior) no soluciona el problema.
  • He determinado que el problema ocurre SÓLO cuando me conecto con una interfaz Ethernet específica.

En particular, con respecto al último punto:

  • si uso la tarjeta inalámbrica de mi computadora portátil, los nombres .locales se resuelven
  • si uso la tarjeta ethernet de mi computadora portátil, los nombres .local se resuelven
  • Si uso la interfaz Ethernet de la estación de acoplamiento USB que normalmente uso para conectar todos mis dispositivos (incluido el mouse, el teclado, la pantalla, etc.), los nombres .local NO se resuelven.

Parece que hay un problema con la interfaz de red de la estación de acoplamiento. Sin embargo, esto funcionó hasta hace unos días y no cambié nada relacionado con esta estación de acoplamiento (controlador o similar). Incluso el puerto USB que uso es siempre el mismo. Esta interfaz de red se identifica como enx0050b6166946 y también veo esto en 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.
[...]

Entonces, parece que avahi también se está "registrando" correctamente en esta interfaz, tanto para IPv6 como para IPv4.

¿Alguna idea?

Respuesta1

Resultó que se trataba de algún tipo de falla temporal de hardware en mi estación de acoplamiento. Por cierto, es una estación de acoplamiento USB 3.0 i-tec, con un chipset DisplayLink DL-3900.

Desconectar la estación de acoplamiento del tomacorriente de CA y volver a enchufarla solucionó el problema. Esto explica por qué una restauración del sistema con Timeshift no resolvió el problema, confirmando que nada había cambiado en mi sistema. Probablemente se debió a un par de apagones que ocurrieron durante las últimas semanas, uno de los cuales probablemente arruinó temporalmente algo en el comportamiento de funcionamiento de la estación de acoplamiento.

Sin embargo, es un problema realmente extraño, que nunca ha ocurrido hasta ahora durante varios años de uso: aparte de este problema con mDNS, la red funcionaba bien, así como todos los puertos USB de la estación de acoplamiento o incluso la función de vídeo USB a HDMI.

información relacionada