【P2P 邀请后 5G 单信道扫描 dwell 加长】

咖丨喱2026-10-30 8:27
项 内容
Commit 3e9726cce079bcff392f7658e1d2591d9328d3a6
标题相关 fix OPPO Find N2 Flip / HP ProBook 465 cannot connected
文件 hal_apollo/scan.c → atbm_hw_scan()
性质 仅影响「单信道 + 带 SSID + 5GHz」且 dwell 已被压短的扫描

本文只详细分析该 commit 中的 修改点 1（scan.c） 。同 commit 的 txrx.c（Public Action expireTime）与 AirP2P filter ioctl 不在此展开，仅在文末说明与修改点 1 的配合关系。

1. 修改原文

c 复制代码 
/*
 * Invited P2P GO search is a one-channel 5 GHz scan. A 50 ms dwell
 * ends before a 100 ms beacon. Stay 200 ms and send 3 probes.
 */
if (scan.numOfChannels == 1 && scan.numOfSSIDs >= 1 &&
    scan.ch[0].number > 14 && scan.ch[0].maxChannelTime < 200) {
	scan.ch[0].minChannelTime = 100;
	scan.ch[0].maxChannelTime = 200;
	if (scan.numOfProbeRequests < 3)
		scan.numOfProbeRequests = 3;
}

插入位置：在 single_channel_scan_reduce_time 处理逻辑 之后 、atbm_scan_start() 之前。

2. 问题现象与产品背景

2.1 现象

部分源端（实测点名 OPPO Find N2 Flip 、HP ProBook 465）在 Miracast / Wi‑Fi Display 建连时：

  • Invitation / GO Negotiation 阶段看似有进展；
  • 随后投影端 找不到 GO BSS，Auth/Assoc 失败；
  • 用户侧表现为「扫到了设备 / 点了投屏，但连不上」。

2.2 为何容易出在这些设备上

这类源端作为 P2P GO 时，Operating Channel 经常落在 5 GHz 。

投影端在 Invitation 完成后必须做一次 只扫该工作信道、并带目标 SSID 的扫描。

若该次扫描驻留时间被产品侧「单信道加速」压到约 50 ms ，且 Probe 只发 1 次，则极易错过 GO 的 Beacon / Probe Response。

3. 建连时序里这一步在哪

典型 Miracast Client（投影端）路径：

复制代码 
1. 社交信道 (1/6/11) 发现 / listen
2. Public Action：Invitation 或 GO Negotiation
   └─ IE 中携带 Operating Channel（常为 5G，如 36/149）
3. ★ Client 对 Operating Channel 做「单信道 + 指定 SSID」扫描
   └─ 期望收到 GO Beacon 或 Probe Response
4. Auth / Assoc / 四次握手 / RTSP

修改点 1 只加强第 3 步，不改变 Action 帧内容，也不改关联算法。

对应驱动入口：

  • mac80211 / wpa_supplicant 下发 ieee80211_scan_request
  • atbm_hw_scan() 填 struct wsm_scan，经 wsm_scan() 下发 WSM_START_SCAN_REQ (0x0007)

4. atbm_hw_scan 中与本修改相关的字段

本修改直接改动的字段：

字段 所属结构 本补丁的动作
numOfChannels wsm_scan 只读，作为匹配条件（须为 1）
numOfSSIDs wsm_scan 只读，作为匹配条件（须 ≥ 1）
ch[0].number wsm_scan_ch 只读 ，判断是否 5G（> 14）
ch[0].minChannelTime wsm_scan_ch 写为 100
ch[0].maxChannelTime wsm_scan_ch 写为 200 （且条件要求原值 < 200）
numOfProbeRequests wsm_scan 若 < 3 则抬到 3

4.1 numOfChannels（匹配条件）

  • 含义：本次固件要依次驻留的信道个数。
  • 赋值 ：scan.numOfChannels = req_wrap->req->n_channels（上层透传）。
  • 本补丁要求 == 1：只命中「定点找 GO」类扫描，不误伤全频段 / social 多信道扫。

4.2 numOfSSIDs（匹配条件）

  • 含义：Probe Request 携带的 SSID 个数；0 表示广播发现。
  • 赋值 ：scan.numOfSSIDs = req_wrap->req->n_ssids。
  • 本补丁要求 >= 1 ：邀请后找特定 DIRECT-xxx，与无 SSID 的 listen/被动扫区分。

