《WiFi 嵌入式物联网开发全套实战》| 第 34 章 无线抓包分析：扫描超时、关联失败、认证失败原因

专栏：《WiFi 嵌入式物联网开发全套实战》 专栏定位：嵌入式 Linux/ESP32 WiFi 从原理→驱动→配网→协议→稳定性→抓包调试→量产优化全套工业实战 适配：物联网设备、智能家居、工控网关、无线透传设备、4G+WiFi 双模设备 💖 点赞 + 收藏 + 关注，嵌入式 WiFi 量产实战全套教程持续更新！

本章前言

上一章我们搭建好了 Wireshark 无线抓包环境，掌握监听模式、过滤表达式。但拿到 pcap 抓包文件之后，很多开发者不知道该从哪里下手分析问题。

设备日志经常打印笼统报错：scan timeout、associate fail、auth fail，日志只给结果，不给真实根因。同样是连接失败，根因可能是：信道干扰、AP 拒绝关联、加密握手失败、国家码不匹配、信号太差丢帧、AP 接入满、漫游策略、802.11 保活拦截。

核心思路：抓包按照 WiFi 连接完整时序逐段排查：扫描 → 发送认证帧 → 认证应答 → 发送关联请求 → 关联应答 → 4‑way 握手 → DHCP 获取 IP，在哪一个流程中断，问题就锁定在哪一层。

本章围绕工程最高频三类故障：扫描超时、关联失败、认证失败，结合真实抓包现象、帧交互、reason_code、常见根因、定位步骤、修复方案，全部面向 ESP32 与嵌入式 Linux 物联网设备实战。

34.1 WiFi STA 完整连接时序回顾

1. Probe Request（设备扫描探测）→ Probe Response（AP 回复）
2. Authentication Request（设备认证请求）→ Authentication Response（AP 认证应答）
3. Association Request（设备关联请求）→ Association Response（AP 关联应答）
4. 4‑Way Handshake 四次握手（WPA/WPA2/WPA3 加密密钥协商）
5. DHCP 请求获取 IP 地址

任意一步没有收到对端响应，就会上报失败，设备重新进入重连逻辑。

34.2 故障一：扫描超时 Scan Timeout

34.2.1 设备现象

设备日志打印 WiFi scan done but no ap found，扫描超时，扫描列表为空，无法启动连接。

注意区分：完全扫描不到任何 AP；能扫到部分 AP，唯独搜不到目标 AP。

34.2.2 抓包观测要点

抓包网卡信道跟随设备扫描信道切换，重点观察：

1. 是否能够捕获到设备发出大量 Probe Request（wlan.fc.type_subtype == 0x04）
2. Probe Request 里面 SSID 字段：是广播扫描（空 SSID）还是定向扫描
3. AP 有没有回复 Probe Response
4. Probe Response 是否被空口干扰丢失，看不到应答帧

34.2.3 抓包对应的根因分类

场景 A：抓包看不到设备发出任何 Probe Request

• 设备 WiFi 驱动 / 射频异常，没有发出扫描报文；
• 国家码配置错误 ：信道被限制，设备不会发送对应信道探测帧；ESP‑IDF 必须正确配置wifi_country_t，否则部分信道直接禁用；
• 射频硬件故障、晶振偏移。

场景 B：设备发出 Probe Request，但是抓包看不到 AP 返回 Probe Response

1. AP 隐藏 SSID，关闭广播；设备定向扫描才可以发现；广播扫描搜不到；
2. 2.4G 信道干扰严重，Probe Response 空口丢包；
3. AP 开启 AP 隔离、黑名单，丢弃探测响应；
4. 设备与 AP 带宽模式不兼容。

场景 C：Probe Response 可以抓到，但是设备上层扫描结果为空

• 收到大量干扰噪声帧，驱动过滤掉 AP 条目；
• AP 信号 RSSI 过低，驱动 RSSI 阈值过滤直接丢弃 AP 记录；
• 扫描缓存溢出，AP 条目被覆盖。

34.2.4 工程修复方案

1. 固件必须正确设置 WiFi 国家码，匹配实际部署地区；
2. 隐藏 SSID 场景关闭广播扫描，使用定向 SSID 扫描；
3. 调整扫描参数：扫描信道驻留时间，干扰环境适当增大驻留时间；
4. 调高射频发射功率，避开拥挤信道；
5. 关闭固件端过强 RSSI 过滤阈值。

34.3 故障二：认证失败 Authentication Fail

认证失败发生在：Authentication Request/Response 交互阶段。 很多人混淆 802.11 认证和 WPA 四次握手：802.11 认证是链路层认证；4‑way 握手属于加密密钥协商，二者完全不是一回事。

34.3.1 现象

扫描 AP 列表正常，找到目标 AP，发起连接，日志报authentication failed，直接断开，无法走到关联阶段。

34.3.2 抓包观测

过滤：wlan.addr == 设备MAC && wlan.fc.type_subtype == 0x0b（Authentication 帧）

1. 设备发出 Authentication Request；
2. 看 AP 是否回复 Authentication Response；
3. 查看 Authentication 帧 status_code 状态码。

Status Code	含义	工程解读
0	成功	认证流程正常
1	未指定失败	AP 侧未知原因拒绝
2	无法支持认证算法	开放 / WEP/WPA 认证算法模式不匹配
13	无法接受该帧	AP 负载过高拒绝接入

34.3.3 典型实战场景

场景 1：开放网络，802.11 Open System 认证失败

抓包看到设备发认证请求，AP 回复 status_code=13。 根因：AP 接入数量已满，拒绝新客户端接入；或者 AP 开启 MAC 黑名单。

