Dado este problema de 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 da recompilação personalizada do kernel com um patch ou usar 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 udev 70-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 dizendo olhando para o dispositivo ... mas depois diz olhando 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
Parece que encontrei uma resposta para isso nesta postagem: 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 de pai único com o nível real usando ATTRS , usando ATTRS{serial} em vez de ATTR{address} e usando o serial fornecido por udevadm info -a -p /sys/class/net/eth1 do o emprego.
Exemplo:
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 isso na 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