"发送是塔台下指令，接收是塔台听回报——来机怎么分类、怎么处理、怎么上报，决定了调度系统的响应速度。"

本章导读

上一章（管理帧的发送 — 控制面的帧构建与下发）我们追踪了管理帧的发送路径：从 supplicant 构建 Auth/Assoc/Deauth 帧，经 nl80211 穿过内核边界，进入 QCOM 的双路径（Auth 快速通道 / Action 标准通道）和 MTK 的单入口 + 大帧直通优化，最终到达固件。

本章聚焦硬币的另一面——管理帧的接收与分发。对端发来的管理帧到达固件后，如何穿越 WMI/MBOX 上报到驱动？驱动如何按 category 分类——哪些本地消化、哪些上报 supplicant？QCOM 的两层分发和 MTK 的单层分派各有什么优劣？最后聊一类特殊的帧：RTS/CTS/ACK——为什么你永远看不到它们的代码？

"数据帧是乘客，管理帧是塔台的调度指令——乘客只关心能不能到达，调度指令决定了飞机能不能起飞。"

本章导读

WiFi 的帧分为三大类：数据帧（运乘客）、管理帧（发指令）、控制帧（自动化信号）。上一章我们讲完了连接的全流程，但你有没有想过——那些 Auth、Assoc、Action 帧是怎么从用户态一路下发到固件的？

这就是本章的主题：管理帧在控制面的完整发送路径。从 supplicant 构建帧体开始，穿过 nl80211 的内核边界，进入 QCOM 和 MTK 各自的驱动世界，最终到达固件。

四次握手完成、密钥安装到驱动——L2 加密通道已经建立。但此时 STA 还 "不能上网"：没有 IP 地址，没有路由，系统不知道这个网络的存在。从 L2_CONNECTED 到用户看到 "已连接，可上网"，中间还有一段精密的 L3 配置链路。本篇追踪从 L3ProvisioningState 到 ConnectivityService 注册网络的完整过程。

上一篇追踪了 wpa_supplicant 到 Kernel 的 Auth/Assoc/EAPOL/四次握手全链路，终点是密钥安装到驱动、L2 加密通道建立。本篇从 L2 完成后继续，接上 IP 配置、路由构建、网络注册。

本章导读

WiFi 连上了但上不了网，到底是 DHCP 没拿到 IP，还是网关不通，还是 Captive Portal 拦截了？沿着 L2 加密通道建立之后的完整链路，本篇逐条排查：

WPA2-PSK 的正常连接流程（Open Auth + Assoc + 四次握手）在前面的 Auth/Assoc 流程分析中已经详细拆解。但 WiFi 安全远不止这一条路——open 网络没有加密直接连、OWE 在 Assoc 阶段偷偷交换 DH 密钥、SAE 把密钥协商搬到了 Auth 阶段（4 帧 Dragonfly 握手）、EAP-TLS 引入 RADIUS 服务器做三方证书认证、WiFi 7 的 MLO 更是把「一条连接」变成了「多条链路协同」。本篇的角色是：将前面没走的安全协议分支逐一捋清楚——每种协议在代码的哪个位置分叉、为什么分、分叉后走了什么完全不同的路径。

上篇回顾：前面在 Framework 状态机追踪中我们跟踪了 ClientModeImpl 如何从用户点击一直走到调用 Supplicant AIDL，拆解了 Supplicant 的 sme_send_authentication() 如何根据 key_mgmt 设置 params.auth_alg——这个函数就是本篇所有协议的分叉原点，也深入到 QCOM/MTK 驱动的 Auth/Assoc 状态机和四次握手。本篇回到 sme_send_authentication() 的决策枢纽，逐一追踪 open/OWE/SAE/EAP-TLS/MLO 的完整代码路径。

