Norme de convention de dénomination pour les interfaces Ethernet et Wi-Fi sur les machines Linux

13

Quelle est la norme de convention de dénomination pour les interfaces Ethernet et Wi-Fi sur une machine Linux?

Nous développons un outil qui ne devrait montrer que les interfaces Ethernet et Wi-Fi de la machine Linux et son état actuel.

Par exemple, voici la liste des interfaces réseau (physiques et virtuelles) sur ma machine Linux (Ubuntu):

docker0, enp0s25, lo,wlp3s0

Lorsque j'exécute l'outil, voici le résultat que j'obtiens:

enp0s25, wlp3s0

Nous avons écrit le code avec la logique que toutes les interfaces Ethernet commencent toujours par la lettre eet que les interfaces Wi-Fi commencent toujours par la lettre w.

La logique est-elle correcte? Sinon, comment pouvons-nous y remédier?

Mohan Raj
la source
en relation: unix.stackexchange.com/a/179931/117549
Jeff Schaller
Je voudrais voir comment iwconfigfiltre les interfaces WiFi des autres.
Patrick Mevzek
1
Y a-t-il une raison pour laquelle vous ne regarderiez pas quelque chose comme lshw? Inspecter spécifiquement le contenu de lshw -class networkpeut-être? Cherchez tout ce qui est capabilities: ethernet physical? Vous recherchez peut-être également certaines des autres capacités?
Zoredache
Pour faire face au défi de cadre soulevé par @dirkt, une meilleure question serait simplement: "comment puis-je obtenir le type d'une interface réseau sous Linux (ou macOS, ou autre ...)?"
Roger Lipscombe

Réponses:

41

Les interfaces réseau peuvent être nommées n'importe quoi, donc peu importe ce que vous faites, vous rencontrerez des situations où (1) il y a une interface réseau "physique" avec un nom qui ne correspond pas à votre modèle, ou (2) il y a un interface réseau "physique" qui correspondra à votre modèle.

En plus de cela, si j'étais un utilisateur de votre outil, le moment où votre outil ne me permettrait pas de faire quelque chose que je veux, parce que j'ai une interface réseau qui est "virtuelle", mais pour des raisons pratiques, elle devrait être considérée " physique "dans ma configuration, je commencerais à maudire bruyamment et avec force votre application, et je ne l'utiliserai plus jamais.

Les interfaces réseau physiques et virtuelles partagent toutes une API commune sont une chose qui rend Linux vraiment flexible. N'essayez pas de garder votre utilisateur et ne lui enlevez pas cela. Vos utilisateurs vous remercieront.

dirkt
la source
11
Vous n'avez pas réellement répondu à la question; vous avez passé 3 paragraphes à contester le contexte général de la question. Bien que je sois conscient que les réponses aux défis de trame sont une chose, cela ne ressemble pas à l'un de ces cas ... d'autant plus que user4556274 a donné une réponse succincte à la question posée.
Mike Ounsworth
18
@MikeOunsworth: Le problème est que la réponse de user4556274 ne fonctionne pas dans le cas général, cela ne fonctionne que si les noms d'interface sont en effet des noms d'interface prédictibles. Quel simple ip link set ... name ...peut changer. Et oui, j'aurais pu énumérer les noms d'interface prévisibles moi-même. La réponse à la question d'origine est "veuillez ne pas le faire de cette façon". Parce que peu importe comment vous vous y prendrez, cela ne fonctionnera pas.
dirkt
@ fpmurphy1 Non, je pense qu'il veut dire des noms d'interface prévisibles. Peu importe que ce soit systemd, traditionnel (ethN), les conventions spécifiques de votre entreprise ou toute autre norme qui rend les noms prévisibles
slebetman
12
@MikeOunsworth: La réponse se trouve dans la toute première sous-clause de la toute première phrase du tout premier paragraphe: "Les interfaces réseau peuvent être nommées n'importe quoi […]" Par conséquent, ce que l'OP demande est impossible et ne peut pas être fait . Vous ne pouvez pas détecter le type d'une interface réseau basée sur une norme de convention de dénomination, car il n'y a pas de norme de convention de dénomination et n'importe qui peut nommer ses interfaces comme bon lui semble. Par exemple, sur mon ancien routeur Linux, je dirige des autocollants de couleur sur le dos, et les interfaces Ethernet physiques ont été nommé red, blueet green.
Jörg W Mittag
1
@ JörgWMittag, bien sûr, vous pouvez les détecter sur la base d'une norme, si vous savez que la norme est utilisée (et que vous en attendez une qui exporte ces informations dans le nom en premier lieu). Nous savons que systemd a une norme de dénomination d'interface réseau , il est donc inutile de dire qu'une n'existe pas.
ilkkachu
28

Pour les noms d'interface prévisibles systemd , les préfixes peuvent être vus dans 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

Ainsi, pour le ethXstyle traditionnel de dénomination et la dénomination Systemd plus récente, une lettre initiale e devrait être une interface Ethernet pour tous les noms d'interface générés automatiquement. Toutes les interfaces wifi doivent commencer par un w dans les deux schémas, bien que toutes les interfaces commençant par w ne soient pas wifi.

