☰

¿Cómo restablecer el estado de un adaptador de red antes de asignar el nombre en un conjunto de reglas udev?

tag-icon • tag-icon debian network-interface udev usb-device
¿Cómo restablecer el estado de un adaptador de red antes de asignar el nombre en un conjunto de reglas udev?

Parte 4 del problema con las interfaces NIC USB3 después de la actualización del kernel de Debian 6.1.0-20.

Vea las otras publicaciones aquí:

Abstracto: Una actualización reciente de Debian con el kernel 6.1.0-20 rompió el reconocimiento de la dirección mac almacenada dentro de las EEPROM de la NIC USB-LAN, por lo que todas las reglas de udev escritas anteriormente con elATR{dirección}(cambiar el nombre de la interfaz según la dirección mac) ya no funciona.

Ahora por qué esta publicación:

  • utilizando elATTRS{serie}Funcionó, pero tengo 3 adaptadores de 6 que comparten el mismo atributo "serie", por lo que no es posible determinar cuál es cuál.
  • Intenté en este punto usar los USB.ATTRS{busnum}yATTRS{devnum}para identificar específicamente las 3 interfaces restantes, sin embargo, parece que estos valores no son estables y cambian de vez en cuando al quitar la corriente alterna de la red eléctrica y volver a colocarla.

Entonces, ninguna de las soluciones anteriores resolvió el problema final.

Sin embargo, parece que si baja y sube (o tal vez solo hacia arriba), eth interactúa con comandos como:

ip link set dev eth0 down
ip link set dev eth0 up

eth0, también conocido como el adaptador lan usb3, vuelve a leer la dirección mac correcta almacenada en la EEPROM...

En este punto mi única idea es:

  • ¿Puedo desactivar o activar todas las interfaces para que obtengan la dirección mac correcta y hacer que udev vuelva a aplicar las reglas o es solo algo que sucede una vez en el momento del arranque? En caso de que sea posible, ¿pueden ayudarme a escribir un script que pueda colocar -> subir eth de 0 a 10 y luego recuperar udev para poder cambiar el nombre de las interfaces?

o...

  • Ser capaz de actualizar los ETH hacia abajo/arriba antes del momento principal en que se llama a udev, cuando las interfaces ya recuperaron su dirección mac original y, en este caso, udev debería hacer su trabajo.

¿La solución con RUN+= que sugeriste la última vez @AB está relacionada con esto?

Respuesta1

Descripción

Para arreglar el estado actual, siguiendo la idea de OP, hice un soloudevregla que:

  • sólo cuando se cumplan todas estas condiciones:

    • agregando
    • un dispositivo de red
    • con conductorax88179_178a
    • creado con una dirección MAC aleatoria ( addr_assign_type=1)

  • voluntad:

    • configure la interfaz ARRIBA (haciendo así que el controlador recupere la propiedad de dirección MAC permanente)

    • Vuelva a configurarlo ABAJO (ese es el estado esperado de una interfaz recién agregada)

    • Si se confirma que la interfaz ahora ha recuperado su dirección MAC permanente ( addr_assign_type=0), vuelva a activar una adición de la interfaz.

      ... desencadenando así una nueva ronda con el cambio de nombre apropiado de la interfaz. (por ejemplo: cuando nada más indica lo contrario, normalmente las interfaces de red USB cambian de nombre a partir de su dirección MAC como enx...)

Regla y activación

Cree una regla con una prioridad suficientemente baja (elegí 40)

/etc/udev/rules.d/40-local-net-ax88179_178a.rules:

ACTION=="add", SUBSYSTEM=="net", ATTR{addr_assign_type}=="1", DRIVERS=="ax88179_178a", \
  RUN="/bin/ip link set %k up", RUN+="/bin/ip link set %k down", \
  RUN+="/bin/udevadm trigger -s net -a addr_assign_type=0 -p INTERFACE=%k -c add"

Luego, solo la primera vez (del efecto más intenso al más ligero):

  • reiniciar

  • o reiniciar udev:

    systemctl restart udev

    • y desconecte/reconecte los dispositivos USB

    • o recargar el controlador

      rmmod ax88179_178a
modprobe ax88179_178a

    • o activar artificialmente la nueva regla solo en interfaces que necesitan una solución

      udevadm trigger -v -s net -p ID_NET_DRIVER=ax88179_178a -a addr_assign_type=1 -c add

      Si la interfaz ya fue activada (por ejemplo: mediante una herramienta de red comoGerente de Redes), es posible que sea necesario no verificar su tipo de dirección MAC y hacer simplemente:

      udevadm trigger -v -s net -p ID_NET_DRIVER=ax88179_178a -c add

Notas adicionales

  • Al final, esto tendrá la misma cantidad de reinicios del dispositivo que antes del parche, evitando que se produzca dicho reinicio del dispositivo: dos, porque la interfaz obtiene un ARRIBA (luego ABAJO) adicional que activa dicho reinicio.

    Por lo tanto, al compilar un kernel de todos modos, revertir el parche es aún más sencillo. Cuando uno necesita SecureBoot y no puede firmar el módulo del kernel resultante, esta solución es útil.

    Aún sería bienvenido un tercer parche de controlador real.

  • Comandos EJECUTAR

    • Se DEBE utilizar el primer comando RUN.

    • El segundo comando RUN DEBE usarse para tener el mismo resultado que cuando se ejecuta con un controlador de kernel que maneja la NIC correctamente: una interfaz agregada en estado ABAJO. Se podría considerar no configurarlo ABAJO y dejarlo ARRIBA, evitando reiniciar un dispositivo, si las herramientas de red posteriores pueden hacer frente a eso.

    • Es posible que se omita el último comando EJECUTAR: es posible que no sea necesario si una herramienta de red posterior ya cambió el nombre de la interfaz y se basó únicamente en la dirección MAC.

      • el bucle no sucederá porque:

        • si la interfaz obtuvo la dirección MAC permanente: ninguna acción
        • Si la interfaz, una vez activada y luego desactivada, todavía no obtuvo la dirección MAC permanente (es decir, la solución alternativa no funcionó), entonces la addacción no se realizará (porque está restringida a un dispositivo con dirección MAC permanente), dejar el dispositivo con una dirección MAC aleatoria

  • Otras distribuciones además de Debian

    • Asegúrese de /bin/ipque exista o reemplácela con una ruta correcta (por ejemplo /sbin/ip:)

    • eudev(Devuan, Gentoo...): No sé sieudevse comporta igual quesistemad'sudeval desencadenar un evento desde dentro. La tercera carrera podría necesitar un cambio.

  • Si por alguna razón es necesario agregar condiciones adicionales, ya que las ...Svariantes coincidentes (para una propiedad principal) deben ser todas parte del mismo padre, DRIVERS=="ax88179_178a"podrían reemplazarse por ATTRS{product}=="AX88179"para obtener un efecto similar si es necesario (y si el dispositivo USB específico realmente coincide esta propiedad) para alcanzar propiedades útiles alternativas de otro padre (como ATTRS{serial}).

  • Al menos también addr_assign_type=3parece significar que la dirección MAC se ha cambiado (manualmente o de otro modo, por ejemplo: configurando la interfaz como esclava de enlace). Esta regla no afectará a este caso (ni debería afectarlo ni afectaría este caso)

  • documentación utilizada

información relacionada