Padrão de convenção de nomenclatura para interfaces Ethernet e Wi-Fi em máquinas Linux

Question

Qual é o padrão de convenção de nomenclatura para interfaces Ethernet e Wi-Fi em uma máquina Linux?

Estamos desenvolvendo uma ferramenta que deve mostrar apenas as interfaces Ethernet e Wi-Fi da máquina Linux e seu status atual.

Por exemplo, abaixo está a lista de interfaces de rede (físicas e virtuais) na minha máquina Linux (Ubuntu):

docker0 , enp0s25 , lo , wlp3s0

Quando eu executo a ferramenta, abaixo está o resultado:

enp0s25 , wlp3s0

Escrevemos o código com a lógica de que todas as interfaces Ethernet sempre começam com a letra e e as interfaces Wi-Fi sempre começam com a letra w .

A lógica está correta? Se não, como podemos resolver isso?

    

Answer 1

As interfaces de rede podem receber qualquer nome, portanto, não importa o que você faça, você encontrará situações em que (1) há uma interface de rede "física" com um nome que não corresponde ao seu padrão ou (2) existe uma interface de rede "física" que corresponde ao seu padrão.

Além disso, se eu fosse um usuário de sua ferramenta, no momento em que sua ferramenta não permitiria que eu fizesse algo que eu quisesse, porque eu tenho uma interface de rede que é "virtual", embora para fins práticos ela deva ser considerado "físico" na minha configuração, eu começaria a xingar em voz alta e com força em seu aplicativo e nunca mais o usaria novamente.

Todas as interfaces de rede físicas e virtuais compartilham uma API comum, o que torna o Linux realmente flexível. Por favor, não tente babysit seu usuário, e tirar isso dele ou dela. Seus usuários agradecerão.

    

Answer 2

Para nomes de interface previsíveis , os prefixos podem ser vistos em udev-builtin-net_id.c :

* Two character prefixes based on the type of interface:
*   en — Ethernet
*   ib — InfiniBand
*   sl — serial line IP (slip)
*   wl — wlan
*   ww — wwan

Assim, para o estilo tradicional ethX de nomeação e a nomenclatura mais recente do systemd, uma letra inicial e deve ser uma interface ethernet para quaisquer nomes de interface gerados automaticamente. Todas as interfaces wifi devem começar com um w em ambos os esquemas, embora nem todas as interfaces que começam com w sejam wifi.

Se essa ferramenta tiver que funcionar em um ambiente arbitrário (em vez de apenas em ambientes internos que você controla), observe que os usuários podem renomear interfaces em sistemas linux com nomes arbitrários, como [ wan0 , lan0 , lan1 , dmz0 ] que irá quebrar quaisquer suposições sobre letras iniciais.

    

Answer 3

A convenção de nomenclatura é que as interfaces LAN são nomeadas eth0 , eth1 , ... e que as interfaces WLAN são nomeadas wlan0 , wlan1 , ...

O que você vê são os chamados "nomes previsíveis" introduzidos pelo sistema. Na prática, eles são tudo menos previsíveis e podem até mudar quando o hardware é alterado, que é exatamente o problema que eles devem evitar.

