wifit3 beacon_watch 基准测试指南：如何量化 RX 灵敏度并与内核驱动性能打平

wifit3 beacon_watch 基准测试指南：如何量化 RX 灵敏度并与内核驱动性能打平

【免费下载链接】wifit3Wifite but USB-only & cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3

wifit3 是一款纯 Python 编写的 USB Wi-Fi 审计（嗅探）工具，内置用户态无线驱动，跨 Linux / Windows / macOS 运行。它的beacon_watch脚本专门用来量化 USB 网卡的 RX 接收灵敏度：以“每秒收到多少 Beacon 帧”为核心指标，把 wifit3 用户态驱动和 Linux 内核驱动放在同一张卡、同一个参考 AP 下背靠背对比，让“性能打平”变成可复现的数字，而不是感觉。

为什么“每秒 Beacon 数”是 RX 灵敏度的最佳量尺 📡

Beacon 是路由器按固定间隔（通常 102.4 ms，约9.77 帧/秒）广播的心跳帧。一个 AP 的 Beacon 流就是天然的“标准测试信号源”：

• 理论上限固定：单个 AP 的 Beacon 流上限是 ~9.77/s，收到多少就是真实接收能力，不存在刷分空间。
• 只报一个 BSSID：scripts/rx/beacon_watch.py 默认只统计“听得分最多”的那个 AP（或用--bssid指定），避免把所有 AP 的 Beacon 求和造成虚高的“总产量”。
• 输出秒级直方图 + 接收率：每秒一格的柱状图能直接看到 RX 爬坡、丢帧毛刺；reception: N%一行给出相对线上上限的丢帧率。

这就是它文档里说的“快速 RX 脉搏检查”（quick RX pulse-check）——改了驱动某段代码，跑一次就知道“帮了还是害了”。

一次学会两种测量模式：实时监听 vs 离线回放

beacon_watch.py有两种模式，渲染格式完全一致，因此可以直接互相对比：

1. 实时模式（默认）：拉起被检测的 USB 网卡，停留在指定信道固定时长（默认 15 秒），按秒桶统计 Beacon。测量的是wifit3 自己的用户态驱动。
2. 离线模式（--pcap）：读取 Kali 上内核驱动抓的固定信道 airodump 包（用 tshark 解析），生成同样的直方图。测量的是内核驱动。

典型用法（在仓库根目录）：

uv run python scripts/rx/beacon_watch.py # 实时：听得分最好的 AP uv run python scripts/rx/beacon_watch.py --bssid 11:22:33:44:55:66 --channel 1 uv run python scripts/rx/beacon_watch.py --pcap captures/airodump-fixed-ch1.cap

细节见 scripts/rx/README.md。

跨芯片对比内核驱动的秘诀：beacon_watch_usbcap

内核侧最“干净”的数据来自usbmon 原始抓包：网卡收到的每个 802.11 帧都会以 bulk-IN 数据流经 USB 总线。scripts/rx/beacon_watch_usbcap.py 直接在 USB 原始字节流里扫描 Beacon 签名（帧控制字8000+ 广播目的地址 + BSSID），不需要为每种芯片写描述符解析，所以任何芯片族的抓包都能用。

它还有两个保证数据公正的设计：

• 自动裁剪到 FIXED-CH1 窗口：从日志里找出网卡真正固定在 1 信道的 15 秒区间，避免开机爬坡、空闲时间稀释接收率。
• 与实时模式共用同一渲染函数：usbmon 基线与 wifit3 实时驱动的输出长得一模一样，数字可以直接相减对比。

uv run python scripts/rx/beacon_watch_usbcap.py CAP.pcap --bssid 11:22:33:44:55:66

从单点数字到完整基准：baseline 三件套

一次 15 秒的脉搏检查之外，项目用 scripts/baseline/ 做逐信道完整基线：

关键设计：两侧原始 802.11 帧走同一个WlanFrameParser，分组逻辑完全一致——数字出现差距，只可能是驱动或射频的问题，绝不可能是解析器口径不同。

