Linux机器上以太网和Wi-Fi接口的命名约定标准

13

Linux机器上的以太网和Wi-Fi接口的命名约定标准是什么？

我们正在开发一种仅显示Linux机器的以太网和Wi-Fi接口及其当前状态的工具。

例如，以下是我的Linux（Ubuntu）计算机上的网络接口（物理和虚拟）列表：

docker0，enp0s25，lo，wlp3s0

当我运行该工具时，得到的结果如下：

enp0s25， wlp3s0

我们编写的代码具有以下逻辑：所有以太网接口始终以字母开头，e而Wi-Fi接口始终以字母开头w。

逻辑对吗？如果没有，我们如何解决呢？

— 莫汉·拉吉（Mohan Raj）
source

相关：unix.stackexchange.com/a/179931/117549

— Jeff Schaller

我将研究如何iwconfig从其他接口过滤WiFi接口。

— Patrick Mevzek '18年

1

您为什么不看lshw之类的东西是有原因的？具体检查一下内容lshw -class network吧？寻找的是capabilities: ethernet physical什么？可能还会寻找其他功能吗？

— Zoredache '18年

为了应对@dirkt提出的框架挑战，一个更好的问题是：“如何在Linux（或macOS或其他...）上获得网络接口的类型？”

— 罗杰·利普斯科姆

41

网络接口可以命名为任何名称，因此无论您做什么，都会遇到以下情况：（1）存在一个“物理”网络接口，其名称与您的模式不匹配；或者（2）存在一个将与您的模式匹配的“物理”网络接口。

最重要的是，如果我是您的工具的用户，那一刻您的工具将不允许我做我想做的事情，因为我有一个“虚拟”网络接口，尽管出于实用目的，它应该被视为“物理”中，我将开始大声地对您的应用程序进行诅咒，并且永远不会再使用它。

物理和虚拟网络接口都共享一个通用的API，这使Linux真正具有灵活性。请不要试图照顾您的用户，并将其从他或她身边拿走。您的用户将感谢您。

— 直接
source

11

您实际上尚未回答问题；您花了3个段落来挑战问题的背景。虽然我知道框架质询答案是一回事，但感觉不像是其中一种情况...尤其是因为user4556274 对所询问的问题给出了简洁的答案。

— Mike Ounsworth

18

@MikeOunsworth：问题是user4556274的答案在一般情况下不起作用，仅当接口名称确实是可定义的接口名称时才有效。一个简单的ip link set ... name ...就可以改变。是的，我本来可以列出可预测的接口名称。原始问题的答案是“请不要那样做”。因为无论您怎么做，它都不会起作用。

— dirkt

@ fpmurphy1不，我认为他的意思是可预测的接口名称。不管是系统化的，传统的（ethN），贵公司的特定惯例还是可预测名称的任何其他标准

— slebetman

12

@MikeOunsworth：答案就在第一段第一句的第一小节中：“网络接口可以命名为[…]”因此，OP询问的内容是不可能的，而且不可能做到。您无法基于命名约定标准检测网络接口的类型，因为没有命名约定标准，任何人都可以根据需要命名其接口。例如，我的老的Linux路由器，我把头颜色的贴纸就回来了，和物理以太网接口被命名为red，blue和green。

— 约尔格W¯¯米塔格

1

@JörgWMittag，当然，如果您知道使用的是标准，则可以基于标准进行检测（并且您期望一个首先以名称导出该信息的标准）。我们知道systemd有一个用于网络接口命名的标准，因此说一个不存在没有用。

— ilkkachu

28

对于系统可预测的接口名称，可以在以下位置看到前缀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

因此，对于传统ethX的命名方式和较新的systemd命名方式，首字母e应该是任何自动生成的接口名称的以太网接口。在这两种方案中，所有wifi接口均应以w开头，尽管并非所有以w开头的接口都是wifi。

如果这个工具有工作在任意环境（而不是仅仅在其上控制内部环境），请注意，用户可以重命名任意名称，如[Linux系统的接口wan0，lan0，lan1，dmz0]这将打破约首字母的任何假设。

— 用户名
source

7

我们中有些人是坚定的系统拒绝者。

— chrylis-罢工-18年

1

请注意，该解决方案不适biosdevname用于用于接口命名的系统，在该系统中，以太网接口可以命名为like p3p7。这种方法是新的系统可预测名称的前身，尽管现在已在通用发行版中弃用，但几年前它还是默认名称时，仍然有许多系统选择它。

— TooTea