Si cet outil doit travailler dans un environnement arbitraire (plutôt que sur des environnements internes que vous contrôlez), notez que les utilisateurs peuvent renommer les interfaces sur les systèmes Linux avec des noms arbitraires, tels que [ wan0, lan0, lan1, dmz0] qui cassera toutes les hypothèses sur les lettres initiales .

user4556274
la source
7
Et certains d'entre nous sont des refusistes systématiques.
chrylis -on strike-
1
Notez que cette solution ne fonctionnera pas sur les systèmes utilisant le nom biosdevnamed'interface, où une interface Ethernet peut être nommée comme p3p7. Cette méthode est un prédécesseur des nouveaux noms prévisibles de systemd et bien qu'elle soit désormais déconseillée sur les distributions courantes, de nombreux systèmes la reprendront alors qu'elle était la valeur par défaut il y a quelques années.
TooTea
systemd appelle utilement une de mes interfaces Ethernet «rename3». Celui-ci peut varier, soupir :(
user1908704
1
@ user1908704: Cela signifie généralement que udev a été invité à donner le même nom à plusieurs interfaces. (Peut-être avez-vous un ancien fichier "noms persistants" généré automatiquement dans /etc/udev/rules.d?) Cela dit, le processus de changement de nom a été corrigé dans v187 pour être entièrement atomique (réussir ou annuler) et le rename%uformat n'a pas ' t existait dans le code source depuis 2012. Je voudrais soupirer que votre logiciel est obsolète depuis six ans.
user1686
1
@grawity C'est Ubuntu 18.04. Il s'avère que certaines cartes mères ont deux cartes réseau avec la même entrée ACPI, ce qui les rend toutes deux eno1. Comme cela ne peut pas se produire, l'un d'eux s'appelle 'rename3'. Je n'ai pas complètement élaboré la logique de qui remporte la course, mais tout changement peut perturber le concours et faire renommer l'autre3.
user1908704
9

La convention de nommage est que les interfaces LAN sont nommées eth0, eth1... et que les interfaces WLAN sont nommés wlan0, wlan1...

Ce que vous voyez sont les soi-disant «noms prévisibles» que systemd a introduits. En pratique, ils sont tout sauf prévisibles, et ils peuvent même changer lorsque le matériel est changé, ce qui est exactement le problème qu'ils sont censés éviter.

Pour une supposition, la lettre de départ peut être assez bonne. Certaines interfaces, en particulier le WLAN, ont des indices dans /sys/class/net/*/uevent:

DEVTYPE=wlan

Malheureusement, il n'y en a pas DEVTYPEpour les interfaces LAN.

RalfFriedl
la source
2
Le nom du périphérique change lorsque le matériel change n'est pas le problème que les noms d'interface prévisibles tentent d'éviter. Les noms d'interface prévisibles évitent les changements de nom lorsque le matériel est inchangé . Il s'agit d'un problème lorsque les périphériques matériels sont détectés dans un ordre aléatoire.
Johan Myréen
@ JohanMyréen C'est faux: "... qu'ils (nom de l'interface) restent fixes même si du matériel est ajouté ou supprimé" freedesktop.org/wiki/Software/systemd/…
RalfFriedl
La motivation pour introduire les noms d'interface prévisibles était que le sondage n'est pas déterministe et que "l'affectation des noms" eth0 "," eth1 "et ainsi de suite n'est plus fixe et il pourrait très bien arriver que" eth0 "sur un démarrage finisse par être "eth1" sur le suivant. " C'est un bonus si les noms prévisibles peuvent survivre aux changements matériels, mais ce n'était pas la raison principale pour eux.
Johan Myréen
1
Gagner certains en perdre - dans certains scénarios, il est très souhaitable que le matériel modifié clique de manière fiable dans le même "emplacement de nommage" :)
rackandboneman
@ JohanMyréen L'ancien schéma d'attribution des noms d'interfaces basé sur MAC ou d'autres propriétés fonctionnait plus fiable lors de l'ajout d'interfaces, sans les tracas des nouveaux noms.
RalfFriedl
5

Une mise en garde avec ma réponse (s'applique à la plupart des autres aussi): je ne connais pas le but de votre candidature. S'il s'agit d'une application jetable pour résoudre un problème particulier ou pour mieux comprendre la mise en réseau, pour ne plus jamais être utilisée, alors s'appuyer sur la première lettre de l'interface peut être une excellente option rapide et sale. Si vous envisagez d'écrire le prochain concurrent sur Wireshark ou tcpdump, vous devez être sûr de le faire pour toutes sortes de cas de bord.

Et si l'application que vous écrivez se situe quelque part entre ces extrêmes, vous seul (et vos clients) pouvez savoir avec quelle prudence vous devez mettre en œuvre votre logique.

D'autres ont déjà souligné que les noms ne sont jamais fiables, pour un certain nombre de raisons. Le problème ultime est très courant dans le logiciel: les hypothèses de codage en dur au lieu de s'appuyer sur des faits connus / documentés.

Le deuxième problème qui n'a pas été mentionné est également basé sur une hypothèse concernant vos besoins: que la liste des interfaces que vous souhaitez répertorier est toujours exactement «interfaces Ethernet matérielles» et «interfaces wifi».

Le troisième problème est une autre hypothèse: toutes les interfaces tomberont dans les catégories auxquelles vous pouvez penser en ce moment. Qu'en est-il d'Infiniband, comme mentionné par @ user4556274? Que diriez-vous des interfaces de tunnel pour un VPN? Et les interfaces pontées? Que diriez-vous des interfaces pontées qui combinent des interfaces physiques et logiques?

Mais il peut y avoir des options pour accomplir ce que vous recherchez. Tout d'abord, définissez exactement ce qui caractérise une interface que vous souhaitez lister, par rapport à une interface que vous n'avez pas.

Dans la plupart des cas, une caractéristique sur laquelle vous pouvez compter est la table de routage (cependant, cela ne fonctionnera que tant que l'interface est en place, donc ce n'est peut-être pas ce que vous recherchez réellement).

Toute interface qui a une route par défaut (c'est-à-dire une route vers 0.0.0.0) est probablement celle que vous recherchez.

Notez que même cela est toujours basé sur une hypothèse, juste une plus fiable: il est concevable qu'un système soit configuré pour acheminer tout le trafic sortant via une machine virtuelle ou un conteneur Docker (par exemple, s'il existe un conteneur exécutant un pare-feu ). Et l'inverse est également vrai: un administrateur système peut potentiellement bloquer le trafic extérieur en supprimant l'itinéraire par défaut.

Une autre option consiste à utiliser le matériel réel et à voir quel pilote il utilise. Vous pouvez ensuite exclure certains pilotes connus

Kevin Keane
la source
4

Excluez-vous explicitement les interfaces liées ou associées? Notre valeur par défaut ici est d'utiliser bond0ou team0pour l'interface principale de nos serveurs.

Je pense que vous devez repenser votre logique. Essayez peut-être d'itérer toutes les interfaces réseau définies sur un système donné, divisez-les entre Ethernet, wifi, infiband, série, etc., puis faites votre magie.

doneal24
la source
3

Ne codez pas en dur ou ne correspondez pas aux noms de matériel. Cela s'applique à tous les appareils. Comptez sur les outils fournis par udev pour déterminer la liste des appareils et prendre les mesures appropriées. Voir 16.7 Attribution d'un nom de périphérique persistant , puis lisez l' intégralité de ce document , en particulier 16.2 et 16.3. Notez que udev est indépendant de la distribution et également du système init, car udev est désormais la méthode préférée pour la gestion des périphériques sous linux.

Notez que @ user4556274, y a fait allusion dans sa réponse udev-builtin-net-id.c, ce qui signifie en bref que la correspondance de modèle que vous essayez d'accomplir fait partie intégrante de udev.

Citation de PredictableNetworkInterfaceNames :

Avec systemd 197, nous avons ajouté la prise en charge native d'un certain nombre de politiques de dénomination différentes dans systemd / udevd proprement dit et fait un schéma similaire à celui de biosdevname (mais généralement plus puissant et plus proche des schémas d'identification des périphériques internes au noyau) par défaut. Les différents schémas de dénomination suivants pour les interfaces réseau sont désormais pris en charge nativement par udev:

  1. Noms incorporant les numéros d'index fournis par le micrologiciel / BIOS pour les périphériques intégrés (exemple: eno1)
  2. Noms contenant le micrologiciel / BIOS fournis avec les numéros d'index des emplacements de branchement à chaud PCI Express (exemple: ens1)
  3. Noms incorporant l'emplacement physique / géographique du connecteur du matériel (exemple: enp2s0)
  4. Noms incorporant l'adresse MAC des interfaces (exemple: enx78e7d1ea46da) Nommage ethX natif classique et imprévisible (exemple: eth0)

Par défaut, systemd v197 nommera désormais les interfaces suivant la politique 1) si ces informations du micrologiciel sont applicables et disponibles, retombant à 2) si ces informations du micrologiciel sont applicables et disponibles, retombant à 3) le cas échéant, retombant à 5) dans tous les autres cas. La stratégie 4) n'est pas utilisée par défaut, mais est disponible si l'utilisateur le souhaite.

Cette politique combinée n'est appliquée qu'en dernier recours. Cela signifie que si biosdevname est installé sur le système, il aura la priorité. Si l'utilisateur a ajouté des règles udev qui modifient le nom des périphériques du noyau, celles-ci prévaudront également. En outre, tous les schémas de dénomination spécifiques à la distribution ont généralement la priorité.

eyoung100
la source
2

Comme d'autres l'ont dit, vous ne pouvez pas entièrement dépendre du nom.

Dans mon cas, il semble que pour le sans fil /sys/class/net/<ifacename>/aura un répertoire appelé "sans fil" s'il s'agit d'une interface sans fil:

# 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
Kyle Brandt
la source