Norma de convención de nomenclatura para interfaces Ethernet y Wi-Fi en máquinas Linux

¿Cuál es el estándar de la convención de nomenclatura para interfaces Ethernet y Wi-Fi en una máquina Linux?

Estamos desarrollando una herramienta que debe mostrar solo las interfaces Ethernet y Wi-Fi de la máquina Linux y su estado actual.

Por ejemplo, a continuación se muestra la lista de interfaces de red (tanto físicas como virtuales) en mi máquina Linux (Ubuntu):

docker0, enp0s25, lo,wlp3s0

Cuando ejecuto la herramienta, a continuación se muestra el resultado que obtengo:

enp0s25, wlp3s0

Hemos escrito el código con la lógica de que todas las interfaces Ethernet siempre comienzan con la letra ey las interfaces Wi-Fi siempre comienzan con la letra w.

¿Es correcta la lógica? Si no, ¿cómo podemos abordar esto?

Las interfaces de red pueden tener cualquier nombre, así que no importa lo que haga, se encontrará con situaciones en las que (1) hay una interfaz de red "física" con un nombre que no coincide con su patrón, o (2) hay un interfaz de red "física" que coincidirá con su patrón.

Además de eso, si fuera usuario de su herramienta, en el momento en que su herramienta no me permitiera hacer algo que quisiera, porque tengo una interfaz de red que es "virtual", aunque para fines prácticos debería considerarse " físico "en mi configuración, comenzaría a maldecir en voz alta y enérgica en su aplicación, y nunca lo volveré a usar.

Las interfaces de red físicas y virtuales comparten una API común son una cosa que hace que Linux sea realmente flexible. Por favor, no trate de cuidar a su usuario y quítele eso. Tus usuarios te lo agradecerán.

Para los nombres de interfaz predecibles de systemd , los prefijos se pueden ver en 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

por lo tanto, tanto para el ethXestilo tradicional de denominación como para la denominación systemd más reciente, una letra inicial e debería ser una interfaz ethernet para cualquier nombre de interfaz generado automáticamente. Todas las interfaces wifi deben comenzar con una w en ambos esquemas, aunque no todas las interfaces que comienzan con w serán wifi.

Si esta herramienta tiene que trabajar en un ambiente arbitraria (en lugar de sólo en ambientes internos que control), nota que los usuarios pueden cambiar el nombre de las interfaces de sistemas Linux con nombres arbitrarios, tales como [ wan0, lan0, lan1, dmz0] que romperá ninguna hipótesis sobre letras iniciales .

La convención de nomenclatura es que las interfaces LAN se nombran eth0, eth1, ... y que las interfaces WLAN se nombran wlan0, wlan1, ...

Lo que ves son los llamados "nombres predecibles" que introdujo systemd. En la práctica, son todo menos predecibles, e incluso pueden cambiar cuando se cambia el hardware, que es exactamente el problema que se supone que deben evitar.

