Standard di convenzione di denominazione per interfacce Ethernet e Wi-Fi su macchine Linux

Qual è lo standard della convenzione di denominazione per le interfacce Ethernet e Wi-Fi su una macchina Linux?

Stiamo sviluppando uno strumento che dovrebbe mostrare solo le interfacce Ethernet e Wi-Fi della macchina Linux e il suo stato attuale.

Ad esempio, di seguito è riportato l'elenco delle interfacce di rete (sia fisiche che virtuali) sul mio computer Linux (Ubuntu):

docker0, enp0s25, lo,wlp3s0

Quando eseguo lo strumento, di seguito è riportato il risultato che ottengo:

enp0s25, wlp3s0

Abbiamo scritto il codice con la logica che tutte le interfacce Ethernet iniziano sempre con la lettera ee le interfacce Wi-Fi iniziano sempre con la lettera w.

La logica è giusta? In caso contrario, come possiamo affrontarlo?

Le interfacce di rete possono essere nominate in qualsiasi modo, quindi, indipendentemente da ciò che fai, ti imbatterai in situazioni in cui (1) esiste un'interfaccia di rete "fisica" con un nome che non corrisponde al tuo modello o (2) c'è un interfaccia di rete "fisica" che corrisponderà al tuo modello.

Inoltre, se fossi un utente del tuo strumento, nel momento in cui il tuo strumento non mi permetterebbe di fare qualcosa che desidero, perché ho un'interfaccia di rete "virtuale", anche se per scopi pratici dovrebbe essere considerata " fisico "nella mia configurazione, inizierei a maledire ad alta voce e con forza la tua app e non la userò mai più.

Le interfacce di rete fisiche e virtuali condividono tutte un'API comune sono una cosa che rende Linux davvero flessibile. Per favore, non provare a fare da babysitter al tuo utente e portalo via da lui. I tuoi utenti ti ringrazieranno.

Per i nomi di interfaccia prevedibili systemd , i prefissi possono essere visualizzati in 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

quindi, sia per lo ethXstile tradizionale di denominazione che per la nuova denominazione di sistema, una lettera iniziale e dovrebbe essere un'interfaccia ethernet per qualsiasi nome di interfaccia generato automaticamente. Tutte le interfacce wifi dovrebbero iniziare con una w in entrambi gli schemi, anche se non tutte le interfacce che iniziano con w saranno wifi.

Se questo strumento deve lavorare in un ambiente arbitrario (e non solo in ambienti interni che si Control), nota che gli utenti possono rinominare interfacce su sistemi Linux con nomi arbitrari, come [ wan0, lan0, lan1, dmz0] che romperà qualsiasi ipotesi circa le lettere iniziali .

La convenzione di denominazione è che le interfacce LAN sono chiamati eth0, eth1, ... e che le interfacce WLAN sono chiamati wlan0, wlan1, ...

Quello che vedi sono i cosiddetti "nomi prevedibili" introdotti dal sistema. In pratica, sono tutt'altro che prevedibili e possono persino cambiare quando si cambia l'hardware, che è esattamente il problema che dovrebbero evitare.

