做 Wi-Fi DFS 测试，真正让人头大的不是"雷达一来就换信道"这个行为本身，而是怎么在实验室里把一次雷达事件复现得干净、记录得完整，并且让 AP 日志、终端行为和频谱仪观测三方对上账。环境搭建、参数配置、日志记录这三件事看着独立，实际是一环扣一环——配置错了，测出来的结果能骗过脚本；日志少抓一类，出了问题根本没法追溯。我前前后后做过好几轮 5GHz 频段的无线 DFS 一致性验证，踩过的坑比教程上写满一整页的还多。这篇把我从零开始搭测试环境、调参数、抓日志的完整思路梳理出来，重点讲那些"常规文档不会写"的细节，适合刚接手 Wi-Fi DFS 测试、或者做无线射频验证但总被 5GHz 频段规则绕晕的同学参考。1. DFS 到底在避什么：5GHz 频段上的"共享公约"1.1 一种看不见的邻居：雷达不是网络设备DFS 全称是动态频率选择，是 Wi-Fi 在 5GHz 频段上必须遵守的一套雷达避让机制。这不是无线工程自己卷出来的功能，而是因为 5GHz 里有一部分频率是先分配给雷达系统使用的，后来开放给 Wi-Fi 等免许可设备共用，但共用是有条件的——Wi-Fi 设备一旦感知到雷达信号，必须主动让出信道。说的直白一点，Wi-Fi 就像住在别人屋檐下的房客，雷达才是这套房子的"产权人"。产权人说要用房间了，房客得在规定时间内搬走，还要在门口安静待一阵，确认产权人真的不来了，才能重新住回去。这个机制在 AP（无线接入点）侧实现，终端本身并不主动做雷达检测，它只是被动接收 AP 的切换指令。所以整个 DFS 测试的核心对象就是 AP：它能不能准确检测到雷达信号，能不能在时间限制内完成信道切换，切换后能不能保持有效的避让状态。这些行为，决定了 5GHz 频段上的 Wi-Fi 和雷达系统能不能和平共处。1.2 CAC、静默期、NOP：三个词背熟还要会用DFS 测试里天天要打交道的是三个概念：信道可用性检查、静默期、非占用期。很多刚开始做测试的同事把这三个词混着用，结果就是日志分析对不上。信道可用性检查（Channel Availability Check，简称 CAC）是 AP 在某个 DFS 信道上开始发射前必须完成的"雷达侦察"过程。AP 要在这个信道上安静监听一段时间，确认没有雷达信号，才能开启发射。这段时间不是随便定的，是监管规则明确要求的，通常为 60 秒，某些特定场景下短一些。测试时就要留意：AP 启动后不能立即在 DFS 信道上发包，必须先经历完整的 CAC 过程。静默期则是检测到雷达并且完成切换之后的行为。AP 检测到雷达，立刻让当前信道进入静默，停止在该信道上的所有发射，然后根据规则切换到另一个"干净"信道。静默不是一秒钟的事，它代表着一整套"停止发射、切换信道、在新信道重新做可用性确认"的状态。非占用期（Non-Occupancy Period，简称 NOP）是更长时间的约束。某个信道上曾经检测到雷达之后，AP 在一段时间内不会主动回到这个信道发射，时间通常是以 30 分钟为单位。这个参数容易被忽略，因为它的验证周期长，很多自动化脚本最多只跑十分钟，根本覆盖不到 NOP 的完整行为。把这几个概念放一张表里，测试时对照着看：概念含义典型时间测试关注点CAC信道发射前的雷达监听约 60 秒AP 启动时序、监听时长是否达标静默期检测到雷达后的发射停止通常几秒内切换延迟、上下线时机NOP雷达信道禁入时间约 30 分钟AP 是否会提前回到旧信道信道切换时间从雷达检测到新信道发射一般不超过 10 秒终端感知盲区长度这些时间参数会因不同地区的监管规则略有差异，配套的法规文档里都有明确规定。工程上做测试配置前，第一步永远是确认目标地区的规则要求，而不是直接照搬另一个项目的参数。2. 环境搭建：把无线空口变成可控实验场2.1 设备拓扑与射频链路：怎么接才是"干净"的DFS 测试的环境搭建，第一原则是"可控"。所谓可控，是指雷达信号必须是我们主动注入的，而不是靠运气在实验室里碰巧抓到某个真实雷达信号。真实雷达信号的到达时间、功率、波形都是不可控的，用它来验证 AP 行为，评测结果根本没法复现。我最常用的一套拓扑是这样的：被测 AP（DUT，Device Under Test）放在屏蔽箱或屏蔽室里，天线口通过射频线缆引出；雷达信号模拟器输出经过一个可调衰减器，再通过功分器分成两路，一路接到实时频谱仪做监测，另一路通过定向耦合器注入到 AP 的天线口。为什么用功分器分一路给频谱仪？因为单看 AP 日志是不够的——AP 说"我检测到了雷达"，你总得有个客观证据证明雷达信号真的在最关键的时刻到了天线口、功率等级真的足够触发检测。频谱仪那一路就是为了做这个交叉验证。如果测试环境没有独立雷达模拟器，也可以用信号源和任意波形发生器自己拼一段脉冲序列。但这么做的前提是你对雷达波形参数有精确掌握，而且要确保发射功率误差在可容忍范围内。模拟器省心，但价格不低；自己拼信号省钱，但调试时间会拉长。我在多个项目里两种方式都用过，给不出绝对最优解，只能说：预算允许就上专用模拟器，预算有限就自己拼，但一定要预留足够的排障时间。2.2 屏蔽室里的底噪基线检查：测之前先量"房间干不干净"环境搭建完毕，第一件事不是启动 AP，而是测底噪基线。这个步骤经常被忽略，但它直接决定测试结果可信度。具体做法是：把 AP 射频口接上负载，然后把实时频谱仪设置在目标 DFS 信道上，观察一段时间的噪声基底。不同项目对此要求不太一样，但经验值一般要求噪声基底低于某个合理门限，比如优于 -95dBm/MHz，而且在整个 DFS 频段上不能有明显突起。如果底噪偏高或者存在明显尖峰，通常说明屏蔽箱没盖严、射频线缆接头松了、或者附近有其他设备在发信号。有一回我排查了整整半天，最后发现是屏蔽箱门边上的密封条老化，雷达模拟器自身泄漏信号直接进了箱体，导致 AP 连 CAC 都没完成就报"检测到雷达"。这种问题如果不做底噪基线检查，会直接被误判成"AP 功能正常，雷达检测灵敏度过高"。底噪基线的意义还在于：它能帮你反推雷达信号注入功率的上限和下限。注入功率太低，会被底噪淹没，AP 无法稳定检测；注入功率太高，又可能超过 AP 接收前端线性范围，引入非线性失真。基线测量结果可以指导衰减器初始值的选择。2.3 雷达模拟波形的等级设置：先定相位，再定功率雷达波形的描述通常涉及脉冲宽度、脉冲重复间隔和脉冲数量这几个核心参数。不同监管规则对不同雷达类型的波形有不同定义，测试时要按目标地区的要求逐一配置并命名场景。我第一次做 DFS 时犯过一个错误：把所有雷达场景都按同一个脉冲等级设置，结果某个场景 AP 检测到了，另一个场景却始终测不出来。后来才意识到不同雷达类型的"检测难度"差异极大——有的长脉冲容易触发，有的短脉冲序列对检测算法要求很高，不能混为一谈。所以环境搭建阶段就要把雷达场景做分类管理。我的做法是给每个波形编号，记录它的脉宽、重复间隔、脉冲个数、注入功率、对应频谱仪捕获波形截图。这样一个场景出现"AP 没检测到"的问题时，可以直接凭编号倒查是波形参数变了还是功率等级变了。功率等级设置也需要特别说明：注入 AP 天线口的雷达信号功率要模拟"AP 能实际感知到的雷达信号"，而不是模拟雷达站发射功率。两者差着路径损耗，不能用雷达站功率直接换算。实际操作中，我会先以某个标称功率开始，比如 -45dBm 左右，再按测试需求上下调整，直到 AP 行为出现稳定响应。3. 参数配置：把 AP 的 DFS 行为配置得可预测3.1 hostapd 的 DFS 相关配置：每一行都要知道为什么如果被测 AP 是基于 Linux 无线栈的方案，大概率绕不开 hostapd。DFS 相关配置里，最核心的是这两行：ieee80211d=1 ieee80211h=1ieee80211d 开启的是国家信息通告，它会向终端宣告所在地区规则，让终端知道哪些信道可用、哪些信道不可用；ieee80211h 开启的才是真正的 DFS 功能，包括雷达检测和信道切换机制。只开 d 不开 h，5GHz 频段上很多 DFS 信道根本不会启用；只开 h 不开 d，地区规则又可能不完整。接下来是信道选择方式。想让 AP 在 5GHz 上按照 DFS 逻辑自己挑信道，可以把信道配置为 0，也就是动态信道选择模式：channel=0配合chanlist指定候选信道列表，例如：chanlist=5180 5260 5280 5500 5580这样配置的好处是，AP 会在这个列表里按照可用性规则遍历选择，遇到雷达就换下一个。如果直接把 channel 写死成某个固定 DFS 信道，比如 5260，那 AP 在这个信道上检测到雷达后，会因为没有可切换的候选信道而陷入一种比较尴尬的"无信道可用"状态，测试场景就不完整了。还有一个容易被忽略的参数是区域码。在无线网络领域，区域码决定了可用信道和发射功率上限。做 DFS 测试时，区域码必须和目标测试地区的无线电监管规则一致，否则 AP 可能会按照另一个地区的规则去执行 CAC 时长和 NOP，测试结果自然没有意义。启动 hostapd 时，我建议加上调试选项：hostapd -dd /etc/hostapd/hostapd.conf两个 d 会把调试级别的日志打到前台，方便实时观察 DFS 状态机变化。实际工程中，我会把这个进程输出重定向到一个滚动日志文件，避免分析时日志已经滚没了。3.2 CAC 时间从哪来：不要只盯着"60 秒"这个数字有人看到 CAC 60 秒，就觉得所有场景都是 60 秒。其实 CAC 时长的具体数值取决于多个因素，包括地区规则和信道类型。有些信道属于普通 DFS 信道，有些则属于特定条件下的信道，它们的可用性检查策略是不同的。最常见的差异是：如果一个信道在 AP 启动前已经处于静默状态一段时间，部分规则允许缩短 CAC；但这不意味着测试时可以随便把 CAC 改成 10 秒来加速验证。工程上更稳妥的做法是：测试脚本里显式记录每个信道的 CAC 起始和结束时间，而不是依赖 hostapd 默认数值。我在脚本里通常会这样处理：AP 上电后，从 hostapd 日志里抓CAC_STARTED和CAC_COMPLETED两个事件，计算实际 CAC 时长，然后和规则要求比对。这样无论是普通情况还是特殊情况，都有实打实的时间戳。千万别因为"反正 AP 会自动做 CAC"就把这步省了。我见过不止一次，驱动版本更新后 CAC 功能没有回归测试，AP 在 DFS 信道上直接开始发射，完全跳过了监听过程。问题不一定会导致测试失败，但一定会在实际部署中埋雷。3.3 雷达检测阈值与误检之间的平衡雷达检测阈值本质上是一个灵敏度设定。阈值设得太高，AP 对弱雷达信号不敏感，该切换时不切换，测试直接失败；阈值设得太低，AP 会把一些非雷达的脉冲信号误判成雷达，频繁触发切换，终端体验一团糟。很多 Linux 驱动允许通过 debugfs 或对应驱动参数调整检测阈值。这个参数一般以 dBm 为单位，表示最小触发检测的雷达信号功率。我在某芯片平台上调过多次，经验是：不能只看阈值本身，还要关注 AP 天线口到接收链路的插损。射频线缆、衰减器、连接器都会衰减信号，同一个阈值设置，不同的链路插损等于不同的实际灵敏度。举个例子说明链路插损的影响。假设阈值配置为 -60dBm，AP 天线口到射频输入端的插损是 3dB，那么要想让 AP 真正触发检测，雷达信号注入功率至少要达到 -57dBm 以上。如果测试拓扑里多接了一个 10dB 衰减器而忘了换算，即使模拟器输出 -50dBm，到了 AP 也只有 -60dBm，刚好在阈值边缘，时好时坏，误检和漏检同时存在，问题最难查。4. 日志记录：让雷达事件从"听说"变成"实锤"4.1 该同时抓哪些日志：日志少抓一类，回溯就断一截DFS 测试的日志记录，核心目标是"让雷达事件可复盘"——事后可以说清楚，哪一秒雷达信号被注入，哪一秒 AP 检测到，哪一秒发出切换指令，哪一秒终端才真正失去连接。需要同时抓的日志至少包括这几类：hostapd 前台日志（带调试级别）内核日志，包括驱动发出的 802.11 管理帧相关信息无线事件日志，比如通过 iw event 监听接口状态变化终端侧日志，确认断开和重新关联的时间点频谱仪测量记录，确认射频信号实际到达时间很多项目只抓 hostapd 日志，把终端侧日志省略了。这会导致一个问题：AP 日志显示"切换成功"，但终端实际断线了几秒钟，没有终端日志根本定位不到这段体验劣化。DFS 测试不仅测 AP 遵守规则，更要测规则执行对业务的影响，终端侧数据是这条链路里不可缺少的一环。4.2 时间戳对齐是日志分析的生命线日志抓了却不做时间同步，等于没抓。有一次我处理一个"AP 明明在 2 秒内完成了信道切换，但终端却断线 8 秒"的疑难问题，查了整整一天，最后发现终端日志的时间和频谱仪时间差了 6 秒——根本是同一个事件被对齐到了错误的时间轴，导致结论完全反了。时间戳对齐的标准做法是：在测试环境里搭一台统一的日志采集服务器，所有被测设备通过 NTP 同步到这个服务器。但实验室环境往往不允许 AP 直接对公网 NTP，那就需要自己起一个内部时间服务器。如果涉及频谱仪这类仪器，还要留意仪器本身的时间设置，最好也在测试脚本启动时统一校正。光有时钟同步还不够。工程上我会在测试开始前做一个"时间锚点"操作：手动触发一次已知事件，比如人为断开 AP 电源，然后在各日志里查找对应的记录点，用来校准各日志之间的相对偏移。这个操作成本极低，但对事后分析帮助巨大。4.3 一个可复用的取证流程：预触发、记录、比对把整个日志记录流程串成一个固定步骤，每次测试都照做，出来的数据就不会乱。第一步，测试开始前完成时间同步，并且在所有日志源打上测试编号。第二步，配置好采集脚本，确保 hostapd、内核终端日志持续落盘，频谱仪开启连续记录模式。第三步，注入雷达信号，同时手动记录注入时间。第四步，等待 AP 完成切换后，停止采集。第五步，把所有来源的记录拉齐到同一时间轴，生成事件对齐表。事件对齐表是分析的核心，我会把它做成下面这样的结构：时间事件源事件描述T0测试脚本开始注入雷达波形T0+xx频谱仪捕获到雷达脉冲序列T0+xxhostapd上报 DFS 雷达事件T0+xx内核信道切换指令发出T0+xx终端收到信道切换通告有了这个表，再配合每一类事件的原始日志片段，一个 DFS 事件就彻底从"听说"变成了"实锤"。我这个流程结合了之前提到的三层数据来源，实际操作中建议固定成模板脚本，不要每次临时搭。5. 实测中三次"假通过"复盘：看似达标，实则埋雷5.1 第一次："明明切换了信道，雷达压根没被检测到"第一次做完整的 DFS 回归测试时，我遇到的场景是：注入雷达信号后，AP 日志里出现了信道切换记录，测试脚本判定"通过"。但我总觉得不对劲，因为频谱仪那一侧并没有捕获到一次像样的雷达脉冲到达 AP 天线口。后来排查发现，雷达模拟器和 AP 之间的衰减器被误调到了最大档位，注入功率比预期低了一大截，AP 本来不可能检测到。那 AP 为什么切换信道了呢？原因更尴尬——测试脚本里另外有一个手动触发切换的调试动作，时间刚好和雷达注入重叠，脚本把两次事件混在了一起。这件事给我的教训是：DFS 测试的"通过"不能只看 AP 有没有切换信道，必须先确认"AP 确实检测到了雷达信号"这个前提成立。最可靠的验证就是频谱仪捕获到的信号到达时间，要早于或等于 AP 日志里的检测时间，并且功率要确实超过检测门限设置。5.2 第二次：切换消息发得出来，终端却断了音讯另一次测试中，AP 完美完成了检测和切换，主机日志里的时间戳干净利落，切换耗时也完全在预期范围内。但压测终端时才发现，终端在信道切换后的重关联过程中反复失败，业务中断时间远超容忍值。问题出在 802.11 管理帧的处理上。AP 发出信道切换通告后，终端需要在新信道上重新同步。如果 AP 在切换通告和实际信道切换之间的间隔太短，终端还没处理完通告，信道就已经变了，终端就会在新旧信道之间来回找。从测试角度讲，这暴露了一个问题：单台终端"能连上"并不代表切换平滑。我后来把终端行为纳入测试指标，不只记录"是否最终重连成功"，还要记录"断连到重连的精确时长"。这个时长才是真正影响用户体验的指标，只看 AP 侧日志永远发现不了这类问题。5.3 第三次：日志说"静默完成"，频谱仪却说"一直有波形"还有一次比较典型的"假通过"是日志和空口行为不一致。AP 日志显示已经进入静默期，所有发射都该停止了，但空间耦合的频谱仪记录显示在静默期内，该信道上仍时不时出现能量突起。排查后确认，这不是 AP 主机本身在发射，而是测试环境里另一台辅助设备在同样的信道上运行，它不在 DFS 控制范围内。辅助设备持续发包，干扰了静默期的观测。这类问题说明，测试环境的"干净"不仅指射频噪声低，还包括环境里所有无线设备都要纳入统一管控。解决方法是把整个测试只留下被测 AP 和必要的终端、雷达模拟器，其他无关设备全部关闭或挪到另外的频段。这个结论听起来很简单，但实际操作中"杜绝干扰"往往要花很长时间，尤其是多团队共用一个实验室的时候。我现在会在测试前把实验室设备清单过一遍，明确哪些设备会开机，在什么信道工作，全部记录在案。6. 几个从工程现场带回来的固化建议6.1 把雷达场景固化成自动化脚本：人在，不如案在DFS 测试涉及的场景组合很多，如果每次人工操作，效率低且容易漏项。我的做法是把雷达波形参数、注入时长、注入功率、目标信道、预期行为全部写进一个测试清单文件，用脚本驱动整个流程。脚本里至少要有这样的逻辑：拉起 hostapd、等待 CAC 完成、确认工作信道、注入雷达、等待 AP 上报事件、采集日志、对比频谱仪记录、生成结果报告。整个过程不需要人坐在屏幕前盯细节，但每一步的结果都会沉淀下来，方便事后追溯。脚本的断言不能只断"有没有上报雷达事件"这种粗粒度结论。我通常还会断言"频谱仪是否捕获到波形""信道切换通告是否发送""终端是否在限定时间内重关联"。断言越细，假通过的漏网概率越低。6.2 配置文件和日志的版本管理：测完一个月后还能复盘测试过程会产生多轮配置调整，如果不对配置做版本管理，一个月后回溯会非常痛苦。我会把 hostapd 配置、雷达场景文件、测试脚本、日志解析工具统一丢进版本管理仓库，每次变更都打上标签，标签里写明针对哪个测试轮次。这是一个很轻量的习惯，但长期坚持下来，项目经验就能不断沉淀。日志本身不需要全部进版本库，但日志的"提取脚本和分析脚本"必须进。数据体积太大时，我会只保留对应测试轮次的事件对齐表，原始日志在本地归档，目录命名用"日期+测试编号+场景名"格式。6.3 做 DFS 测试的几条军规第一，永远先确认区域配置再谈测试结果。不同地区的监管规则决定了对 CAC、NOP 和切换时间的不同要求，拿 A 地区的规则去测 B 地区的配置，结果毫无意义。第二，频谱仪记录是"事实层"，AP 日志是"行为层"，两者必须同时出现并交叉验证才可以作为判定依据。第三，测试之前把底噪、链路插损、天线增益全部量一遍，别相信上一次调完就永远不用再调。最后分享一个我坚持了很久的小细节：每次测试开始前，我会把雷达模拟器的输出功率校准记录贴到测试记录里，同时记录当天室温。看起来多此一举，但有一次结果有差异，排查下来就是因为某个功分器在不同温度下插损变化导致注入功率漂移。DFS 测试就是这样，每一个"看着没事"的环节都值得被认真对待，最终才能让结果真正站得住脚。
做 Wi-Fi DFS 测试，真正让人头大的不是"雷达一来就换信道"这个行为本身，而是怎么在实验室里把一次雷达事件复现得干净、记录得完整，并且让 AP 日志、终端行为和频谱仪观测三方对上账。环境搭建、参数配置、日志记录这三件事看着独立，实际是一环扣一环——配置错了，测出来的结果能骗过脚本；日志少抓一类，出了问题根本没法追溯。我前前后后做过好几轮 5GHz 频段的无线 DFS 一致性验证，踩过的坑比教程上写满一整页的还多。这篇把我从零开始搭测试环境、调参数、抓日志的完整思路梳理出来，重点讲那些"常规文档不会写"的细节，适合刚接手 Wi-Fi DFS 测试、或者做无线射频验证但总被 5GHz 频段规则绕晕的同学参考。1. DFS 到底在避什么：5GHz 频段上的"共享公约"1.1 一种看不见的邻居：雷达不是网络设备DFS 全称是动态频率选择，是 Wi-Fi 在 5GHz 频段上必须遵守的一套雷达避让机制。这不是无线工程自己卷出来的功能，而是因为 5GHz 里有一部分频率是先分配给雷达系统使用的，后来开放给 Wi-Fi 等免许可设备共用，但共用是有条件的——Wi-Fi 设备一旦感知到雷达信号，必须主动让出信道。说的直白一点，Wi-Fi 就像住在别人屋檐下的房客，雷达才是这套房子的"产权人"。产权人说要用房间了，房客得在规定时间内搬走，还要在门口安静待一阵，确认产权人真的不来了，才能重新住回去。这个机制在 AP（无线接入点）侧实现，终端本身并不主动做雷达检测，它只是被动接收 AP 的切换指令。所以整个 DFS 测试的核心对象就是 AP：它能不能准确检测到雷达信号，能不能在时间限制内完成信道切换，切换后能不能保持有效的避让状态。这些行为，决定了 5GHz 频段上的 Wi-Fi 和雷达系统能不能和平共处。1.2 CAC、静默期、NOP：三个词背熟还要会用DFS 测试里天天要打交道的是三个概念：信道可用性检查、静默期、非占用期。很多刚开始做测试的同事把这三个词混着用，结果就是日志分析对不上。信道可用性检查（Channel Availability Check，简称 CAC）是 AP 在某个 DFS 信道上开始发射前必须完成的"雷达侦察"过程。AP 要在这个信道上安静监听一段时间，确认没有雷达信号，才能开启发射。这段时间不是随便定的，是监管规则明确要求的，通常为 60 秒，某些特定场景下短一些。测试时就要留意：AP 启动后不能立即在 DFS 信道上发包，必须先经历完整的 CAC 过程。静默期则是检测到雷达并且完成切换之后的行为。AP 检测到雷达，立刻让当前信道进入静默，停止在该信道上的所有发射，然后根据规则切换到另一个"干净"信道。静默不是一秒钟的事，它代表着一整套"停止发射、切换信道、在新信道重新做可用性确认"的状态。非占用期（Non-Occupancy Period，简称 NOP）是更长时间的约束。某个信道上曾经检测到雷达之后，AP 在一段时间内不会主动回到这个信道发射，时间通常是以 30 分钟为单位。这个参数容易被忽略，因为它的验证周期长，很多自动化脚本最多只跑十分钟，根本覆盖不到 NOP 的完整行为。把这几个概念放一张表里，测试时对照着看：概念含义典型时间测试关注点CAC信道发射前的雷达监听约 60 秒AP 启动时序、监听时长是否达标静默期检测到雷达后的发射停止通常几秒内切换延迟、上下线时机NOP雷达信道禁入时间约 30 分钟AP 是否会提前回到旧信道信道切换时间从雷达检测到新信道发射一般不超过 10 秒终端感知盲区长度这些时间参数会因不同地区的监管规则略有差异，配套的法规文档里都有明确规定。工程上做测试配置前，第一步永远是确认目标地区的规则要求，而不是直接照搬另一个项目的参数。2. 环境搭建：把无线空口变成可控实验场2.1 设备拓扑与射频链路：怎么接才是"干净"的DFS 测试的环境搭建，第一原则是"可控"。所谓可控，是指雷达信号必须是我们主动注入的，而不是靠运气在实验室里碰巧抓到某个真实雷达信号。真实雷达信号的到达时间、功率、波形都是不可控的，用它来验证 AP 行为，评测结果根本没法复现。我最常用的一套拓扑是这样的：被测 AP（DUT，Device Under Test）放在屏蔽箱或屏蔽室里，天线口通过射频线缆引出；雷达信号模拟器输出经过一个可调衰减器，再通过功分器分成两路，一路接到实时频谱仪做监测，另一路通过定向耦合器注入到 AP 的天线口。为什么用功分器分一路给频谱仪？因为单看 AP 日志是不够的——AP 说"我检测到了雷达"，你总得有个客观证据证明雷达信号真的在最关键的时刻到了天线口、功率等级真的足够触发检测。频谱仪那一路就是为了做这个交叉验证。如果测试环境没有独立雷达模拟器，也可以用信号源和任意波形发生器自己拼一段脉冲序列。但这么做的前提是你对雷达波形参数有精确掌握，而且要确保发射功率误差在可容忍范围内。模拟器省心，但价格不低；自己拼信号省钱，但调试时间会拉长。我在多个项目里两种方式都用过，给不出绝对最优解，只能说：预算允许就上专用模拟器，预算有限就自己拼，但一定要预留足够的排障时间。2.2 屏蔽室里的底噪基线检查：测之前先量"房间干不干净"环境搭建完毕，第一件事不是启动 AP，而是测底噪基线。这个步骤经常被忽略，但它直接决定测试结果可信度。具体做法是：把 AP 射频口接上负载，然后把实时频谱仪设置在目标 DFS 信道上，观察一段时间的噪声基底。不同项目对此要求不太一样，但经验值一般要求噪声基底低于某个合理门限，比如优于 -95dBm/MHz，而且在整个 DFS 频段上不能有明显突起。如果底噪偏高或者存在明显尖峰，通常说明屏蔽箱没盖严、射频线缆接头松了、或者附近有其他设备在发信号。有一回我排查了整整半天，最后发现是屏蔽箱门边上的密封条老化，雷达模拟器自身泄漏信号直接进了箱体，导致 AP 连 CAC 都没完成就报"检测到雷达"。这种问题如果不做底噪基线检查，会直接被误判成"AP 功能正常，雷达检测灵敏度过高"。底噪基线的意义还在于：它能帮你反推雷达信号注入功率的上限和下限。注入功率太低，会被底噪淹没，AP 无法稳定检测；注入功率太高，又可能超过 AP 接收前端线性范围，引入非线性失真。基线测量结果可以指导衰减器初始值的选择。2.3 雷达模拟波形的等级设置：先定相位，再定功率雷达波形的描述通常涉及脉冲宽度、脉冲重复间隔和脉冲数量这几个核心参数。不同监管规则对不同雷达类型的波形有不同定义，测试时要按目标地区的要求逐一配置并命名场景。我第一次做 DFS 时犯过一个错误：把所有雷达场景都按同一个脉冲等级设置，结果某个场景 AP 检测到了，另一个场景却始终测不出来。后来才意识到不同雷达类型的"检测难度"差异极大——有的长脉冲容易触发，有的短脉冲序列对检测算法要求很高，不能混为一谈。所以环境搭建阶段就要把雷达场景做分类管理。我的做法是给每个波形编号，记录它的脉宽、重复间隔、脉冲个数、注入功率、对应频谱仪捕获波形截图。这样一个场景出现"AP 没检测到"的问题时，可以直接凭编号倒查是波形参数变了还是功率等级变了。功率等级设置也需要特别说明：注入 AP 天线口的雷达信号功率要模拟"AP 能实际感知到的雷达信号"，而不是模拟雷达站发射功率。两者差着路径损耗，不能用雷达站功率直接换算。实际操作中，我会先以某个标称功率开始，比如 -45dBm 左右，再按测试需求上下调整，直到 AP 行为出现稳定响应。3. 参数配置：把 AP 的 DFS 行为配置得可预测3.1 hostapd 的 DFS 相关配置：每一行都要知道为什么如果被测 AP 是基于 Linux 无线栈的方案，大概率绕不开 hostapd。DFS 相关配置里，最核心的是这两行：ieee80211d=1 ieee80211h=1ieee80211d 开启的是国家信息通告，它会向终端宣告所在地区规则，让终端知道哪些信道可用、哪些信道不可用；ieee80211h 开启的才是真正的 DFS 功能，包括雷达检测和信道切换机制。只开 d 不开 h，5GHz 频段上很多 DFS 信道根本不会启用；只开 h 不开 d，地区规则又可能不完整。接下来是信道选择方式。想让 AP 在 5GHz 上按照 DFS 逻辑自己挑信道，可以把信道配置为 0，也就是动态信道选择模式：channel=0配合chanlist指定候选信道列表，例如：chanlist=5180 5260 5280 5500 5580这样配置的好处是，AP 会在这个列表里按照可用性规则遍历选择，遇到雷达就换下一个。如果直接把 channel 写死成某个固定 DFS 信道，比如 5260，那 AP 在这个信道上检测到雷达后，会因为没有可切换的候选信道而陷入一种比较尴尬的"无信道可用"状态，测试场景就不完整了。还有一个容易被忽略的参数是区域码。在无线网络领域，区域码决定了可用信道和发射功率上限。做 DFS 测试时，区域码必须和目标测试地区的无线电监管规则一致，否则 AP 可能会按照另一个地区的规则去执行 CAC 时长和 NOP，测试结果自然没有意义。启动 hostapd 时，我建议加上调试选项：hostapd -dd /etc/hostapd/hostapd.conf两个 d 会把调试级别的日志打到前台，方便实时观察 DFS 状态机变化。实际工程中，我会把这个进程输出重定向到一个滚动日志文件，避免分析时日志已经滚没了。3.2 CAC 时间从哪来：不要只盯着"60 秒"这个数字有人看到 CAC 60 秒，就觉得所有场景都是 60 秒。其实 CAC 时长的具体数值取决于多个因素，包括地区规则和信道类型。有些信道属于普通 DFS 信道，有些则属于特定条件下的信道，它们的可用性检查策略是不同的。最常见的差异是：如果一个信道在 AP 启动前已经处于静默状态一段时间，部分规则允许缩短 CAC；但这不意味着测试时可以随便把 CAC 改成 10 秒来加速验证。工程上更稳妥的做法是：测试脚本里显式记录每个信道的 CAC 起始和结束时间，而不是依赖 hostapd 默认数值。我在脚本里通常会这样处理：AP 上电后，从 hostapd 日志里抓CAC_STARTED和CAC_COMPLETED两个事件，计算实际 CAC 时长，然后和规则要求比对。这样无论是普通情况还是特殊情况，都有实打实的时间戳。千万别因为"反正 AP 会自动做 CAC"就把这步省了。我见过不止一次，驱动版本更新后 CAC 功能没有回归测试，AP 在 DFS 信道上直接开始发射，完全跳过了监听过程。问题不一定会导致测试失败，但一定会在实际部署中埋雷。3.3 雷达检测阈值与误检之间的平衡雷达检测阈值本质上是一个灵敏度设定。阈值设得太高，AP 对弱雷达信号不敏感，该切换时不切换，测试直接失败；阈值设得太低，AP 会把一些非雷达的脉冲信号误判成雷达，频繁触发切换，终端体验一团糟。很多 Linux 驱动允许通过 debugfs 或对应驱动参数调整检测阈值。这个参数一般以 dBm 为单位，表示最小触发检测的雷达信号功率。我在某芯片平台上调过多次，经验是：不能只看阈值本身，还要关注 AP 天线口到接收链路的插损。射频线缆、衰减器、连接器都会衰减信号，同一个阈值设置，不同的链路插损等于不同的实际灵敏度。举个例子说明链路插损的影响。假设阈值配置为 -60dBm，AP 天线口到射频输入端的插损是 3dB，那么要想让 AP 真正触发检测，雷达信号注入功率至少要达到 -57dBm 以上。如果测试拓扑里多接了一个 10dB 衰减器而忘了换算，即使模拟器输出 -50dBm，到了 AP 也只有 -60dBm，刚好在阈值边缘，时好时坏，误检和漏检同时存在，问题最难查。4. 日志记录：让雷达事件从"听说"变成"实锤"4.1 该同时抓哪些日志：日志少抓一类，回溯就断一截DFS 测试的日志记录，核心目标是"让雷达事件可复盘"——事后可以说清楚，哪一秒雷达信号被注入，哪一秒 AP 检测到，哪一秒发出切换指令，哪一秒终端才真正失去连接。需要同时抓的日志至少包括这几类：hostapd 前台日志（带调试级别）内核日志，包括驱动发出的 802.11 管理帧相关信息无线事件日志，比如通过 iw event 监听接口状态变化终端侧日志，确认断开和重新关联的时间点频谱仪测量记录，确认射频信号实际到达时间很多项目只抓 hostapd 日志，把终端侧日志省略了。这会导致一个问题：AP 日志显示"切换成功"，但终端实际断线了几秒钟，没有终端日志根本定位不到这段体验劣化。DFS 测试不仅测 AP 遵守规则，更要测规则执行对业务的影响，终端侧数据是这条链路里不可缺少的一环。4.2 时间戳对齐是日志分析的生命线日志抓了却不做时间同步，等于没抓。有一次我处理一个"AP 明明在 2 秒内完成了信道切换，但终端却断线 8 秒"的疑难问题，查了整整一天，最后发现终端日志的时间和频谱仪时间差了 6 秒——根本是同一个事件被对齐到了错误的时间轴，导致结论完全反了。时间戳对齐的标准做法是：在测试环境里搭一台统一的日志采集服务器，所有被测设备通过 NTP 同步到这个服务器。但实验室环境往往不允许 AP 直接对公网 NTP，那就需要自己起一个内部时间服务器。如果涉及频谱仪这类仪器，还要留意仪器本身的时间设置，最好也在测试脚本启动时统一校正。光有时钟同步还不够。工程上我会在测试开始前做一个"时间锚点"操作：手动触发一次已知事件，比如人为断开 AP 电源，然后在各日志里查找对应的记录点，用来校准各日志之间的相对偏移。这个操作成本极低，但对事后分析帮助巨大。4.3 一个可复用的取证流程：预触发、记录、比对把整个日志记录流程串成一个固定步骤，每次测试都照做，出来的数据就不会乱。第一步，测试开始前完成时间同步，并且在所有日志源打上测试编号。第二步，配置好采集脚本，确保 hostapd、内核终端日志持续落盘，频谱仪开启连续记录模式。第三步，注入雷达信号，同时手动记录注入时间。第四步，等待 AP 完成切换后，停止采集。第五步，把所有来源的记录拉齐到同一时间轴，生成事件对齐表。事件对齐表是分析的核心，我会把它做成下面这样的结构：时间事件源事件描述T0测试脚本开始注入雷达波形T0+xx频谱仪捕获到雷达脉冲序列T0+xxhostapd上报 DFS 雷达事件T0+xx内核信道切换指令发出T0+xx终端收到信道切换通告有了这个表，再配合每一类事件的原始日志片段，一个 DFS 事件就彻底从"听说"变成了"实锤"。我这个流程结合了之前提到的三层数据来源，实际操作中建议固定成模板脚本，不要每次临时搭。5. 实测中三次"假通过"复盘：看似达标，实则埋雷5.1 第一次："明明切换了信道，雷达压根没被检测到"第一次做完整的 DFS 回归测试时，我遇到的场景是：注入雷达信号后，AP 日志里出现了信道切换记录，测试脚本判定"通过"。但我总觉得不对劲，因为频谱仪那一侧并没有捕获到一次像样的雷达脉冲到达 AP 天线口。后来排查发现，雷达模拟器和 AP 之间的衰减器被误调到了最大档位，注入功率比预期低了一大截，AP 本来不可能检测到。那 AP 为什么切换信道了呢？原因更尴尬——测试脚本里另外有一个手动触发切换的调试动作，时间刚好和雷达注入重叠，脚本把两次事件混在了一起。这件事给我的教训是：DFS 测试的"通过"不能只看 AP 有没有切换信道，必须先确认"AP 确实检测到了雷达信号"这个前提成立。最可靠的验证就是频谱仪捕获到的信号到达时间，要早于或等于 AP 日志里的检测时间，并且功率要确实超过检测门限设置。5.2 第二次：切换消息发得出来，终端却断了音讯另一次测试中，AP 完美完成了检测和切换，主机日志里的时间戳干净利落，切换耗时也完全在预期范围内。但压测终端时才发现，终端在信道切换后的重关联过程中反复失败，业务中断时间远超容忍值。问题出在 802.11 管理帧的处理上。AP 发出信道切换通告后，终端需要在新信道上重新同步。如果 AP 在切换通告和实际信道切换之间的间隔太短，终端还没处理完通告，信道就已经变了，终端就会在新旧信道之间来回找。从测试角度讲，这暴露了一个问题：单台终端"能连上"并不代表切换平滑。我后来把终端行为纳入测试指标，不只记录"是否最终重连成功"，还要记录"断连到重连的精确时长"。这个时长才是真正影响用户体验的指标，只看 AP 侧日志永远发现不了这类问题。5.3 第三次：日志说"静默完成"，频谱仪却说"一直有波形"还有一次比较典型的"假通过"是日志和空口行为不一致。AP 日志显示已经进入静默期，所有发射都该停止了，但空间耦合的频谱仪记录显示在静默期内，该信道上仍时不时出现能量突起。排查后确认，这不是 AP 主机本身在发射，而是测试环境里另一台辅助设备在同样的信道上运行，它不在 DFS 控制范围内。辅助设备持续发包，干扰了静默期的观测。这类问题说明，测试环境的"干净"不仅指射频噪声低，还包括环境里所有无线设备都要纳入统一管控。解决方法是把整个测试只留下被测 AP 和必要的终端、雷达模拟器，其他无关设备全部关闭或挪到另外的频段。这个结论听起来很简单，但实际操作中"杜绝干扰"往往要花很长时间，尤其是多团队共用一个实验室的时候。我现在会在测试前把实验室设备清单过一遍，明确哪些设备会开机，在什么信道工作，全部记录在案。6. 几个从工程现场带回来的固化建议6.1 把雷达场景固化成自动化脚本：人在，不如案在DFS 测试涉及的场景组合很多，如果每次人工操作，效率低且容易漏项。我的做法是把雷达波形参数、注入时长、注入功率、目标信道、预期行为全部写进一个测试清单文件，用脚本驱动整个流程。脚本里至少要有这样的逻辑：拉起 hostapd、等待 CAC 完成、确认工作信道、注入雷达、等待 AP 上报事件、采集日志、对比频谱仪记录、生成结果报告。整个过程不需要人坐在屏幕前盯细节，但每一步的结果都会沉淀下来，方便事后追溯。脚本的断言不能只断"有没有上报雷达事件"这种粗粒度结论。我通常还会断言"频谱仪是否捕获到波形""信道切换通告是否发送""终端是否在限定时间内重关联"。断言越细，假通过的漏网概率越低。6.2 配置文件和日志的版本管理：测完一个月后还能复盘测试过程会产生多轮配置调整，如果不对配置做版本管理，一个月后回溯会非常痛苦。我会把 hostapd 配置、雷达场景文件、测试脚本、日志解析工具统一丢进版本管理仓库，每次变更都打上标签，标签里写明针对哪个测试轮次。这是一个很轻量的习惯，但长期坚持下来，项目经验就能不断沉淀。日志本身不需要全部进版本库，但日志的"提取脚本和分析脚本"必须进。数据体积太大时，我会只保留对应测试轮次的事件对齐表，原始日志在本地归档，目录命名用"日期+测试编号+场景名"格式。6.3 做 DFS 测试的几条军规第一，永远先确认区域配置再谈测试结果。不同地区的监管规则决定了对 CAC、NOP 和切换时间的不同要求，拿 A 地区的规则去测 B 地区的配置，结果毫无意义。第二，频谱仪记录是"事实层"，AP 日志是"行为层"，两者必须同时出现并交叉验证才可以作为判定依据。第三，测试之前把底噪、链路插损、天线增益全部量一遍，别相信上一次调完就永远不用再调。最后分享一个我坚持了很久的小细节：每次测试开始前，我会把雷达模拟器的输出功率校准记录贴到测试记录里，同时记录当天室温。看起来多此一举，但有一次结果有差异，排查下来就是因为某个功分器在不同温度下插损变化导致注入功率漂移。DFS 测试就是这样，每一个"看着没事"的环节都值得被认真对待，最终才能让结果真正站得住脚。