前面 6 篇走完了 P2P 从初始化到建群的标准流程——但相亲角的故事不止于此。有人不谈判直接立群（Autonomous GO），有人存了密码下次秒重连（Persistent Group），有人在群里发广告（Service Discovery），还有人一边在别人群里当客人一边自己当老大（并发）。出问题了怎么查？四层日志一网打尽。本文是 P2P 系列的 "番外篇"——四个独立高级功能 + 运维排障，按需阅读。
前面 6 篇按 P2P 的标准路径层层推进：初始化《P2P（一）》《P2P（二）》拉起相亲角的管理处和场地，设备发现《P2P（三）》逛一圈收集名单，GO 谈判《P2P（四）》坐下来商量谁当老大，Provision Discovery + WPS《P2P（五）》对暗号验身份，Group Formation《P2P（六）》建群发钥匙。这是一条完整的 "陌生人建群" 路径——从互不相识到建群完毕，每一步都走。
WPS 暗号对上了——现在不是谈判 "谁当老大"，而是真正 "成立群组"。本文追踪从 WPS 成功到 GROUP_STARTED 广播的完整链路：GO 侧启动 Beacon 开张挂牌、接受 Client Auth/Assoc 报到、执行四次握手发群聊密钥、DHCP 分配群内编号；Client 侧关联 GO 领钥匙拿编号；驱动侧模式切换与 NOA 调度。
上一篇（P2P（五）Provision Discovery + WPS）的结尾，暗号对上了——p2p_wps_success_cb() 清除了 GO Negotiation 的临时状态。但这只是 WPS 层面的 "验证通过"，真正的 "群组" 还没成立。现在 GO 要挂牌营业（Beacon 发射）、接客登记（Auth/Assoc）、发群聊密钥（四次握手）、分配群内编号（DHCP IP）。Client 要像连普通 WiFi 一样连上 GO、领钥匙、拿编号。双方都完成这一切后，管理处（Framework）收到 "群正式成立" 的通知——GROUP_STARTED event。
老大定了，地点定了——但你怎么证明你不是骗子？本文追踪从 Framework ProvisionDiscoveryState 到 WPS 注册成功的完整链路：Provision Discovery 亮出身份验证方式、WPS PIN/PBC 方法协商、EAP-WSC 八轮消息交换、15 秒超时兜底，以及驱动侧 WPS 帧收发。
GO Negotiation 结束的那一刻，p2p_go_complete() 做了两件事：打包结果（GO 角色、信道、SSID、passphrase），然后把状态机切到 P2P_PROVISIONING。上一篇的结尾写道："谈判结束了，但建组还没开始——中间隔着 Provision Discovery + WPS。"
看中了一个人，现在要约出来谈谁当老大。本文追踪从 Framework connect 到 GO 角色确定的完整链路：GroupCreatingState 挂起等待牌、
p2p_go_det()的意愿值对比算法、三次握手帧的 8 个 P2P Attribute 构建、十级信道选择的优先级链，以及 Autonomous GO 怎么绕过谈判直接建组。
相亲角里逛了一圈，名单上的人看中了（上一篇的结尾，peer 列表已广播）。现在的问题是：怎么约出来谈？
这就是 GO Negotiation——P2P 协议里最有 "人味" 的环节。不是冷冰冰的扫描和关联，而是两个设备坐下来谈判：谁当老大？在哪见面？规矩怎么定？
相亲角开门营业了，第一个相亲者走进来说 "看看周围有谁"。本文追踪从用户点击到 peer 列表广播的全链路：Framework 把指令传下去，Supplicant 启动 Find 循环（Listen 和 Scan 交替），驱动在社交信道 1/6/11 上发 Probes、收 Probes，P2P IE 名片上写着设备能力和 Listen 信道，最终 peer 名单贴出来给用户看。
相亲角开了。上两篇我们把管理处挂牌、印制名片雇跑腿全部准备好了，系统停在 InactiveState——场地有了、流程有了、人脉有了，就等第一个相亲者走进来。
这个人走进来，对管理处说了一句："看看周围还有谁。"
相亲角的电话线接通了，现在是时候印制名片、摆好档案柜、雇跑腿了。本文追踪从 Framework 层的 SUP_CONNECTION_EVENT 到达，到 wpa_supplicant 的 P2P 模块完整初始化（p2p_data 就绪、35 个回调注册、P2P Device Address 生成），再到 QCOM 和 MTK 驱动各自拉起 P2P 组件的全过程。
上一篇我们看着相亲角的管理处（P2pStateMachine）挂牌了，场地（p2p0 接口）辟好了，电话线（ISupplicantP2pIface的 AIDL 通道）也接通了。但这个相亲角目前只是一间空屋子——没有名片、没有档案柜、没有跑腿的人。真正干活的东西，都在 supplicant 和驱动里面。
你打开手机热点，朋友连上来，屏幕几乎同时亮起 "已连接"，然后他的手机上弹出一条通知：网络已连接，可以上网了。从按下开关到朋友能刷视频，中间只隔了几百毫秒——但就在这瞬间，Android 在手机内部走完了一条从
Tethering到IpServer再到DhcpServer的完整分房流程：热点接口被创建、一个私有网段被划出来、DHCP 服务在接口上监听、朋友的客户端拿到地址和网关，然后数据才被允许转发到上游。
上回讲到《SAP（四）》：SAP 作为 "老板" 要处理共存（DBDC/MCC/SCC）、要管理驱动层状态机、还要在客户端离开时打扫房间。但有个环节被跳过了——客户端关联成功后，它连的只是一个加密的无线链路，它还没有 IP 地址，也就谈不上上网。民宿挂牌了（《SAP（一）》）、装修好了（《SAP（二）》）、客人入住办完手续（《SAP（三）》）、老板在管理前台和客房部（《SAP（四）》）——可客人到现在还没拿到房间钥匙。
本文是 SAP 热点系列第四篇。前三篇讲了 Framework 层启动（第一篇）、hostapd 启动与 Beacon 上线（第二篇）、AP 侧 Auth/Assoc/四次握手（第三篇）。本篇讲运营：手机既是热点又是 WiFi 客户端时怎么共存？QCOM 和 MTK 两家驱动怎么管理 AP 状态机？客人走了怎么办？以及出问题时怎么从四层日志定位根因。
核心看点：DBDC 双频并发下的信道冲突、QCOM SAP FSM 四状态分派 vs MTK 复用 P2P Role FSM、异步回调转同步等待的 qdf_wait_single_event 模式、客户端离开的三种路径（自己走/被踢/空闲关）。
沙漠民宿开起来了，Beacon 已经挂上，客户端也陆续入住。但这只是开始——真正的挑战在你运营起来之后才会浮现。
第一个烦恼：你想当老板接待客人，但你自己也是个 "客人"——手机还连着家里 WiFi 呢。同一部手机，既要接收 STA 端的下行数据，又要发送 AP 端的 Beacon，只有一套射频硬件，怎么办？这是共存管理的世界。
本文是 SAP 热点系列第三篇。第一篇讲了 Framework 层从点击到 hostapd AIDL，第二篇讲了 hostapd 启动、ACS 选频、Beacon 上线。本篇讲 Beacon 上线后发生的事：客户端来敲门了，hostapd 怎么在前台登记（Auth）、怎么分配房间号和房卡（Assoc+AID）、怎么加密发钥匙（四次握手）？
核心看点：角色反转。STA 模式下四次握手是收到 1/4 生成 SNonce 回复 2/4——你是敲门的人。AP 模式下是发送 1/4 等待对方回复 2/4 再验证 MIC——你是发钥匙的人。同样是四个 EAPOL 帧，两边的状态机推进方向完全对称但方向相反。
第一篇讲了怎么 "开民宿"——选信道（选地）、挂 SSID（挂牌子）、发射 Beacon（点亮招牌灯）。现在民宿门开了，灯亮了，有人来敲门了。
如果把 WiFi 连接比作住民宿，STA 模式就是你带着行李走进大堂——看别人家招牌（扫描 Beacon）、选一家顺眼的（选网）、前台登记（Auth/Assoc）、拿房卡进门（四次握手）。整个流程里，客户端是被动的：AP 不来找你，是你去找 AP。