Como redefinir o status de um adaptador de rede antes de atribuir o nome em um conjunto de regras do udev?

Descrição

Para corrigir o estado atual, seguindo a ideia do OP, criei uma única regra do udev que:

• somente quando todas essas condições forem atendidas:

  • adicionando
  • um dispositivo de rede
  • com motoristaax88179_178a
  • criado com um endereço MAC aleatório ( addr_assign_type=1)

• vai:

  • configure a interface para cima (fazendo com que o driver recupere a propriedade do endereço MAC permanente)

  • coloque-o novamente em DOWN (esse é o estado esperado de uma interface recém-adicionada)

  • se for confirmado que a interface recuperou seu endereço MAC permanente ( addr_assign_type=0), acione novamente uma adição da interface

    ... desencadeando assim uma nova rodada com a renomeação apropriada da interface. (por exemplo: quando nada mais diz o contrário, geralmente as interfaces de rede USB são renomeadas a partir de seu endereço MAC como enx...)

Regra e ativação

Crie uma regra com prioridade baixa o suficiente (escolhi 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"

Então, apenas na primeira vez (do efeito mais pesado para o mais leve):

• reinício

• ou reinicie udev:

  systemctl restart udev
  

  • e desconecte/reconecte dispositivos USB

  • ou recarregar o driver

    rmmod ax88179_178a
    modprobe ax88179_178a
    

  • ou acionar artificialmente a nova regra apenas em interfaces que precisam de correção

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

    Se a interface já foi ativada (por exemplo: por uma ferramenta de rede como NetworkManager ), pode ser necessário não verificar o tipo de endereço MAC e fazer apenas:

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

Notas Adicionais

• isso terá no final o mesmo número de reinicializações de dispositivos que antes do patch, evitando que tal redefinição de dispositivo aconteça: dois, porque a interface recebe um UP (depois DOWN) adicional que aciona tal redefinição.

  Assim, ao compilar um kernel de qualquer maneira, reverter o patch ainda é mais simples. Quando alguém precisa do SecureBoot e não consegue assinar o módulo do kernel resultante, esta solução alternativa é útil.

  Um terceiro patch de driver real ainda seria bem-vindo.

• Comandos de EXECUÇÃO

  • O primeiro comando RUN DEVE ser usado.

  • O segundo comando RUN DEVE ser usado para ter o mesmo resultado de quando executado com um driver de kernel que lida com a NIC corretamente: uma interface adicionada no estado DOWN. Pode-se considerar não configurá-lo e deixá-lo ATIVADO, poupando a reinicialização de um dispositivo, se ferramentas de rede posteriores puderem lidar com isso

  • O último comando RUN PODE ser ignorado: pode não ser necessário se a interface já tiver sido renomeada por uma ferramenta de rede posterior que dependa apenas do endereço MAC.

    • loop não acontecerá porque:

      • se a interface obteve o endereço MAC permanente: nenhuma ação
      • se a interface, uma vez ativada e desativada, ainda não obteve o endereço MAC permanente (ou seja: a solução alternativa não funcionou), a addação não será executada (porque está restrita a um dispositivo com endereço MAC permanente), deixando o dispositivo com um endereço MAC aleatório

• Outras distribuições além do Debian

  • Certifique-se /bin/ipde que existe ou substitua-o por um caminho correto (por exemplo /sbin/ip:)

  • eudev (Devuan, Gentoo ...): Não sei se o eudev se comporta da mesma forma que o udev do systemd ao disparar um evento de dentro. A 3ª RUN pode precisar de uma mudança.

• Se por algum motivo condições adicionais tiverem que ser adicionadas, já que as ...Svariantes de correspondência (para uma propriedade pai) devem ser todas parte do mesmo pai, DRIVERS=="ax88179_178a"poderão ser substituídas por ATTRS{product}=="AX88179"para um efeito semelhante, se necessário (e se o dispositivo USB específico realmente corresponder esta propriedade) para alcançar propriedades úteis alternativas de outro pai (como ATTRS{serial}).

• Pelo menos também addr_assign_type=3parece significar que o endereço MAC foi alterado (manualmente ou não, por exemplo: definindo a interface como escravo de ligação). Esta regra não tocará nisso (nem deveria, nem encontraria este caso)

• documentação usada

  • udev(7)
  • udevadm(8)
  • arquivos /lib/udev/rules.d/como exemplos