Para um palpite, a letra inicial pode ser boa o suficiente. Algumas interfaces, em especial a WLAN, possuem dicas em /sys/class/net/*/uevent :

DEVTYPE=wlan

Infelizmente, não existe DEVTYPE para interfaces LAN.

    

Answer 4

Uma ressalva com minha resposta (também se aplica à maioria dos outros): não sei o propósito da sua inscrição. Se for um aplicativo descartável para solucionar um problema específico ou para entender melhor a rede, para nunca mais ser usado novamente, confiar na primeira letra da interface pode ser uma ótima opção rápida e suja. Se você está planejando escrever o próximo concorrente para o Wireshark ou o tcpdump, você precisa ter certeza de que está certo para todos os tipos de casos extremos.

E se o aplicativo que você está escrevendo estiver em algum ponto entre esses extremos, somente você (e seus clientes) poderão saber com que cuidado você precisa implementar sua lógica.

Outros já apontaram que os nomes nunca são confiáveis, por vários motivos. O problema final é muito comum no software: suposições de codificação em vez de confiar em fatos conhecidos / documentados.

A segunda questão que não foi mencionada também se baseia em uma suposição sobre seus requisitos: que a lista de interfaces que você deseja listar seja sempre exatamente "interfaces ethernet de hardware" e "interfaces wifi".

A terceira questão é outra suposição: que toda a interface se enquadra nas categorias que você pode imaginar agora. Como cerca de Infiniband, como mencionado por @ user4556274? Como sobre interfaces de túnel para uma VPN? Como sobre interfaces em ponte? Que tal interfaces em ponte que combinam interfaces físicas e lógicas?

Mas pode haver opções para realizar o que você está procurando. Primeiro, defina exatamente o que caracteriza uma interface que você deseja listar, em vez de uma que você não deseja.

Na maioria dos casos, uma característica na qual você pode confiar é a tabela de roteamento (no entanto, isso só funcionará enquanto a interface estiver ativa, então pode não ser o que você está realmente procurando).

Qualquer interface que tenha uma rota padrão (ou seja, uma rota para 0.0.0.0) provavelmente será a que você está procurando.

Observe que mesmo isso ainda é baseado em uma suposição, apenas mais confiável: é concebível que um sistema seja configurado para rotear todo o tráfego de saída através de uma máquina virtual ou de um contêiner docker (por exemplo, se houver um contêiner executando um firewall). E o contrário também é verdadeiro: um sysadmin poderia bloquear o tráfego externo excluindo a rota padrão.

Outra opção é ir pelo hardware real e ver qual driver ele usa. Você pode então excluir certos drivers conhecidos

    

Answer 5

Você exclui explicitamente as interfaces associadas ou agrupadas? Nosso padrão aqui é usar bond0 ou team0 para a interface principal de nossos servidores.

Eu acho que você precisa repensar sua lógica. Talvez tente iterar todas as interfaces de rede definidas em um determinado sistema, divida-as entre ethernet, wifi, infiband, serial, etc., e faça sua mágica.

    

Answer 6

Não codifique ou padronize os nomes de hardware. Isso se aplica a todos os dispositivos. Confie nas ferramentas fornecidas pelo udev para determinar a lista de dispositivos e tomar as medidas adequadas. Consulte 16.7 Nomenclatura de dispositivo persistente e depois leia o documento inteiro , especificamente 16.2 e 16.3. Note que o udev é independente da distribuição, e também é independente do sistema init, já que o udev é agora o método preferido para o gerenciamento de dispositivos no linux.

Observe que @ user4556274, aludiu a isso em sua resposta quando se referiu a udev-builtin-net-id.c , o que, em suma, significa que a correspondência de padrões que você está tentando realizar é uma parte interna de udev .

Citando PredictableNetworkInterfaceNames :

With systemd 197 we have added native support for a number of different naming policies into systemd/udevd proper and made a scheme similar to biosdevname's (but generally more powerful, and closer to kernel-internal device identification schemes) the default. The following different naming schemes for network interfaces are now supported by udev natively:

1. Names incorporating Firmware/BIOS provided index numbers for on-board devices (example: eno1)
2. Names incorporating Firmware/BIOS provided PCI Express hotplug slot index numbers (example: ens1)
3. Names incorporating physical/geographical location of the connector of the hardware (example: enp2s0)
4. Names incorporating the interfaces's MAC address (example: enx78e7d1ea46da) Classic, unpredictable kernel-native ethX naming (example: eth0)

By default, systemd v197 will now name interfaces following policy 1) if that information from the firmware is applicable and available, falling back to 2) if that information from the firmware is applicable and available, falling back to 3) if applicable, falling back to 5) in all other cases. Policy 4) is not used by default, but is available if the user chooses so.

This combined policy is only applied as last resort. That means, if the system has biosdevname installed, it will take precedence. If the user has added udev rules which change the name of the kernel devices these will take precedence too. Also, any distribution specific naming schemes generally take precedence.

    

Answer 7

Como outros já disseram, você não pode depender totalmente do nome.

No meu caso, parece que, para o wireless /sys/class/net/<ifacename>/ , haverá um diretório chamado "wireless" se for uma interface sem fio:

# kbrandt @ kbrandtlx in /sys/class/net [9:47:43] C:130
$ ls
br-b293588ecdae  enp11s0  lo    veth6061cd8  virbr0-nic
docker0          enp12s0  ppp0  virbr0       wlp13s0

# kbrandt @ kbrandtlx in /sys/class/net [9:47:44] 
$ echo  /sys/class/net/*/wireless
/sys/class/net/wlp13s0/wireless