WiFi 接入主线

设备日志里已经写着 connected，业务却还是不通。问题通常不在一个“连上”的状态，而在 802.11 接入、安全建立、DHCP、DNS 和业务连接被混成了一步。

把 “看见 AP” “已关联” “密钥已装好” “已拿 IP” “业务已通” 当成同一个状态，是 WiFi 接入里最常见的误判之一。对嵌入式设备的实现、抓包和排障来说，这几个状态的观察点完全不同，混写之后，日志也会跟着失去判断力。

最常见的场景是 STA (Station) 接入普通 AP (Access Point) 的主链路，语境限定为 Open / WPA2-Personal / WPA3-Personal。802.1X、漫游、Mesh、WiFi Direct 和高阶 PHY 细节先不展开。

扫描 -> 选 AP / BSSID -> 802.11 认证 -> 关联 -> 密钥安装 / 数据面可用 -> DHCP / DNS -> 业务联网

SSID (Service Set Identifier) 是网络名字，BSSID (Basic Service Set Identifier) 是某个具体 AP 无线接口的标识，通常就是它的 MAC 地址。终端看到的是 SSID，真正接入的是某个 BSSID。

最小心智模型：先切阶段，再切分层

WiFi 入网先分两层：

无线接入层：扫描、发现、认证、关联、密钥安装、链路可发数据
IP 入网层：地址获取、默认路由、DNS，以及后续业务连接

先看哪层，取决于现象：

现象	优先看哪层
扫不到 AP、连不上指定路由器	`802.11` 接入层
已连接但没有 IP	`DHCP`
有 IP 但域名不通	`DNS`
网关可达但业务失败	`TCP / TLS / 应用层`

现场要把下面五个状态分开：

已看到 AP
已关联
已安装密钥
已拿 IP
业务已通

它们不是同一状态。很多日志里的 connected，最多只够说明其中一段已经完成。

扫描在解决什么

STA 上电后并不知道目标网络在哪个信道，所以第一步只能先扫描。扫描解决的不是“我要不要连接”，而是“空口里现在有哪些候选对象”。

最常见的两种方式是：

被动扫描：监听各信道上的 Beacon
主动扫描：发送 Probe Request，等待 Probe Response

后续判断真正依赖的，不是“有没有搜到一个 WiFi 名字”，而是：

SSID
BSSID
Channel
RSSI
RSN IE (Robust Security Network Information Element) 里的安全能力
设备实际扫了哪些频段和信道

扫描阶段常见的高频误判有两类。

扫到 SSID 不等于后面一定能连上。它只说明某个 AP 在空口里可见，不说明安全能力和设备实现一定兼容。
看到同名 SSID 不等于看到了同一个 AP。一个 SSID 背后可以挂多个 BSSID，兼容性问题经常只落在其中某一个。

所以“扫不到”通常先检查：

设备是否支持目标频段
扫描结果里是否真的出现目标 BSSID
信道列表是否完整
RSSI 是否低到无法稳定关联
隐藏 SSID 是否让主动探测变得必要

为什么认证和关联要分开

扫到候选 BSSID 之后，终端才进入连接阶段。802.11 里的认证，不总等于“校验 WiFi 密码”。

对 Open 和大多数 WPA2-Personal 场景，最常见的是 Open System Authentication：

STA -> Authentication Request -> AP
STA <- Authentication Response <- AP

它更像“允许你进入下一阶段”，不是“密码已经验证完毕”。

所以它成功，只能说明：

AP 允许你继续下一步关联

不能说明：

密码已经正确
后续四次握手一定成功

随后进入关联：

STA -> Association Request -> AP
STA <- Association Response <- AP

关联阶段主要完成：

STA 声明自己支持哪些能力
AP 决定是否接纳这个 STA
AP 分配 Association ID

对 WPA3-Personal 来说，这一段还要额外注意：前面的认证阶段通常就是 SAE (Simultaneous Authentication of Equals)，也就是：

WPA3-Personal 不再把“口令相关认证”完全放到关联之后
SAE 成功后才继续关联
关联成功后仍然要继续走四次握手安装数据面密钥