对比覆盖 4 个维度（每张卡各一行，附“与 Linux 的差距”和“与历史最佳卡的差距”）：

• Breadth（广度）：2.4 / 5 GHz 各听到了多少个 AP
• Beacon rate（信标率）：参考 AP 的每秒 Beacon 数
• RSSI：同卡同 AP 的接收电平差（同卡下持续偏差 = 解码 bug）
• Channel tune（信道调谐）：N/N 信道听到自己的 Beacon | 静默 | 串扰

数字如何变成评级：GRADING 的两根轴

基线数字最终喂给评级流程 docs/GRADING.md，核心是把“卡不行”拆成两根互不相干的轴：

1. Port 保真度：wifit3 用户态驱动 vs 同卡 Linux 内核驱动。差距 = 移植没做好，可修复。
2. 硬件天花板：这张卡在最好的驱动下本身行不行。Linux 都弱，移植也救不了。

结果写在 docs/SUPPORTED-HARDWARE.md。几个真实例子说明“打平”长什么样：

• RTL8822BU：2.4G 6.5 vs 6.4/s（102%，反超内核），RSSI 差仅 −0.5 dB → Port ✅
• AR9271：参考 AP 7.1 vs 7.6/s（93%），RSSI 准确 → 评级 92% (A)
• RTL8821AU：双频段 DKMS 90%/97% 打平 → 91% (A)
• RTL8814AU：未卡死时与 Linux 打平，但移植后有“跳信道后卡死”的内核没有的 bug → Port ⚠️，评级只给 D

新手 3 步跑通第一次 Beacon 基准 🚀

1. 准备硬件：一张 支持列表 里的 USB 网卡，只插这一张（拔掉其他卡，避免总线争抢干扰 RX）。
2. 抓内核侧基线：在 Kali 上用 scripts/capture.py 产生固定信道的抓包，或直接airmon-ng+tcpdump（BASELINING.md 有完整命令）。
3. 对比：
   • 快速版：beacon_watch.py（实时）vsbeacon_watch.py --pcap 内核抓包
   • 完整版：baseline_wifit3.py→baseline_linux.py→baseline_diff.py --diff ...

拿到reception: N%后，与 docs/SUPPORTED-HARDWARE.md 里同芯片的历史数字对照：接近 9.77/s 上限说明 RX 健康；明显偏低先看静默秒数（直方图里的 0 值格），再决定是驱动问题还是射频前端的硬件天花板。

常见坑位速查清单 📋

• 为什么不用 airodump 的.cap数 Beacon？airodump 会把 Beacon 去重成每 AP 每秒 1 帧还丢掉 radiotap——必须用 usbmon 原始包或带 radiotap 的 tcpdump。
• 参考 AP 漂信道怎么办？基线要求参考 AP 锁定在预期信道（如 ref2g 在 ch1），不在场则本次运行直接判无效，不记 0 分。
• RX 爬坡怎么看？秒级直方图开头的低/空桶就是爬坡期，--full关闭窗口裁剪时会稀释百分比，默认裁剪才是可信数字。
• 想隔离 DIG 看门狗的影响？加--no-dig禁用驱动内的 DIG/AGC 看门狗再测一次，差值就是它的 RX 贡献。
• 要验证长期稳定性？用 scripts/rx/soak.py 跑 30 分钟跳信道浸泡（30 分钟足以分辨退化曲线，且十几张卡全测下来不过一天）。

关键文件索引

一句话总结：beacon_watch用“每秒 Beacon 数”这个不可作弊的指标，加上“同一张卡、同一个参考 AP、同一套解析”的公平测试环境，让 wifit3 用户态驱动与内核驱动的 RX 能力对比从玄学变成了数字——大多数支持的 USB 网卡都能跑到 90% 以上的打平水平，差距一眼可见、可复现、可修复。

【免费下载链接】wifit3Wifite but USB-only & cross-platform.项目地址: https://gitcode.com/GitHub_Trending/wi/wifit3