Standard konwencji nazewnictwa dla interfejsów Ethernet i Wi-Fi na komputerach z systemem Linux

12

Jaki jest standard konwencji nazewnictwa dla interfejsów Ethernet i Wi-Fi na komputerze z systemem Linux?

Opracowujemy narzędzie, które powinno pokazywać tylko interfejsy Ethernet i Wi-Fi maszyny z systemem Linux oraz jej obecny status.

Na przykład poniżej znajduje się lista interfejsów sieciowych (fizycznych i wirtualnych) na moim komputerze z systemem Linux (Ubuntu):

docker0, enp0s25, lo,wlp3s0

Po uruchomieniu narzędzia poniżej otrzymuję wynik:

enp0s25, wlp3s0

Napisaliśmy kod z logiką, że wszystkie interfejsy Ethernet zawsze zaczynają się na literę, ea interfejsy Wi-Fi zawsze zaczynają się na literę w.

Czy logika jest prawidłowa? Jeśli nie, jak możemy rozwiązać ten problem?

Mohan Raj
źródło
powiązane: unix.stackexchange.com/a/179931/117549
Jeff Schaller
Spojrzałbym na to, jak iwconfigfiltruje interfejsy WiFi od innych.
Patrick Mevzek,
1
Czy istnieje powód, dla którego nie spojrzałbyś na coś takiego jak lshw? W szczególności sprawdź zawartość lshw -class networkmoże? Poszukaj wszystkiego, co jest capabilities: ethernet physical? Być może poszukaj również innych możliwości?
Zoredache,
Aby poradzić sobie z wyzwaniem ramowym podniesionym przez @dirkt, lepszym pytaniem byłoby po prostu: „jak uzyskać typ interfejsu sieciowego w systemie Linux (lub macOS lub inny ...)?”
Roger Lipscombe

Odpowiedzi:

40

Interfejsy sieciowe można nazwać dowolnymi nazwami, więc bez względu na to, co robisz, natkniesz się na sytuacje, w których (1) istnieje „fizyczny” interfejs sieciowy o nazwie, która nie pasuje do twojego wzorca, lub (2) istnieje „fizyczny” interfejs sieciowy, który będzie pasował do twojego wzorca.

Co więcej, gdybym był użytkownikiem twojego narzędzia, moment, w którym twoje narzędzie nie pozwoli mi zrobić czegoś, co chcę, ponieważ mam interfejs sieciowy, który jest „wirtualny”, chociaż ze względów praktycznych należy to wziąć pod uwagę „ physical ”w mojej konfiguracji zacząłem przeklinać głośno i mocno na twoją aplikację i nigdy więcej jej nie użyję.

Fizyczne i wirtualne interfejsy sieciowe mają wspólny interfejs API. To jedna z rzeczy, która sprawia, że ​​Linux jest naprawdę elastyczny. Proszę nie próbować opiekować się użytkownikiem i zabrać mu to. Twoi użytkownicy będą Ci wdzięczni.

reż
źródło
11
Właściwie nie odpowiedziałeś na pytanie; spędziłeś 3 akapity, kwestionując kontekst pytania. Chociaż zdaję sobie sprawę z tego, że odpowiedzi na wyzwanie ramkowe to coś, ale nie wydaje się to jednym z tych przypadków ... zwłaszcza, że ​​użytkownik4556274 udzielił zwięzłej odpowiedzi na zadane pytanie.
Mike Ounsworth,
18
@MikeOunsworth: Problem polega na tym, że odpowiedź użytkownika 4556274 nie działa w ogólnym przypadku, działa tylko wtedy, gdy nazwy interfejsów są rzeczywiście przewidywalnymi nazwami interfejsów. Który prosty ip link set ... name ...może się zmienić. I tak, sam mogłem wymienić przewidywalne nazwy interfejsów. Odpowiedź na pierwotne pytanie brzmi: „proszę nie rób tego w ten sposób”. Ponieważ bez względu na to, jak sobie z tym poradzisz, to nie zadziała.
dirkt
@ fpmurphy1 Nie, myślę, że ma na myśli przewidywalne nazwy interfejsów. Nie ma znaczenia, czy jest to systemowe, tradycyjne (ethN), specyficzne konwencje twojej firmy lub jakiekolwiek inne standardy, które sprawiają, że nazwy są przewidywalne
slebetman
12
@MikeOunsworth: Odpowiedź znajduje się w pierwszej pod-klauzuli pierwszego zdania pierwszego akapitu: „Interfejsy sieciowe można nazwać jakikolwiek […]” Dlatego to, o co prosi OP, jest niemożliwe i nie da się tego zrobić . Nie można wykryć typu interfejsu sieciowego opartego na standardzie konwencji nazewnictwa, ponieważ nie ma standardu konwencji nazewnictwa i każdy może nazwać swój interfejs dowolnie. Na przykład, na moim starym routerze Linux, I głowę kolorowe naklejki na plecach, a fizyczne interfejsy Ethernet zostały nazwane red, bluei green.
Jörg W Mittag
1
@ JörgWMittag, oczywiście możesz je wykryć na podstawie standardu, jeśli wiesz, że standard jest używany (i oczekujesz takiego, który eksportuje te informacje w nazwie). Wiemy, że systemd ma standard nazewnictwa interfejsów sieciowych , więc nie ma sensu mówić, że nie istnieje.
ilkkachu
27

