it-swarm.com.de

Namenskonventionsstandard für Ethernet- und Wi-Fi-Schnittstellen auf Linux-Computern

Was ist der Namenskonventionsstandard für Ethernet- und Wi-Fi-Schnittstellen auf einem Linux-Computer?

Wir entwickeln ein Tool, das nur die Ethernet- und Wi-Fi-Schnittstellen des Linux-Computers und seinen aktuellen Status anzeigen soll

Im Folgenden finden Sie beispielsweise die Liste der Netzwerkschnittstellen (sowohl physische als auch virtuelle) auf meinem Linux-Computer (Ubuntu):

docker0, enp0s25, lo, wlp3s0

Wenn ich das Tool starte, ist das folgende Ergebnis:

enp0s25, wlp3s0

Wir haben den Code mit der Logik geschrieben, dass alle Ethernet-Schnittstellen immer mit dem Buchstaben e beginnen und Wi-Fi-Schnittstellen immer mit dem Buchstaben w beginnen.

Ist die Logik richtig? Wenn nicht, wie können wir das angehen?

12
Mohan Raj

Netzwerkschnittstellen können beliebig benannt werden. Unabhängig davon, was Sie tun, treten Situationen auf, in denen (1) eine "physische" Netzwerkschnittstelle mit einem Namen vorhanden ist, der nicht zu Ihrem Muster passt, oder (2) eine "physische" Netzwerkschnittstelle, die Ihrem Muster entspricht.

Wenn ich ein Benutzer Ihres Tools wäre, würde mir Ihr Tool in dem Moment nicht erlauben, etwas zu tun, was ich möchte, da ich eine Netzwerkschnittstelle habe, die "virtuell" ist, obwohl dies aus praktischen Gründen in Betracht gezogen werden sollte. " physisch "In meinem Setup würde ich laut und heftig auf Ihre App fluchen und sie nie wieder verwenden.

Physische und virtuelle Netzwerkschnittstellen, die alle eine gemeinsame API haben, sind eine Sache, die Linux wirklich flexibel macht. Bitte versuchen Sie nicht, Ihren Benutzer zu babysitten, und nehmen Sie ihm das weg. Ihre Benutzer werden es Ihnen danken.

40
dirkt

Für systemd vorhersehbare Schnittstellennamen sind die Präfixe 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

daher sollte ein Anfangsbuchstabe e sowohl für den traditionellen ethX-Benennungsstil als auch für die neuere systemd-Benennung eine Ethernet-Schnittstelle für alle automatisch generierten Schnittstellennamen sein. Alle WLAN-Schnittstellen sollten in beiden Schemata mit einem w beginnen, obwohl nicht alle Schnittstellen, die mit w beginnen, WLAN sind.

Wenn dieses Tool in einer beliebigen Umgebung arbeiten muss (und nicht nur in internen Umgebungen, die Sie steuern), beachten Sie, dass Benutzer Schnittstellen auf Linux-Systemen mit beliebigen Namen wie [wan0, lan0, lan1, dmz0], die alle Annahmen über Anfangsbuchstaben brechen.

27
user4556274

Die Namenskonvention lautet, dass LAN-Schnittstellen eth0, eth1, ... und WLAN-Schnittstellen wlan0, wlan1, ... heißen.

Was Sie sehen, sind die sogenannten "vorhersehbaren Namen", die systemd eingeführt hat. In der Praxis sind sie alles andere als vorhersehbar und können sich sogar ändern, wenn die Hardware geändert wird. Dies ist genau das Problem, das sie vermeiden sollen.

