Linux判断无线网卡状态

靠ip/ifconfig获取网络接口信息来判断网卡状态(比如是否启用)是不可靠的。

为什么ip a不可靠

在实际开发中遇到过这样的情况：明明ip a显示网卡是UP状态，但无线功能就是不工作。排查了很久才发现，原来是网卡被rfkill软件禁用了。这种情况下，传统的网络命令根本看不出问题所在。

所以更可靠的做法是使用rfkill list命令，根据结果中的Soft blocked和Hard blocked字段来判断网卡的真实状态。Soft blocked表示软件层面的禁用，Hard blocked则是硬件开关导致的禁用。只有这两个状态都是no时，无线网卡才真正可用。

理解抽象层次

Linux 将 WLAN 接口映射到能够使用 ip link 命令看到的通用接口对象。像 ip 这类命令运作在较高的抽象层上，其将 Ethernet、TAP、WLAN 这样实际的物理介质都抽象掉了。更具体来说，这些物理差异是由内核中的 struct net_device 结构体统一抽象的。

这意味着，ip命令看到的是一个通用的网络接口视图，它不关心底层到底是有线网卡、无线网卡还是虚拟网卡。对于ip来说，它们都只是"网络接口"而已。这种设计简化了网络管理，但也导致了一个问题：你无法从这个层面获知物理层的真实状态。

PHY 索引是指在无线网络设备中与物理层（PHY）相关的特定标识符。它用于标识特定的物理层设备，通常在多个无线接口或设备并存的系统中出现。每个无线接口可能对应不同的 PHY，因此通过索引可以准确定位到具体使用哪个物理层硬件。

RFKill 状态是指无线设备的射频开关状态。RFKill 是 Linux 内核提供的一个用于管理无线设备射频功能的子系统，可以通过软件控制（软开关）或硬件控制（硬开关，如笔记本上的物理开关或组合键）来启用和禁用无线功能。这个机制独立于网络接口的UP/DOWN状态，是更底层的控制手段。

换句话说，即使网络接口状态是UP，但如果rfkill把射频关闭了，无线功能依然不可用。这就是为什么单纯看ip a的结果不够准确的原因。

具体差异对比

ip a 显示的是网络接口的整体状态，包括接口是否启用、IP 地址配置、MAC 地址、广播地址、MTU等网络层和数据链路层的信息。它给出的是一个"逻辑视图"。 而 PHY 索引和 RFKill 状态则专注于无线接口的物理层和射频控制状态，提供更细粒度的底层信息。这是一个"物理视图"，更接近硬件本身的真实状态。

这是最容易踩的坑：ip a 不会直接显示 RFKill 状态。如果无线功能被软件或硬件禁用（即 RFKill blocked），ip a 仍然可能显示接口为"UP"状态，看起来一切正常，但实际上无线射频已经被关闭，根本无法扫描到WiFi信号或建立连接。 这种表里不一的情况会让开发者或用户感到困惑，以为网卡正常工作，实际上问题出在更底层。

ip a 只提供网络层和数据链路层的信息，对于物理层的实现细节完全不可见。而在无线网络中，可能存在多个 PHY 接口（比如支持双频的网卡会有多个物理层接口），ip a无法告诉你当前使用的是哪个PHY，也看不到射频硬件的实际状态。

这个问题在国产操作系统适配时尤其明显。统信UOS与麒麟V10虽然都基于Linux，但在网卡管理的实现上有明显区别：

在UOS系统中，当你在图形界面的网卡管理中点击"禁用无线网卡"，系统其实只是做了一个表面动作，底层的网卡接口依然是UP状态。这更像是一种"软禁用"，可能只是停止了NetworkManager对该接口的管理，或者设置了某些标志位，但并没有真正DOWN掉接口。

而麒麟V10的处理更彻底，它会真正把无线网卡DOWN掉，使用ip a就能看到接口状态变成了DOWN。这种差异意味着，如果你的程序依赖ip a的输出来判断网卡状态，在不同系统上可能得到完全不同的结果。 所以，想要写出跨平台兼容的网卡状态检测逻辑，必须结合rfkill机制，而不能只依赖传统的网络接口状态查询命令。这样才能准确判断网卡在不同系统、不同禁用方式下的真实可用性。

总结

判断Linux无线网卡状态时，建议采用rfkill list配合网络接口状态的组合判断方式。单独使用ip或ifconfig可能会得到不准确的结果，特别是在处理跨平台兼容或者需要精确控制无线功能的场景中。记住这个原则：网络接口UP不等于射频可用，射频未blocked才是无线功能真正可用的前提。