4.3 ch[0].number（匹配条件）

  • 含义：硬件信道号。
  • 赋值 ：channel_hw_value(req_wrap->req->channels[i])。
  • 本补丁要求 > 14 ：按 ATBM 习惯，2.4G 为 1～14，大于 14 视为 5 GHz 信道号。

4.4 minChannelTime / maxChannelTime

  • 含义：固件在该信道上的最少 / 最多驻留时间（驱动按毫秒量级下发）。
  • 作用 ：maxChannelTime 决定该信道最长听多久；atbm_scan_start() 也会用各信道 maxChannelTime 累加 host 侧超时。

4.5 numOfProbeRequests

  • 含义 ：每个 SSID、每个信道 发送 Probe Request 的次数。
  • 0 ：被动扫（只听 Beacon）；>0：主动扫。
  • 补丁保证在命中分支后至少发 3 次，抵消前面「单信道加速」把它降成 1 的副作用。

5. 改前：dwell 为何会变成约 50 ms

5.1 默认主动扫估算

c 复制代码 
ProbeRequestTime  = 10;
ChannelRemainTime = 20;

maxChannelTime = (numOfSSIDs * numOfProbeRequests * ProbeRequestTime)
               + ChannelRemainTime;
maxChannelTime = max(maxChannelTime, 35);

例：1 个 SSID、默认 3 次 Probe → (1×3×10)+20 = 50。

numOfProbeRequests 默认也多为 3（首信道非 no_IR 时）。

5.2 单信道加速（问题主因）

c 复制代码 
if (scan.numOfChannels == 1 && hw_priv->single_channel_scan_reduce_time) {
	scan.ch[0].minChannelTime = 35;
	scan.ch[0].maxChannelTime = hw_priv->single_channel_scan_reduce_time;
	if (scan.ch[0].maxChannelTime <= 50)
		scan.numOfProbeRequests = 1;
}
  • single_channel_scan_reduce_time 可由 ioctl 设为 36～255 （见 dev_ioctl.c 的 atbm_dev_set_single_scan_time）。
  • 产品侧常把它设到 ≤50，目的是普通「单信道快扫 / 关联前确认」更快。
  • 副作用 ：Invitation 后找 GO 的单信道扫也被压短，并且 Probe 被降为 1。

5.3 与 GO Beacon 周期的冲突

P2P GO / SoftAP 的 Beacon Interval 常见为 100 TU ≈ 100 ms。

改前典型参数 后果
maxChannelTime ≈ 50 ms 时间窗短于一个 Beacon 周期，进信道若错过 Beacon 则整次扫完都听不到
numOfProbeRequests = 1 仅一次 Probe，冲突/瞬时休眠时极易无 Response

注释中的判断即：

A 50 ms dwell ends before a 100 ms beacon.

6. 改后：补丁如何纠正

6.1 触发条件（四个 AND）

条件 意图
numOfChannels == 1 定点单信道
numOfSSIDs >= 1 带目标 SSID（邀请找 GO）
ch[0].number > 14 仅 5 GHz
maxChannelTime < 200 仅当已被 shorten；本来就够长则不改

6.2 写入结果

参数 改后值 设计意图
minChannelTime 100 至少听满约一个 Beacon 周期
maxChannelTime 200 覆盖约 两个 100 ms Beacon 周期
numOfProbeRequests ≥ 3 恢复主动扫默认 probe 次数

6.3 为何写在 reduce 逻辑之后

顺序必须是：

复制代码 
填默认 ch[] dwell
  → single_channel_scan_reduce_time 可能压短
  → ★ 本补丁按条件再拉长
  → atbm_scan_start / wsm_scan

若写在 reduce 之前，随后仍会被 single_channel_scan_reduce_time 覆盖，补丁失效。

6.4 时序对比（概念）

复制代码 
改前（reduce ≤ 50）:
  |---- ~50 ms ----|
  Probe×1 ······ (可能整窗错过 Beacon)
                 → scan complete → 无 BSS → 连不上

改后:
  |---------- 200 ms -----------|
  Probe×3 · Beacon · Probe · Beacon ···
                 → 看到 GO → Auth/Assoc

7. 不会命中本补丁的扫描（副作用边界）

场景 不命中原因
全频段 / 多信道 discovery numOfChannels != 1
2.4 GHz 单信道 number ≤ 14
无 SSID 的 listen / 广播扫 numOfSSIDs < 1
单信道但 maxChannelTime 已 ≥ 200 第四条件不满足
AP 模式下的扫 函数开头直接 -EOPNOTSUPP，到不了此处