Per indovinare la lettera iniziale potrebbe essere abbastanza buona. Alcune interfacce, in particolare la WLAN, hanno suggerimenti in /sys/class/net/*/uevent:

DEVTYPE=wlan

Sfortunatamente, non esiste tale DEVTYPEper le interfacce LAN.

Un avvertimento con la mia risposta (vale anche per la maggior parte degli altri): non conosco lo scopo della tua candidatura. Se si tratta di un'applicazione usa e getta per risolvere un particolare problema o per comprendere meglio la rete, per non essere mai più utilizzata, fare affidamento sulla prima lettera dell'interfaccia potrebbe essere un'ottima opzione rapida e sporca. Se stai pianificando di scrivere il prossimo concorrente su Wireshark o tcpdump, devi essere sicuro di farlo bene per tutti i tipi di casi limite.

E se l'applicazione che stai scrivendo si colloca da qualche parte tra questi estremi, solo tu (e i tuoi clienti) potete sapere con quanta cura avete bisogno per implementare la vostra logica.

Altri hanno già sottolineato che i nomi non sono mai affidabili, per una serie di motivi. Il problema finale è molto comune nel software: ipotesi di codifica rigida invece di basarsi su fatti noti / documentati.

Il secondo problema che non è stato menzionato si basa anche su un'ipotesi relativa alle vostre esigenze: che l'elenco delle interfacce che si desidera elencare sia sempre esattamente "interfacce ethernet hardware" e "interfacce wifi".

Il terzo problema è l'ennesimo presupposto: tutte le interfacce rientreranno nelle categorie a cui puoi pensare ora. Che ne dici di Infiniband, come menzionato da @ user4556274? Che ne dite di interfacce tunnel per una VPN? Che ne dici di interfacce a ponte? Che ne dici di interfacce a ponte che combinano interfacce fisiche e logiche?

Ma potrebbero esserci delle opzioni per realizzare ciò che stai cercando. Innanzitutto, definisci esattamente ciò che caratterizza un'interfaccia che desideri elencare, rispetto a quella che non hai.

Nella maggior parte dei casi, una caratteristica su cui puoi fare affidamento è la tabella di routing (tuttavia, funzionerà solo finché l'interfaccia è attiva, quindi potrebbe non essere quello che stai effettivamente cercando).

Qualsiasi interfaccia che ha una route predefinita (ovvero una route a 0.0.0.0) è probabilmente quella che stai cercando.

Si noti che anche questo si basa ancora su un presupposto, solo più affidabile: è concepibile che un sistema sia configurato per instradare tutto il traffico in uscita attraverso una macchina virtuale o un contenitore docker (ad esempio, se è presente un contenitore che esegue un firewall ). E anche il contrario è vero: un amministratore di sistema potrebbe potenzialmente bloccare il traffico esterno eliminando il percorso predefinito.

Un'altra opzione è quella di passare dall'hardware effettivo e vedere quale driver utilizza. È quindi possibile escludere alcuni driver noti

Stai escludendo esplicitamente le interfacce collegate o in team? Il nostro default qui è usare bond0o team0per l'interfaccia primaria per i nostri server.

Penso che devi ripensare la tua logica. Forse prova a iterare attraverso tutte le interfacce di rete definite su un dato sistema, dividerle tra ethernet, wifi, infiband, seriale, ecc., E poi fare la tua magia.

Non hardcode o pattern corrispondono a nomi hardware. Questo vale per tutti i dispositivi. Affidati agli strumenti forniti da udev per determinare l'elenco dei dispositivi e prendere le misure appropriate. Vedere 16.7 Denominazione persistente del dispositivo , quindi leggere l' intero documento , in particolare 16.2 e 16.3. Nota che udev è agnostico di distribuzione e anche agnostico di sistema di init, poiché udev è ora il metodo preferito per la gestione dei dispositivi in ​​linux.

Si noti che @ user4556274, ha accennato a questo nella sua risposta quando ci si riferisce udev-builtin-net-id.c, il che in breve significa che il pattern matching che stai cercando di realizzare è parte integrante di udev.

Citando PredictableNetworkInterfaceNames :

Con systemd 197 abbiamo aggiunto il supporto nativo per una serie di diverse politiche di denominazione in systemd / udevd corretto e reso predefinito uno schema simile a biosdevname (ma generalmente più potente e più vicino agli schemi di identificazione dei dispositivi interni al kernel). I seguenti diversi schemi di denominazione per le interfacce di rete sono ora supportati da udev in modo nativo:

1. I nomi che incorporano il firmware / BIOS hanno fornito i numeri di indice per i dispositivi di bordo (esempio: eno1)
2. Nomi che incorporano firmware / BIOS forniti numeri indice slot hotplug PCI Express (esempio: ens1)
3. Nomi che incorporano la posizione fisica / geografica del connettore dell'hardware (esempio: enp2s0)
4. Nomi che incorporano l'indirizzo MAC delle interfacce (esempio: enx78e7d1ea46da) Denominazione ethX classica, imprevedibile, nativa del kernel (esempio: eth0)

Per impostazione predefinita, systemd v197 ora denominerà le interfacce seguendo la politica 1) se tali informazioni dal firmware sono applicabili e disponibili, ritornando a 2) se tali informazioni dal firmware sono applicabili e disponibili, tornando a 3) se applicabile, ricadendo a 5) in tutti gli altri casi. Il criterio 4) non viene utilizzato per impostazione predefinita, ma è disponibile se l'utente lo sceglie.

Questa politica combinata viene applicata solo come ultima risorsa. Ciò significa che se nel sistema è installato biosdevname, avrà la precedenza. Se l'utente ha aggiunto regole udev che cambiano il nome dei dispositivi del kernel, anche queste avranno la precedenza. Inoltre, qualsiasi schema di denominazione specifico per la distribuzione ha generalmente la precedenza.

Come altri hanno già detto, non puoi dipendere completamente dal nome.

Nel mio caso sembra che per wireless /sys/class/net/<ifacename>/avrà una directory chiamata "wireless" se è un'interfaccia wireless:

# 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