一、简介 

在XXXX银行网络运维服务项目中，遇到了多次客户反映无线网络中断需要多次重新认证才有可能再次连接到网络的故障现象；发生在XXXX等地点的类似故障，多为单个客户、分散小范围出现，未进入深层次分析；此次XXXX园区因大量开发测试人员搬入办公，导致无线接入数量成“井喷”式增长，导致工作日上班高峰期间（约08：50-09:40）大面积集中式出现无线网络频繁掉线需多次重认证才有可能登陆成功，影响到了正常办公；

收集到大量重复相关日志信息如下

“

21 Mon Sep 7 09:06:36 2015 RADIUS server 10.102.64.51:1812 failed to respond to request (ID 128) for client 3c:a9:f4:81:5b:2c / user 'unknown'

22 Mon Sep 7 09:06:35 2015 RADIUS server 10.103.64.51:1812 failed to respond to request (ID 51) for client 28:b2:bd:b7:01:42 / user 'unknown'

*Sep 15 10:03:58.928: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

*Sep 15 10:03:58.478: %DHCP-4-LEASE_NOT_MATCH: dhcpd.c:307 Lease for 10.115.48.21 does not belong to34:02:86:4d:be:85.

*Sep 15 10:03:56.148: %DHCP-4-LEASE_NOT_OBTAINED: dhcpd.c:381 DHCP Lease could not be allocated to the client

*Sep 15 10:03:55.206: %DHCP-4-RELAY_SERVER_NOTGET: dhcp_proxy.c:2216 Unable to get the dhcp relay server's ip address

*Sep 15 10:02:41.728: %DOT1X-3-MAX_EAP_RETRIES: 1x_auth_pae.c:2872 Max EAP identity request retries (13) exceeded for client 28:e3:47:71:fc:bb

*Sep 15 10:02:41.727: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

*Sep 15 10:02:36.729: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

*Sep 15 10:02:31.727: %DOT1X-4-INVALID_MSG_TYPE: authlib.c:85 Invalid message type 9 received from AAA

”

由抓包及Debug输出信息Cisco TAC工程师分析如下：

“

在其他时间，我们看到的都是这样的消息：

5804: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 Adding mobile on LWAPP AP 00:3a:98:eb:4f:c0(0)    <————我们收到了客户端发送的probe信息

5805: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 23) in 5 seconds <————我们开启了5s超时，等待用户发关联请求

5806: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 apfProcessProbeReq (apf_80211.c:4722) Changing state for mobile e8:2a:ea:a0:b9:e1 on AP 00:3a:98:eb:4f:c0 from Idle to Probe

5806: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 apfProcessProbeReq (apf_80211.c:4722) Changing state for mobile e8:2a:ea:a0:b9:e1 on AP 00:3a:98:eb:4f:c0 from Idle to Probe

5808: *Sep 17 09:04:51.742: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5809: *Sep 17 09:04:51.747: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5810: *Sep 17 09:04:51.747: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5811: *Sep 17 09:04:51.747: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

5812: *Sep 17 09:04:56.701: e8:2a:ea:a0:b9:e1 apfMsExpireCallback (apf_ms.c:418) Expiring Mobile!   <———5s过后没收到用户关联请求，这个用户被清除。

5813: *Sep 17 09:04:56.701: e8:2a:ea:a0:b9:e1 0.0.0.0 START (0) Deleted mobile LWAPP rule on AP [00:3a:98:eb:4f:c0]  <———5s过后没收到用户关联请求，这个用户被清除。

5814: *Sep 17 09:04:56.701: e8:2a:ea:a0:b9:e1 Deleting mobile on AP 00:3a:98:eb:4f:c0(0)          

对比你那个成功的，你就能看到：

 

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 Adding mobile on LWAPP AP 00:16:47:4d:7e:60(0)

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 23) in 5 seconds

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 apfProcessProbeReq (apf_80211.c:4722) Changing state for mobile e8:2a:ea:a0:b9:e1 on AP 00:16:47:4d:7e:60 from Idle to Probe

*Sep 17 09:06:50.267: e8:2a:ea:a0:b9:e1 Scheduling deletion of Mobile Station:  (callerId: 24) in 5 seconds

*Sep 17 09:06:51.090: e8:2a:ea:a0:b9:e1 Association received from mobile on AP 00:16:c8:17:b8:e0  <————5s钟内我们收到了用户的关联请求，这个用户就开始关联的各种状态操作直至连接成功。

 

