Received state timer timeout in Auth state

如何调整功率和信道？

没有radio这个视图啊

突然出现的，之前使用一直都没有问题

AP如果没有掉线情况的话，只有客户端那么就看下空口利用率： 查看AP的IP <>display wlan ap name XXXX address 之后在AC 命令行： probe视图下 执行命令 syy probe WLAN ap-execute all exec-console enable 之后就可以Telnet上面查询出来的AP地址 进入到AP命令行中后，就可以执行查看空口利用率的命令： [H3C]probe [H3C-probe]display ar5 2 channelbusy （1）RxBusy>>TxBusy，RxBusy+TxBusy总和达到80以上。 例如RxBusy平均80，TxBusy小于5。此种情况属于典型的WLAN内部干扰，即同频AP之间互相可见，竞争一个信道介质，导致空口利用率RX方向异常偏高。解决的办法包括合理的信道规划、功率规划、关闭RRM低速率、关闭广播Probe应答和调大Beacon帧间隔、二层隔离等。 （2）RxBusy和TxBusy相差不多，RxBusy+TxBusy总和达到80以上。 例如RxBusy平均50，TxBusy平均40左右。此种情况下一般体验尚可，如果仍有终端上网慢，最有可能的原因是无线CPE数量过多，或者部分CPE业务量较大，占用了过多带宽。建议开启终端限速或者扩容增加AP解决。 （3）CtlBusy>>RxBusy+TxBusy，CtlBusy达到80以上。 该情况情况是存在非WLAN干扰，但非WLAN干扰存在的证据不明显。从空口利用率上看，当CtlBusy大大超出RxBusy和TxBusy总和时，可以认为是非WLAN干扰存在的一个证据。常见的非WLAN干扰源有如无线摄像头、微波炉、靠的太近的3G/4G基站等。 当怀疑存在非WLAN干扰时，可以用排除法来证明。即先排除周边的WLAN干扰源，比如关闭周边AP，并使用omnipeek抓包发现无法抓取WiFi报文。如果此种情况下仍然存在CtlBusy异常高，可以作为外部干扰存在的证据。 （4）RxBusy<<TxBusy，RxBusy+TxBusy总和达到80以上。 例如TxBusy平均80，RxBusy小于5。此种情况说明AP下行方向发包受阻。在室外CPE应用中较为常见。发生这类故障时，一般伴随着client verbose信息中TX协商速率低，即AP发送给CPE的帧经常丢失，进而降速重传，最后导致AP发送的帧都是低速帧。低速帧会大量消耗空口资源，进而导致CPE体验集体变差。 遇到这种情况，可以先观察该AP下的CPE信号强度，如果RSSI都在30以上，则可以尝试在AP侧通过强制TX高速率解决，11n情况下建议尝试MCS 13。

如果AP都出现掉线需要先查看优先侧情况，其次最好进入到有线交换机命令行看下日志，也有可能是因为地址冲突或者环路那些基本影响传输的问题