W przypadku systemowo przewidywalnych nazw interfejsów prefiksy można zobaczyć w 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

więc zarówno dla tradycyjnego ethXstylu nazewnictwa, jak i nowszego systemowego nazewnictwa, pierwsza litera e powinna być interfejsem ethernetowym dla wszelkich automatycznie generowanych nazw interfejsów. Wszystkie interfejsy Wi-Fi powinny zaczynać się od W w obu schematach, chociaż nie wszystkie interfejsy rozpoczynające się od W będą Wi-Fi.

Jeśli narzędzie to musi pracować w dowolnym środowisku (a nie tylko na środowiskach wewnętrznych którego Control), należy zauważyć, że użytkownicy mogą zmieniać nazwy interfejsów w systemach Linux z dowolnych nazwach, takich jak [ wan0, lan0, lan1, dmz0], które będą łamać żadnych założeń dotyczących początkowych liter .

użytkownik4556274
źródło
7
A niektórzy z nas są zagorzałymi zwolennikami systemu.
Chrylis -on strike-
1
Pamiętaj, że to rozwiązanie nie będzie działać w systemach używających biosdevnamenazewnictwa interfejsów, w których interfejs Ethernet można nazwać jak p3p7. Ta metoda jest poprzednikiem nowej przewidywalnej nazwy systemowej i chociaż obecnie jest przestarzała w typowych dystrybucjach, nadal będzie wiele systemów, które wybrały ją, gdy była domyślna kilka lat temu.
TooTea,
systemd pomaga wywołać jeden z moich interfejsów Ethernet „rename3”. Który to może się różnić, westchnienie :(
user1908704
1
@ user1908704: Zwykle oznacza to, że udev kazano nadać tę samą nazwę wielu interfejsom. (Być może masz stary, automatycznie wygenerowany plik „nazw trwałych” w /etc/udev/rules.d?) To powiedziawszy, proces zmiany nazwy został naprawiony w wersji 187, aby był w pełni atomowy (albo sukces, albo wycofanie), a rename%uformat nie t istniał w kodzie źródłowym od 2012 roku. Chciałbym westchnąć, że wasze oprogramowanie jest sześć lat przestarzałe.
user1686,
1
@grawity To jest Ubuntu 18.04. Okazuje się, że niektóre płyty główne mają dwie karty sieciowe z tym samym wpisem ACPI, w wyniku czego obie są eno1. Ponieważ tak się nie dzieje, jeden z nich nazywa się „rename3”. Nie do końca opracowałem logikę wygranej w wyścigu, ale wszelkie zmiany mogą zakłócać konkurencję i powodować zmianę nazwy drugiej.
user1908704
8

Konwencja nazewnictwa jest to, że interfejsy LAN są nazywane eth0, eth1... i że interfejsy WLAN są nazywane wlan0, wlan1...

To, co widzisz, to tak zwane „przewidywalne nazwy”, które wprowadził system. W praktyce są one mało przewidywalne, a nawet mogą ulec zmianie po zmianie sprzętu, co jest dokładnie problemem, którego powinni unikać.

Domyślam się, że litera początkowa może być wystarczająca. Niektóre interfejsy, w szczególności WLAN, mają podpowiedzi w /sys/class/net/*/uevent:

DEVTYPE=wlan

Niestety nie ma takich DEVTYPEinterfejsów LAN.

RalfFriedl
źródło
2
Nazwy urządzeń zmieniają się, gdy zmiany sprzętowe nie stanowią problemu, którego nazwy interfejsów stara się uniknąć. Przewidywalne nazwy interfejsów pozwalają uniknąć zmian nazw, gdy sprzęt pozostaje niezmieniony . Jest to problem, gdy urządzenia są wykrywane w losowej kolejności.
Johan Myréen,
@ JohanMyréen To nieprawda: „... że (nazwa interfejsu) pozostają stałe, nawet jeśli sprzęt zostanie dodany lub usunięty” freedesktop.org/wiki/Software/systemd/...
RalfFriedl
Motywacją do wprowadzenia przewidywalnych nazw interfejsów było to, że sondowanie nie jest deterministyczne, a „przypisanie nazw” eth0 ”,„ eth1 ”itd. Nie jest już naprawione i może się zdarzyć, że„ eth0 ”na jednym rozruchu będzie „eth1” w następnym. ” Jest to bonus, jeśli przewidywalne nazwy mogą przetrwać zmiany sprzętowe, ale nie był to główny ich powód.
Johan Myréen,
1
Wygraj trochę, zgub trochę - w niektórych scenariuszach bardzo pożądane jest, jeśli zmieniony sprzęt niezawodnie kliknie w to samo „gniazdo nazewnictwa” :)
rackandboneman,
@ JohanMyréen Stary schemat przypisywania nazw interfejsów na podstawie MAC lub niektórych innych właściwości działał bardziej niezawodnie podczas dodawania interfejsów, bez kłopotów związanych z nowymi nazwami.
RalfFriedl
5

Jedno zastrzeżenie z moją odpowiedzią (dotyczy również większości pozostałych): nie znam celu twojej aplikacji. Jeśli jest to aplikacja jednorazowa, która rozwiązuje jeden konkretny problem lub lepiej rozumie sieć, nigdy więcej nie będzie używana, to poleganie na pierwszej literze interfejsu może być świetną szybką i brudną opcją. Jeśli planujesz napisać kolejnego konkurenta do Wireshark lub tcpdump, musisz upewnić się, że masz rację.

A jeśli pisana przez Ciebie aplikacja znajduje się gdzieś pomiędzy tymi skrajnościami, tylko Ty (i Twoi klienci) możesz wiedzieć, jak ostrożnie musisz wdrożyć swoją logikę.

Inni wskazywali już, że nazwy te nigdy nie są wiarygodne z wielu powodów. Ostateczny problem jest bardzo powszechny w oprogramowaniu: założenia zakodowane na stałe zamiast polegać na znanych / udokumentowanych faktach.

Drugi problem, o którym nie wspomniano, opiera się również na założeniu o twoich wymaganiach: lista interfejsów, które chcesz wymienić, to zawsze dokładnie „sprzętowe interfejsy Ethernet” i „interfejsy Wi-Fi”.

Trzecia kwestia to kolejne założenie: że cały interfejs będzie należał do kategorii, o których możesz teraz pomyśleć. Co powiesz na Infiniband, o którym wspomniał @ user4556274? Co powiesz na interfejsy tunelowe dla VPN? Co powiesz na zmostkowane interfejsy? Co powiesz na pomostowe interfejsy łączące interfejsy fizyczne i logiczne?

Ale mogą istnieć opcje, aby osiągnąć to, czego szukasz. Najpierw zdefiniuj dokładnie, co charakteryzuje interfejs, który chcesz wyświetlić, a nie interfejs, którego nie chcesz.

W większości przypadków jedną z cech, na których można polegać, jest tablica routingu (będzie to jednak działać tylko wtedy, gdy interfejs jest włączony, więc może nie być tym, czego tak naprawdę szukasz).

Każdy interfejs, który ma domyślną trasę (tj. Trasę do 0.0.0.0), prawdopodobnie będzie tym, którego szukasz.

Zauważ, że nawet to wciąż opiera się na założeniu, po prostu bardziej niezawodnym: można sobie wyobrazić, że system jest skonfigurowany do kierowania całego ruchu wychodzącego przez maszynę wirtualną lub kontener dokujący (na przykład, jeśli istnieje kontener z zaporą ogniową ). Jest też odwrotnie: administrator systemu może potencjalnie zablokować ruch zewnętrzny, usuwając domyślną trasę.

Inną opcją jest obejście rzeczywistego sprzętu i sprawdzenie, którego sterownika używa. Następnie możesz wykluczyć niektóre dobrze znane sterowniki

Kevin Keane
źródło
4

Czy wyraźnie wykluczasz interfejsy powiązane lub zespolone? Naszym domyślnym tutaj jest użycie bond0lub team0jako podstawowy interfejs dla naszych serwerów.

Myślę, że musisz przemyśleć swoją logikę. Może spróbuj wykonać iterację przez wszystkie zdefiniowane interfejsy sieciowe w danym systemie, podziel je między ethernet, wifi, infiband, serial itp., A następnie wykonaj swoją magię.

doneal24
źródło
3

Nie koduj na stałe ani nie dopasowuj wzorca do nazw sprzętowych. Dotyczy to wszystkich urządzeń. Polegaj na narzędziach dostarczonych przez udev, aby określić listę urządzeń i podjąć odpowiednie działania. Zobacz 16.7 Trwałe nazewnictwo urządzeń , a następnie przeczytaj cały ten dokument , w szczególności 16.2 i 16.3. Zauważ, że udev jest agnostyczny dla dystrybucji, a także dla systemu inicjującego, ponieważ udev jest obecnie preferowaną metodą zarządzania urządzeniami w systemie Linux.

Zauważ, że @ user4556274, nawiązał do tego w swojej odpowiedzi, odnosząc się do tego udev-builtin-net-id.c, co w skrócie oznacza, że ​​wzorzec dopasowania, który próbujesz osiągnąć, jest wbudowaną częścią udev.

Cytując PredictableNetworkInterfaceNames :

W systemd 197 dodaliśmy natywną obsługę wielu różnych zasad nazewnictwa do właściwego systemd / udevd i nadaliśmy domyślny schemat podobny do biosdevname (ale ogólnie bardziej wydajny i bliższy wewnętrznym schematom identyfikacji urządzeń jądra). Udev natywnie obsługuje następujące różne schematy nazewnictwa interfejsów sieciowych:

  1. Nazwy zawierające numery indeksowe dostarczone przez Firmware / BIOS dla urządzeń pokładowych (przykład: eno1)
  2. Nazwy zawierające numery indeksów gniazd hotplug PCI Express podanych w oprogramowaniu układowym / systemie BIOS (przykład: ens1)
  3. Nazwy zawierające fizyczne / geograficzne położenie złącza sprzętu (przykład: enp2s0)
  4. Nazwy zawierające adres MAC interfejsów (przykład: enx78e7d1ea46da) Klasyczne, nieprzewidywalne nazewnictwo ethX dla jądra (przykład: eth0)

Domyślnie systemd v197 będzie teraz nazywał interfejsy zgodnie z polityką 1), jeśli informacje z oprogramowania wewnętrznego są dostępne i dostępne, cofając się do 2), jeśli te informacje z oprogramowania wewnętrznego są dostępne i dostępne, cofając się do 3), jeśli dotyczy, cofając się do 5) we wszystkich innych przypadkach. Zasada 4) nie jest domyślnie używana, ale jest dostępna, jeśli użytkownik tak wybierze.

Te połączone zasady są stosowane tylko w ostateczności. Oznacza to, że jeśli system ma zainstalowaną nazwę biologiczną, będzie mieć pierwszeństwo. Jeśli użytkownik doda reguły udev, które zmieniają nazwy urządzeń jądra, również one będą miały pierwszeństwo. Ponadto wszelkie schematy nazewnictwa specyficzne dla dystrybucji zwykle mają pierwszeństwo.

eyoung100
źródło
2

Jak powiedzieli inni, nie możesz w pełni polegać na nazwie.

W moim przypadku wydaje się, że dla sieci bezprzewodowej /sys/class/net/<ifacename>/będzie miał katalog o nazwie „bezprzewodowy”, jeśli jest to interfejs bezprzewodowy:

# 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
źródło