所以，从debug来看，有两种可能：

 

1.      故障时刻客户没法association，这个就是客户端侧的问题了，WLC上无法控制和影响。您可以尝试去升级下客户端网卡驱动，看看是不是客户端侧的一些已知问题。

2.      故障时刻客户端发了association，但是WLC没收到，比如信道太繁忙，空中报文丢失。但是从之前的信息，如果你这个客户端是在那个-08 AP （信道利用率80%），那有可能是这种现象，但是如果是在其他AP，信道利用率都很低，应该不会是这个原因。

 

另外从你的描述，重启客户端就能解决，这个更像是客户端侧当时有些问题。当然还有一个点也需要关注，你的客户端相对较新，WLC和AP都比较老，l两者的兼容性可能不是***，如果可能的话，可以尝试拿一个2504，安装几个双频AP，在小范围先做测试，看看是不是这个问题。

”

 

 

 

WLC收集DEBUG信息命令：

 

Show run-config

Show msglog

Show traplog

Show ap auto-rf 802.11b <AP 名称> ***能包括故障区域当时的所有AP的情况以便我们了解故障时刻的信道拥挤程度。

 

Debug client e8:2a:ea:a0:b9:e1  << e8:2a:ea:a0:b9:e1为故障终端无线MAC；

debug aaa all enable

debug dot1x packet enable

debug disable-all  <<关闭WLC上DEBUG输出；                       

二、故障现象缓解解决方案

***在无法及时升级无线网络硬件设备条件下，提出缓解故障方案；

（以故障终端中存在较多的Wireless-N 7260无线网卡为例，提出缓解解决方案）

1、  请优先在官网下载客户终端无线网卡的最新驱动程序!!!

(版本17.1.1501.01 Drive已显示开始可以解决问题)（请提前告知IT服务台，获得管理员权限！）

下载地址：https://downloadcenter.intel.com/zh-cn

  若依然效果不好，请依次进行以下尝试；

2、请尝试将终端802.11无线协议改为802.11g only；

[请尽量避免无线网络中终端单独使用802.11b协议，作为802.11b的升级协议802.11g为兼容802.11b将整体拉低无线网络的使用速率802.11b----11Mbps（实际值为550～600kB/s）802.11g----54Mbps，所以建议单独使用速率较大的802.11g]

3、请尝试将无线网卡属性中有关“支持U-APSD”选项禁用；

Unscheduled automatic power-save delivery，非调度自动节能发送 ，802.11e-WLAN-Qos属性。与某些型号AP互联期间可能存在兼容性问题，导致下行链路停止，从而减少RX数据吞吐量，建议禁用；

参考链接：

http://www.intel.com/support/cn/wireless/wlan/sb/cs-034875.htm

故障AP包括：

tp-link*TL-WA801N

Netgear*3700

等；

4、请尝试将无线网卡属性中“2.4GHz 802.11n信道宽带”调整为“20MHz”

11N默认使用频宽是20M，和11BG一样。考虑11BG，11个信道，1、6、11三个中心频点。1信道占据-1到3共计4个频段，每个频段5M，合计20M。6信道占据4到8也是4个频段计20M。11信道是一样的，每个频段都是5M。到了11N，开始支持40M频宽。同理推一下，从-1开始要占据8个频段计40M频宽。剩余的频宽只能再支持1个20M频宽的信道了。很显然，正交信道从BG的3个变成了11N的2个。就是说，在环境中，任意使用1和6信道的信号都会干扰40M频宽的通讯。总结起来就是40M频宽吞吐量是20M的一倍，但环境中有干扰就不适宜选40M。总之，20MHZ的抗干扰能力强，如绕过障碍物等，40MHZ确实快点，但并不很稳定。 

以上具体操作内容根据Intel论坛，参考链接如下！

https://communities.intel.com/thread/47940?start=120&tstart=0

“

   802.11n channel width for band 2.4: 20 MHz.

   802.11n channel width for band 5.2: Auto (not in 20 MHz only)

   Fat channel intolerant: Disabled

   Roaming aggressiveness: Medium or less.

   Throughput enhancement: Disabled

   Transmit power: Highest

   Wireless mode: 802.11b/g

 

Also, try the following to disable other 802.11n and 802.11ac features:

 

   802.11n mode: Disabled

   HT mode: Disabled

   uAPSD: Disabled

 