所以“卡在认证”和“卡在关联”不是一个问题，“关联成功”和“数据面已可用”也不是一个问题。

现场更该核对这些信息：

Association Response Status Code
请求和响应里的能力位是否匹配
RSN IE、支持速率、信道带宽、PMF (Protected Management Frames) 要求是否一致

为什么关联之后还不能立刻发业务数据

如果网络是开放网络，关联成功后通常就可以继续走网络层流程。可对加密网络来说，关联成功后还只是“挂进了这个 BSS (Basic Service Set)”，后面还得把数据面密钥真正装好。

加密网络里最常见的两条路径如下：

WPA2-Personal
扫描 -> Open System Authentication -> Association -> 4-Way Handshake -> DHCP / DNS

WPA3-Personal
扫描 -> SAE -> Association -> 4-Way Handshake -> DHCP / DNS

安全细节和 WPA2 / WPA3 / PMF 的分工，放到 WiFi 安全：WPA2、WPA3 与 PMF 展开。对主链路判断来说，加密网络里只有密钥安装完成，后面的 DHCP 才真正有意义。

DHCP / DNS 为什么必须单独算下一层

无线链路可发数据之后，设备才进入真正的 IP 入网阶段。最常见的是：

DHCP Discover
-> DHCP Offer
-> DHCP Request
-> DHCP Ack

DHCP 交付的通常不只是一个 IP，还包括：

IP 地址
子网掩码
默认网关
DNS 服务器
租约时间

拿到这些参数之后，业务仍然不一定通。还要继续确认：

是否能到达默认网关
是否能解析业务域名
是否能成功建立 TCP / TLS 连接

所以 “已连接但没有 IP” 和 “有 IP 但业务不通” 已经不是同一层问题。

抓包和系统日志在这一段也经常错位：

阶段	抓包里更容易看到什么	系统日志里更常怎么报
扫描	`Beacon / Probe Response`、目标 `SSID / BSSID / Channel`	`scan done`、找到候选 AP、`RSSI` 列表
认证 / 关联	`Authentication`、`Association Request / Response`、状态码	`auth failed`、`assoc reject`、`wrong capabilities`
密钥安装	`EAPOL-Key` 或 `SAE` 往返、是否进入受保护数据面	`4-way handshake timeout`、`key install failed`、`PMF mismatch`
IP 入网	`DHCP`、`ARP`、`DNS`	`dhcp timeout`、`no lease`、`dns resolve failed`

同一个现场里，抓包可能已经看到关联成功，日志却还停留在“connecting”；也可能日志已经报 connected，抓包却显示四次握手还没完成。判断时要先把它们对回同一阶段，再决定往哪层继续看。

现场先按什么顺序看

先看有没有扫描到目标 SSID / BSSID
扫到了，再看卡在认证、关联还是安全阶段
密钥安装完成后，再看 DHCP
有 IP 之后，再看网关、DNS 和后续 TCP / TLS

如果只能先留最少证据，优先保留：

扫描结果：SSID / BSSID / Channel / RSSI / Security
认证与关联结果：状态码、断开原因
安全阶段：EAPOL / SAE / PMF
DHCP 结果：地址、网关、DNS
业务入口：ARP、DNS、TCP / TLS

这条顺序的价值不在于把所有异常都覆盖完，而在于让你先把问题切到正确阶段，而不是笼统地说“设备连不上网”。

参考与继续阅读

规范入口

IEEE Std 802.11
- 扫描、认证、关联：Clause 11
- RSN / PMF / 安全协商：Clause 12
RFC 2131：DHCP
RFC 1034 / RFC 1035：DNS

继续阅读

WiFi 安全：WPA2、WPA3 与 PMF：继续看 WPA2 / WPA3 / PMF 为什么决定了“已关联”能不能变成“数据面可用”
DHCP：安全阶段完成后，为什么设备还可能卡在地址获取
DNS：已经拿到 IP 之后，为什么业务仍然可能因为名字解析失败而不可用