STA Packet Loss (Wireless Side)
Context
When a STA accesses services after associating with an AP, the traffic needs to pass through the air interface and intermediate network devices, including the AP (wireless side: Wi-Fi module; wired side: forwarding module) and switch or AC (wired side). Packet loss may occur on the wired or wireless side. In this case, you can enable the station-trace function on the AP or AC to locate the cause.
For details about how to locate packet loss on the wired side, see "A STA Fails to Ping the Gateway (Packets Are Lost on the Wired Side)". This troubleshooting guide describes how to analyze and locate common causes of packet loss on the wireless side.
Symptom
Packet loss occurs on a STA on the wireless network.
Possible Causes
- The STA's signal strength is low.
- Severe interference exists on the air interface.
- A large number of STAs with low RSSIs access the same radio.
- There are too many access STAs on the same radio, and the concurrency rate is high.
- STAs on the same radio are performing operations that generate heavy traffic, such as downloading.
- A large number of multicast or broadcast packets are sent to the AP and flooded to the air interface, causing high AP channel utilization.
- The AP's CPU usage is high and reaches the AP's peak performance.
- The STA is in power-saving mode for a long time.
- The STA is faulty.
Troubleshooting Procedure
- In the diagnostic view of the AC, enable the station-trace function and perform ping tests to check whether ping packets are properly sent and received on the wireless side.
- Enable the station-trace function.
[AC-diagnose] station-trace sta-mac 482c-a042-8227
- Perform ping tests.
Ping a STA from the AC. If the AC does not serve as the user gateway, ping the user gateway from the STA.
In normal cases, ping the STA from the device, that is, ping from the wired side to the wireless side (downstream). Complete ping packets are displayed as follows:
In V200R019C00 and earlier versions:
<7>Oct 18 2018 14:41:21.320.1 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[7] [ICMP] Ping request from [31.1.1.1] to [31.1.1.49] id[43991] seq[1548] payload[56] Recved from software switch <7>Oct 18 2018 14:41:21.320.2 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[7] [ICMP] Ping request from [31.1.1.1] to [31.1.1.49] id[43991] seq[1548] payload[56] elapsed[0 ms] Sending pkt to target(Single) <7>Oct 18 2018 14:41:21.320.3 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[7] [ICMP] Ping request from [31.1.1.1] to [31.1.1.49] id[43991] seq[1548] payload[56] elapsed[10 ms] Success to send pkt to air <7>Oct 18 2018 14:41:21.340.1 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[8] [ICMP] Ping reply from [31.1.1.49] to [31.1.1.1] id[43991] seq[1548] payload[56] Recved from target <7>Oct 18 2018 14:41:21.340.2 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[8] [ICMP] Ping reply from [31.1.1.49] t [31.1.1.1] id[43991] seq[1548] payload[56] elapsed[0 ms] Entering rx reorder <7>Oct 18 2018 14:41:21.340.3 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[8] [ICMP] Ping reply from [31.1.1.49] to [31.1.1.1] id[43991] seq[1548] payload[56] elapsed[0 ms] Exiting rx reorder for release <7>Oct 18 2018 14:41:21.340.4 c88d-833a-8d40 WIFI/7/BTRACE:[BTRACE][WLAN_WIFI][482C-A042-8227]:SeqNo[8] [ICMP] Ping reply from [31.1.1.49] to [31.1.1.1] id[43991] seq[1548] payload[56] elapsed[0 ms] Success to send pkt to software switch
The first three lines indicate a downstream ping request packet sent from the device to the STA. The last four lines indicate an upstream ping response packet received by the device from the STA. Key fields are described as follows:
- Seq[xxx]: indicates the sequence number carried in a ping packet. This field can map the trace action and a specific ping packet.
- Recved from software switch: indicates that the Wi-Fi driver receives a ping request packet sent from the forwarding module destined for the STA.
- Success to send pkt to air: indicates that the Wi-Fi driver successfully forwards the ping request packet to the STA through the air interface.
- Recved from target: indicates that the Wi-Fi driver receives a ping response packet from the STA through the air interface.
- Success to send pkt to software switch: indicates that the Wi-Fi driver successfully forwards the ping response packet to the forwarding module for processing and to the wired network device through the AP's network port.
If the ping packet is sent from the STA to the gateway, that is, from the wireless side to the wired side (upstream), the station-trace command output is similar to the preceding ping packet. The difference is that the Wi-Fi driver receives the ping response packet destined for the STA from the forwarding module, and receives the ping request packet from the STA through the air interface.
In V200R019C10:
<7>Aug 11 2020 15:02:30.0.1 0032-4516-4100 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f72d-6365):SeqNo[10] [ICMP] Ping request from [192.168.110.2] to [192.168.110.214] id[44094] seq[1] payload[56] Receive from fwd <7>Aug 11 2020 15:02:30.40.1 0032-4516-4100 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f72d-6365):SeqNo[10] [ICMP] Ping request from [192.168.110.2] to [192.168.110.214] id[44094] seq[1] payload[56] elapsed[23 ms] send to rt ok format :1 seqType:6 eof:0 total_mpdu_num:0 <7>Aug 11 2020 15:02:30.40.2 0032-4516-4100 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f72d-6365):SeqNo[10] [ICMP] Ping request from [192.168.110.2] to [192.168.110.214] id[44094] seq[1] payload[56] elapsed[23 ms] send to air ok <7>Aug 11 2020 15:02:30.40.3 0032-4516-4100 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f72d-6365):SeqNo[9] [ICMP] Ping reply from [192.168.110.214] to [192.168.110.2] id[44094] seq[1] payload[56] send to np ok
- SeqNo[xxx]: indicates the sequence number carried in a ping packet. This field can map the trace action and a specific ping packet.
- Receive from fwd: indicates that the Wi-Fi module receives a ping request packet sent from the forwarding module destined for the STA.
- send to rt ok: indicates that the Wi-Fi PMAC module successfully sends a ping request packet to the SMAC module.
- send to air ok: indicates that the Wi-Fi module successfully forwards the ping request packet to the STA through the air interface.
- send to np ok: indicates that the Wi-Fi module successfully forwards the ping response packet to the forwarding module for processing and to the wired network device through the AP's network port.
- send to air fail, reason code: 0: indicates that receiving a response frame times out and further analysis is required.
In V200R020C00 and later versions (AirEngine X760 series APs):<7>Aug 02 2021 16:26:31.355.1 8c68-3a11-ebc0 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[7] [ICMP] Ping request from [192.190.190.2] to [192.190.190.139] id[11436] seq[BE:1 LE:256] payload[56] Receive from fwd <7>Aug 02 2021 16:26:31.435.1 8c68-3a11-ebc0 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[7] [ICMP] Ping request from [192.190.190.2] to [192.190.190.139] id[11436] seq[BE:1 LE:256] payload[56] elapsed[4294964076 ms] send to rt ok format :4 seqType:2 eof:0 total_mpdu_num:0 <7>Aug 02 2021 16:26:31.435.2 8c68-3a11-ebc0 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[7] [ICMP] Ping request from [192.190.190.2] to [192.190.190.139] id[11436] seq[BE:1 LE:256] payload[56] elapsed[4294964077 ms] send to air ok, rate:229400 Kbps, ack_rssi:-30 <7>Aug 02 2021 16:26:31.435.3 8c68-3a11-ebc0 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[8] [ICMP] Ping reply from [192.190.190.139] to [192.190.190.2] id[11436] seq[BE:1 LE:256] payload[56] sec rx pkt ok. radio:0, userId:0, len:122, msduNum:1, msduLen:98, fc:0x0188, seq:413, addr1-8c:68:3a:11:eb:c8 addr2-94:e6:f7:41:9f:83 <7>Aug 02 2021 16:26:31.435.4 8c68-3a11-ebc0 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[9] [ICMP] Ping reply from [192.190.190.139] to [192.190.190.2] id[11436] seq[BE:1 LE:256] payload[56] send to np ok
- SeqNo[xxx]: indicates the sequence number carried in a ping packet. This field can map the trace action and a specific ping packet.
- seq[BE: x LE:y]: indicates the sequence number of a trace packet. The request and response sequence numbers of the same ping packet are the same. BE and LE indicate the big-endian and little-endian numbers of the sequence number, respectively.
- Receive from fwd: indicates that the Wi-Fi module receives a ping request packet sent from the forwarding module destined for the STA.
- send to rt ok: indicates that the Wi-Fi PMAC module successfully sends a ping request packet to the SMAC module.
- send to air ok: indicates that the Wi-Fi module successfully forwards the ping request packet to the STA through the air interface.
- sec rx pkt ok: indicates that the Wi-Fi module successfully receives ping response packets.
- send to np ok: indicates that the Wi-Fi module successfully forwards the ping response packet to the forwarding module for processing and to the wired network device through the AP's network port.
- send to air fail: indicates that the Wi-Fi module fails to send a ping request packet. If the reason code is displayed, the packet has been sent to the air interface but the corresponding ACK packet is not received. If other reason is displayed, the packet is discarded and not sent to the air interface.
In V200R020C00 and later versions (AirEngine X761 series APs):<7>Aug 02 2021 15:36:12.650.1 38eb-4821-3300 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[35] elapsed[0 ms][ICMP] Ping request from [192.190.190.2] to [192.190.190.139] id[11180] seq[BE:1 LE:256] payload[56] recv from cap vapid:1 <7>Aug 02 2021 15:36:12.650.2 38eb-4821-3300 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[35] elapsed[0 ms][ICMP] Ping request from [192.190.190.2] to [192.190.190.139] id[11180] seq[BE:1 LE:256] payload[56] send to fw len:98 <7>Aug 02 2021 15:36:12.910.1 38eb-4821-3300 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[35] elapsed[257 ms][ICMP] Ping request from [192.190.190.2] to [192.190.190.139] id[11180] seq[BE:1 LE:256] payload[56] send to air success status :0 ack_rssi:63 bw:0 mcs:9 trans_cnt:1 tid:0 rate:114 Mbps <7>Aug 02 2021 15:36:12.910.2 38eb-4821-3300 WSRV/7/BTRACE:(BTRACE)(WLAN_AP)(94e6-f741-9f83):SeqNo[36] elapsed[0 ms][ICMP] Ping reply from [192.190.190.139] to [192.190.190.2] id[11180] seq[BE:1 LE:256] payload[56] send pkt to cap vapid:18
- SeqNo[xxx]: indicates the sequence number carried in a ping packet. This field can map the trace action and a specific ping packet.
- seq[BE: x LE:y]: indicates the sequence number of a trace packet. The request and response sequence numbers of the same ping packet are the same. BE and LE indicate the big-endian and little-endian numbers of the sequence number, respectively.
- recv from cap: indicates that the Wi-Fi module receives a ping request packet sent from the forwarding module destined for the STA.
- send to fw: indicates that the Wi-Fi LMAC module successfully sends a ping request packet to the firmware module.
- send to air: indicates whether the Wi-Fi module successfully sends a ping request packet to the STA through the air interface. success status 0 indicates a success; fail status x indicates a failure. x indicates the specific reason code. The description is as follows:
- /* 0: The packet is sent successfully. */
- /* 2: The packet is discarded on the firmware, due to the Remove_mpdus command. */
- /* 3: The packet is discarded on the firmware, due to the Remove_transmitted_mpdus command. */
- /* 4: The packet is discarded on the firmware, due to the Remove_untransmitted_mpdus command. */
- /* 5: The packet is discarded on the firmware, due to the fw_reason1 command. */
- /* 6: The packet is discarded on the firmware, due to the fw_reason2 command. */
- /* 7: The packet is discarded on the firmware, due to the fw_reason3 command. */
- /* 8: The packet is discarded on the firmware, due to the queue_disable command. */
- send pkt to cap: indicates that the Wi-Fi module successfully forwards the ping response packet to the forwarding module for processing and to the wired network device through the AP's network port.
- Determine whether the fault occurs on the wired or wireless side based on the station-trace command output.
For a downstream ping packet (from the wired network device to the STA), locate the fault as follows:
In V200R019C00 and earlier versions:
- If Recved from software switch is not displayed, the ping request packet is not successfully sent from the forwarding module to the Wi-Fi driver. In this case, there is a high probability that the fault occurs on the wired side.
- If Recved from software switch is displayed but Success to send pkt to air is not displayed, the Wi-Fi driver fails to send the packet to the STA. In this case, the fault occurs on the wireless side.
- If Success to send pkt to software switch is displayed, the STA has sent the ping response packet, which is forwarded to the forwarding module. In this case, there is a high probability that the fault occurs on the wired side.
- If the ping request packet is successfully sent to the STA but Success to send pkt to software switch is not displayed, the fault occurs on the wireless side.
In V200R019C10:
- If Receive from fwd is not displayed, the ping request packet is not successfully sent from the forwarding module to the Wi-Fi module. In this case, there is a high probability that the fault occurs on the wired side.
- If Receive from fwd is displayed but send to air ok is not displayed, the Wi-Fi module fails to send the packet to the STA. In this case, the fault occurs on the wireless side.
- If send to np ok is displayed, the STA has sent the ping response packet, which is forwarded to the forwarding module. In this case, there is a high probability that the fault occurs on the wired side.
- If the ping request packet is successfully sent to the STA but send to np ok is not displayed, the fault occurs on the wireless side.
In V200R020C00 and later versions (AirEngine X760 series APs):
- If Receive from fwd is not displayed, the ping request packet is not successfully sent from the forwarding module to the Wi-Fi module. In this case, there is a high probability that the fault occurs on the wired side.
- If send to rt ok is not displayed, the ping request packet is not sent to the SMAC module. The fault occurs on the wireless PMAC module.
- If send to air fail is displayed, there is a high probability that the fault occurs on the wireless side.
- If send to np ok is displayed, the STA has sent the ping response packet, which is forwarded to the forwarding module. In this case, there is a high probability that the fault occurs on the wired side.
- If the ping request packet is successfully sent to the STA but send to np ok is not displayed, the fault occurs on the wireless side.
In V200R020C00 and later versions (AirEngine X761 series APs):
- If recv from cap is not displayed, the ping request packet is not successfully sent from the forwarding module to the Wi-Fi module. In this case, there is a high probability that the fault occurs on the wired side.
- If send to fw is not displayed, the ping request packet is not sent to the firmware. The fault occurs on the wireless side.
- If send to air success status 0 is displayed but send pkt to cap is not displayed, the STA has received the ping response packet, but the AP does not receive the ping response packet. In this case, there is a high probability that the fault occurs on the wireless side.
- If send to air fail status x is displayed, the Wi-Fi module fails to send the packet to the STA. The fault occurs on the wireless side.
- If send pkt to cap is displayed, the STA has sent the ping response packet, which is forwarded by the Wi-Fi module to the forwarding module. In this case, there is a high probability that the fault occurs on the wired side.
For upstream ping packets (ping packets from the wireless side to the wired network device), the fault location method is the same as that for downstream ping packets.
Use the preceding methods to preliminarily determine whether the fault occurs on the wired or wireless side. If the fault occurs on the wired side, go to A STA Fails to Ping the Gateway (Packets Are Lost on the Wired Side).
If the fault occurs on the wireless side, perform the following operations.
- Enable the station-trace function.
- Check STA association information on the AC, and check whether the STA's signal strength received by the AP and the link setup rate are proper.
[AC-wlan-view] display station sta-mac 8844-7748-3c81 ------------------------------------------------------------------------------ Station MAC-address : 8844-7748-3c81 Station IP-address : 192.168.150.162 Station gateway : 192.168.150.1 Associated SSID : WLAN-TEST Station online time(ddd:hh:mm:ss) : 000:00:00:57 The upstream SNR(dB) : 44.0 //Signal strength The upstream aggregate receive power(dBm) : -51.0 Station connect rate(Mbps) : 58 //Connection rate ......
If the STA's signal strength or connection rate is low, packets may be lost. In normal office scenarios, STAs' signal strength and connection rate should not be lower than –70 dBm and 13 Mbit/s, respectively. If the displayed values are lower than these values, perform the following steps for rectification and optimization:
- Check whether AP deployment is proper and coverage holes exist. If coverage holes exist, deploy more APs for coverage hole compensation.
- If no coverage hole exists, check whether the STA is connected to a remote AP. If so, perform the following steps:
- If the transmit power of the remote AP is high, adjust the transmit power in the AP view.
[AC-wlan-view] ap-id 19 [AC-wlan-ap-19] radio 1 [AC-wlan-radio-19/1] eirp 20 [AC-wlan-radio-19/1] display this # vap-profile test2 wlan 1 vap-profile test4 wlan 2 channel 20mhz 153 eirp 20 # return
Reduce the transmit power based on actual test results while ensuring that the coverage requirements can be met. You are advised to adjust the transmit power of surrounding APs at the same time.
- Configure the function of disconnecting low-RSSI STAs.
<AC> system-view [AC] wlan [AC-wlan-view] rrm-profile name default [AC-wlan-rrm-prof-default] smart-roam enable //In V200R008C10 and later versions, smart roaming and the function of quickly disconnecting STAs are enabled by default. [AC-wlan-rrm-prof-default] smart-roam quick-kickoff-threshold snr 20
Configure the SNR-based threshold based on actual network coverage conditions. For example, configure a high threshold in areas where APs are densely deployed. Otherwise, configure a low threshold.
In V200R007 and later versions, the SNR-based threshold is calculated based on the fixed noise floor value –95 dBm. In versions earlier than V200R007, the SNR-based threshold is calculated based on dynamic noise floor values, which is generally about –105 dBm. Therefore, configure different SNR-based thresholds in different versions. That is, configure a lower SNR-based threshold in V200R007 or later than that in versions earlier than V200R007. Otherwise, STAs with SNRs lower than the threshold will be mistakenly forced to go offline.
If the STA's signal strength and connection rate are normal, go to the next step.
- If the transmit power of the remote AP is high, adjust the transmit power in the AP view.
- Check whether the STA is faulty.
- On the AC or gateway, ping other STAs that associate with the same radio of the AP as the faulty STA. Check whether packet loss occurs. If not, the problem may be caused by the STA itself. Then, check whether the STA is in power-saving mode.
<AC> display station sta-mac 482c-a042-8227 ------------------------------------------------------------------------------ Station MAC-address : 482c-a042-8227 Station IP-address : FE80::D287:F82B:9D2C:827C : 10.10.10.49 Station gateway : 10.10.10.1 Associated SSID : test Station online time(ddd:hh:mm:ss) : 000:00:03:36 ...... Station current state ...... Power save mode enabled : YES ......When the STA enters the power-saving mode, its packet transmission delay increases. The actual packet transmission delay is related to the interval at which beacon frames are sent. A smaller interval at which beacon frames are sent indicates a shorter packet forwarding delay.
- Ping the STA from the device to check the delay and packet loss.
Most mobile terminals, such as smartphones and laptops, stay in power-saving mode when no service is running. Therefore, the large delay and occasional packet loss of ping packets are normal. In this case, verify the actual delay and packet loss by means of fast ICMP reply.
[AC] ping -c 1000 -m 10 10.1.1.49 PING 10.1.1.49: 56 data bytes, press CTRL_C to break Reply from 10.1.1.49: bytes=56 Sequence=1 ttl=64 time=326 ms Reply from 10.1.1.49: bytes=56 Sequence=2 ttl=64 time=1 ms Reply from 10.1.1.49: bytes=56 Sequence=3 ttl=64 time=1 ms Reply from 10.1.1.49: bytes=56 Sequence=4 ttl=64 time=1 ms Reply from 10.1.1.49: bytes=56 Sequence=5 ttl=64 time=2 ms Reply from 10.1.1.49: bytes=56 Sequence=6 ttl=64 time=4 ms Reply from 10.1.1.49: bytes=56 Sequence=7 ttl=64 time=5 ms Reply from 10.1.1.49: bytes=56 Sequence=8 ttl=64 time=2 ms Reply from 10.1.1.49: bytes=56 Sequence=9 ttl=64 time=1 ms Reply from 10.1.1.49: bytes=56 Sequence=10 ttl=64 time=1 ms Reply from 10.1.1.49: bytes=56 Sequence=11 ttl=64 time=5 ms Reply from 10.1.1.49: bytes=56 Sequence=12 ttl=64 time=5 ms Reply from 10.1.1.49: bytes=56 Sequence=13 ttl=64 time=3 ms Reply from 10.1.1.49: bytes=56 Sequence=14 ttl=64 time=4 ms Reply from 10.1.1.49: bytes=56 Sequence=15 ttl=64 time=5 ms Reply from 10.1.1.49: bytes=56 Sequence=16 ttl=64 time=5 ms Reply from 10.1.1.49: bytes=56 Sequence=17 ttl=64 time=3 msIf the fast ICMP reply function works properly, the high delay and packet loss occur because the STA is in power-saving mode, which does not affect actual services. When the STA runs services, it automatically exits from the power-saving mode. Some handheld PDAs, such as voice phones, barcode scanners, and healthcare terminals, may stay in power-saving mode even when running services to prolong the standby time. In this case, these STAs exchange packets with the AP in PS-poll or U-ASPD mode. You need to check the beacon interval.
- Check the beacon interval and adjust it as required.
The default interval at which beacon frames are sent is 100 ms. Therefore, when a STA in power-saving mode sends ping packets, the average delay is typically about 100 ms. If the average delay is far larger than 100 ms (for example, larger than 500 ms) or packet loss occurs, check whether the interval at which beacon frames are sent is large in the radio profile.
<AC> system-view [AC] wlan [AC-wlan-view] radio-5g-profile name abc [AC-wlan-radio-5g-prof-abc] display this # beacon-interval 500 # return
If the interval at which beacon frames are sent is changed to a large value, decrease it properly. If it is not changed or the delay is still long or packets are frequently lost after the default value is restored, the STA may have compatibility issues. In this case, contact technical support personnel in a timely manner.
- It is recommended that the network adapter driver of the STA be upgraded to the latest version.
If the fault is irrelevant to the power-saving mode of the STA or packet loss occurs on all STAs associated with the same radio of the AP, go to the next step.
- On the AC or gateway, ping other STAs that associate with the same radio of the AP as the faulty STA. Check whether packet loss occurs. If not, the problem may be caused by the STA itself. Then, check whether the STA is in power-saving mode.
- Check whether the channel utilization is high.
- On the AC, check the channel utilization and noise floor value of the AP radio that the STA associates with.
<AC> display ap traffic statistics wireless ap-id 19 radio 1 ...... Wireless noise(dBm) :-104 //Noise floor Wireless port up rate(Kbps) :0 //Uplink traffic on the radio port Wireless port down rate(Kbps) :0 //Downlink traffic on the radio port ...... Wireless channel utilization(%) :84 //Channel utilization ......
If the channel utilization or noise floor value is too high, packet loss is more likely to occur.
- Check the reason for the high channel utilization.
High channel utilization is generally caused by the AP's faults or external interference. You can use either of the following methods to check the reasons:
- Method 1: Log in to the AP and run the following commands in the diagnostic view:
In V200R019C10 and later versions:
[AP-diagnose] display lmac base-info radio 1 ...... ChannelUtilizationRate(%) : 3 //Channel utilization CoChanInterferenceRate(%) : 3 //Co-channel interference rate
In V200R006C20 to V200R019C00:
<AP> system-view [AP] diagnose [AP-diagnose] display wifi base-info radio 0 ...... ChanUtilizationRate(%) = 80 //Channel utilization CoChanInterferenceRate(%) = 10 //Interference rate ......
In V200R005 and V200R006C10:
<AP> system-view [AP] diagnose [AP-diagnose] display interface radio 0 ...... ChanUtilizationRate(%) = 80 //Channel utilization CoChanInterferenceRate(%) = 10 //Interference rate ......
If the channel utilization is high but the interference rate is not, the high channel utilization is caused by the AP's faults. If both the channel utilization and interference rate are high, the high channel utilization is caused by external interference.
- Method 2: Log in to the web platform.
Choose Monitoring > Radio. On the Radio page that is displayed, check the channel utilization and interference rate of the AP.
If the high channel utilization is caused by co-channel interference or non-Wi-Fi device interference, solve the problem by referring to Signal Interference Occurs. If the high channel utilization is caused by the AP's faults, perform the following steps:
- Method 1: Log in to the AP and run the following commands in the diagnostic view:
- Check information about the upstream and downstream traffic of the AP radio.
<AC> display ap traffic statistics wireless ap-id 19 radio 1 ...... Wireless port up rate(Kbps) :311112 Wireless port down rate(Kbps) :402245 ......
- If the volume of upstream and downstream traffic is large, upload or download operations are being performed on STAs on the AP, occupying a large number of air interface channel resources. As a result, other STAs cannot preempt channels, causing long delay or packet loss. In this case, you are advised to perform the following configurations to limit traffic rates according to actual service requirements:
<AC> system-view [AC] wlan [AC-wlan-view] traffic-profile name default [AC-wlan-traffic-prof-default] rate-limit client up 5120 [AC-wlan-traffic-prof-default] rate-limit client down 8192
- If the volume of upstream and downstream traffic is not large, log in to the AP remotely from the AC and run the following commands in the diagnostic view to check whether a large number of multicast or broadcast packets are sent to the AP's air interface:
In V200R019C10 and later versions:
[AP-diagnose] display lmac radio-tx-statistics radio 1 Tx stats: ...... Multicast packets : 54 Broadcast packets : 27
In V200R006C20 to V200R019C00:
<AP> system-view [AP] diagnose [AP-diagnose] display wifi radio-statistics radio 1 ...... Broadcast Pkt Num : 323212 Multicast Pkt Num : 234223 ......
In V200R005 and V200R006C10:
<AP> system-view [AP] diagnose [AP-diagnose] display radio-statistics radio 1 ...... Broadcast Pkt Num : 323212 Multicast Pkt Num : 234223 ......
Run this command for several times, and observe the change in the counts of multicast and broadcast packets. If the counts increase rapidly, a large number of multicast or broadcast packets are sent to the air interface. By default, multicast or broadcast packets are transmitted at a low physical layer rate (11 Mbit/s on the 2.4 GHz band and 6 Mbit/s on the 5 GHz band). Therefore, transmission of a large number of multicast or broadcast packets exhausts the air interface bandwidth, which affects normal unicast data services. If the high air interface channel utilization is caused by a large number of multicast or broadcast packets, configure port isolation (in direct forwarding mode) and rate limiting for multicast and broadcast packets to lower the channel utilization.
Configuring Port Isolation
Run the following commands to enable port isolation on the interface connecting the switch or AC to the AP:
<AC> system-view [AC] interface gigabitethernet 0/0/1 [AC-GigabitEthernet0/0/1] port-isolate enable group 1
In tunnel forwarding mode, port isolation does not need to be enabled. In this case, all AP packets are sent to the AC for forwarding. When configuring port isolation, check whether Layer 2 communication is required. If so, enabling port isolation will cause unavailable Layer 2 communication.
Limiting the Rate of Multicast or Broadcast Packets
In direct forwarding mode, you can configure a traffic policy on the interface connected to the AP to limit the rate of multicast or broadcast packets.
[AC] traffic classifier test [AC-classifier-test] if-match destination-mac 0100-5e00-0000 mac-address-mask ffff-ff00-0000 [AC] traffic behavior test [AC-behavior-test] statistic enable [AC-behavior-test] car cir 100 [AC] traffic policy test [AC-policy-test] classifier test behavior test [AC] interface gigabitethernet 0/0/2 [AC-GigabitEthernet0/0/2] traffic-policy test outbound [AC-GigabitEthernet0/0/2] traffic-policy test inbound
For V200R006 or later, in tunnel forwarding mode, you can configure VAP-based multicast or broadcast suppression in the traffic profile on the AC to suppress multicast or broadcast packets sent by STAs.
[AC] wlan [AC-wlan-view] traffic-profile name default [AC-wlan-traffic-prof-default] traffic-optimize broadcast-suppression packets 300 [AC-wlan-traffic-prof-default] traffic-optimize multicast-suppression packets 300
For V200R005, in tunnel forwarding mode, bind the traffic policy to the WLAN-ESS interface to limit the rate of multicast or broadcast packets.
[AC] traffic classifier test [AC-classifier-test] if-match destination-mac 0100-5e00-0000 mac-address-mask ffff-ff00-0000 [AC-classifier-test] quit [AC] traffic behavior test [AC-behavior-test] statistic enable [AC-behavior-test] car cir 100 [AC] traffic policy test [AC-policy-test] classifier test behavior test [AC] interface wlan-ess 1 [AC-Wlan-Ess1] traffic-policy test inbound [AC-Wlan-Ess1] traffic-policy test outbound
- If the traffic volume and the number of multicast or broadcast packets are not large, check whether there are low-rate or low-RSSI STAs associated with the AP radio on which upload or download operations are being performed.
display station ap-id 19 Rf/WLAN: Radio ID/WLAN ID Rx/Tx: link receive rate/link transmit rate(Mbps) ------------------------------------------------------------------------------------------------ STA MAC Rf/WLAN Band Type Rx/Tx RSSI VLAN IP address SSID ------------------------------------------------------------------------------------------------ 8844-7748-3c81 1/1 5G 11ac 39/52 -64 1 192.168.150.162 m0_tes ------------------------------------------------------------------------------------------------ Total: 1 2.4G: 0 5G: 1
# Display STA traffic statistics.
<AC> display station statistics sta-mac 8844-7748-3c81 ----------------------------------------------------------------- Packets sent to the station : 11234 Packets received from the station : 23423 Bytes sent to the station : 123434 Bytes received from the station : 323444 Wireless data rate sent to the station(kbps) : 4320 Wireless data rate received from the station(kbps) : 4599 Trigger roam total : 0 Trigger roam failed : 0 STA power save percent : 0% ------------------------------------------------------------------------------
The Rx field in the preceding command output indicates the physical layer rate at which the STA sends packets to the AP, and the Tx field indicates the physical layer rate at which the AP sends packets to the STA. The value of the Rx or Tx field changes automatically with packet transmission on the air interface (packet loss after retransmission or retransmission upon the maximum number of times). Higher air interface bandwidth is occupied when the same traffic is transmitted at a lower physical layer rate. For example, if a STA sends packets to an AP at the physical layer rate of about 13 Mbit/s, the air interface bandwidth is exhausted when 5 Mbit/s traffic is transmitted. As a result, the channel utilization is high and services of other STAs on the same radio are affected.
Generally, low-rate STAs have low signal strength. If low-RSSI STAs lose packets, rectify the fault by referring to 1.
- If the volume of upstream and downstream traffic is large, upload or download operations are being performed on STAs on the AP, occupying a large number of air interface channel resources. As a result, other STAs cannot preempt channels, causing long delay or packet loss. In this case, you are advised to perform the following configurations to limit traffic rates according to actual service requirements:
- Check whether a large number of VAPs are configured on the AP, which causes large internal interference.
Check the number of VAPs on the AP.
[AC-wlan-view] display vap ap-id 26 WID : WLAN ID ------------------------------------------------------------------------------------------- AP ID AP name RfID WID BSSID Status Auth type STA SSID ------------------------------------------------------------------------------------------- 26 2028-3e97-4240 0 1 2028-3E97-4240 ON Open 0 ldbc 26 2028-3e97-4240 0 2 2028-3E97-4241 ON Open 0 radio0 26 2028-3e97-4240 0 3 2028-3E97-4242 ON Open+Portal 0 portal 26 2028-3e97-4240 1 1 2028-3E97-4250 ON Open 0 ldbc 26 2028-3e97-4240 1 2 2028-3E97-4251 ON Open 0 radio1 26 2028-3e97-4240 1 3 2028-3E97-4252 ON Open+Portal 0 portal -------------------------------------------------------------------------------------------
If the number of VAPs is large, packet loss may occur due to internal interference caused by a large number of SSIDs of the AP. In this case, perform the following operations:
- Increase the transmission rate of beacon frames.
[AC-wlan-view] ssid-profile name ssid1 [AC-wlan-ssid-prof-ssid1] beacon-2g-rate 11
- After the rate of sending beacon response frames increases, the AP coverage range decreases. You are advised to adjust this parameter in scenarios where APs are densely deployed to reduce interference between APs while increasing the effective network bandwidth. It is recommended that the rate not exceed 11 Mbit/s. If the rate is not set to 1, 2, 5.5, or 11 (802.11b data rates), 802.11b-only STAs cannot discover the network.
- The minimum rate of the 5 GHz band is 6 Mbit/s and there are many channels at 5 GHz. Therefore, this parameter is typically not adjusted for the 5 GHz band.
- Increase the beacon interval.
[AC-wlan-view] radio-2g-profile name default [AC-wlan-radio-2g-prof-default] beacon-interval 200
The following intervals for sending Beacon frames are recommended for APs with different VAP quantities on a single radio:
- No more than 4 VAPs: about 100 TUs
- 5 to 8 VAPs: about 200 TUs
- 9 to 12 VAPs: about 300 TUs
- 13 to 16 VAPs: about 400 TUs
- Delete unnecessary VAPs.
- Increase the transmission rate of beacon frames.
If the AP's channel utilization and noise floor value are normal, go to the next step.
- On the AC, check the channel utilization and noise floor value of the AP radio that the STA associates with.
- Check whether packet loss occurs due to high CPU usage on the AP.
Check the CPU usage of the AP on the AC.
<AC> display ap performance statistics ap-id 15 ...... CPU usage(%) : 80 ......
High CPU usage of an AP is generally caused by a large number of services. For example, an AP's CPU usage increases when users on the AP use upload or download services, or a large number of multicast or broadcast packets are sent to the AP. For details on how to check reasons for high CPU usage and troubleshoot, see 1 and 2. If the high CPU usage is not caused by a large number of services, collect fault information and contact technical support personnel.
If the CPU usage is normal, go to the next step.
- Check whether the transmit queues on an AP radio are working properly.
- Log in to the access AP and check whether the transmit queues on the access radio are working properly.
- For 802.11n APs, such as AP6010DN, AP5010DN, and AP5030DN (2.4 GHz):
<AP> system-view [AP] diagnose [AP-diagnose] display interface radio 0 txq-buf [txqbuf] ath_softc free buf:1024 tx queue depth :1024 txq 0:buf_used = 0 minfree = 48 aggr_depth = 0 axq_depth = 0 txq 1:buf_used = 0 minfree = 32 aggr_depth = 0 axq_depth = 0 txq 2:buf_used = 0 minfree = 16 aggr_depth = 0 axq_depth = 0 txq 3:buf_used = 0 minfree = 0 aggr_depth = 0 axq_depth = 0 txq 4:buf_used = 0 minfree = 0 aggr_depth = 0 axq_depth = 0 txq 5:buf_used = 0 minfree = 0 aggr_depth = 0 axq_depth = 0 txq 6:buf_used = 0 minfree = 0 aggr_depth = 0 axq_depth = 0 txq 7:buf_used = 0 minfree = 0 aggr_depth = 0 axq_depth = 0 txq 8:buf_used = 0 minfree = 48 aggr_depth = 0 axq_depth = 0 txq 9:buf_used = 0 minfree = 0 aggr_depth = 0 axq_depth = 0
Observe the buffer usage of txq 0, 1, 2, 3, 7, and 8. In normal cases, the value of buf_used of queues is small. When the volume of service traffic is high, the value of buf_used of a queue may increase, for example, to 500. This value may be higher when a low-rate STA is using the download service or sends a large number of multicast or broadcast packets. The buffer resources are shared by all STAs on a radio. When a STA occupies too many resources, other STAs may fail to apply for buffer resources, leading to a high delay or packet loss. In this case, refer to 2 and 4 for handling.
- For 802.11ac APs, such as AP5030DN (5 GHz), AP7050DE, and AP4050DN:
[AP-diagnose] display wifi txq-buf radio 1 [Txqbuf] Host tx queue depth:2500 [Frames queued to hwq] -------------------------------------- Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 0 0 0 0 0 0 0 0 0 0 -------------------------------------- [Tid queue stats] SW queue stats <---> HW queue stats ------------------------------ TID 0 0 0 TID 1 0 0 TID 2 0 0 TID 3 0 0 TID 4 0 0 TID 5 0 0 TID 6 0 0 TID 7 0 0 TID 8 0 0 TID 9 0 0 TID 10 0 0 TID 11 0 0 TID 12 0 0 TID 13 0 0 TID 14 0 0 TID 15 0 0 TID 16 0 0 TID 17 0 0 TID 18 0 0 TID 19 0 0 ------------------------------ [Prefetch Tx queue stats] //This item is displayed only on an 802.11ac Wave 2 AP, such as AP7050DE, AP6050DN, or AP4050DN. ------------------------------ TID 0 0 TID 1 0 TID 2 0 TID 3 0 TID 4 0 TID 5 0 TID 6 0 TID 7 0 ------------------------------
Observe the SW queue stats values of TID 0, 1, 2, 3, 16, and 17, which are usually small.
In normal cases, the number of buffer resources used by each queue changes in accordance with the change in the volume of service traffic.
- For APs using 802.11ax chips in V200R019C10:
[AP-diagnose] display lmac txq-buf radio 1 Hardware tx queue statistic: ------------------------------------------------------------------ Txq0 Txq1 Txq2 Txq3 Txq4 Txq5 Txq6 Txq7 Total 0 0 0 0 0 0 0 0 ------------------------------------------------------------------ Txq8 Txq9 Txq10 Txq11 Txq12 Txq13 Txq14 Txq15 Total 0 0 0 0 0 0 0 0 ------------------------------------------------------------------ Software tid queue statistic: ------------------------------------------------------------------ Tid0 Tid1 Tid2 Tid3 Tid4 Total 0 0 0 0 0 ------------------------------------------------------------------ Tid5 Tid6 Tid7 Tid8 Tid9 Total 0 0 0 0 0 ------------------------------------------------------------------ Qos queue statistic: ------------------------------------------------------------------ BE BK VI VO Total 0 0 0 0 ------------------------------------------------------------------If the value of a queue is not 0, the queue has buffered packets. In normal cases, the number of buffer resources used by each queue changes in accordance with the change in the volume of service traffic.
- For 802.11n APs, such as AP6010DN, AP5010DN, and AP5030DN (2.4 GHz):
- Check which STA occupies many buffer resources.
When the volume of service traffic on a radio is small and the channel utilization is normal, if the number of buffer resources remains high (for example, more than 800) and the service packet loss ratio is high, locate the STA that occupies the buffer. The fault may be caused by the STA.
In V200R019C00 and earlier versions:
[AP-diagnose] display wifi sta-statistics radio 1 --------------------------STA:c88d-833a-8d50 Statistics------------------------- [NorMalPS] sendPktAsNiPsUmac : 0 [RateFind Lastest Info] GoodPut(kbps) : 0 Per : 0% RateCode : 0x0 ---------------------------STA:8844-7748-3c81 TidInfo--------------------------- [tidno: 17] wal_txq_id : 4 is_registered_for_hwq_empty : 0 sw_retry_failure : 0 tx_header_size : 0 tid_flags : 0x108a0 pause_module_id_map : 0x0 block_module_id_map : 0x0 tid_winsn : 0xffffffffffffffff tid_startsn : 2379 tid_winunack : 0x0 tid_frameqhead : 0x44a520 tid_frameqaddr : 0x44a520 num_mpdu_in_frameq : 0 num_mpdu_in_hwq : 0 tid_frameqlastnum : 0 tid_frameqlastpad : 0 total_mpdus_allowed : 0 allow_n_flags : 0x0 win_credit : 1 win_size_o : 1 fail_cnt_succ : 0 pn_low : 0x1509410000000 [tidno: 0] wal_txq_id : 1 is_registered_for_hwq_empty : 0 sw_retry_failure : 0 tx_header_size : 26 tid_flags : 0x108c0 pause_module_id_map : 0x0 block_module_id_map : 0x0 tid_winsn : 0xffffffffffffffff tid_startsn : 9 tid_winunack : 0x0 tid_frameqhead : 0x44a450 tid_frameqaddr : 0x44a450 num_mpdu_in_frameq : 900 num_mpdu_in_hwq : 0 tid_frameqlastnum : 0 tid_frameqlastpad : 0 total_mpdus_allowed : 0 allow_n_flags : 0x0 win_credit : 1 win_size_o : 1 fail_cnt_succ : 0 pn_low : 0x800000000 .......................................................................................
A large number of STAs may connect to the radio. Save the command output to the log file, open the log file, and search for the fields in bold. Check the value of num_mpdu_in_frameq (or BuffInBuf for 802.11n APs, such as AP6010DN and AP5010DN) in the command output. This field indicates the number of packets buffered in different priority queues (specified by tidno) of each STA. In this way, you can locate the STA with the highest buffer value. In the preceding command output, 900 packets are buffered in the priority queue 0 of the STA with the MAC address 8844-7748-3c81.
In V200R019C10:
[AP-diagnose] display lmac sta-statistics queue-status sta d453-83e1-1bea Tx tid queue info: Base info: Tid num : 0 1 2 3 4 5 6 7 8 Hardware txq ID : 1 0 0 1 2 2 3 3 11 Tid flag : 0x65 0x1 0x1 0x1 0x1 0x1 0x65 0x1 0x1007 Tid start sn : 1 0 0 0 0 0 196 0 0 Negotiate window size : 64 1 1 1 1 1 64 1 1 Software retry failure : 0 0 0 0 0 0 0 0 0 Failure count : 0 0 0 0 0 0 0 0 0 MPDU count : 0 0 0 0 0 0 0 0 0 Retrans MPDU count : 0 0 0 0 0 0 0 0 0 MPDU byte : 0 0 0 0 0 0 0 0 0 Retrans MPDU byte : 0 0 0 0 0 0 0 0 0 MSDU num : 0 0 0 0 0 0 0 0 0 MSDU byte : 0 0 0 0 0 0 0 0 0 MPDU total num : 0 0 0 0 0 0 0 0 0 Window credit : 64 1 1 1 1 1 64 1 1 Queue ctrl info: MSDU limit due rate : 25273 0 0 0 0 0 25273 0 0 MSDU limit due dequeue : 26325 0 0 0 0 0 26325 0 0 Max allowed MSDU : 26325 0 0 0 0 0 25273 0 0 MSDU drop due limit : 0 0 0 0 0 0 0 0 0 MSDU timeout threshold(ms): 10000 10000 10000 10000 10000 10000 10000 10000 10000 Fisrt MSDU dwell time : 0 0 0 0 0 0 0 0 0 MSDU drops due expire : 0 0 0 0 0 0 0 0 0 Current time : 11564320 11564320 11564320 11564320 11564320 11564320 11564320 11564320 11564320 Last success send time : 85463 0 0 0 0 0 11544699 0 0 Dequeue MSDU count : 0 0 0 0 0 0 0 0 0 MSDU limit due powersave : 25273 25273 25273 25273 25273 25273 25273 25273 0 Protocal info: Max MSDU num : 1 1 1 1 1 1 1 1 0 Max MSDU byte : 1500 1500 1500 1500 1500 1500 1500 1500 0 Packet type : 0 0 0 0 0 0 0 0 0 Packet encryption type : 0 0 0 0 0 0 0 0 0 Has qos flag : 0 0 0 0 0 0 0 0 0 Has ctrl flag : 0 0 0 0 0 0 0 0 0 Prot info tid flag : 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 Power save info: Service period start time : 0 0 0 0 0 0 0 0 0 Pause cmd flag : 0 0 0 0 0 0 0 0 0 Su only on flag : 0 0 0 0 0 0 0 0 0 Pending frame sleep : 0 0 0 0 0 0 0 0 0 Power saving info : 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 Schedule info: Schedule list type : 2 0 0 0 0 0 2 0 0 Tid in schedule : 1 0 0 0 0 0 1 0 0 Tokens num : 1 0 0 0 0 0 0 0 0 Priority : 0 0 0 0 0 0 0 0 0 Schedule abnormal num : 0 0 0 0 0 0 0 0 0 Tid pending status : 0 0 0 0 0 0 0 0 0 Rx pkt seqnumber info: Tid num : 0 1 2 3 4 5 6 7 8 Mask : 0 0 0 0 0 0 0 0 0 Seq num start : 2151 0 0 0 0 0 0 0 0 Seq num end : 167 0 0 0 0 0 0 0 0 Seq num : 0x8660 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0If this STA is not exchanging a large number of packets, the STA status may be faulty on the AP. The AP cannot send packets to the STA, leading to continuous packet buffering for this STA.
In this case, run the debugging wifi target radio x dump command in the diagnostic view of the AP to collect necessary dump files. After the command is executed, wait for about 30s and run the dir command in the user view of the AP to check whether the dump files are successfully collected.
The debugging wifi target radio x dump command is supported in V200R007C20 and later versions. This command is invalid for 802.11n APs (such as AP6010DN and AP5010DN) and is valid only for 802.11ac APs (such as AP8030DN, AP6050DN, and AP7050DE).
<AP> dir Directory of flash:/ Idx Attr Size(Byte) Date Time(LMT) FileName 0 -rw- 646,518 Oct 07 2017 16:38:08 athdiag 1 -rw- 1,116 Oct 18 2018 14:34:41 autodiag.log 2 -rw- 7,779 Mar 13 2018 14:49:51 ca-bundle5.crt 3 -rw- 1,261 Sep 26 2018 18:56:13 ca.cer 4 -rw- 200 Mar 13 2018 14:50:01 ca_config.ini 5 drw- - Jan 01 1970 00:00:37 config 6 drw- - May 24 2017 11:27:40 corefile 7 -rw- 2,253 Jan 01 2017 11:02:13 daemon.log 8 -rw- 2,194 Oct 08 2018 23:44:46 daemon.log.bak 9 drw- - Jan 01 1970 00:00:38 default-sdb 10 -rw- 7,779 Mar 13 2018 14:49:51 default_ca.cer 11 -rw- 1,196 Mar 13 2018 14:50:01 default_local.cer 12 drw- - Aug 09 2018 06:07:29 dhcp 13 drw- - Sep 26 2018 00:14:50 flash 14 -rw- 28,672 Jan 09 2018 17:34:50 fw_apb0_reg 15 -rw- 12,288 Oct 17 2017 11:54:44 fw_apb1_reg 16 -rw- 20,480 Apr 09 2018 22:24:15 fw_ce_reg 17 -rw- 524,288 Oct 18 2018 22:40:43 fw_dram //The file applies to 802.11ac Wave 2 APs. The file for 802.11ac Wave 1 APs is dramdump. 18 -rw- 327,680 Oct 18 2018 22:40:46 fw_iram //The file applies to 802.11ac Wave 2 APs. The file for 802.11ac Wave 1 APs is iramdump. 19 -rw- 24,576 Nov 25 2017 13:23:05 fw_soc_reg 20 -rw- 262,144 Oct 18 2018 22:40:49 fw_sram //The file applies only to 802.11ac Wave 2 APs. No corresponding file is available for 802.11ac Wave 1 APs. 21 -rw- 12,288 Nov 25 2017 13:23:02 fw_wifi_reg- For 802.11ac Wave 2 APs, such as AP7050DE, AP6050DN, and AP4050DN, the dump files are fw_sram, fw_dram, and fw_iram.
- For 802.11ac Wave 1 APs, such as AP5030DN, AP4030DN, and AP8030DN, the dump files are dramdump and iramdump.
Determine whether the files are generated successfully by check whether the time before the corresponding file names is updated to the latest system time of the AP. After the files are generated, you can transfer the files from the AP to the PC through FTP. This facilitates the subsequent operations of technical support engineers.
After the preceding steps are complete, force the STA to go offline on the AC and check whether services are restored.<AC> system-view [AC] aaa [AC-aaa] cut access-user mac-address 8844-7748-3c81
If services cannot be restored after the STA is forced to go offline, contact technical support personnel.
If the transmit queues are normal and the packet buffer size of each queue is small, for example, smaller than 50, go to the next step.
- Log in to the access AP and check whether the transmit queues on the access radio are working properly.
- Check whether the air scan parameters are properly configured.
[AC-wlan-view] display air-scan-profile name default -------------------------------------------------------------------- Scan switch : enable Scan period(ms) : 100 //Scan period Scan interval(ms) : 2000 //Scan interval Scan channel-set : country-channel Voice scan aware : enable Video scan aware : enable Scan enhancement : disable --------------------------------------------------------------------
The air scan parameters mainly include the scan interval and scan period. If the parameters are not properly set, for example, setting a small scan interval (less than 3s) or a long scan period (such as 100 ms), the AP will frequently switch to a non-working channel for information collection. This may affect user services on working channels, for example, leading to a high delay or packet loss.
You can disable the air scan function to check whether the STA packet loss is related to the air scan function.
[AC-wlan-view] air-scan-profile name default [AC-wlan-air-scan-prof-default] scan-disable
- If no packet is lost or the packet loss ratio greatly decreases after the air scan function is disabled, the fault is caused by improper air scan parameter settings. If there are no special service requirements, such as STA location, retain the default values of the scan interval and scan period.
- If ping packets are still lost after the air scan function is disabled, the fault is not caused by this function. Go to the next step.
- On the AC, check whether EDCA parameters are properly configured in the radio profile of the AP. Currently, the Ack-Policy parameter has a great impact on services.
[AC-wlan-view] display radio-2g-profile name default -------------------------------------------------------------------- ... AP EDCA parameters: ------------------------------------------------------------ ECWmax ECWmin AIFSN TXOPLimit(32us) Ack-Policy AC_VO 3 2 1 47 no ack AC_VI 4 3 1 94 no ack AC_BE 6 4 3 0 no ack AC_BK 10 4 7 0 no ack ------------------------------------------------------------EDCA parameters are used to control air interface channel preemption of four priority queues and determine whether an ACK response is required for sent unicast data packets.
In most cases, it is recommended that the default settings of the EDCA parameters be retained. If the parameters are adjusted improperly, services will be greatly affected. For example, the default value of Ack-Policy is normal, indicating that the receiver needs to respond with an ACK packet for a unicast data packet to be sent. If the value is changed to no ack, the sender considers that the packet is sent successfully even if it does not receive an ACK response; however, due to the uncertainty of the air interface, the receiver may not receive the packet. As a result, the retransmission mechanism becomes unavailable, causing severe packet loss.
In addition to Ack-Policy, inappropriate settings of other EDCA parameters may also cause packet loss or long delay. Therefore, you are not advised to manually adjust EDCA parameters. In some scenarios, such as high-density scenarios, it is recommended that dynamic EDCA be enabled so that APs can adaptively adjust EDCA parameters based on service requirements. To configure dynamic EDCA, run the following commands:
[AC-wlan-view] rrm-profile name huawei [AC-wlan-rrm-prof-huawei] dynamic-edca enable
- Collect statistics about packets on the AP forwarding module and Wi-Fi module. Display statistics about packets discarded because the forwarding threshold is exceeded.
- On the Wi-Fi driver (in V200R019C00 and earlier versions):
- Downlink: Ping STAs from the AC and check whether the Wi-Fi driver properly sends downlink ping packets.
[AP-diagnose] debugging wifi print condition clear //Clear the filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging wifi print condition counter clear //Clear the packet count to facilitate subsequent query. [AP-diagnose] debugging wifi print 3 //The value 3 indicates that only packet statistics are collected. The packet content is not displayed. [AP-diagnose] debugging wifi print condition icmp //Set a filtering condition. [AP-diagnose] debugging wifi print condition dst-mac 2469-a593-6d9a //Set the destination MAC address to the STA's MAC address. [AP-diagnose] debugging wifi print on print-num 1000 //Set the maximum number of packets that meet the filtering condition and are counted. [AP-diagnose] debugging wifi print condition counter query //Check the packet count. [AP-diagnose] debugging wifi print condition clear //Clear the filtering condition. [AP-diagnose] debugging wifi print off //Disable the statistics collection function after the fault is rectified.
For downlink packet statistics, the top item is statistics about packets when they enter the Wi-Fi driver. The subsequent items indicate that the packets pass through the sending processes within the driver until the packets are successfully sent (last item). In normal cases, the count is the same for all processes. If a value is different or all values are 0, the Wi-Fi driver does not receive the packet or the packet is lost due to some reasons.
- Uplink: Ping STAs from the AC and check whether the Wi-Fi driver properly receives ping packets from the STAs.
[AP-diagnose] debugging wifi print condition clear //Clear the filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging wifi print condition counter clear //Clear the packet count to facilitate subsequent query. [AP-diagnose] debugging wifi print 3 //The value 3 indicates that only packet statistics are collected. The packet content is not displayed. [AP-diagnose] debugging wifi print condition icmp //Set a filtering condition. [AP-diagnose] debugging wifi print condition src-mac 2469-a593-6d9a //Set the source MAC address to the STA's MAC address. [AP-diagnose] debugging wifi print on print-num 1000 //Set the maximum number of packets that meet the filtering condition and are counted. [AP-diagnose] debugging wifi print condition counter query //Check the packet count. [AP-diagnose] debugging wifi print condition clear //Clear the filtering condition. [AP-diagnose] debugging wifi print off //Disable the statistics collection function after the fault is rectified.
For uplink packet statistics, the bottom item is statistics about packets when they enter the Wi-Fi driver. The upward items indicate that the packets pass through the receiving processes within the driver until the packets are successfully sent to the forwarding module (top item). In normal cases, the count is the same for all processes. If a value is different or all values are 0, the Wi-Fi driver does not receive the packet or the packet is lost due to some reasons.
- Downlink: Ping STAs from the AC and check whether the Wi-Fi driver properly sends downlink ping packets.
- On the Wi-Fi driver side (in V200R019C10 and later versions):
- Downlink: Ping STAs from the AC and check whether the Wi-Fi driver properly sends downlink ping packets.
[AP-diagnose] debugging lmac pkt-print condition clear //Clear the filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging lmac pkt-print condition counter clear //Clear the packet count to facilitate subsequent query. [[AP-diagnose] debugging lmac pkt-print condition icmp //Set a filtering condition. [AP-diagnose] debugging lmac pkt-print dst-ip 192.190.190.232 //Set the destination MAC address to the STA's MAC address. [AP-diagnose] debugging lmac pkt-print level 0 //Configure the content to be printed. [AP-diagnose] debugging lmac pkt-print module 0 //Configure the printing module. [[AP-diagnose] debugging lmac pkt-print on print-num 1000 //Set the maximum number of packets meeting the filtering condition that can be counted. [AP-diagnose] debugging lmac pkt-print condition counter query //Check the packet count. [AP-diagnose] debugging lmac pkt-print condition clear //Clear the filtering condition. [AP-diagnose] debugging lmac pkt-print off //Disable the statistics collection function after the fault is rectified.
- Uplink: Ping STAs from the AC and check whether the Wi-Fi driver properly receives ping packets from the STAs.
[AP-diagnose] debugging lmac pkt-print condition clear //Clear the filtering condition so that you can set a new filtering condition. [AP-diagnose] debugging lmac pkt-print condition counter clear //Clear the packet count to facilitate subsequent query. [[AP-diagnose] debugging lmac pkt-print condition icmp //Set a filtering condition. [AP-diagnose] debugging lmac pkt-print src-ip 192.190.190.232 //Set the source MAC address to the STA's MAC address. [AP-diagnose] debugging lmac pkt-print level 0 //Configure the content to be printed. [AP-diagnose] debugging lmac pkt-print module 0 //Configure the printing module. [[AP-diagnose] debugging lmac pkt-print on print-num 1000 //Set the maximum number of packets meeting the filtering condition that can be counted. [AP-diagnose] debugging lmac pkt-print condition counter query //Check the packet count. [AP-diagnose] debugging lmac pkt-print condition clear //Clear the filtering condition. [AP-diagnose] debugging lmac pkt-print off //Disable the statistics collection function after the fault is rectified.
Run the debugging lmac pkt-print counter query command to check the number of times Tx/Rx packets pass through nodes. If the value of Tx is inconsistent on the nodes, packet loss occurs during packet transmission.
- Downlink: Ping STAs from the AC and check whether the Wi-Fi driver properly sends downlink ping packets.
- Collect statistics on the forwarding module as follows:
- Downlink: Collect statistics about packets from an AP's Ethernet port to the Wi-Fi driver. If packet loss occurs, check whether ping packets reach the AP's Ethernet port based on the statistics.
<AP> terminal debugging <AP> terminal monitor [AP-diagnose] debugging cap catch-filter 0 condition clear [AP-diagnose] debugging cap catch-filter 0 condition inner icmp [AP-diagnose] debugging cap catch-filter 0 condition inner dst-mac 2469-a593-6d9a [AP-diagnose] reset cap catch-filter 0 statistics [AP-diagnose] debugging cap print on [AP-diagnose] display cap catch-filter 0 statistics [AP-diagnose] debugging cap catch-filter 0 condition clear [AP-diagnose] debugging cap print off
- The forwarding module can be configured with four filters at the same time. (To specify the filter in use, run the catch-filter x command.) You can set different filtering conditions to collect packet statistics at the same time to quickly locate faults.
- In the preceding commands, inner is added to the filter criteria because the packets entering an AP's Ethernet port carry the CAPWAP tunnel header and are traced based on the protocol type and destination IP address in the inner tunnel header.
In the displayed statistics, focus only on MSU_GET_MATCHED_PKT_FROM_PORT and MSU_SEND_MATCHED_PKT_TO_DRV, which indicate statistics about packets received from the Ethernet port driver and those about packets sent to the Wi-Fi driver, respectively.
- Uplink: Collect statistics about packets from the Wi-Fi driver to an AP's Ethernet port.
<AP> terminal debugging <AP> terminal monitor [AP-diagnose] debugging cap catch-filter 0 condition clear [AP-diagnose] debugging cap catch-filter 0 condition icmp [AP-diagnose] debugging cap catch-filter 0 condition src-mac 2469-a593-6d9a [AP-diagnose] reset cap catch-filter 0 statistics [AP-diagnose] debugging cap print on [AP-diagnose] display cap catch-filter 0 statistics [AP-diagnose] debugging cap catch-filter 0 condition clear [AP-diagnose] debugging cap print off
- The forwarding module can be configured with four filters at the same time. (To specify the filter in use, run the catch-filter x command.) You can set different filtering conditions to collect packet statistics at the same time to quickly locate faults.
- In the preceding commands, you do not need to add inner to the filter criteria. This is because packets sent from the Wi-Fi driver to the forwarding module do not carry the CAPWAP tunnel header, which will be added by the forwarding module before sending the packets to an Ethernet port. Instead, the outer protocol type and destination MAC address of the packets are directly used for filtering.
In the displayed statistics, focus only on MSU_GET_MATCHED_PKT_FROM_PORT and MSU_SEND_MATCHED_PKT_TO_DRV, which indicate statistics about packets received from the Wi-Fi driver and those about packets sent to the Ethernet port driver, respectively.
- Downlink: Collect statistics about packets from an AP's Ethernet port to the Wi-Fi driver. If packet loss occurs, check whether ping packets reach the AP's Ethernet port based on the statistics.
- Display statistics about packets discarded because the forwarding threshold is exceeded.
Run the display cap all error statistics command to check whether the statistics contain the CHECK_TODROP_INGRESS_BUFFER_LEVEL field. If so, packet loss occurs.
Packet loss in this case indicates the heavy volume of service traffic, which is usually caused by a large number of multicast or broadcast packets. It is recommended that rate limiting be configured for multicast and broadcast packets.[AC-diagnose] display cap all error statistics [ 1]Mss Timer-Unicast [ 93]MSS_TIMER_DEL_JOB_FAIL 1 [16]ip-Unicast [ 274]IP_FWD_PROC_FAIL 1190 [ 312]IPMC_ING_PROC 2451 [ 332]IPMC_DISABLE_DROP 2451 [ 373]IP_SEARCH_FIB_IPV4_FIB_LOOKUP 38093 [26]cpu-defend-Unicast [1166]PROC_BODY_FAIL 9571 [1172]SEARCH_CPCTRL_FAIL 6140 [1182]CAR_RED_DROP 3431 [1229]SEARCH_HSB_CAR_FAIL 2429030 [1263]CHECK_IPV4_UDPCHKSUM_FAIL 4 [27]eth-Unicast [1266]ING_ETH_PROC_BODY_FAIL 61527 [1281]ING_ETH_DROP_BC_PKT 53823 [1345]CAP_ETH_EG_RC_PROC_ARP_FAKE 1 [1454]ETH_L2_SSW_SAP_PKT_FAIL 7704 [36]txrx-Unicast [1833]L1_ING_HIG_GET_RXIF_FAIL 3 [1838]L1_ING_GET_FWDIF_FAIL 3 [37]svc-Unicast [1921]SVC_AUTO_UNKNOWMC_CAR_RED_DROP 9181 [1954]SVC_L2_ING_MACLEARN_ADD_ENTRY_FAIL 2 ...
- On the Wi-Fi driver (in V200R019C00 and earlier versions):
- Collect fault information.
- STA's MAC address: xxxx-xxxx-xxxx
- Check AC version information.
[AC-diagnose] vrbd
- Check the AC configuration.
<AC> display current-configuration
- Check AP version information.
[Huawei-diagnose] vrbd
- Collect diagnostic information about the AP.
<Huawei> display diagnostic-information saved-file <Huawei> display diagnostic-information
- Collect kernel logs of the AP.
[Huawei-diagnose] display kernel-logbuf record-range 1 [Huawei-diagnose] display kernel-logbuf record-range 2 [Huawei-diagnose] display kernel-logbuf record-range 3
If the problem persists for a long time, run the following commands to export logs on the AP or AC.
<Huawei> save logfile [Huawei-diagnose] save diag-logfile <Huawei> cd logfile/ <Huawei> dir Directory of flash:/logfile/ Idx Attr Size(Byte) Date Time(LMT) FileName 0 -ro- 1,113,850 Aug 31 2015 11:26:57 2015-08-31.12-29-00.dblg 1 -ro- 1,113,970 Aug 31 2015 19:45:02 2015-08-31.23-14-59.dblg 2 -ro- 1,113,920 May 06 2016 08:42:07 2016-05-06.08-47-07.dblg 3 -ro- 1,113,472 May 11 2016 16:19:54 2016-06-09.17-15-52.dblg 4 -ro- 1,114,104 Jun 14 2016 17:55:56 2016-06-14.18-29-52.dblg 5 -ro- 1,114,031 Jun 14 2016 22:22:06 2016-06-14.22-54-08.dblg 6 -ro- 1,113,835 Jun 17 2016 17:29:24 2016-06-17.18-08-54.dblg 7 -ro- 1,113,843 Jun 17 2016 20:34:50 2016-06-17.20-47-59.dblg 8 -ro- 1,113,743 Jun 22 2016 20:06:19 2016-06-22.20-50-06.dblg 9 -ro- 1,113,271 Jun 28 2016 16:58:37 2016-06-28.19-58-45.dblg 10 -ro- 1,113,494 Jun 29 2016 17:33:23 2016-06-29.18-32-36.dblg 11 -ro- 1,113,824 Jun 30 2016 01:22:38 2016-06-30.02-19-21.dblg 12 -ro- 1,113,773 Jun 30 2016 09:10:31 2016-06-30.10-09-39.dblg 13 -ro- 1,125,418 Jun 30 2016 09:26:03 2016-06-30.12-25-03.log 14 -ro- 1,113,801 Jul 11 2016 09:59:38 2016-07-11.10-13-26.dblg 15 -ro- 1,113,732 Jul 13 2016 15:41:02 2016-07-13.15-54-31.dblg 16 -ro- 1,129,531 Jul 13 2016 19:55:33 2016-07-15.10-37-46.dblg 17 -ro- 1,113,787 Nov 26 2018 21:54:45 2018-11-27.01-02-52.dblg 18 -ro- 1,113,604 Nov 27 2018 22:56:38 2018-11-28.00-20-24.dblg 19 -ro- 1,113,723 Nov 28 2018 07:37:57 2018-11-28.08-40-58.dblg 20 -ro- 1,113,744 Nov 28 2018 15:14:40 2018-11-28.16-10-55.dblg 21 -rw- 384,570 Jul 19 2016 10:07:11 log.dblg 22 -rw- 681,533 Jul 19 2016 10:06:57 log.log 11,144 KB total (1,512 KB free)You must log in to the AP to collect AP logs.
In V200R008C10 and later versions, you only need to run the save logfile command to save logs. After the logs are saved, use FTP or TFTP to export .log and .dblg log files in the corresponding time period.
Information collection is mainly performed in the diagnostic view. To enter the diagnostic view, run the following commands.
<Huawei> system-view [Huawei] diagnose