In the wireless router, check the following options:

 

   Auto channel scan: Enable

   802.11 mode: Use 802.11g

Channel width: 20 MHz

                              ”

5、以实际无线环境中WLC为例，尝试设置”Use 802.11g only”可通过在802.11b设置里把802.11b的相关速率 1, 2, 5.5, 11Mbps 都disable，效果就等同禁用了802.11b；

   (通过禁用较低速率强制客户使用高速率登录，虽然牺牲了无线有效覆盖范围，但实际相对优化了无线网络，对整体环境有利；)

6、实施后建议客户若网络再次中断可以尝试点击行内安全软件赛门铁克进行“更新策略”或“重新验证”操作，重新进行身份认证尝试恢复连接，而不用重启设备花费时间；

三、无线诊断过程中相关无线抓包经验分享

由CISCO TAC推荐《802.11 Wireless Sniffing (Packet Capture)》抓包文章；

https://supportforums.cisco.com/document/75331/80211-wireless-sniffing-packet-capture#Introduction

https://supportforums.cisco.com/document/100651/80211-sniffer-capture-analysis(额外参考文章)

文章中分享了“无线抓包基础”“使用Mac(OS X10.6以上版本)进行无线抓包”“在Windows 7中使用Microsoft Network Monitor 3.4进行无线抓包”“使用瘦AP进行无线抓包”“基于Linux Live版本进行无线抓包”“使用OmniPeek Remote Assistant软件诊断”汇总了各种环境下无线抓包方案；

本文章以“在Windows 7中使用Microsoft Network Monitor 3.4软件进行无线抓包”为例进行无线抓包经验分享；所需软件下载地址如下：

 

Microsoft Network Monitor 3.4

[支持802.11a/b/g(部分支持11n)。Win7 64bit,需安装NM34_x64.exe，安装后需重启]

http://www.microsoft.com/en-us/download/details.aspx?id=4865

[Microsoft Message Analyzer (Microsoft Network Monitor升级版本值得推荐)http://www.microsoft.com/en-us/download/details.aspx?id=44226 ]  

Wireshark (Wireshark 1.4.x版本无法读取Netmon2文件格式，建议使用1.5.x以上版本)

https://www.wireshark.org/#download

 

 

牢记注意事项：

①请将无线测试设备靠近目标终端；②确认需要检测的802.11协议、信道和带宽③抓包期间保持“ WiFi Scanning Options”页面打开状态,禁点[Close and Return to Local Mode]

1、 选择所需网卡；

2、 确定扫描协议及信道； 

抓包结束后，可以点击 [Stop] and use File -> Save as to save the .CAP file；保存之后即可使用wirshark等软件分析；

 

追加备注：

1、安装Microsoft Network Monitor 3.4/Microsoft Message Analyzer 后，若无法显示网卡信息，请尝试重启设备；之后如果依然无法显示网卡信息,可能是虚拟网卡设置属性问题，请尝试在注册表(regedit.ext)中修改“MaxNumFilters”属性，设置一个较大数值，例如“14”；

解决Netmon3.4安装后无法显示网卡信息，参考链接：

https://social.technet.microsoft.com/Forums/en-US/c5043fa7-691b-4b55-8630-57e734a98be8/network-monitor-34-wont-install-driver-on-nic-in-win7-x86?forum=netmon

2、针对使用较新的802.11ac无线网卡的测试终端，可能需要确保无线网卡设置中的“有线连接可用时禁用”的值为“启用”，才能保障Netmon3.4/ Message Analyzer的正常使用；PS.默认即为“启用”状态，若同时使用有线和无线网络可设置“禁用”；

                         PPS.“不做死就不会死！”该属性“坑”了我好久、好久、好久（重要的事情要说三遍！！！）...

 

 发现本支持社区中有类似帖子

“http://bbs.csc-china.com.cn/forum.php?mod=viewthread&tid=3872&highlight=%CE%DE%CF%DF%D7%A5%B0%FC”大家也可参考；

 最后吐槽下，如果有上传附件功能直接上传报告得了...害我一个个复制粘贴...

特别提醒：

本文档为自行翻译理解，能力有限不能保证绝对性。

如果您使用的是真实网络，请确保您已经了解所有命令的潜在影响。

转载自小伙伴鱼排饭的博客

本文转自Grodd51CTO博客，原文链接：http://blog.51cto.com/juispan/2066396，如需转载请自行联系原作者