上一篇停在
HostapdHal.addAccessPoint()的 AIDL 跨进程调用那一刻。民宿老板拿到了营业执照，装修队进场——这一篇，我们跨过那行代码，进入 hostapd 的纯 C 世界，看装修队怎么选铺位（ACS）、检测环境（DFS CAC）、硬装（BSS 初始化）、做招牌灯（Beacon 组装）、挂灯牌（nl80211 + 驱动下发）。
本文覆盖约 10,000 字，核心问题：
NL80211_CMD_START_AP 后经历了哪三个阶段的处理？连接建立后，STA 和 AP 之间维持着一条脆弱的链路。当这条链路断裂时，STA 可能是主动离开的那个人，也可能是被踢出局的受害者。断连不是一种病——它是五种完全不同的病因导致的同一种症状。要治好 WiFi 断连，第一步不是查日志，而是分清 "谁先动的手"。
我们把 WiFi 断连比作一次急诊就诊。STA 是病人，断连是昏倒，AP 是医院，四层日志是 X 光片、血液检查、心电图和基因检测。不同科室的医生看同一张片子关注点不同——Framework 工程师看 "心跳"（SupplicantState），驱动工程师看 "血氧"（Beacon Miss Count），固件工程师看 "脑电波"（FW Roam Event）。本文是一本断连急诊手册：先教你看懂五张面孔（五种断开类型），再教你区分 Deauth 和 Disassoc 两张化验单，然后讲自动重连的 "急救流程" 和省电模式的 "体质调理"，最后给出 13 种常见病因和四层对照诊断法。
PS：本文聚焦 STA 模式下的断连，不涉及 SAP（热点）断连和 P2P 断连。漫游导致的断开在 STA 漫游那篇已展开，本文只讨论 "不回来了" 的断连。
连接不是终点。当你拿着手机从一个房间走到另一个房间，信号掉到 -78dBm，STA 面临选择：撑住旧 AP，还是切到新 AP？本文追踪漫游的最后一步——谁来执行搬家、搬错了怎么办。漫游比作搬家：QCOM 的 RSO 是全包搬家公司，MTK 的 Host Roaming 是自己动手。本文聚焦 ESS 内漫游，分析 wpa_supplicant、QCOM qcacld-3.0、MTK gen4m 驱动及 AOSP WiFi Framework 源码（精简处标注
// ...省略...，文件路径标注在代码块首行）。漫游前的扫描机制见《扫描》系列，连接信令见《连接》系列，本文复用不重复。
《STA 漫游（一）触发与决策》《STA 漫游（二）802.11k/v/r 三协议》讨论的漫游决策和协议机制，在不同平台上的实现路径截然不同。QCOM 把整个闭环卸载到固件（RSO），MTK 让驱动亲自下场（Host Roaming）。本节回答：两种架构各自的状态机长什么样？扫描调度怎么管？漫游完成后 host 怎么知道结果？
连接不是终点。当你拿着手机从一个房间走到另一个房间，信号掉到 -78dBm，STA 面临选择：撑住旧 AP，还是切到新 AP？本文追踪漫游的第二步——搬去哪、怎么搬得无缝。漫游比作搬家：邻居报告是中介推荐房源，BTM 是房东通知你搬，FT 是 VIP 快速通道。本文聚焦 ESS 内漫游，分析 wpa_supplicant、QCOM qcacld-3.0、MTK gen4m 驱动源码（精简处标注
// ...省略...，文件路径标注在代码块首行）。漫游前的扫描机制见《扫描》系列，连接信令见《连接》系列，本文复用不重复。
802.11k RRM（Radio Resource Management）的做法很直接：STA 问当前 AP"你附近有哪些邻居？"，AP 回复一份邻居报告（Neighbor Report），里面列出附近 AP 的 BSSID、信道号和操作类别——相当于中介递给你的房源清单，上面有地址（BSSID）、所在楼层（信道号）和户型（PHY Type）。拿到这份清单，漫游扫描就能从 "满城跑" 变成 "直奔目标"。
连接不是终点。当你拿着手机从一个房间走到另一个房间，信号掉到 -78dBm，STA 面临选择：撑住旧 AP，还是切到新 AP？本文追踪漫游的第一步——什么时候该搬、值不值得搬。漫游比作搬家：信号变差是墙裂，Beacon Loss 是房塌，BTM 是房东通知你搬。
本文聚焦 ESS 内漫游，分析 wpa_supplicant、QCOM qcacld-3.0、MTK gen4m 驱动源码（精简处标注
// ...省略...，文件路径标注在代码块首行）。漫游前的扫描机制见《扫描》系列，连接信令见《连接》系列，本文复用不重复。
老房子住久了你自然会注意到墙上的裂缝：信号变弱（RSSI 下降）、邻居的噪音变大（PER 升高）、甚至直接断水断电（Beacon 连续丢失）。现代 AP 还多了一个高级玩法——房东主动发通知：这栋楼要拆了，建议你搬到隔壁那栋（BTM Request）。这三种情况分别对应漫游的三个触发源头。
"WiFi 7 的路由器有 2.4G+5G+6G 三条链路，你的手机也同时连着三条——但一个 TCP ACK 走哪条？这不是简单的'随便选一条'——语音帧需要低延迟走 5GHz，后台下载不介意延迟走 2.4GHz 还能省电。谁来做这个选择？host 还是固件？QCOM 和 MTK 给出了同一个答案，但背后的架构逻辑完全不同。"
数据帧发送篇追踪了从 ndo_start_xmit 到固件的完整发送路径——QCOM 的 10 道关卡、MTK 的 18 道工序、WMM AC 分类、Block ACK 协议。但那篇文章聚焦的是单链路场景：一个 WiFi 网卡，一条信道，数据包从协议栈一路走到空口。
WiFi 7 改变了游戏规则。MLO（Multi-Link Operation）让 STA 可以同时关联 2.4GHz、5GHz 和 6GHz 三条链路——数据包在进入驱动后不再是 "一条路走到黑"，而是面临一个岔路口：走哪条链路？用仓库来比喻：单链路是一间只有一条传送带的仓库，MLO 把它扩成了多航线分拨中心——每个数据帧进仓后，第一件事就是决定装进哪架货机。
"WMM AC 分类决定数据包走哪条传送带，但传送带编号是从哪来的？DSCP→UP (User Priority) 映射就是快递单上的'优先级戳'——寄件人写了'加急'，快递公司认不认、怎么认，取决于 AP 和 STA 之间的一纸协议。"
上一章把数据帧从 ndo_start_xmit 一路送到了固件——QCOM 的 10 道关卡、MTK 的 18 道工序、WMM AC 分类、Block ACK 协议，该过的流程都过了一遍。但 WMM AC 分类的输入——User Priority（UP，0-7）——是从哪来的？
答案在 IP 头的 DSCP 字段（0-63）。从 64 个 DSCP 值到 8 个 UP 值，中间经过一层 QoS Map 的映射。这层映射由 AP 在关联时下发，决定了同一个 DSCP 值在不同网络上可能走不同优先级的队列——你的手机发一个 DSCP=46（EF，语音）的包，在 QCOM 平台上走 VO 队列，在 MTK 平台上呢？答案可能是 "一样也可能不一样"——取决于 AP 有没有下发 QoS Map，以及两个平台的默认映射表怎么定义。
"入港的包裹不比出港——你不知道它什么时候到、走哪条路、属于哪个客户。出港分拣靠流程，入港分拣靠应变。"
数据帧发送路径中我们追踪了从 ndo_start_xmit 到固件的完整出港分拣线。TX 路径的核心矛盾是 "如何在软中断的约束下高效搬运"，驱动和协议栈的角色是 "主动推送"——协议栈决定什么时候发、发什么，驱动只需按流程搬。
但 RX 是另一个世界。你不知道帧什么时候到、是什么类型、属于哪个流、是否需要重排。 驱动在 RX 路径上是被动的——硬件通过中断告诉你 "有包了"，你必须在极短的时间窗口内把数据从 DMA ring 里捞出来、组装成 skb、分类、解密、转换格式、最终上送协议栈。任何一环卡顿，都会导致 DMA ring 溢出、丢包、吞吐量骤降。
"管理帧是调度指令；数据帧是跑道上真正的货物——每个包裹都要经过揽件、分拣、干线运输，一站都不能少。"
上一章我们追踪了管理帧的控制面路径——supplicant 构建 Auth/Assoc/Action 帧，经 nl80211 下发驱动，再由驱动/固件发出。那是 "塔台" 的世界：指令轻量、路径分叉、部分帧硬件自主处理。
但数据帧是另一个世界。它们不需要 supplicant 构建，不需要双路径分流——所有数据包只认一个入口。然而，数据帧的量级远大于管理帧（一个 TCP 流就能产生成百上千个数据帧），所以数据面的核心挑战不是 "路径分支多" 而是 "吞吐量"——如何在软中断不能睡眠、不能长时间占 CPU 的约束下，高效地搬运数以万计的 skb。