Dado este problema do kernel aguardando para ser corrigido e que atribui aleatoriamente o endereço MAC a estes adaptadores lan usb3:Debian 12 - De repente, meu adaptador Lan USB3 recebe um endereço MAC aleatório a cada reinicialização
Estou tentando encontrar uma solução alternativa além do personalizadorecompilando o kernel com um patchouuse uma versão antiga do kernel.
Basicamente toda a configuração das minhas interfaces é baseada em nomes personalizados obtidos usando um arquivo de configuração do udev70-persistent-net.rules(certas interfaces são renomeadas com base em seu endereço MAC, mas devido ao bug acima, isso não funciona mais).
Observando a sintaxe dos arquivos udev/etc/udev/rules.d/70-persistent-net.rules
Minha conf tem várias linhas como:
SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{address}="00:....", ATTR{dev_id}="0x0", ATTR{type}="1", KERNEL="eth*", NAME="lan1"
Agora o que descobri chamando o comando:
informações do udevadm -a -p /sys/class/net/eth1
e o mesmo com eth2, eth3, eth4, eth5...
é que existe um ATTR interessante para identificar de forma única as interfaces.
É um atributo chamado "serial", mas não está disponível para eth1, eth2... mas para seu desenvolvedor pai direto.
Na verdade, o comando começa dizendoolhando para o dispositivo...mas depois que dizolhando para o dispositivo pai...
Então, estou me perguntando se posso fazer algo como:
SUBSYSTEM="net", ACTION="add", DRIVERS="?*", ATTR{parent>serial}="00000003", ATTR{dev_id}="0x0", ATTR{type}="1", KERNEL="eth*", NAME="lan1"
usando o serial pai em vez de basear a configuração no endereço MAC para renomear a interface LAN.
Existe uma sintaxe como esta?
Obrigado
Responder1
Parece que encontrei uma resposta para isso neste post:Como os dispositivos USB são diferenciados de maneira única?
Lendo esta referência:https://www.reactivated.net/writing_udev_rules.html
Parece que você pode misturar os pais solteiros com o nível real usandoATTRS, então usandoATTRS{série}em vez deATTR{endereço}e usando o serial fornecido porinformações do udevadm -a -p /sys/class/net/eth1faça o trabalho.
Exemplo:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTRS{serial}=="00000000000094", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="lan1"
Então, voltei a usar o kernel Linux mais recente enquanto esperava que os desenvolvedores debian colocassem o patch no canal upstream para que o mac no eeprom pudesse ser lido. Uma solução alternativa por enquanto, mas sólida.
A única parte divertida é que se os dispositivos não tiverem cabos conectados, tanto lan1 quanto eth0 estarão presentes no meu caso, lan1 ativo e "estranhamente" obtendo o endereço mac correto e o eth0 ainda desativado com o endereço mac aleatório.
EDIT: Isso funcionou até descobrir que alguns dispositivos compartilham a mesma série ¯_(ツ)_/¯ então comecei a usar diretamente o número do barramento raiz usb e o número do dispositivo para identificar exclusivamente os adaptadores, visto que sempre os deixo no lugar sem movê-los. Verifique para isso a pergunta:Use o caminho usb de um endereço nic usb nas regras do udev para atribuir um nome de interface em vez do endereço mac