主要代价：命中的 5G 邀请定点扫每次多驻留约百毫秒级，用延迟换建连成功率。

8. 与同 commit 修改点 2（txrx）的关系

修改点 2 对 Public Action（category=4） 设置 expireTime = 300 TU，避免固件在 listen 信道对未 ACK 帧重试数秒、射频无法去 5G 扫 GO。

修改 解决的卡点
txrx expireTime Action 发完后射频被长时间占用
scan dwell（本文） 射频已空出，但定点扫太短仍找不到 GO

两条同属「OPPO/HP 连不上」闭环：先腾出射频，再扫够时间。只合其中一条，仍可能复现失败。

本修改 与 AirP2P IW_PRIV_DRIVER_CFG filter ioctl 无关。

9. 验证建议

9.1 日志关键词

驱动已有：

  • scan single channel = %d（进入 reduce 分支时）
  • scan start band(%d),(%d)（band 与 numOfChannels）
  • [SCAN_WSM] start_scan ... nCh=%u nSSID=%u

建议在补丁分支临时加一行确认覆盖结果（调试用）：

c 复制代码 
atbm_printk_scan("p2p5g go search: ch=%u min=%u max=%u probes=%u\n",
	scan.ch[0].number, scan.ch[0].minChannelTime,
	scan.ch[0].maxChannelTime, scan.numOfProbeRequests);

期望在 OPPO/HP 邀请建连时看到：nCh=1、nSSID≥1、max=200、probes=3。

9.2 抓包关注点

  1. Invitation / GO Neg 后的 Operating Channel 是否为 5G；
  2. 随后 Client 是否在该信道发出 多次 Probe Request；
  3. 信道驻留窗口内是否出现 GO Beacon 或 Probe Response；
  4. 对比合入前后：合入前常出现「短 dwell + 单次 Probe + 无 Response」。

9.3 回归

  • 2.4G Miracast / 普通 STA 单信道快扫是否仍受 single_channel_scan_reduce_time 加速；
  • 多信道扫描总时长无明显拉长；
  • 确认 single_channel_scan_reduce_time 未设（为 0）时，本分支因 maxChannelTime < 200 仍可能对默认 ~50 ms 的 5G 单信道带 SSID 扫生效（同样合理）。

10. 结论

修改点 1 在 atbm_hw_scan() 中，针对 邀请后 5G 单信道、带 SSID、且 dwell 不足 200 ms 的扫描，强制：

  • 驻留 100～200 ms（覆盖约两个 Beacon 周期）；
  • Probe 至少 3 次。

从而抵消 single_channel_scan_reduce_time 把定点找 GO 压成「50 ms + 1 Probe」的副作用，修复 OPPO Find N2 Flip / HP ProBook 465 等源端在 5G Operating Channel 上 扫不到 GO 导致连不上 的问题。

相关推荐
乌恩大侠2 小时前
从 5G 通信到厘米级感知：基于 NVIDIA Aerial、SRS 与 UL-TDOA 构建 6G 无线定位实验平台
人工智能·5g·电信大模型
广州灵眸科技有限公司9 小时前
4G 模组开机自连 systemd 服务方案：基于灵眸科技EAI1106--Core-T
运维·服务器·科技
qq_4017004110 小时前
Linux设备树详解
linux·运维·服务器
刚入门的大一新生11 小时前
Linux-信号
linux·运维·服务器
云宏信息16 小时前
超融合和存算分离怎么选？从性能、可靠性、扩展、成本四个维度讲述如何精准匹配架构选型 | 附企业降本轻量云方案
运维·服务器·架构·云计算
咸鱼梦想家π17 小时前
Linux开发工具（下）
linux·运维·服务器
云飞云共享云桌面18 小时前
机械制造研发部门：一台SolidWorks云主机替代 10 台传统图形工作站
运维·服务器·网络·3d·自动化·制造
j7～19 小时前
【ProtoBuf】(篇一）初识 ProtoBuf
运维·服务器·序列化·protobuf·protobuf的适用特点
丰锋ff19 小时前
用户管理命令
linux·运维·服务器
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03GitHub 镜像站点04历年考研数学一、数学二、数学三真题试卷及答案PDF05几个好用的ip纯净度检测网站06昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战07苹果iPA游戏软件资源下载网站08蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接09CVE-2026-91403 高危漏洞预警：Java JSSE 信任链被攻破 全场景修复方案与Linux系统级彻底清理实操10Windows 10/11 如何退出微软账户并改用本地账户登录（含找不到选项的解决方法）