Solved

Client Wifi Health Score

  • 3 December 2020
  • 10 replies
  • 129 views

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.

 

 

icon

Best answer by Sam Pirok 7 December 2020, 18:50

Hi Jayotte, my apologies for the delay here. I took a look at the captures you sent over and I’m not seeing any clients that are sending an inordinate amount of traffic, in fact most clients seem to be sending a small amount of traffic. I think you might want to open a technical support case and attach those packet captures to the case so one of our technicians can look in to this with you further. It’s possible there is a loop or something else causing a lot of background traffic. 

View original

10 replies

Userlevel 5

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. 

Thanks Sam

 

I’ll check back on the client trail and see if I can find results from when clients are it that room. It’s in one of the residences so it’s not readily accessible to pop in and test.

 

How many minutes of packet capture would you like?

Userlevel 5

I typically do 5 minutes just to make sure we see a spike but if it’s pretty constant and you can replicate at will, 1 minute should be fine. 

HI Sam

I sent the captures on Friday but forgot to update here.

Thanks

Userlevel 5

Hi Jayotte, my apologies for the delay here. I took a look at the captures you sent over and I’m not seeing any clients that are sending an inordinate amount of traffic, in fact most clients seem to be sending a small amount of traffic. I think you might want to open a technical support case and attach those packet captures to the case so one of our technicians can look in to this with you further. It’s possible there is a loop or something else causing a lot of background traffic. 

No need to apologize for a delay, it was the weekend, I appreciate the assistance.

I will open a case today.

Thanks

When support reviewed the packet captures they said that the protocol distribution was normal. I’ll try the numbers again when 10.0r10a has been out for a bit.

Thanks for your help

Userlevel 2

@jayotte Hi i found out a few things about the behaviour of Apple TV in the past. The most comprehensive document about how Apple TV actually behave in the network can be found here:

https://arxiv.org/pdf/1808.03156.pdf

What I learned is this: the Apple TVs will always generate an ad-hoc network and not use the existing wireless infrastructure as long as the wifi channel is less than 80 MHz wide (which will always be the case in business and education). If the existing Wifi is on 40 MHz channels the adhoc network (AWDL Apple Wireless Direct Link) will create also an 40 MHz wide Adhoc wifi, if you use 20 MHz it will create an 80 MHz wide Ad-hoc wifi. 

To my knowledge today there is no way to force an Apple TV to use the existing wireless infrastruction.

Best 
Andi

Userlevel 2

what i forgot to mention the Apple Ad-Hoc network uses the following channels:

6

44

149

 

Thanks for the info Andi. The PDF looks interesting, will read more in greater depth later.

This was an older (pre REV 3) AppleTV which I thought I had read had different behaviour but can’t find the site now. The user was running the NetFlix app on the AppleTV, not AirPlaying. Anyway, the user has since replaced this unit.

Thanks again

 

 

Reply