Penamaan standar konvensi untuk antarmuka Ethernet dan Wi-Fi pada mesin Linux

13

Apa standar konvensi penamaan untuk antarmuka Ethernet dan Wi-Fi pada mesin Linux?

Kami sedang mengembangkan alat yang seharusnya hanya menampilkan antarmuka Ethernet dan Wi-Fi dari mesin Linux dan statusnya saat ini.

Sebagai contoh, di bawah ini adalah daftar antarmuka jaringan (baik fisik dan virtual) di mesin Linux (Ubuntu) saya:

docker0, enp0s25, lo,wlp3s0

Ketika saya menjalankan alat, di bawah ini adalah hasil yang saya dapatkan:

enp0s25, wlp3s0

Kami telah menulis kode dengan logika bahwa semua antarmuka Ethernet selalu dimulai dengan huruf edan antarmuka Wi-Fi selalu dimulai dengan huruf w.

Apakah logikanya benar? Jika tidak, bagaimana kita mengatasi ini?

— Mohan Raj
sumber

terkait: unix.stackexchange.com/a/179931/117549

— Jeff Schaller

Saya akan melihat bagaimana iwconfigfilter antarmuka WiFi dari yang lain.

— Patrick Mevzek

1

Apakah ada alasan mengapa Anda tidak melihat sesuatu seperti lshw? Khusus memeriksa isi lshw -class networkmungkin? Cari semua yang ada capabilities: ethernet physical? Mungkin mencari beberapa kemampuan lain juga?

— Zoredache

Untuk menghadapi tantangan bingkai yang diangkat oleh @dirkt, pertanyaan yang lebih baik adalah: "bagaimana saya mendapatkan jenis antarmuka jaringan di Linux (atau macOS, atau lainnya ...)?"

— Roger Lipscombe

41

Antarmuka jaringan dapat dinamai apa saja, jadi apa pun yang Anda lakukan, Anda akan mengalami situasi di mana (1) ada antarmuka jaringan "fisik" dengan nama yang tidak cocok dengan pola Anda, atau (2) ada Antarmuka jaringan "fisik" yang akan cocok dengan pola Anda.

Lebih dari itu, jika saya adalah pengguna alat Anda, saat alat Anda tidak akan memungkinkan saya untuk melakukan sesuatu yang saya inginkan, karena saya memiliki antarmuka jaringan yang "virtual", meskipun untuk tujuan praktis itu harus dipertimbangkan " fisik "di pengaturan saya, saya akan mulai mengutuk keras dan paksa pada aplikasi Anda, dan tidak akan pernah menggunakannya lagi.

Antarmuka jaringan fisik dan virtual semua berbagi API umum adalah satu hal yang membuat Linux sangat fleksibel. Tolong jangan mencoba mengasuh pengguna Anda, dan ambil itu darinya. Pengguna Anda akan berterima kasih.

— dirkt
sumber

11

Anda belum benar-benar menjawab pertanyaan; Anda telah menghabiskan 3 paragraf menantang konteks latar belakang pertanyaan. Meskipun saya sadar bahwa jawaban tantangan bingkai adalah sesuatu, ini tidak terasa seperti salah satu kasus ... terutama karena pengguna 4556274 memberikan jawaban singkat untuk pertanyaan yang diajukan.

— Mike Ounsworth

18

@MikeOunsworth: Masalahnya adalah bahwa jawaban user4556274 tidak berfungsi dalam kasus umum, hanya berfungsi jika nama antarmuka memang nama antarmuka yang dapat diprediksi. Yang sederhana ip link set ... name ...bisa berubah. Dan ya, saya bisa membuat daftar nama antarmuka yang dapat diprediksi sendiri. Jawaban untuk pertanyaan awal adalah "tolong jangan lakukan itu". Karena tidak peduli bagaimana Anda melakukannya, itu tidak akan berhasil.

— dirkt

@ fpmurphy1 Tidak, saya pikir maksudnya adalah nama antarmuka yang dapat diprediksi. Tidak masalah apakah itu systemd, tradisional (ethN), konvensi khusus perusahaan Anda atau standar lain yang membuat nama-nama itu dapat diprediksi

— slebetman

12

