☰

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

tag-icon • tag-icon debian network-interface udev usb-device
Como redefinir o status de um adaptador de rede antes de atribuir o nome em um conjunto de regras do udev?

Parte 4 do problema com as interfaces nic usb3 após a atualização do kernel debian 6.1.0-20.

Veja as outras postagens aqui:

Abstrato: Uma atualização recente do debian com kernel 6.1.0-20 quebrou o reconhecimento do endereço mac armazenado dentro das EEPROMs usb-lan nics para que todas as regras do udev escritas anteriormente com oATTR{endereço}(alterar o nome da interface com base no endereço MAC) não funciona mais.

Agora, por que esta postagem:

  • usando oATTRS{série}funcionou, mas tenho 3 de 6 adaptadores que compartilham o mesmo atributo "serial", portanto, não é possível determinar qual é qual.
  • Eu tentei neste momento usar o USBATTRS{número do ônibus}eATTRS{número de desenvolvimento}para identificar especificamente as 3 interfaces restantes, no entanto, parece que esses valores não são estáveis ​​e mudam de tempos em tempos, removendo a corrente CA da rede elétrica e colocando-a de volta.

Portanto, nenhuma das soluções acima realmente resolveu o problema final.

No entanto, parece que se você colocar para baixo e para cima (ou talvez apenas para cima), o eth fará interface com comandos como:

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

eth0, também conhecido como adaptador lan usb3, lê o endereço MAC correto armazenado na EEPROM ...

Neste ponto, minha única ideia é:

  • Posso desativar/ativar todas as interfaces para que elas obtenham o endereço MAC correto e faça o udev reaplicar as regras novamente ou é apenas uma coisa que acontece uma vez no momento da inicialização? Caso seja possível, você pode me ajudar a escrever um script que seja capaz de colocar down -> up eth de 0 a 10 e depois recuperar o udev para que as interfaces possam ser renomeadas.

ou...

  • Ser capaz de atualizar/ativar os ETHs antes do momento principal em que o udev é chamado, quando as interfaces já recuperaram seu endereço MAC original e neste caso o udev deve fazer seu trabalho.

A solução com RUN+= que você sugeriu da última vez @AB está relacionada a isso?

Responder1

Descrição

Para corrigir o estado atual, seguindo a ideia do OP, fiz um únicoudevregra 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 comoGerente da rede), 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 seeudevse comporta da mesma forma quesistemadeudevao desencadear 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

informação relacionada