Para adivinar, la carta de inicio puede ser lo suficientemente buena. Algunas interfaces, en particular WLAN, tienen pistas sobre /sys/class/net/*/uevent:

DEVTYPE=wlan

Desafortunadamente, no existe tal DEVTYPEpara las interfaces LAN.

Una advertencia con mi respuesta (también se aplica a la mayoría de los demás): no sé el propósito de su solicitud. Si se trata de una aplicación descartable para solucionar un problema en particular, o para comprender mejor las redes, para nunca volver a usarse, entonces confiar en la primera letra de la interfaz puede ser una excelente opción rápida y sucia. Si planea escribir el próximo competidor a Wireshark o tcpdump, debe asegurarse de hacerlo bien para todo tipo de casos extremos.

Y si la aplicación que está escribiendo cae en algún punto entre esos extremos, solo usted (y sus clientes) pueden saber con qué cuidado necesita implementar su lógica.

Otros ya han señalado que los nombres nunca son confiables, por varias razones. El último problema es muy común en el software: suposiciones de codificación dura en lugar de confiar en hechos conocidos / documentados.

El segundo problema que no se ha mencionado también se basa en una suposición acerca de sus requisitos: que la lista de interfaces que desea enumerar siempre es exactamente "interfaces de ethernet de hardware" e "interfaces wifi".

El tercer problema es otra suposición: que todas las interfaces se incluirán en las categorías que se te ocurran en este momento. ¿Qué tal Infiniband, como lo mencionó @ user4556274? ¿Qué hay de las interfaces de túnel para una VPN? ¿Qué hay de las interfaces puenteadas? ¿Qué hay de las interfaces puenteadas que combinan interfaces físicas y lógicas?

Pero puede haber opciones para lograr lo que está buscando. Primero, defina exactamente qué caracteriza una interfaz que desea enumerar, frente a una que no tiene.

En la mayoría de los casos, una característica en la que puede confiar es la tabla de enrutamiento (sin embargo, esto solo funcionará mientras la interfaz esté activa, por lo que puede no ser lo que realmente está buscando).

Es probable que cualquier interfaz que tenga una ruta predeterminada (es decir, una ruta a 0.0.0.0) sea la que está buscando.

Tenga en cuenta que incluso esto todavía se basa en una suposición, solo una más confiable: es concebible que un sistema esté configurado para enrutar todo el tráfico saliente a través de una máquina virtual o un contenedor acoplable (por ejemplo, si hay un contenedor que ejecuta un firewall) ) Y lo contrario también es cierto: un administrador de sistemas podría bloquear el tráfico externo al eliminar la ruta predeterminada.

Otra opción es ir por el hardware real y ver qué controlador usa. Luego puede excluir ciertos controladores conocidos

¿Está excluyendo explícitamente las interfaces unidas o unidas? Nuestro valor predeterminado aquí es usar bond0o team0para la interfaz principal de nuestros servidores.

Creo que necesitas repensar tu lógica. Tal vez intente iterar a través de todas las interfaces de red definidas en un sistema dado, divídalas entre ethernet, wifi, infiband, serial, etc., y luego haga su magia.

No codifique ni coincida con los nombres de hardware del patrón. Esto se aplica a todos los dispositivos. Confíe en las herramientas proporcionadas por udev para determinar la lista de dispositivos y tomar las medidas adecuadas. Consulte 16.7 Nombres de dispositivos persistentes y luego lea todo el documento , específicamente 16.2 y 16.3. Tenga en cuenta que udev es independiente de la distribución, y también independiente del sistema init, ya que udev es ahora el método preferido para la administración de dispositivos en Linux.

Tenga en cuenta que @ user4556274, aludió a esto en su respuesta al referirse a udev-builtin-net-id.c, lo que en resumen significa que la coincidencia de patrones que está tratando de lograr es una parte incorporada udev.

Citando PredictableNetworkInterfaceNames :

Con systemd 197, hemos agregado soporte nativo para varias políticas de nomenclatura diferentes en systemd / udevd propiamente dicho e hicimos un esquema similar al de biosdevname (pero generalmente más potente y más cercano a los esquemas de identificación de dispositivos internos del núcleo) como predeterminado. Los siguientes esquemas de nomenclatura diferentes para las interfaces de red ahora son compatibles con udev de forma nativa:

1. Los nombres que incorporan números de índice proporcionados por Firmware / BIOS para dispositivos integrados (ejemplo: eno1)
2. Los nombres que incorporan firmware / BIOS proporcionan números de índice de ranura de conexión en caliente PCI Express (ejemplo: ens1)
3. Nombres que incorporan la ubicación física / geográfica del conector del hardware (ejemplo: enp2s0)
4. Nombres que incorporan la dirección MAC de las interfaces (ejemplo: enx78e7d1ea46da) Clásico, impredecible, nombre de ethX nativo del núcleo (ejemplo: eth0)

Por defecto, systemd v197 ahora nombrará interfaces siguiendo la política 1) si esa información del firmware es aplicable y está disponible, volviendo a 2) si esa información del firmware es aplicable y disponible, volviendo a 3) si corresponde, volviendo atrás a 5) en todos los demás casos. La política 4) no se usa de manera predeterminada, pero está disponible si el usuario lo elige.

Esta política combinada solo se aplica como último recurso. Eso significa que, si el sistema tiene biosdevname instalado, tendrá prioridad. Si el usuario ha agregado reglas udev que cambian el nombre de los dispositivos del núcleo, estas también tendrán prioridad. Además, cualquier esquema de nomenclatura específico de distribución generalmente tiene prioridad.

Como otros han dicho, no puedes depender completamente del nombre.

En mi caso, parece que para wireless /sys/class/net/<ifacename>/tendrá un directorio llamado "wireless" si es una interfaz inalámbrica:

# 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