最近幼锐收到了某网点客户的反馈。。。。。。

“平板电脑在衔接网点内AP放出的信号时，，，，，Wi-Fi总是自动断开衔接，，，，，严沉影响业务运行！”

听闻新闻，，，，，幼锐立马赶往客户现场，，，，，火速处置：

机智的幼锐顿时打开Wi-Fi魔盒扫描周围环境滋扰情况，，，，，发现环境相对比力干净。。。。。。。

既然如此，，，，，先瞅一眼AP上有关日志再说，，，，，通过日志上发现终端在发送认证关联报文之后，，，，，顿时又发出了大量的解认证报文：

AP频仍收到终端解认证报文并打印日志

不仅如此，，，，，现场2.4G与5.8G频段所有终端关联时均存在这个景象，，，，，幼锐顿时就意识到：

有了疑惑方向后，，，，，幼锐第一功夫查抄AC配置，，，，，发现AC上配置了有关的反造号令，，，，，为了排除AP间自身相互影响，，，，，先将现场反造AP职能关关，，，，，发现终端关联时依然存在自动断开的情况，，，，，问题的排查陷入了僵局。。。。。。。

(Tips：无线瘦AP放出beacon帧里面有个firendly flag，，，，，别名敦睦标志位。。。。。。。通常情况下，，，，，上线在统一台AC的AP敦睦标志位默认是一样的，，，，，不会相互反造。。。。。。。）

这样的设法在脑中一闪而过，，，，，幼锐顿时拿出了随身携带的空口抓包网卡，，，，，在现场进行了空口抓包

通过空口抓包，，，，，幼锐发现了终端(MAC尾号：F057)从一个源地址收到多个Deauth报文。。。。。。。（解认证）

再通过报文信号强度对比，，，，，正常AP发出的Beacon报文信号强度高（-29dbm），，，，，由于AP就在头顶；；；；；Deauth报文信号比力弱（-90dbm），，，，，正常统一个AP发出的Beacon和Deauth报文信号强度差不多，，，，，因而通过报文对比初步判断的确可能存在反造情况，，，，，并且反造设备距离终端较远。。。。。。。

现场AP地位

既然问题相对明确了，，，，，现场接下来要做的就是找出这个反造源了，，，，，这可难不倒我幼锐！

首先，，，，，通过空口抓包软件omnipeek上设置好抓包前过滤前提，，，，，只抓ap地点信路deauth报文。。。。。。。设置好抓包前过滤前提之后，，，，，拿着电脑，，，，，在AP的四个方向走动，，，，，查看deauth报文的信号强度在哪个方向信号相对较强，，，，，而后往相对较强的方向去查找。。。。。。。

Deauth报文信号强度

忽然，，，，，幼锐灵光一闪：这个反造源会不会只基于某些特定的信路进行反造，，，，，把现场换成5.2G信路试试？？？？？？说做就做，，，，，将现场信路代替成36-64之后，，，，，居然，，，，，反造的景象隐没了，，，，，终端可能正常关联并使用，，，，，由此也能够确认反造源设备并非基于全信路反造。。。。。。。

最终现场掌管人暗示另行找功夫再上门与隔壁网点沟通，，，，，现场能够赞成先使用躲避规划，，，，，同时也表白了对幼锐专业能力的认可。。。。。。。

 敲黑板，，，，，划沉点：