QCOM 驱动层连接执行中，我们拆解了 QCOM 平台的驱动层连接——Host 做监工，固件全权代理 Auth/Assoc 帧交换。本篇聚焦 MTK 平台：驱动亲自下场，两层状态机控场，每一步 Auth/Assoc 帧交换都在 Host 侧可见。与 QCOM 的 "外包安保" 不同，MTK 选择的是 "自营安保"——驱动自己构建 802.11 帧、自己解析回复、自己管理状态转移。本篇将完整拆解 AIS FSM（17 状态）和 SAA FSM（8 状态）两层状态机如何协作完成 L2 连接。

在 QCOM 驱动层连接执行中，我们追踪了 QCOM 的 CM 状态机如何通过序列化模块排队→事件投递→cm_connect_active() 激活连接→固件全权代理 Auth/Assoc 帧交换。QCOM 的 Host 侧全程不碰 802.11 帧——它的角色是 "监工"，不是 "执行者"。但 MTK 走了完全不同的路。

本章导读

如果说 QCOM 是把安保全部外包给专业公司的酒店，那 MTK 就是自己员工亲自办理每一道手续的精品酒店。大堂经理（AIS FSM）统筹全局——从搜索目标、扫描、申请频道到最终入住，全程 17 个状态不遗漏。安保执行员（SAA FSM）接到指令后一步一个脚印：先验证身份证（Auth Request → 等 Response），验证通过后再分配房间（Assoc Request → 等 Response），每一步都有记录、每一步都可追溯。这种 "亲力亲为" 的模式虽然代码量更大，但出了问题你能在 dmesg 里直接看到是哪一步卡住了——不需要任何固件日志工具。

上篇讲到 Supplicant 的 SME 通过 NL80211 把 NL80211_CMD_CONNECT 下发到了内核——命令到达了，但真正的 802.11 帧交换还没开始。Probe Request 探路、Authentication（认证）、Association（关联）三轮帧交换，谁来执行？怎么执行？本篇聚焦 QCOM 平台驱动层 L2 连接的完整过程——从内核收到连接命令开始，到 EAPOL 完成、密钥安装到位、数据帧可以加密传输为止。QCOM 的核心设计哲学是 "交给固件"——Host 侧做监工，固件全权代理 Auth/Assoc 帧交换。MTK 平台（驱动亲自下场、两层状态机控场）见后续 MTK 驱动层连接执行篇。

本章导读

WiFi 连接的四步曲中，Authentication 和 Association 就像入住酒店的前两步——安保人员验证你的身份证（Auth），前台分配房间并登记（Assoc）。在 QCOM 的世界里，酒店的安保全部外包给专业安保公司（固件），前台只需要说一句 "帮这位客人办入住"，安保公司自己搞定验证和分配。本篇聚焦 QCOM 这半边的完整流程。

在上一篇中，我们站在前台视角，看了 Framework 的 ClientModeImpl 状态机如何收到 CMD_START_CONNECT，然后调用 WifiNative.connectToNetwork() 发起连接。现在命令已经到了后场——本文从 Supplicant 进程的 AIDL 入口开始，追踪添加网络配置、推送参数、选择网络、SME 认证 / 关联决策、驱动命令下发，一直到 NL80211_CMD_AUTHENTICATE 和 NL80211_CMD_ASSOCIATE 下发，并贯穿 EAPOL 四次握手到 WPA_COMPLETED 全过程。这是 Supplicant 层 L2 连接的完整全链路。

前台（Framework）把客人的入住申请表递给了后场的制卡机（Supplicant）。制卡机需要做几件事：把客人的信息录入系统（addNetwork + 逐个 setter 推送配置），在系统里选中这条记录触发制卡流程（select），通过安保系统验证客人身份（Auth），签入住单（Assoc），最后用对讲机（nl80211）把指令编码成门禁系统能理解的格式下发到客房控制器（驱动）。本篇就跟着这张房卡，走完从录入到下发对讲机指令的完整旅程。

本文聚焦 Supplicant 内部逻辑和 nl80211 命令下发——驱动收到命令后的固件交互和帧交换在后续驱动层连接执行篇展开，EAPOL 四次握手中 PTK 派生的密码学细节在后续安全协议篇中深入。