场景 2：WEP 模式认证报错

现在基本不再使用 WEP，部分老旧设备强制 WEP，固件配置模式不匹配，认证直接拒绝。

⚠️注意：WPA2‑PSK/WPA3 不会在这里返回密码错误；密码错误体现在 4‑way 握手阶段，不是 802.11 认证阶段，大量开发者踩这个坑。

34.3.4 排查步骤

1. 确认抓包中 Authentication Response 的 status_code；
2. 确认 AP 最大接入客户端数量是否打满；
3. 确认固件 WiFi 认证算法配置与 AP 匹配；
4. 检查 AP 黑名单、白名单策略；
5. 信号极差环境，认证请求帧空口丢包，收不到应答，表现为认证超时失败。

34.4 故障三：关联失败 Association Fail

扫描正常、802.11 认证交互成功，发送 Association Request 之后，AP 返回拒绝，日志打印 associate fail。 这是物联网设备最高频问题。

34.4.1 抓包过滤表达式

wlan.addr == 设备MAC && (wlan.fc.type_subtype == 0x00 || wlan.fc.type_subtype == 0x01)

• 0x00：Association Request 设备关联请求
• 0x01：Association Response AP 关联应答

重点查看 Association Response 里面的status_code状态码。

34.4.2 关键 Status Code 对照表

Status Code	含义	工程场景
0	关联成功	正常流程
10	能力不匹配	带宽、HT/VHT 模式不兼容；AP 不支持设备的无线能力
17	AP 已满	AP 最大客户端数量已满，拒绝关联
18	不支持速率集	设备与 AP 支持的基础速率不匹配
22	拒绝超时	AP 资源紧张，拒绝关联

34.4.3 高频真实案例复盘

案例 1：status_code=10 能力不匹配

现象：老 2.4G 路由器，关闭 HT 高速模式；ESP32 上报关联失败。 抓包 Association Request 携带 HT 能力字段，AP 无法解析，直接拒绝关联。 解决：固件配置关闭 HT 高速模式，强制使用 11g 模式。

案例 2：status_code=17 AP 客户端已满

家用路由器廉价 AP 最大接入 8‑16 台设备，设备多之后直接拒绝新 STA 关联。 现象：重启路由器之后可以短暂连上，运行一段时间复现关联失败。

案例 3：status_code=18 速率集不匹配

AP 强制要求部分基础速率，设备不支持，关联被拒绝；工控网关老旧 AP 经常遇到。

案例 4：设备发出 Association Request，完全收不到 AP 应答

抓包看不到 Association Response 帧。 根因：空口干扰，报文丢包；信号弱；信道噪声大。设备上层判定关联超时失败。

34.4.4 关联失败完整排查流程

1. 抓包拿到 Association Response，读取 status_code；
2. status_code 非 0，按照状态码定位 AP 拒绝原因；
3. 如果完全没有应答帧，优先怀疑空口丢包、干扰；
4. 核对 WiFi 能力配置：HT、VHT、带宽模式，与 AP 保持兼容；
5. 确认 AP 接入上限，是否达到最大连接数；
6. 检查 AP 的漫游、负载均衡策略，部分 AP 会主动拒绝信号弱的客户端关联。

34.5 极易混淆：4‑way 握手失败，被误判为认证 / 关联失败

很多开发者日志看到连接失败，直接归类为 associate fail，抓包一看：

Association Response status_code=0（关联成功），但是 4‑way 握手交互失败，出现 Deauth 帧 reason_code=15。

reason_code=15：4‑way 握手超时。 根因：WiFi 密码错误、AP 加密模式不匹配、MIC 错误。

重点区分：关联已经成功，失败发生在加密密钥协商阶段，不属于关联失败。不要把四次握手失败当成关联问题去调试。

34.6 通用工程定位方法论（可复用到外场问题）

1. 拿到抓包 pcap，先定位设备 MAC，过滤该设备全部 802.11 管理帧；
2. 严格按照扫描‑认证‑关联‑握手时序看报文，定位在哪一步中断；
3. 有应答帧，就看 status_code/reason_code，这是 AP 给出的官方拒绝理由；
4. 没有应答帧，大概率是空口丢包、干扰、信道问题；
5. 同时对照设备串口日志，时间戳对齐，区分 "设备主动断开" 还是 "AP 拒绝接入"。

34.7 量产踩坑总结

1. 只看日志报错文字，不看抓包，很容易误判故障层级，把握手失败当成关联失败；
2. 国家码错误导致扫描异常，是 ESP32 非常高频的隐蔽坑；
3. 廉价家用 AP 接入数上限低，外场多设备场景极易出现关联拒绝；
4. 能力模式不兼容（HT/VHT）是老旧 AP 设备对接的常见坑；
5. 信号差、干扰只会表现为 "收不到应答帧"，不会返回明确 status_code，需要工程师区分 "明确拒绝" 和 "丢包无响应"。

本章小结

扫描超时、认证失败、关联失败，是 WiFi 设备接入阶段三大典型故障。 通过抓包帧交互 + status_code/reason_code，就可以把模糊的日志报错拆解为明确根因：

1. 扫描超时：射频、国家码、隐藏 SSID、RSSI 过滤、空口丢包；
2. 802.11 认证失败：算法不匹配、AP 黑名单、接入满、报文丢包；
3. 关联失败：AP 能力不兼容、客户端已满、速率集不匹配、AP 负载均衡拒绝。

💖 点赞 + 收藏 + 关注，嵌入式 WiFi 量产实战全套教程持续更新！