1. 引言

在嵌入式系统中，STA、AP 和 P2P 往往共用同一套无线硬件、驱动和网络接口。模式切换问题通常不是单个 API 调用失败，而是逻辑状态、物理接口、应用服务和客户端连接之间出现了不同步。

本文整理多模式切换中较常见的问题及通用处理方法。

2. 将 P2P GO 误判为普通 AP

现象

系统准备从 P2P 切换到 AP，但检测到 AP 接口处于 active 状态后直接返回，目标 AP 没有真正启动。

原因

P2P Group Owner 在底层可能复用 AP 网络接口，因此“AP 接口 active”不能表示当前一定是普通 AP。

处理

同时维护逻辑模式和 AP 子类型：

物理接口状态 + 当前逻辑模式 + AP 业务类型

只有三者一致时才允许按“相同模式”处理。

3. 业务层绕过统一控制器

现象

热点可以搜索到，但应用服务没有监听；或者软件记录为 STA，底层实际仍是 AP/P2P。

原因

不同模块分别调用 WLAN、DHCP 和服务启动接口，缺少统一的切换事务。

处理

应用层只调用模式 Controller。Controller 统一编排：

停止旧服务 → 停止旧模式 → 启动目标模式 → 启动新服务 → 提交状态

禁止业务模块直接修改当前模式变量或无线硬件状态。

4. 服务停止和重启竞态

现象

目标 Wi-Fi 模式已经启动，但 TCP、HTTP 等服务没有监听；或者切换后短时间内出现端口占用。

原因

旧服务线程正在退出，新模式又立即请求启动。仅使用一个布尔值无法区分“正在停止”和“已经停止”。

处理

为服务增加生命周期状态：

STOPPED → STARTING → RUNNING → STOPPING

STOPPING 期间收到启动请求时记录延迟重启，旧线程完全退出后再创建新线程。

5. 模式启动成功但客户端无法连接

现象

日志显示 AP 或 P2P 已启动，客户端却没有获得地址，也没有建立应用连接。

原因

模式启动只是连接链路中的第一步：

模式启动 → 无线关联 → 地址分配 → 应用连接

任意一步失败，最终都表现为“客户端连不上”。

处理

分别记录并检查：

• 模式启动函数返回值。
• 配对或 WPS 启动结果。
• 客户端关联事件。
• DHCP 地址分配。
• 应用服务监听状态。
• 应用客户端连接事件。

不要用一条“启动成功”日志代表整条链路成功。

6. 相同模式请求无法恢复

现象

设备已经处于 AP/P2P，但客户端没有连接。上层重复请求相同模式，设备持续返回成功，连接仍无法恢复。

原因

“相同模式”只说明 Controller 的模式值相同，不代表客户端连接正常。直接幂等返回会跳过重新配对、重启服务或重建网络。

处理

根据连接状态区分两种情况：

相同模式 + 连接正常    → 幂等返回
相同模式 + 长时间无连接 → 进入恢复流程

恢复流程可以分级执行：

1. 重新开启配对窗口。
2. 重启应用服务。
3. 完整停止并重启当前模式。
4. 多次失败后恢复默认模式。

所有重试都应限频，避免上层高频请求导致网络持续重启。

7. 只处理“断开”，不处理“从未连上”

现象

已经连接过的客户端断开后可以自动恢复，但模式启动后客户端从未连接时，设备会一直停留在当前模式。

原因

恢复定时器只由“客户端断开事件”触发。首次连接没有成功时，不会产生断开事件。

处理

同时设置两类定时器：

首次连接超时：模式启动后开始计时
断开恢复超时：已连接客户端断开后开始计时

首次连接超时后可以重试配对，超过最大次数后恢复默认模式。

8. 切换失败后状态不一致

现象

Controller 仍记录旧模式，但旧物理模式已经停止；或者底层接口已经部分启动，Controller 却回到了空闲状态。

原因

启动过程包含多个步骤，失败分支只清理了部分状态。

处理

把模式切换设计为事务，并记录启动进度：

是否已设置底层模式
是否已启动 AP/P2P
是否已启动 DHCP
是否已启动应用服务

失败时按相反顺序清理，并把 Controller 设置为明确的 IDLE 或已确认可用的模式。

9. 未检查辅助服务返回值

现象

Wi-Fi 模式启动成功，但客户端无法通信。

原因

只检查了 WLAN 启动结果，没有检查 DHCP、WPS、TCP Server 等后续步骤。

处理

将必要服务视为模式切换事务的一部分：

Wi-Fi 成功 + 必要服务成功 = 模式切换成功

任一必要步骤失败都应触发回滚，而不是继续提交目标模式。

10. 连接状态语义混用

现象

一个 connected 字段在 STA 中表示已连接路由器，在 AP/P2P 中又表示客户端或 TCP 已连接，日志和判断条件容易产生歧义。

处理

拆分状态：

mode_active
network_connected
peer_associated
service_connected

如果暂时无法修改接口，至少在日志中同时输出当前模式和连接层级。

11. 自动恢复与主动切换互相干扰

现象

用户主动切换模式时，旧连接的断开事件又触发自动恢复，导致设备马上切回原模式或默认模式。

原因

主动关闭连接和异常断开共用了相同事件，没有区分断开原因。

处理

在主动切换期间设置明确标记：

manual_switch = true

断开回调检测到主动切换时只清理连接，不启动自动恢复。新模式连接成功后再清除标记。

12. 建议的排障日志

一次模式切换至少记录：

请求来源和目标模式
当前模式和 switching 状态
旧服务停止结果
旧模式停止结果
目标模式启动结果
DHCP/WPS 启动结果
服务监听结果
客户端关联和地址分配事件
应用连接事件
失败回滚结果

正常链路应能够从日志中还原为：

旧模式停止
  → 目标模式启动
  → 必要服务启动
  → 客户端关联
  → 地址就绪
  → 应用连接成功

13. 测试建议

不要只测试单向切换，应覆盖循环和失败恢复：

• STA → AP → STA。
• STA → P2P → STA。
• AP → P2P → AP。
• P2P → AP → STA → P2P。
• 模式启动后客户端不连接。
• 客户端连接后立即断开。
• 服务线程停止较慢时立即切换。
• 高频重复请求相同模式。
• 任一启动步骤返回失败。

14. 总结

Wi-Fi 多模式切换的核心不是“切换 API 调通”，而是保证以下状态同步：

Controller 逻辑模式
底层无线接口模式
客户端关联状态
地址和路由状态
应用服务生命周期

统一控制入口、事务式切换、分层连接状态、完整失败回滚和限频恢复机制，是提高嵌入式 Wi-Fi 多模式稳定性的关键。