systemd有帮助地将我的以太网接口之一称为“ rename3”。它是哪一个可以变化，叹息:(

— user1908704 '18

1

@ user1908704：通常这意味着udev被告知为多个接口赋予相同的名称。（也许你有一个旧的自动生成的“持久性名称” /etc/udev/rules.d中的文件吗？）这就是说，重命名过程固定在v187是完全原子（成功或回滚）和rename%u格式不是招”自2012年以来，源代码中就没有这个词。对于您的软件已经过时了六年，我谨表示感叹。

— user1686 '18

1

@grawity这是Ubuntu 18.04。事实证明，特定的主板有两个具有相同ACPI条目的NIC，因此它们都是eno1。由于这不可能发生，因此其中之一被称为“ rename3”。我还没有完全弄清楚谁在比赛中获胜的逻辑，但是任何更改都会干扰比赛并导致其他人重新命名。

— user1908704 '18

9

命名约定是LAN接口的名称eth0，eth1......和WLAN接口的名称wlan0，wlan1...

您所看到的是systemd引入的所谓“可预测名称”。实际上，它们是不可预测的，甚至在更改硬件时也可以更改，这正是他们应避免的问题。

猜猜起始字母可能就足够了。一些接口，特别是WLAN，在/sys/class/net/*/uevent以下方面有提示：

DEVTYPE=wlan

不幸的是，DEVTYPELAN接口没有这种接口。

— 拉尔夫·弗里德尔
source

2

当硬件更改不是设备名称更改时，可预测的接口名称试图避免这个问题。可预测的接口名称避免了硬件不变时的名称更改。当以随机顺序检测硬件设备时，这是一个问题。

— 约翰·迈伦（JohanMyréen）'18

@JohanMyréen这是错误的：“ ...即使添加或删除了硬件，它们（接口名称）也保持

— 不变

引入可预测接口名称的动机是，探测不是确定性的，并且名称“ eth0”，“ eth1”等的分配不再固定，很可能会在一个引导中最终出现“ eth0”接下来是“ eth1”。如果可预测的名称可以在硬件更改中幸存下来，这是一个好处，但这不是主要原因。

— 约翰·迈伦（JohanMyréen）'18

1

输赢一些-在某些情况下，如果更改的硬件可靠地单击到相同的“命名槽”中，则非常可取：)

— rackandboneman 18/11/2

@JohanMyréen在添加接口时，基于MAC或其他一些属性分配接口名称的旧方案更加可靠，而无需担心新名称的麻烦。

— RalfFriedl

5

请注意我的答案（也适用于大多数其他答案）：我不知道您的应用程序的目的。如果它是用于解决一个特定问题或更好地理解网络的一次性应用程序，而永远不要再次使用它，那么依靠接口的第一个字母可能是个不错的选择。如果您打算将下一个竞争对手写给Wireshark或tcpdump，则需要确保对各种极端情况都正确。

而且，如果您正在编写的应用程序介于这两个极端之间，那么只有您（和您的客户）才能知道您需要多么认真地实现逻辑。

其他人已经指出，出于多种原因，这些名称永远都不可靠。最终问题是软件中的一个非常普遍的问题：硬编码假设而不是依赖已知/记录的事实。

未提及的第二个问题也基于关于您的要求的假设：要列出的接口列表始终完全是“硬件以太网接口”和“ wifi接口”。

第三个问题是另一个假设：所有接口都将属于您现在可以想到的类别。@ user4556274提到的Infiniband怎么样？VPN的隧道接口如何？桥接接口如何？结合了物理和逻辑接口的桥接接口怎么样？

但是可能会有选择来完成您想要的。首先，准确定义您要列出的接口的特征，而不是您要列出的接口。

在大多数情况下，您可以依靠的一个特征是路由表（但是，只有在接口打开的情况下，路由表才起作用，因此它可能并不是您真正要寻找的东西）。

具有默认路由（即到0.0.0.0的路由）的任何接口都可能是您要查找的接口。

请注意，即使这仍基于一种假设，只是一种更可靠的假设：可以想象将系统配置为通过虚拟机或Docker容器路由所有出站流量（例如，如果有运行防火墙的容器）。反之亦然：系统管理员可以通过删除默认路由来锁定外部流量。

另一种选择是通过实际硬件查看其使用哪个驱动程序。然后，您可以排除某些知名的驱动程序

— 凯文·基恩
source

4

您是否明确排除绑定或成组的接口？我们的默认设置是使用bond0或team0作为服务器的主界面。

我认为您需要重新考虑自己的逻辑。也许尝试遍历给定系统上所有已定义的网络接口，然后将它们划分为以太网，wifi，infiband，串行设备等，然后尽力而为。

— 杜纳尔24
source

3

不要硬编码或模式匹配硬件名称。这适用于所有设备。依靠udev提供的工具确定设备列表并采取适当的措施。请参阅16.7持久性设备命名，然后通读整个文档，尤其是16.2和16.3。请注意，udev与发行版无关，也与init系统无关，因为udev现在是Linux中设备管理的首选方法。

请注意，@ user4556274在引用时在其答案中提到了udev-builtin-net-id.c这一点，简而言之，这意味着您要完成的模式匹配是的内置部分udev。

引用PredictableNetworkInterfaceNames：

在systemd 197中，我们将对许多不同命名策略的本机支持添加到了systemd / udevd适当的目录中，并将默认方案类似于biosdevname的方案（但通常更强大，并且更接近于内核内部设备标识方案）。udev现在支持以下网络接口的不同命名方案：

包含固件/ BIOS的名称为板载设备提供了索引号（例如：eno1）

包含固件/ BIOS的名称提供的PCI Express热插拔插槽索引号（例如：ens1）

包含硬件连接器的物理/地理位置的名称（例如：enp2s0）

包含接口的MAC地址的名称（示例：enx78e7d1ea46da）经典的，不可预测的内核本地ethX命名（示例：eth0）

默认情况下，systemd v197现在将按照策略1）命名接口，如果来自固件的信息适用并且可用，则回退到2）如果来自固件的信息适用并且可用，则回退到3）（如果适用）并回退到5）。默认情况下不使用策略4），但如果用户选择使用策略4）。

此组合政策仅在万不得已时才适用。这意味着，如果系统安装了biosdevname，它将具有优先权。如果用户添加了udev规则来更改内核设备的名称，则这些规则也将优先。同样，任何特定于发行版的命名方案通常都优先。

— eyoung100
source

2

正如其他人所说，您不能完全依赖名称。

在我的情况下，如果无线接口是无线接口，似乎其中/sys/class/net/<ifacename>/将有一个名为“无线”的目录：

# 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）
source