关键词：WLAN
摘 要：该文档主要用于指导如何定位WLAN用户ping丢包的问题。
缩略语：
缩略语 | 英文全名 | 中文解释 |
WLAN | Wireless Local Area Network | 无线局域网 |
AC | Access Controller | 无线控制器 |
AP | Access Point | 无线接入点 |
目 录
WLAN使用过程中，有时候会发现Station在ping其他设备时，甚至会出现连续丢包现象。这种情况下可能还伴随ping的延时增大（几百毫秒），可能会导致一些应用感觉不是很好，例如下载速度变慢、视频出现抖动等等。
该种情况应该是WLAN网络中比较困难的一个问题，一方面WLAN本身有一个复杂的不好评估的空间媒质带来了空口的不稳定性，另一方面还要总和考虑整个网络的网络配置和性能。
下面是一个典型的WLAN基本网络构成（FIT方式），当Station ping PC丢包严重时，需要按照报文途经来考虑丢包的可能性。
 |
无线网络中的零丢包，通过目前的协议分析和实际应用来看，可能是一个无法追求到的目标，所以在无线网络问题定位过程中要充分理解网络的“零星丢包”。
本小节简要介绍该特性相关的配置，详细的配置请参见产品操作手册。
编号 | 问题描述 | 初步判断方法 | 解决方法 |
1 | 偶尔出现丢包 | 丢包率小于1%的情况 | 不是问题，正常情况 |
2 | 偶尔出现丢包 | 丢包率大于3%的情况，可以重点关注一下信道占用情况 | 1、调整信道、功率 2、提高重传次数 |
3 | 连续丢包 | Ping操作的时候出现一段时间感觉效果非常差，大量丢包 | 1、可能需要进行抓包分析 |
本小节主要介绍和该特性相关的常用的调试命令：
维护命令 | 命令说明 |
reset counters interface | 清除所有统计信息（AP用户模式） |
display cpu-usage task | 显示各任务的CPU利用率（AP隐藏模式） |
display interface Ethernet | 显示以太网口的统计信息（AP任意模式） |
display ar5drv [1|2] radio | 显示指定Radio的基本信息（AP隐藏模式） |
display ar5drv [1|2] statistics | 显示指定Radio的统计信息（AP隐藏模式） |
display ar5drv [1|2] queue all | |
显示指定Radio的队列信息（AP隐藏模式） | |
display ar5drv [1|2] station all | 显示指定Radio的Station列表（AP隐藏模式） |
display ar5drv [1|2] station <aid> | 显示指定Radio上指定Station的统计信息，aid可以从 display ar5drv [1|2] station all查到（AP隐藏模式） |
分析说明：
1) 每个Radio有4个普通发送队列和1个紧急发送队列，通常数据报文都走1号队列。通常我们主要关注1号队列。
2) TxDiscardFrame表示此队列丢弃的报文总数，包括发送失败和队列溢出的报文。
3) NotEnoughResource表示队列溢出的报文。
4) TxDiscardFrame/ TxUcastFrameCnt表示丢包率，如果超过3%的时候就应当警惕了。
5) RadioResetOnErr意味着Radio芯片复位，会导致丢包。正常情况下不应当出现这个错误。
[H3C-hidecmd]display ar5drv 1 statistics
Radio statistics:
Transmit statistics
TxFrameAllCnt : 3749
TxFrameAllBytes : 380008
Queue Number : 0 1 2 3 EmergencyQ
---------------------------------------------------------------------------------
TxFrameCnt : 2175 332 0 0 6
TxUcastFrameCnt : 2175 0 0 0 6
TxBcastFrameCnt : 0 332 0 0 0
TxFrameBytes : 221850 31834 0 0 252
TxUcastFrameB : 221850 0 0 0 252
TxBcastFrameB : 0 31834 0 0 0
TxRetryCnt : 5708 0 0 0 0
TxMultiRetryCnt : 1473 0 0 0 0
TxFragCnt : 0 0 0 0 0
TxDiscardFrame : 1236 0 0 0 0
BadMbuf : 0 0 0 0 0
BadMbufB : 0 0 0 0 0
NotEnoughResource : 0 0 0 0 0
NotEnoughResourceB: 0 0 0 0 0
BufferFailure : 0 0 0 0 0
BufferFailureB : 0 0 0 0 0
HwRetryExcesive : 1236 0 0 0 0
HwRetryExcesiveB : 126072 0 0 0 0
TxHwRetryExcesive: 1236
TxSwRetryExcesive: 0
TxFilteredCnt : 0
SwRetryCheckFail: 0
RtsSuccessCnt : 0
OutputErrs : 1236
AckFailCnt : 1672
RtsFailCnt : 0
KeyIdxValidErrs: 0
Receive statistics
RxFrameAllCnt : 109904
RxFrameCnt : 16298
RxFrameBytes : 1563460
InDiscards : 0
InputErrs : 93606
FcsErrCnt : 470
TooLongErrs : 0
UnderrunErrs : 0
OverrunErrs : 0
ReachRxTail : 0
DecryptErr : 0
DecryptCRCErrs : 0
KeyCacheMiss : 0
MichaelErrs : 0
Beacon statistics
BeaconIntCnt : 6309
BeaconBusyCnt : 0
BeaconErrCnt : 0
Other statstics
IntCnt : 111817
IntPendingCnt : 0
TxIntCnt : 3749
RxIntCnt : 101751
TxNotFinished : 0
RxNotFinished : 0
RxBusy : 105436
TxBusy : 6906
MibIntCnt : 0
RadioResetOnErr: 0
IsMaskIntr : NO
Physical statistics
UnderRun : 0
Panic : 0
Radar : 0
ErrAbort : 0
TxInterrupt : 0
OfdmTiming : 61477
ofdmOarity : 0
RateIllegal : 0
ofdmLenErr : 0
ofdmPwDrop : 0
ofdmService : 0
ofdmRestart : 0
cckTiming : 31659
cckHeadCRC : 0
cckRateErr : 0
cckService : 0
cckRestart : 0
分析说明：
1) 这个统计可以看出各个队列的使用情况，FrameCount不为0表示有报文积压。偶尔的几个报文积压不会引起什么问题，但长时间积压上百个报文就应当引起警惕。通常我们主要关注AC1（即1号队列）。
2) 目前AC0-AC3队列的默认长度324，当FrameCount持续保持300以上时，通常就会引起队列溢出导致丢包，这个也会在display ar5drv [1|2] statistics中的NotEnoughResource同步体现出来。
[H3C-hidecmd]display ar5drv 1 queue all
Queue(0x81b9bae4) Head(0x81b70880) Tail(0x81b70820) DescCount(128) FrameCount(0)
Transmit Queue AC0:
Queue(0x81b9bb08) Head(0x81b7ab10) Tail(0x81b7ab10) DescCount(0) FrameCount(0)
Transmit Queue AC1:
Queue(0x81b9bb24) Head(0x81b78fb0) Tail(0x81b78fb0) DescCount(0) FrameCount(0)
Transmit Queue AC2:
Queue(0x81b9bb40) Head(0x00000000) Tail(0x00000000) DescCount(0) FrameCount(0)
Transmit Queue AC3:
Queue(0x81b9bb5c) Head(0x00000000) Tail(0x00000000) DescCount(0) FrameCount(0)
Emergency Queue Info:
Queue(0x81b9bbb0) Head(0x81b8b9d0) Tail(0x81b8b9d0) DescCount(0) FrameCount(0)
CAB Queue Info:
Queue(0x81b9bb78) Head(0x81b89ab0) Tail(0x81b89ab0) DescCount(0) FrameCount(0)
Beacon Queue Info:
Queue(0x81b9bb94) Head(0x81b736d0) Tail(0x81b736d0) DescCount(3144312) FrameCount(3144312)
Empty Queue Info:
Queue(0x81b9bac4) Head(0x81b82a30) Tail(0x81b786b0) DescCount(1464) FrameCount(0)
分析说明：
3) 这个统计可以看出指定Radio下连接的所有Station，每个Station分配了一个内部的AID。
[H3C-hidecmd]display ar5drv 1 station all
Station table info:
Station Tbl(0x81b96984) Num(2/64)
Hash info:
H1(1) H2(1)
AID Mac Address KeyIndex
1 00:12:f0:cc:3a:28 31
2 00:09:5b:c8:79:20 63
分析说明：
1) 一是关注Station的信号强度（RSSI），二是关注AP向Station发送报文的速率。
[H3C-hidecmd]display ar5drv 1 station 1
Station assocition ID(1) Hash(1) Mac(00:12:f0:cc:3a:28) Used(YES)
Station 1 statistic:
MPDUs In transmit queue 0, MPDUs need retransmit 0
No.0 Software retry queue, Tx pending 0, Filtered pending 0, Need clear dest NO
No.1 Software retry queue, Tx pending 0, Filtered pending 0, Need clear dest NO
No.2 Software retry queue, Tx pending 0, Filtered pending 0, Need clear dest NO
No.3 Software retry queue, Tx pending 0, Filtered pending 0, Need clear dest NO
No.4 Emergency retry queue, Tx pending 0, Filtered pending 0, Need clear dest NO
Security Info:
No Security
Key Index 31
Software retry queue info
Queue 0x81b96a7c, mpdu 0, descriptor 0, qheader 0x00000000, qtail 0x00000000
Rate information
the median of last three times rssi 37
the elapsed time of last frame sent 932550 ms
current rate 54MBps, recent working max rate 54MBps
station rate capability
1.0 2.0 5.5 6.0 9.0 11.0 12.0 18.0 24.0 36.0 48.0 54.0
support rate number 12
details [support rate, rssi threshold, lost packet percent]
[ 1.0 0 0] [ 2.0 1 0] [ 5.5 2 0] [ 11.0 3 0]
[ 6.0 2 0] [ 9.0 3 0] [ 12.0 4 0] [ 18.0 6 0]
[ 24.0 10 0] [ 36.0 14 0] [ 48.0 19 0] [ 54.0 23 0]
出现此种问题，对于定位问题最直接和有效的信息就是提供出现问题时候的空口抓包，同时现场可以采用“二分法”分段对问题进行判断：
（1） 无线环境是否有问题、无线客户端是否工作正常？
（2） 有线AC到PC之间是否会丢包？
（3） 有线AP到AC之间是否会丢包？
（4） 无线客户端发送问题：Station到AP方面空口是否会丢包？
（5） AP发送问题：Station到AP方面空口是否会丢包？
（6） 无线客户端自身是否有问题？
可以考虑从简单到复杂、逐渐排除的定位方法。首先确定是否为无线客户端自身的问题（参见2.2.3），之后进行分段定位，最后确定是否为空口丢包造成。
特别，如果更换了无线客户端后问题不出现，虽然不能完全说明AP设备不存在问题，但是总体上可以缓解一部分，为后面的继续定位争取时间。
无线丢包定位流程
问题判断和处理：
1. 无线用户的信号强度RSSI偏低（低于20）：需要分析一下该用户状态以及对整个网络的影响，尽量提高无线用户的信号；
2. 无线用户的Rx和Tx速率偏低：通常说明空口环境不是特别好、甚至丢包比较多，需要进行空口的分析（例如信道占用情况、确认网络流量），适当进行流量控制或者无线用户的限速；
3. 无线用户漫游比较频繁（在各个AP上持续的时间都比较短）：可以适当的调整这台客户端连接的AP的发射功率减少用户的漫游，或者将网卡的漫游主动性挑低。（说明，该处理不是特别关键，因为无线网卡自己这种快速的漫游对实际应用影响不是特别大）
在WLAN设备上，对于每一个无线用户都会纪录该无线用户的运行信息，在实际网络分析中可以通过这些信息粗略的评估空间质量，可以用来辅助WLAN网络的优化。
1. RSSI和SNR体现了无线客户端的信号强度：
a) 为了保证无线客户端的正常应用，信号强度应该尽量达到30之上；
b) 当RSSI比较低时，不但该客户端自己表现不好，还可能影响到该空口中其他客户端的使用表现；
2. Rx Rate纪录了无线客户端发送报文的速率：
a) 如果Rx Rate始终保持在较低速率（例如1、2、11），可能该客户端所在的环境丢包比较严重，需要对空间使用情况进行分析（此时应该关注RSSI是否正常，同时考虑进行空口抓包分析）；
b) Rx rate大部分保持在高速率（例如54、48等等），偶尔出现低速率是正常现象；
c) Rx rate发生变化是正常现象：无线设备发送报文是使用的速率是一个动态调整的过程，每发送一个报文，都会根据空口纪录的相关信息（信号强度、重传次数、误码率等等）动态选择一个速率；
d) Rx Rate记录采样时接收到无线客户端的报文速率；
3. Tx Rate纪录了AP发送报文的速率：
a) 如果Tx Rate始终保持在较低速率（例如1、2、11），可能该客户端所在的环境丢包比较严重，需要对空间使用情况进行分析（此时应该关注RSSI是否正常，同时考虑进行空口抓包分析）；
b) Tx rate大部分保持在高速率（例如54、48等等），偶尔出现低速率是正常现象；
c) Tx rate发生变化是正常现象：无线设备发送报文是使用的速率是一个动态调整的过程，每发送一个报文，都会根据空口纪录的相关信息（信号强度、重传次数、误码率等等）动态选择一个速率；
d) Tx Rate记录采样时AP向无线客户端发送的报文速率
4. Up Time纪录了无线客户端当前的在线时间：
a) 如果Up time时间比较短，而该用户已经很长时间应用无线网络，需要考虑该用户是否出现过漫游；
b) 通过display wlan client roam-track mac-address 0019-d20b-6f4d可以查看指定的无线客户端的漫游情况；
c) 如果无线用户经常发生漫游，需要考虑漫游过程中可能会出现零星丢包；
d) 如果在线时间通常比较短，可以参加“无线用户的漫游信息分析”进一步的进行相关分析；
AC设备上可以通过display wlan client mac-address 0019-d20b-6f4d获取到的该无线用户的详细信息：
Client Information
-------------------------------------------------------------------------------
MAC Address : 0019-d20b-6f4d
AID : 7
AP Name : zl_f31_shujing
Radio Id : 1
SSID : DCN
BSSID : 000f-e2ea-2a70
Port : WLAN-DBSS5:35
VLAN : 10
State : Running
Power Save Mode : Active
Wireless Mode : 11g
QoS Mode : WMM
Listen Interval (Beacon Interval) : 10
RSSI : 38
SNR : 38
Rx/Tx Rate : 24/18
Client Type : PRE-RSNA
Authentication Method : Open System
AKM Method : None
4-Way Handshake State : -NA-
Group Key State : -NA-
Encryption Cipher : Clear
Roam Status : Intra-AC roam association
Up Time (hh:mm:ss) : 00:12:34
1. 对于集中WLAN网络，AC上的所有的信息，都是Fit AP主动上报到AC设备的，所以AC上的Client的信息更新不会特别及时；
2. Fit AP默认每50秒钟上报一次信息，所以大部分的信息每50秒会更新一次。
在AC设备上，可以通过display wlan client roam-track mac-address获取到的该无线用户的漫游信息：
<WX5002>dis wlan client roam-t mac 000c-f11a-13df
Roam Track Table
-------------------------------------------------------------------------------
BSSID Online-time(d:h:m:s) AC-IP-address
-------------------------------------------------------------------------------
000f-e2ed-d5b0 0000:01:30:26 -HOME AC-
000f-e2ea-2b40 0000:00:01:11 -HOME AC-
000f-e2ed-d5b0 0000:00:25:02 -HOME AC-
000f-e2ed-d4b2 0000:00:36:45 -HOME AC-
000f-e2ed-d5b0 0000:00:01:15 -HOME AC-
000f-e2ea-2b40 0000:00:10:50 -HOME AC-
000f-e2ed-d4b2 0000:00:00:37 -HOME AC-
000f-e2ed-d5b0 0000:00:00:20 -HOME AC-
000f-e2ea-2b40 0000:00:01:27 -HOME AC-
000f-e2ed-d5b0 0000:00:55:38 -HOME AC-
1. 每一个无线用户最多纪录10条信息，新的纪录会自动覆盖最老的纪录；
2. 最上面的纪录为最新的纪录，其中第一列中的MAC地址为该无线用户所连接的BSSID；
3. 当无线用户彻底下线，也就是AC设备上不再有无线用户任何信息的时候，所有的漫游信息自动清除；
4. 无线用户有可能会和已经连接的AP进行重连接，所以两条连续的纪录的BSSID有可能相同
登陆到AP设备上，进入隐藏命令收集display ar5drv [1|2] statistics信息进行分析，主要判断丢包率，如果丢包率低于1%说明空口质量还可以。具体参见2.1.2 display ar5drv [1|2] statistics描述。
实际使用中，这是最常见的情况了，也是最难定位的情况。涉及其他AP干扰问题、AP自身问题、非WLAN信号干扰问题等等。一个信道的转发能力是固定的，当多台AP使用相同信道并且互相可见的情况下，他们总的空口能力也最多22M左右。因此，当空口的转发能力已经饱和时，必然有的AP就会出现丢包。22M的处理能力也是在都是以高速率，发送1500字节大包的基础上得出的。当发送速率降低，或者都是小包文充斥在空口时，虽然没有22M，但空口的占用率实际上也饱和了，必然有的AP就会出现丢包。
另外，不合理的网络规划会带来隐藏节点问题，AP、Station之间的无谓冲突会降低空口的性能，增加错报几率，从而导致丢包。
可以使用Netstumbler和Airmagenet对空口周围的环境进行相应的分析：特别Airmagnet对空口进行扫描，可以看到信道的占用率和吞吐量，查看信道中AP和Station的数量，查看空口报文的速率组成以及占用比例。例如：
如果进入AP的报文持续大于空口的发送能力，必然会导致发送队列溢出从而丢包。或者AP Radio芯片出现问题，导致报文发送不出去；或者对空口忙闲的判断出现错误，导致不发送报文。
常见的有蓝牙、无绳电话、微波炉等。这个是比较难排查的。
首先，判断AP和AC之间的有线链路是否可能存在问题，可以从以下几方面排查：
1) 用AC ping AP上行网络中的其他设备，看是否丢包严重；
2) 排查是否AP上行链路中报文流量饱和（包括中间设备），从而淹没ping报文；
3) AC下行有线口上是否存在明显的错误统计；
4) AP上行有线口上是否存在明显的错误统计；
其次，可以从以下几方面排查，如果还不能定位丢包原因，寻求其他帮助。
1) 用AC ping上行网络中的其他设备，看是否丢包严重；
2) 排查是否AC上行链路中报文流量饱和（包括中间设备），从而淹没ping报文；
3) AC上行有线口上是否存在明显的错误统计；
在AP上连交换机进行Mirror抓包，直接将AP连接的接口进行镜像，获取所有到达AP以及从AP发送出来的报文。（为了对比分析，在有条件情况下，可以在无线客户端上同时使用Ethereal抓无线网卡相关报文）
1) 为了便于抓包分析，可以在无线客户端ping固定大小的报文，例如130bytes；
2) 提供抓包信息的时候，收集抓包信息后一定要提供无线客户端的MAC地地址和IP地址。
报文分析说明：
1) 报文分析时可以根据报文大小，确定是否每一个ping request报文都很快有ping reply回应消息；（这些信息都是在LWAPP封装里面）；
2) 如果两边抓包，可以通过ping报文的序列号进行匹配分析，确定两个抓包的相对时间进行对比分析，确定延时情况和报文丢失情况；
PS：在无线笔记本上使用Ethereal进行抓包，使用该工具选用无线网卡后，需要将下面的选项去掉，才可以抓包
首先，观察出现丢包是否有固定周期，有没有时间点上的规律，每次丢包的持续时间是否固定。这个主要关注是不是一些特殊的原因造成丢包，通常是些外界的原因。
其次，在出现丢包的时候，可以执行下面的命令收集信息
1) reset counters interface，清除所有统计信息；
2) 隐藏模式下，执行display ar5drv 2 statistics，连续执行多次；
3) 隐藏模式下，执行display ar5drv 2 queue all，连续执行多次；
4) 隐藏模式下，执行display ar5drv 2 station all，观察AP当前的Station数量，并且找到出现问题的Station对应AID。再执行display ar5drv 2 station [AID]，连续执行多次；
5) 如果有其他Station，同样执行display ar5drv 2 station [其他stationAID]，连续执行多次，把每个Station都查看一下。
6) 执行display interface Ethernet，连续执行多次，大概的估计出有线口报文的流入速率，即每秒钟有多少报文进入AP（说明，AP以太口的流量每5分钟更新一次）；
另外，可以在出现丢包的时候使用Airmagnet，观察空口的占用率以及流量，进行截图。关注空口报文的速率组成及占用率。
在解决问题的时候往往“单兵作战”，很难进行全面的同时抓包分析，但是走到了这一步“已经初步认为空口存在丢包的情况”，也必须想法进行空口抓包，下面为抓包相关的注意事项：
1) Omnipeek抓包功能要比Airmagnet好；
2) 抓包工具不一定能够将所有的空口报文都抓上来，也就是在分析过程中要充分考虑到可能偶尔有报文接收不上来的情况；
3) 无论使用哪一种抓包，一定要选择当前Station所在的信道进行抓包；
4) ping有两个方向，一个为ping request从Station到AP，另外一个为ping reply从AP到Station；
5) 为了报文方便分析，可以ping指定大小的报文，例如200bytes；特别对于加密的接入一定要采用ping特殊长度的报文；
抓包分析：（Omnipeek的抓包）
说明：802.11为了尽量保证单播数据的可靠传输，每一个单播报文都回等待ACK确认。例如无线客户端发送一个报文（227），AP接收到之后会回应一个ACK报文（228）。
相关分析：
1) 如果收不到ACK确认（Station没有发送ACK，或者AP没有收到Station发送的ACK），则会进行报文重传；
2) 从AP到Station以及从Station到AP都遵循这个规律；
3) AP设备默认重传次数为5次，Station重传次数不定；
4) 如果抓包中连续出现多个相同的重传报文，而没有ACK报文，说明该报文可能丢失；
5) 根据报文MAC地址，可以确定是AP到Station丢失还是Station到AP丢失；
下面的判断可以使用，在一定程度上可以验证是否与网卡关系密切，当前应用过程中还是发现了好多网卡也存在这样或者那样的问题，特别是11n网卡：
1) 通常我们习惯上用Station去ping网关，而很多时候网关不在AC上，也就是相当于AC连接的一台PC。更换Station，再ping相同的PC，看是否还丢包严重。
2) 如果不是，则说明原来Station自身很可能存在问题，禁用或者插拔网卡后再重新使用，看能否恢复正常。如果仍然丢包严重，寻求其他帮助。
3) 更换PC，再用相同的Station ping，看是否还丢包严重。
4) 如果不是，则说明原来PC自身很可能存在问题，寻求其他帮助。 实际网络中，通常更换的PC可以用AC或者中间的交换机替代。
如果上面的抓包还是不能确认问题，可能还是要考虑在多个点同时进行抓包，然后对比分析，下面为操作相关的说明：
1) 空口报文要抓取；
2) 可以在AP的上行接口抓包；
3) 可以在无线客户端上使用Ethereal抓无线网卡收发报文；
4) 有可能条件登陆AP打开debugging ar5 1/2 phy error output verbose命令
相关分析：
1) 空口报文分析参见2.2.6中的描述；
2) 本部分主要可以通过icmp报文中的序列号在多个抓包信息和调试信息中进行对比分析，看看报文到底丢失在什么位置；
3) 对于空口加密报文，由于内部数据无法获知，只能通过猜测匹配
下图为ping的序列号的位置：
新浪微博
腾讯微博
豆瓣空间
搜狐微博
QQ空间
腾讯朋友
网易微博
百度搜藏
开心网
告诉聊友