@MikeOunsworth: Jawabannya ada pada sub-klausa pertama dari kalimat pertama paragraf pertama: "Antarmuka jaringan bisa diberi nama apa saja [...]" Oleh karena itu, apa yang ditanyakan OP tidak mungkin dan tidak mungkin dilakukan . Anda tidak dapat mendeteksi tipe antarmuka jaringan berdasarkan standar konvensi penamaan, karena tidak ada standar konvensi penamaan dan siapa pun dapat memberi nama antarmuka apa pun yang mereka inginkan. Sebagai contoh, pada router Linux lama saya, saya kepala stiker berwarna di bagian belakang, dan antarmuka Ethernet fisik diberi nama red, bluedan green.

— Jörg W Mittag

1

@ JörgWMittag, tentu saja Anda dapat mendeteksinya berdasarkan standar, jika Anda tahu standar yang digunakan (dan Anda mengharapkan yang mengekspor informasi dalam nama di tempat pertama). Kami tahu systemd memiliki standar untuk penamaan antarmuka jaringan , jadi tidak ada gunanya mengatakan tidak ada.

— ilkkachu

28

Untuk nama antarmuka yang dapat diprediksi oleh systemd , awalan dapat dilihat di 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

jadi untuk ethXpenamaan gaya tradisional dan penamaan systemd yang lebih baru, huruf awal e haruslah antarmuka ethernet untuk nama antarmuka yang dibuat secara otomatis. Semua antarmuka wifi harus dimulai dengan w di kedua skema, meskipun tidak semua antarmuka yang dimulai dengan w akan menjadi wifi.

Jika alat ini harus bekerja dalam lingkungan yang arbitrer (bukan hanya pada lingkungan internal yang Anda kendalikan), perhatikan bahwa pengguna dapat mengubah nama antarmuka pada sistem linux dengan nama yang arbitrer, seperti [ wan0,lan0 , lan1, dmz0] yang akan mematahkan asumsi tentang huruf awal .

— pengguna4556274
sumber

7

Dan beberapa dari kita adalah systemusen refuseniks yang setia.

— chrylis -pada mogok-

1

Perhatikan bahwa solusi ini tidak akan bekerja pada sistem yang menggunakan biosdevnamepenamaan antarmuka, tempat antarmuka Ethernet dapat dinamai seperti p3p7. Metode ini adalah pendahulu dari nama sistemd baru yang dapat diprediksi dan meskipun sekarang sudah usang pada distro umum, masih akan ada banyak sistem yang mengambilnya ketika itu adalah default beberapa tahun yang lalu.

— TooTea