全文约 25 分钟读完。如果只关心整体流程，可以跳过代码块，只看每节末尾的「主要功能」小结和 §7 的调用链全景图。

你在 WiFi 列表中点了一下「连接」，几十毫秒之内，Android Framework 完成了权限检查、MAC 地址随机化、配置校验、状态机跳转、AIDL 跨进程调用——最终一条 ISupplicantStaNetwork.select() 命令跨过进程边界抵达 wpa_supplicant。本文追踪从用户点击到 AIDL 调用完成的完整 Framework 层调用链，不涉及 supplicant 内部。

上篇回顾：在扫描三部曲中，我们讲完了从 Framework 通过 wificond 下发扫描、到 supplicant 内部扫描引擎、到驱动执行的完整链路。扫描找到了目标 AP——接下来就是连接。本篇跳到另一个主线：Framework 怎么把连接请求发给 supplicant？中间的每一步做了什么？

本章导读

STA 连接就像酒店入住。WifiServiceImpl.connect() 是前台——它接待你、检查你的身份（权限检查）、查房态（网络配置是否存在）。ConnectHelper 是前台经理——它确认你不是重复入住（防 MCC，Multi-Channel Concurrency 多信道并发）、通知客房部做好准备。ClientModeImpl 是客房系统——它办完登记后通知门锁系统（WifiNative.connectToNetwork()），门锁系统把你的房卡信息（WifiConfiguration）通过内部对讲机（AIDL）发给制卡机（SupplicantStaIfaceHalAidlImpl），制卡机负责把卡上的芯片信息（SSID、PSK、KeyMgmt）写入卡片，交给制卡工厂（wpa_supplicant）激活。

上两篇追踪了扫描请求从 Framework 经 wificond 到 Supplicant 的完整软件路径。现在来到最底层——驱动和固件。Probe Request 是怎么变成空口电磁波的？息屏时 PNO 怎么做到几乎不耗电？WiFi 6E 的 59 个信道怎么高效扫描？驱动层是扫描性能和安全性的最后一道关口。

上篇回顾：在 扫描（一）我们追踪了 Framework 的节流和状态机、wificond 的参数翻译、nl80211 的命令构建。在 扫描（二）我们深入了 Supplicant 的扫描引擎——eloop 调度、350 行参数构建、radio work 排队、BSS 缓存管理。现在，Supplicant 已经把 NL80211_CMD_TRIGGER_SCAN 发给了内核…… 驱动收到后怎么做？

本章导读

把整个扫描链路想象成一套指挥体系：Framework 是指挥中心——决定何时搜索、搜索谁（§05 上篇的节流和状态机）；Supplicant 是参谋部——把搜索意图翻译成精确的作战参数（§05 二篇的 350 行参数构建）；驱动层是前线指挥部——参数在这里经过翻译官（§1.2 的参数转换）、后勤调度（§1.4 的序列化队列）两道工序，最终变成固件能执行的射频操作。

如果 Framework 的 wificond 扫描是雷达指挥中心发起的例行探测任务（定时扫、用户要求扫），那么 wpa_supplicant 的扫描引擎就是雷达的自动维护程序——它在后台悄悄扫描周围环境，自己决定何时扫、扫什么，目的是保持连接质量和发现 P2P 设备。最精妙的设计是 radio work 队列——同一台雷达不能同时做两件事，所有射频操作（扫描、连接、P2P）必须排队。

本章导读

这里有一个关键认知需要先明确：Android Framework 的常规扫描（Settings 10s 扫描、App 调用 startScan、WifiConnectivityManager 周期性扫描）不经过 wpa_supplicant——它们走的是 wificond → nl80211 → 驱动的直通路径（详见上篇《STA 扫描 — Framework 与 wificond》）。Supplicant 的扫描引擎服务于另一条独立路径：Supplicant 自己内部触发的扫描（bgscan 漫游、P2P Discovery、WPS 配网、连接前扫描）。两条路径互不感知，本篇聚焦 Supplicant 这条。