WIFI-Direct学习笔记系列
WIFI-Direct学习笔记系列 1. 01-wifi-direct-lab (个人博客链接) 2. 02-wpa-cli-to-p2p-find (个人博客链接) 3. 03-wpa-supplicant-startup-driver (个人博客链接) 4. 04-interface-protocol-init (个人博客链接) 5. 05-ctrl-iface-eloop (个人博客链接) 6. 06-p2p-find-to-core (个人博客链接) 7. 07-p2p-first-scan (个人博客链接) 8. 08-scan-result-to-peer (个人博客链接) 9. 09-p2p-connect-go-negotiation (个人博客链接) 10. 10-group-formation-security (个人博客链接) 11. 11-group-runtime (个人博客链接) 12. 12-group-teardown (个人博客链接) 13. 13-persistent-group (个人博客链接) 14. 14-kernel-wireless-...
readme
Wi-Fi Direct Source Lab 面向 Linux Wi-Fi Direct / Wi-Fi P2P 源码学习、协议实验与 GDB 调试的可重复实验环境。项目以 hostap / wpa_supplicant 2.12 为固定 userspace 基线：Ubuntu Host 提供真实 Linux wireless kernel stack 与 mac80211_hwsim，Docker 固化源码、Debug binary、编译选项和工具链，VS Code Dev Containers 提供源码跳转与 GDB 调试入口。 @[toc] 本仓库的目标不是封装一个“直接可用的 Wi-Fi Direct 产品”，而是把 Wi-Fi Direct 从： 123456789wpa_cli / control interface ↓wpa_supplicant / P2P state machine ↓nl80211 / cfg80211 / mac80211 ↓802.11 management + dat...
15-group-data-plane-tx-rx
Wi-Fi Direct 源码分析（15）：Group 建立后的真实数据面——Socket、mac80211、hwsim 与 802.11 Data Frame TX/RX 摘要：沿 P2P Group netdev 追踪普通 TCP/UDP 数据的 Linux TX/RX 路径，说明业务 payload 如何绕过 P2P Core 进入 mac80211 与虚拟 radio。 [TOC] 第 11 篇已经建立一个关键边界：P2P-GROUP-STARTED 之后还需要完成 Group Interface、IP 和 route 配置；当三层网络 ready 后，应用不再调用“Wi-Fi Direct 数据发送 API”，而是直接使用标准 Socket。 第 14 篇又补齐了另一半：Discovery、Listen、GO Negotiation 等 控制面进入 kernel 后，会通过 nl80211 → cfg80211 → mac80211 → driver 完成 ROC、Management Frame TX/RX，再由异步 e...
14-kernel-wireless-control-path
Wi-Fi Direct 源码分析（14）：控制面进入 Linux 内核后发生了什么——nl80211、cfg80211、mac80211 与管理帧 TX/RX 摘要：从 P2P Listen 与 Action Frame 两条真实路径追到 Linux Wireless 内核和 mac80211_hwsim，补齐 Wi-Fi Direct 控制面进入驱动后的 TX/RX 闭环。 [TOC] 第 01～13 篇已经把 Wi-Fi Direct 的主要用户态机制闭环：wpa_cli 命令进入 wpa_supplicant，P2P Core 完成 Discovery、GO Negotiation、Group Formation、Teardown 与 Persistent Group；eloop、radio work、callback 和状态机也已经有了明确的运行模型。 到这里还剩一个有意保留的黑盒： 1234567wpa_supplicant ↓driver_nl80211 ↓Linux kernel / Wi-Fi driver ↓8...
13-persistent-group
Wi-Fi Direct 源码分析（13）：Persistent Group 如何再次建立——P2P_INVITE、Invitation 与 Reinvocation 摘要：追踪 Persistent Group 凭据保存、P2P_INVITE、Invitation Request/Response 与重新建组，说明 teardown 后如何复用原角色和密钥再次到达 P2P-GROUP-STARTED。 @[toc]第 12 篇结束在一个很关键的生命周期边界： 1234567active P2P Group ↓P2P_GROUP_REMOVE / internal removal ↓P2P-GROUP-REMOVED ↓Group Interface 与运行态资源被释放 但第 12 篇同时保留了一个没有继续展开的问题： 当前 Group 被删除以后，为什么同一对设备下一次还能“恢复”原来的 Group，而不必重新完成一次完整的 GO Negotiation？ 答案就是 Persistent Group。S3 它并不是一个一直运行、不被删除...
12-group-teardown
Wi-Fi Direct 源码分析（12）：P2P Group 如何结束——P2P_GROUP_REMOVE、资源释放与 P2P-GROUP-REMOVED 摘要：沿 P2P_GROUP_REMOVE 追踪 Group teardown：定位目标接口、安全延迟删除、P2P-GROUP-REMOVED、Group 资源与 IP/DHCP 清理，并说明自动移除原因和 P2P Device 保留边界。 @[toc]第 11 篇已经把一次已建立的 P2P Group 追到真正可用的数据通路： 123456789P2P-GROUP-STARTED ↓Group Interface ↓GO / Client ↓IP Address Allocation 或 DHCP ↓TCP / UDP / ICMP 但 Group 不会永久存在。用户可以主动结束 Group，GO 也可能因为空闲超时、频率冲突、驱动资源变化等原因被系统自动终止；Client 还可能因为 GO 宣告 session 结束而退出。 第 12 篇只解决这一条新的生命周期主线： 1234...
11-group-runtime
Wi-Fi Direct 源码分析（11）：P2P-GROUP-STARTED 之后——Group Interface、IP 配置与真实数据通路 摘要：从 P2P-GROUP-STARTED 追踪本机 Group netdev、IP/route 配置，并区分 P2P 控制面与 Linux Socket 数据面。 @[toc]第 10 篇已经把一次经典 Wi-Fi Direct Group Formation 追到最终事件： 123456789P2P_CONNECT ↓GO Negotiation ↓WPS Group Formation ↓P2P-GROUP-FORMATION-SUCCESS ↓P2P-GROUP-STARTED 到这里最容易出现一个新的误解：既然已经收到 P2P-GROUP-STARTED，是否意味着两台设备已经拥有 IP 地址，可以直接 ping、建立 TCP 连接或发送 UDP 数据？ 答案不能简单写成“是”。 P2P-GROUP-STARTED 首先说明 P2P Group 已经进入可运行阶段：如果本端是 GO...
10-group-formation-security
Wi-Fi Direct 源码分析（10）：从 GO Negotiation 结果到 P2P-GROUP-STARTED 摘要：从 wpas_go_neg_completed() 的 GO/Client 分叉继续，追踪 WPS provisioning、关联、4-Way Handshake 与 P2P-GROUP-STARTED。 @[toc]第 09 篇停止在一个明确边界：P2P Core 已经完成 GO Negotiation，并通过： 123cfg->go_neg_completed ↓wpas_go_neg_completed() 把 struct p2p_go_neg_results 交回 wpa_supplicant。此时已经知道： 哪一端成为 GO； 哪一端成为 Client； Group 使用的频率/信道； peer device/interface address； classic 路径使用的 WPS method； Group ID/SSID 等后续 formation 参数。S1 但此时仍未完...
09-p2p-connect-go-negotiation
Wi-Fi Direct 源码分析（09）：从 P2P_CONNECT 到 GO Negotiation 完成 摘要：从 CLI 显式执行 P2P_CONNECT 开始，追踪 Find 停止、可选 Provision Discovery、GO Intent、Action frame 与 GO Negotiation 完成回调。 @[toc]第 08 篇已经把 Device Discovery 追到 P2P-DEVICE-FOUND，并确认 peer 已进入 P2P Core 的 p2p->devices。这一步只表示“已经发现对端”，不会自动进入 Group Formation。 真正的连接阶段需要上层再次做一个明确动作：选择一个已经发现的 P2P Device Address，然后发送第二条 control command： 1P2P_CONNECT <peer_device_addr> ... hostap 2.12 的 README-P2P 也把 p2p_connect 定义为“与已发现的 P2P peer 开始 Group Formation”...
08-scan-result-to-peer
Wi-Fi Direct 教程 08：Scan Result 如何变成 P2P Peer——BSS、P2P/WPS IE、peer table 与 P2P-DEVICE-FOUND 摘要：从 NL80211_CMD_NEW_SCAN_RESULTS 进入 eloop 与 EVENT_SCAN_RESULTS，再追踪 BSS/IE、peer table、P2P-DEVICE-FOUND 和 Find 回环。 @[toc]上一阶段已经把 NL80211_CMD_TRIGGER_SCAN 提交给 kernel。本文从 kernel/driver 宣告扫描完成开始，先补齐 NL80211_CMD_NEW_SCAN_RESULTS 如何经 nl80211 event socket、eloop 与 driver_nl80211 变成 EVENT_SCAN_RESULTS，再追踪 BSS table、Probe Response/Beacon IE、peer table 与 P2P-DEVICE-FOUND。 重点是解释“扫描到一个 BSS”为什...
