Client Wifi Health Score

[JA]

Hi

I have a few clients connected to an AP (AP230 10.0r9b) that give me numbers that I am trying to figure out.

RSSIs are between -51 and -63 and SNRs between 44 and 31. Application Health is 100 but Wifi Health scores are between 56 and 38.

One of the clients is an AppleTV and the Wifi Health is 100 when not in use but drops to 38 when in use. I'm not sure if this is just as simple of people sitting between the AP and AppleTV when it's in use.

Working through the RF troubleshooting guide I get the following info.

sho ascp nei (AP is currently on channel 44)
Chan Rssi(dBm) Aerohive AP  CU  CRC STA Channel-width VID  NVID
44   -87       yes          2   22  0   40+           1    1    
44   -87       yes          2   22  2   40+           1    1    
44   -87       yes          2   22  1   40+           1    1    
44   -87       yes          2   22  0   40+           1    1    
100  -88       yes          7   0   3   40+           -    -    
60   -75       yes          4   10  0   40+           1    1    
60   -75       yes          4   10  1   40+           1    1    
60   -75       yes          4   10  3   40+           1    1    
100  -88       yes          7   0   0   40+           -    -    
100  -89       yes          7   0   0   40+           -    -    
100  -89       yes          7   0   0   40+           -    -    
157  -80       yes          2   31  0   40+           1    1    
157  -80       yes          2   31  0   40+           1    1    
157  -80       yes          2   31  0   40+           1    1    
157  -80       yes          2   31  0   40+           1    1    
157  -91       yes          6   15  0   40+           1    1

sho int wifi1
Summary state=High collision
Freq(Chan)=5220Mhz(44*); EIRP power=18.00*dBm(12dBm + 6.00dBi + 0.00dBi); Diversity=enabled;
Noise floor=-95dBm;  
BGSCAN allow=enabled; BGSCAN during voice=disabled; BGSCAN interval=10 minutes;
BGSCAN with client=enabled; BGSCAN with PS client=enabled;
Number of BGSCAN=4959; Number of BGSCAN requested=5143; Number of BGSCAN missed=184;
DFS=enabled; Number of detected radar signals=0; DFS static-channel restore=disabled;
Tx utilization=2%; Rx utilization=3%; Interference utilization=2%; Total utilization=7%;
CRC error rate=23%;

sho int wifi1 _count
2% rx retry rate
9151823 rx CRC errors
28% rx CRC rate
0% tx retry rate
0% unicast data tx retry rate

sho acsp channel-info detail
When I run this I get this message on wifi1
This interface did not finish scanning all available channels.

When I run clear forward count eth01 it takes about 30 seconds to show that it has completed.
Should I be starting the timer from when I enter the command or when it completes? Either way the
number is between 200-300 per second. Way too high.

sho forward count int eth0

Interface [eth0]
-----------------
Inocming Counters
------------------------------
LLC: 100619; ARP: 1473; IP 47666
ICMP: 18; UDP: 47614; TCP: 4; GRE: 0; ESP: 0
HTTP: 0; HTTPS: 0; FTP: 0; TELNET: 0; DNS: 0; DHCP: 0; SSH: 0
Dropped: 30273

From the numbers the only thing bad I see is the CRC errors and the LLC packets. Could the CRC just be a distance issue with the clients? There are 2 lath and plaster walls between and the AP should be mounted higher.

With a 28% rx CRC error rate I would expect the retry rate would be higher so I'm wondering if I am not understanding these numbers properly.

Thanks for taking the time to read this, any thoughts would be appreciated.

[SamPirok]

Hi Jayotte, thank you for providing all of that data. I agree the only issues I see here are the elevated CRC rate and the high LLC count. Starting with CRC, this is typically environmental interference. What we’re seeing here is that 28% of the received packets are failing their cyclic redundancy check (CRC), indicating these packets are too damaged to read and have to be re-sent at least once (likely more than once) before the receiving radio can read them. Any barriers between the client device and the AP radios can cause packet damage, and you want to especially watch out for metal, glass, or water. Do you get the same results when using this client device in the same room as the AP?

For the LLC count, we usually start seeing issues at around 30 packets per second, so the 200-300 packets per second will absolutely be causing issues. You want to start the timer as soon as you enter that command, then check the count after the time has ended. We are timing it so we can divide the number of packets by the number of seconds since the counter was cleared so we can get an average packet per second count. I’d recommend running a packet capture to identify the clients that are sending too much traffic on the network, and then checking the settings on those client devices to reduce the amount of traffic coming from any one device. If you’d like to send the packet capture to me at community@extremenetworks.com, I can take a look and help ID the clients that are sending an inordinate amount of traffic when compared to most clients.