Für eine Vermutung kann der Startbuchstabe gut genug sein. Einige Schnittstellen, insbesondere WLAN, enthalten Hinweise in /sys/class/net/*/uevent:

DEVTYPE=wlan

Leider gibt es für LAN-Schnittstellen kein solches DEVTYPE.

8
RalfFriedl

Eine Einschränkung bei meiner Antwort (gilt auch für die meisten anderen): Ich kenne den Zweck Ihrer Bewerbung nicht. Wenn es sich um eine Wegwerfanwendung handelt, um ein bestimmtes Problem zu beheben oder das Netzwerk besser zu verstehen und nie wieder verwendet zu werden, kann es eine schnelle und schmutzige Option sein, sich auf den ersten Buchstaben der Benutzeroberfläche zu verlassen. Wenn Sie planen, den nächsten Konkurrenten an Wireshark oder tcpdump zu schreiben, müssen Sie sicherstellen, dass Sie es für alle Arten von Edge-Fällen richtig machen.

Und wenn die Anwendung, die Sie schreiben, irgendwo zwischen diesen Extremen liegt, können nur Sie (und Ihre Kunden) wissen, wie sorgfältig Sie Ihre Logik implementieren müssen.

Andere haben bereits darauf hingewiesen, dass die Namen aus einer Reihe von Gründen niemals zuverlässig sind. Das ultimative Problem ist ein sehr häufiges Problem in der Software: Annahmen hart zu codieren, anstatt sich auf bekannte/dokumentierte Fakten zu stützen.

Das zweite Problem, das nicht erwähnt wurde, basiert ebenfalls auf einer Annahme über Ihre Anforderungen: Die Liste der Schnittstellen, die Sie auflisten möchten, ist immer genau "Hardware-Ethernet-Schnittstellen" und "WLAN-Schnittstellen".

Das dritte Problem ist eine weitere Annahme: Alle Benutzeroberflächen fallen in die Kategorien, an die Sie gerade denken können. Wie wäre es mit Infiniband, wie von @ user4556274 erwähnt? Wie wäre es mit Tunnelschnittstellen für ein VPN? Wie wäre es mit überbrückten Schnittstellen? Wie wäre es mit überbrückten Schnittstellen, die physische und logische Schnittstellen kombinieren?

Möglicherweise gibt es jedoch Optionen, um das zu erreichen, wonach Sie suchen. Definieren Sie zunächst genau, was eine Schnittstelle auszeichnet, die Sie auflisten möchten, und eine, die Sie nicht auflisten.

In den meisten Fällen können Sie sich auf die Routing-Tabelle verlassen (dies funktioniert jedoch nur, solange die Schnittstelle aktiv ist, sodass es möglicherweise nicht das ist, wonach Sie tatsächlich suchen).

Jede Schnittstelle mit einer Standardroute (d. H. Einer Route zu 0.0.0.0) ist wahrscheinlich eine, nach der Sie suchen.

Beachten Sie, dass auch dies immer noch auf einer zuverlässigeren Annahme basiert: Es ist denkbar, dass ein System so konfiguriert ist, dass der gesamte ausgehende Datenverkehr über eine virtuelle Maschine oder einen Docker-Container geleitet wird (z. B. wenn in einem Container eine Firewall ausgeführt wird) ). Und das Gegenteil ist auch der Fall: Ein Systemadministrator kann möglicherweise den externen Datenverkehr blockieren, indem er die Standardroute löscht.

Eine andere Möglichkeit besteht darin, anhand der tatsächlichen Hardware zu ermitteln, welcher Treiber verwendet wird. Sie können dann bestimmte bekannte Treiber ausschließen

5
Kevin Keane

Schließen Sie verbundene oder Team-Schnittstellen ausdrücklich aus? Unsere Standardeinstellung hier ist die Verwendung von bond0 oder team0 für die primäre Schnittstelle für unsere Server.

Ich denke, Sie müssen Ihre Logik überdenken. Versuchen Sie vielleicht, alle definierten Netzwerkschnittstellen auf einem bestimmten System zu durchlaufen, teilen Sie sie in Ethernet, WLAN, Infiband, Seriell usw. auf und zaubern Sie dann.

4
doneal24

Keine Hardcode- oder Pattern-Match-Hardwarenamen. Dies gilt für alle Geräte. Verlassen Sie sich auf die von udev bereitgestellten Tools, um die Liste der Geräte zu ermitteln und geeignete Maßnahmen zu ergreifen. Siehe 16.7 Persistent Device Naming und lesen Sie dann das gesamtes Dokument durch, insbesondere 16.2 und 16.3. Beachten Sie, dass udev verteilungsunabhängig und auch init-systemunabhängig ist, da udev jetzt die bevorzugte Methode für die Geräteverwaltung unter Linux ist.

Beachten Sie, dass @ user4556274 in seiner Antwort auf udev-builtin-net-id.c Darauf hingewiesen hat, was kurz gesagt bedeutet, dass der Mustervergleich, den Sie erreichen möchten, ein integrierter Bestandteil von udev ist.

Zitieren PredictableNetworkInterfaceNames :

Mit systemd 197 haben wir systemd/udevd native Unterstützung für eine Reihe verschiedener Namensrichtlinien hinzugefügt und ein Schema ähnlich dem von biosdevname (aber im Allgemeinen leistungsfähiger und näher an kernelinternen Geräteidentifikationsschemata) als Standard festgelegt. Die folgenden unterschiedlichen Benennungsschemata für Netzwerkschnittstellen werden jetzt von udev nativ unterstützt:

  1. Namen mit Firmware/BIOS lieferten Indexnummern für integrierte Geräte (Beispiel: eno1)
  2. Namen mit Firmware/BIOS lieferten PCI Express-Hotplug-Steckplatzindexnummern (Beispiel: ens1)
  3. Namen, die den physischen/geografischen Standort des Anschlusses der Hardware enthalten (Beispiel: enp2s0)
  4. Namen, die die MAC-Adresse der Schnittstellen enthalten (Beispiel: enx78e7d1ea46da) Klassische, unvorhersehbare kernel-native ethX-Benennung (Beispiel: eth0)

Standardmäßig benennt systemd v197 jetzt Schnittstellen gemäß Richtlinie 1), wenn diese Informationen aus der Firmware anwendbar und verfügbar sind, und greift auf 2) zurück, wenn diese Informationen aus der Firmware anwendbar und verfügbar sind, und auf 3), falls zutreffend, zurück bis 5) in allen anderen Fällen. Richtlinie 4) wird nicht standardmäßig verwendet, ist jedoch verfügbar, wenn der Benutzer dies wünscht.

Diese kombinierte Richtlinie wird nur als letztes Mittel angewendet. Das heißt, wenn auf dem System biosdevname installiert ist, hat dies Vorrang. Wenn der Benutzer udev-Regeln hinzugefügt hat, die den Namen der Kernelgeräte ändern, haben diese ebenfalls Vorrang. Außerdem haben verteilungsspezifische Benennungsschemata im Allgemeinen Vorrang.

3
eyoung100

Wie andere gesagt haben, kann man sich nicht vollständig auf den Namen verlassen.

In meinem Fall ist es scheint das für drahtlose /sys/class/net/<ifacename>/ enthält ein Verzeichnis mit dem Namen "drahtlos", wenn es sich um eine drahtlose Schnittstelle handelt:

# 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
2
Kyle Brandt