Eu tenho vários NUCs pequenos com alguns desses adaptadores LAN USB3 conectados em cada um (porque os NUCs têm apenas uma Ethernet, então adicionei outros extras com adaptadores USB3).
Você pode ver uma imagem do produtoaqui.
De repente, provavelmente devido a uma atualização automática autônoma, esses dispositivos começaram a receber endereços MAC aleatórios.
Antes:
Cada dispositivo USB3 conectado tinha um endereço no formato:
00:0E:C6:XX:XX:XX
Cada um era distinto e sempre o mesmo (estável), sobrevivendo às reinicializações.
Agora eles têm endereços como:
eth1 - be:7d:ee:6a:26:ab
eth2 - be:7d:ee:6a:26:ab
eth3 - be:7d:ee:6a:26:ab
eth4 - be:7d:ee:6a:26:ab
eth5 - be:7d:ee:6a:26:ab
todos compartilhando o mesmo endereço escolhido aleatoriamente.
Em suma, problemas:
- Cada vez que a máquina é reinicializada, esse endereço MAC aleatório muda.
- Todos eles compartilham o mesmo endereço MAC aleatório. Anteriormente cada um tinha um diferente e claramente distinto.
Os dispositivos são identificados lsusbcomo:
ASIX Electronics Corp.
Não tenho ideia do que aconteceu desde a última atualização automática, é uma questão de 2 dias, 1h atrás tudo estava funcionando bem, depois que todos esses dispositivos começaram a ter esse comportamento estranho.
Poderia ser uma atualização problemática? Poderia ser lançado um novo driver que randomiza o endereço MAC a cada vez? Poderia ser um recurso do kernel Linux ou da distribuição ou configuração do GRUB, onde os dispositivos LAN USB agora obtêm endereços MAC aleatórios a cada vez? Mas neste caso, por que todos eles compartilham o mesmo? Eles deveriam ser totalmente aleatórios....
Procuro ajuda e estou disposto a fazer testes...
Em relação ao sistema operacional:
Versão Debian:12,5
Linux 6.1.0-20-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.85-1 (2024-04-11) x86_64 GNU/Linux
Soluções alternativas sugeridas até agora, incluindo a final sempre funcionando graças ao @AB:
- Use o atributo parrent "serial" na configuração UDEV para atribuir outro nome à interface lan em vez de depender do endereço mac
- 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
- Como redefinir o status de um adaptador de rede antes de atribuir o nome em um conjunto de regras do udev?
Responder1
EsseConfirmação do kernel 6.8, portado para 6.1.x:
net: usb: ax88179_178a: evite duas reinicializações consecutivas do dispositivo
destinado a evitar uma redefinição dupla na NIC baseada em AX88179 teve como efeito colateral obter um endereço MAC aleatório para a NIC.
Há uma correção em andamento para o futuro kernel 6.9,já portado para o kernel 6.1.85+que reconhece a questão anterior (e ésupostopara fixar isso). Aqui está a parte do reconhecimento:
net: usb: ax88179_178a: evite a interface sempre configurada como endereço aleatório
Após o commit d2689b6a86b9 ("net: usb: ax88179_178a: evite duas redefinições consecutivas do dispositivo"), a redefinição não é executada a partir da operação de ligação e o endereço MAC não é lido nos registros do dispositivo ou na árvore de dispositivos naquele momento. Como a verificação para configurar se o endereço MAC atribuído é aleatório ou não para a interface, acontece após a operação de bind de usbnet_probe, a interface continua configurada como endereço aleatório, embora o endereço seja lido e definido corretamente durante a operação aberta (o único reset agora ).
O problema é que o kernel 6.1.0-20-amd64 do Debian já usa o kernel upstream 6.1.85 que inclui a correção. Pelo comentário do OP, isso não parece funcionar corretamente, pois o OPéusando kernel 6.1.0-20-amd64.
O que é garantido que funcionará é reverter para o estado anterior: antes do backport do patch para 6.1.x em 05/02/2024. Parece que atualmente isso significa reverter DOIS patches:
- net: usb: ax88179_178a: evite a interface sempre configurada como endereço aleatório
- net: usb: ax88179_178a: evite duas reinicializações consecutivas do dispositivo
para ter a garantia de fazê-lo funcionar como antes (e recuperar o comportamento de reinicialização dupla, o que não parecia ser um problema).
Pude verificar nas últimas semanas que reverternet: usb: ax88179_178a: evite duas reinicializações consecutivas do dispositivofez funcionar, não verifiquei como o estado mais recente (por exemplo: kernel 6.1.85 ou Debian 6.1.0-20-AMD64) se comporta. As perguntas e respostas do OP sugerem que talvez o segundo patch destinado a corrigir o comportamento causado após o primeiro patch não seja suficiente e possivelmente ainda outra correção deva ser fornecida.
Para resumir, opções possíveis hoje:
- manter um kernel mais antigo, como o 6.1.0-18-amd64 do Debian, disponível emhttps://snapshot.debian.org/ lá:
linux-image-6.1.0-18-amd64 - corrigir um kernel entre 6.1.77 e 6.1.84 revertendo o primeiro patch mencionado nesta resposta e recompilar (testado funcionando)
- verifique se um kernel 6.1.85 ou mais recente funciona para você como está.
ou funciona (nada mais a fazer)
ou não (caso do OP)
reverta pelo menos o primeiro patch e recompile:
net: usb: ax88179_178a: evite a interface sempre configurada como endereço aleatório(opcional, pode ser mantido em vez de revertido)
net: usb: ax88179_178a: evite duas reinicializações consecutivas do dispositivo: (é necessário reverter este)
ou espere um patch futuro corrigindo isso:
ATUALIZAR: este commit de 18/04/2024:
net: usb: ax88179_178a: evite escrever o endereço mac antes da primeira leitura
corrige (eu testei em um kernel 6.8.x). Provavelmente deverá ser incluído no próximo kernel upstream 6.1.x 6.1.88, e será escolhido mais cedo ou mais tarde pelo Debian. Bônus adicional: a redefinição parece ser feita no momento da sonda e não mais na interface UP. Portanto, o atraso nas transições entre baixo e cima agora é mais rápido.