systemd membantu memanggil salah satu antarmuka ethernet saya 'rename3'. Yang mana itu bisa bervariasi, sigh :(

— user1908704

1

@ user1908704: Biasanya ini berarti udev disuruh memberikan nama yang sama ke banyak antarmuka. (Mungkin Anda memiliki file "persistent names" yang dihasilkan secara otomatis di /etc/udev/rules.d?) Yang mengatakan, proses penggantian nama diperbaiki di v187 menjadi sepenuhnya atom (baik berhasil atau kembalikan) dan rename%uformat belum t ada dalam kode sumber sejak 2012. Saya ingin mendesah perangkat lunak Anda menjadi enam tahun kedaluwarsa.

— user1686

1

@grawity Ini Ubuntu 18.04. Ternyata motherboard tertentu memiliki dua NIC dengan entri ACPI yang sama, sehingga keduanya sama-sama eno1. Karena itu tidak bisa terjadi, salah satunya disebut 'rename3'. Saya belum sepenuhnya memahami logika siapa yang memenangkan perlombaan, tetapi perubahan apa pun dapat mengganggu kontes dan menyebabkan yang lain berganti nama3.

— user1908704

9

Konvensi penamaan adalah bahwa interface LAN diberi nama eth0, eth1... dan bahwa interface WLAN diberi nama wlan0, wlan1...

Apa yang Anda lihat adalah apa yang disebut "nama yang dapat diprediksi" yang diperkenalkan oleh systemd. Dalam praktiknya, mereka sama sekali tidak dapat diprediksi, dan mereka bahkan dapat berubah ketika perangkat keras diubah, yang merupakan masalah yang seharusnya mereka hindari.

Sebagai tebakan, huruf awal mungkin cukup bagus. Beberapa antarmuka, khususnya WLAN, memiliki petunjuk di /sys/class/net/*/uevent:

DEVTYPE=wlan

Sayangnya, tidak ada DEVTYPEantarmuka LAN untuk itu.

— RalfFriedl
sumber

2

Nama perangkat berubah ketika perubahan perangkat keras bukan masalah yang bisa dihindari oleh nama antarmuka yang diprediksi. Nama antarmuka yang dapat diprediksi menghindari perubahan nama saat perangkat keras tidak berubah . Ini adalah masalah ketika perangkat perangkat keras terdeteksi dalam urutan acak.

— Johan Myréen

@ JohanMyréen Itu salah: "... bahwa mereka (nama antarmuka) tetap tetap meskipun perangkat keras ditambahkan atau dihapus" freedesktop.org/wiki/Software/systemd/…

— RalfFriedl

Motivasi untuk memperkenalkan nama antarmuka yang dapat diprediksi adalah bahwa probing tidak deterministik dan "penugasan nama" eth0 "," eth1 "dan seterusnya tidak diperbaiki lagi dan mungkin sekali terjadi" eth0 "pada satu boot akhirnya menjadi "eth1" pada selanjutnya. " Ini adalah bonus jika nama yang dapat diprediksi dapat selamat dari perubahan perangkat keras, tetapi ini bukan alasan utama bagi mereka.

— Johan Myréen

1

Menangkan sebagian kehilangan sebagian - dalam beberapa skenario, sangat diinginkan jika perangkat keras yang diubah secara andal mengklik ke dalam "slot penamaan" yang sama :)

— rackandboneman

@ JohanMyréen Skema lama untuk menetapkan nama antarmuka berdasarkan MAC atau beberapa properti lain bekerja lebih andal saat menambahkan antarmuka, tanpa perlu repot dengan nama-nama baru.

— RalfFriedl

5

Satu peringatan dengan jawaban saya (berlaku untuk sebagian besar yang lain juga): Saya tidak tahu tujuan aplikasi Anda. Jika itu adalah aplikasi sekali pakai untuk memecahkan satu masalah tertentu, atau untuk memahami jaringan yang lebih baik, tidak pernah digunakan lagi, maka mengandalkan huruf pertama dari antarmuka mungkin merupakan opsi cepat dan kotor yang bagus. Jika Anda berencana untuk menulis pesaing berikutnya ke Wireshark atau tcpdump, Anda harus yakin Anda melakukannya dengan benar untuk semua jenis casing tepi.

Dan jika aplikasi yang Anda tulis berada di antara yang ekstrem, hanya Anda (dan pelanggan Anda) yang dapat mengetahui seberapa cermat Anda perlu menerapkan logika Anda.

Yang lain telah menunjukkan bahwa nama-nama itu tidak pernah dapat diandalkan, karena sejumlah alasan. Masalah pamungkas adalah masalah yang sangat umum dalam perangkat lunak: asumsi pengkodean keras alih-alih mengandalkan fakta yang diketahui / didokumentasikan.

Masalah kedua yang belum disebutkan juga didasarkan pada asumsi tentang persyaratan Anda: bahwa daftar antarmuka yang ingin Anda daftarkan selalu persis "antarmuka perangkat keras ethernet" dan "antarmuka wifi".

Masalah ketiga adalah asumsi lain: bahwa semua antarmuka akan jatuh ke dalam kategori yang dapat Anda pikirkan saat ini. Bagaimana dengan Infiniband, seperti yang disebutkan oleh @ user4556274? Bagaimana dengan antarmuka terowongan untuk VPN? Bagaimana dengan antarmuka yang dijembatani? Bagaimana dengan antarmuka dijembatani yang menggabungkan antarmuka fisik dan logis?

Tetapi mungkin ada opsi untuk mencapai apa yang Anda cari. Pertama, tentukan dengan tepat apa yang mencirikan antarmuka yang ingin Anda daftarkan, vs yang tidak.

Dalam kebanyakan kasus, satu karakteristik yang dapat Anda andalkan adalah tabel routing (namun, ini hanya akan berfungsi selama antarmuka sudah aktif, sehingga mungkin bukan yang sebenarnya Anda cari).

Setiap antarmuka yang memiliki rute default (yaitu, rute ke 0.0.0.0) cenderung menjadi yang Anda cari.

Perhatikan bahwa meskipun ini masih didasarkan pada asumsi, hanya asumsi yang lebih andal: dapat dibayangkan bahwa sistem dikonfigurasikan untuk merutekan semua lalu lintas keluar melalui mesin virtual atau wadah buruh pelabuhan (misalnya, jika ada wadah yang menjalankan firewall) ). Dan sebaliknya juga benar: sysadmin berpotensi mengunci lalu lintas di luar dengan menghapus rute default.

Pilihan lain adalah menggunakan perangkat keras yang sebenarnya dan melihat driver yang digunakannya. Anda kemudian dapat mengecualikan driver tertentu yang terkenal

— Kevin Keane
sumber

4

Apakah Anda secara eksplisit mengecualikan antarmuka terikat atau tim? Default kami di sini adalah menggunakan bond0atauteam0 untuk antarmuka utama untuk server kami.

Saya pikir Anda perlu memikirkan kembali logika Anda. Mungkin coba ulangi semua antarmuka jaringan yang ditentukan pada sistem yang diberikan, bagilah di antara ethernet, wifi, infiband, serial, dll., Lalu lakukan keajaiban Anda.

— selesai24
sumber

3

Jangan hardcode, atau pola cocok dengan nama perangkat keras. Ini berlaku untuk semua perangkat. Andalkan alat yang disediakan oleh udev untuk menentukan daftar perangkat dan mengambil tindakan yang sesuai. Lihat 16.7 Penamaan Perangkat yang Persisten , dan kemudian baca seluruh dokumen itu , khususnya 16.2 dan 16.3. Perhatikan bahwa udev adalah agnostik distribusi, dan juga sistem agnostik init, karena udev sekarang merupakan metode yang disukai untuk manajemen perangkat di linux.

Perhatikan bahwa @ user4556274, menyinggung ini dalam jawabannya ketika merujuk udev-builtin-net-id.c, yang singkatnya berarti bahwa pencocokan pola yang Anda coba selesaikan adalah bagian bawaan udev.

Mengutip PredictableNetworkInterfaceNames :

Dengan systemd 197 kami telah menambahkan dukungan asli untuk sejumlah kebijakan penamaan yang berbeda ke dalam systemd / udevd yang tepat dan membuat skema yang mirip dengan biosdevname (tetapi umumnya lebih kuat, dan lebih dekat dengan skema identifikasi perangkat kernel-internal) sebagai default. Skema penamaan yang berbeda berikut untuk antarmuka jaringan sekarang didukung oleh udev secara native:

Nama yang memasukkan nomor indeks yang disediakan Firmware / BIOS untuk perangkat terpasang (contoh: eno1)

Nama-nama yang memasukkan Firmware / BIOS disediakan nomor indeks slot hotplug PCI Express (contoh: EN1)

Nama yang memasukkan lokasi fisik / geografis dari konektor perangkat keras (contoh: enp2s0)

Nama-nama yang memasukkan alamat MAC antarmuka (contoh: enx78e7d1ea46da) Klasik, penamaan ethX kernel-asli yang tidak dapat diprediksi (contoh: eth0)

Secara default, systemd v197 sekarang akan menamai antarmuka mengikuti kebijakan 1) jika informasi dari firmware berlaku dan tersedia, turun kembali ke 2) jika informasi dari firmware tersebut berlaku dan tersedia, turun kembali ke 3) jika berlaku, mundur kembali ke 5) dalam semua kasus lainnya. Kebijakan 4) tidak digunakan secara default, tetapi tersedia jika pengguna memilihnya.

Kebijakan gabungan ini hanya diterapkan sebagai upaya terakhir. Itu berarti, jika sistem memiliki biosdevname diinstal, itu akan diutamakan. Jika pengguna telah menambahkan aturan udev yang mengubah nama perangkat kernel, ini juga akan diutamakan. Juga, setiap skema penamaan spesifik distribusi umumnya diutamakan.

— eyoung100
sumber

2

Seperti yang dikatakan orang lain, Anda tidak dapat sepenuhnya bergantung pada namanya.

Dalam kasus saya tampaknya untuk nirkabel /sys/class/net/<ifacename>/akan memiliki direktori bernama "nirkabel" di dalamnya jika itu adalah antarmuka nirkabel:

# 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
sumber