High RF usage on AP

[EClap5]

Last week I was looking through the RF Spectrum section and realized I had a number of APs on a first floor of one of our office building that were all experiencing high to jammed 2.4 channels.  Looking at the RF tab for a specific AP, I see high utilization on 2.4 but only have one client connected for just a portion of the timeline and extremely low usage.  Today I am seeing the same thing on some APs that are serving zero clients.  After a reboot, the channel that was jammed is now down to almost nothing and the majority of the utilization (before reboot) was 802.11 traffic.

I know there are all sorts of things that can cause interference in the 2.4 but most - like microwaves - are stationery and I would think would interfere with the AP after the reboot.  But this isn't the case.  Is there anything with the AP itself that would cause the current channel to be jammed until a reboot?

[PhilipDAth]

It is possible that a user on another AP is using up all the spectrum leaving nothing for the AP you are looking at.

My advice - disable the 2.4Ghz spectrum.  It is at the bottom of the "Edit SSID" page.  I would also set the minimum connect speed to 12Mb/s to disable legacy client support.  Clients operating at low data rates can burn a lot of bandwidth.

[EClap5]

@PhilipDAththanks for replying.  Right now I have 3 SSIDs broadcasting on all APs with the bitrate is set to 12Mbps with bandsteering.  Another odd thing is between 8p last night and 3a this morning, there was one client connected and usage was 95%.  The AP had 5 channel changing events during that time.  This is an office with normal business hours so any clients that were around and connected to the wifi were an iPad or two that was sitting on someone's desk. 

Just looked at the logs for RF events and I must have something in the environment that is causing havoc.

This building has around 1000 mobile clients and I have seen some devices that need 2.4 such as the Chromecast and some contractor laptops that for some reason will only use 2.4 instead of 5.

[MilesMeraki]

Is that the only AP that is now giving your grief? If so I'd start by visiting the area of that AP and trying to locate what could be causing the interference issues by the human eye or a spectrum analyzer if you have one handy.

If it's still across the board I hate to recommend it however it may be time to perform a site survey again to ensure optimal channel selection. 

[ww]

fyi. chromecast has some problems a.t.m.   

http://bgr.com/2018/01/15/google-chromecast-home-wifi-problems-router-crashing/

https://www.theregister.co.uk/2018/01/15/router_vendors_update_firmware_to_protect_against_google_ch...

[Uberseehandel]

---

@ww wrote:

fyi. chromecast has some problems a.t.m.   

http://bgr.com/2018/01/15/google-chromecast-home-wifi-problems-router-crashing/

https://www.theregister.co.uk/2018/01/15/router_vendors_update_firmware_to_protect_against_google_ch...

---

There are, indeed, several problems with Chromecast. Best not to conflate the different issues, although the Vulture always does.

This from information supplied by Google

Which ports does Chromecast use when connecting to external services?

• HTTP:     TCP/80
• HTTPS:  TCP/443
• DNS:      UDP/53
• SNTP:    UDP/123

Which ports are used by Chromecast to communicate with computer/phone/tablet in the same network?

• SSDP:   UDP/1900/multicast
• mDNS:  UDP/5353/multicast
•              TCP/8008
•              TCP/8009

In my experience, when using a L2 switch (MS220-8P) that has IGMPv3 enabled, and an MR32 WAP, connecting from a smartphone via the WAP to a wired Chromecast capable device on the same VLAN and the same physical switch, there are no issues, it works fine.

However, at present, if the Chromecast devices are on a different VLAN, they do not function, despite explicity granting the required permissions for the VLANs to access devices on the other VLAN. At present the MX devices do not handle multicast packets properly and an IGMP proxy cannot be configured, which may prevent Chromecast packets traversing the MX.

Long term, all "smart" devices should be placed on their own VLAN(s), as their manufacturers are not particularly security aware and they are vulnerable. So we have to find a way of overcoming this particular issue sooner rather than later.

[ww]

The articles are about how chromecast has a bug that produces lots of packets and can lock up your network. probably also produce high utilization now and then.

[EClap5]

Thanks for all of the info on the Chromecasts.  I sent those links over to our Wireless Support Team for awareness.  I have a few in the environment but have a hard time tracking them down in my client list. 

I am still trying to learn more about RF properties and behaviors so maybe someone else knows the answer.  When I reboot an AP with a high usage channel, the channel usage then drops down to 1-2% upon reboot.  When an AP reboots, what would cause the channel utilization to drop to almost nothing? One AP in question was not serving any clients when I noticed the high utilization and then rebooted.  In layman's terms it sees like something was 'stuck' but I am sure there is more to it than that.

[ww]

Dit it come back online on the same channel? 

[EClap5]

Sorry @ww I should have included that in my post. Yes this AP came back up on the same channel.  Right now the AP is serving 0 clients on 2.4.  In the RF tab on the AP page, I have 4 events since the reboot and they are all to decrease transmit power on the 2.4 radio.  It looks like in the past 2 hours, max utilization is 9.3% with 1.7% of that being non-802.11 interference. 

[Uberseehandel]

At the moment, I have both Zigbee and Bluetooth issues. These are quite tough to isolate. It would be a big plus if we could see this activity from the WAP.

[EClap5]

It seems that a third of our APs in this building were pinned to an old firmware case.  I had no idea and was never told these particular APs were ever pinned as part of the case.  Anyways, once these APs were updated to my current MR24.12 firmware and then the stable candidate MR25.9 early Saturday morning, any AP/client floods have disappeared.  It's also worth mentioning that the high utilization/jammed channels that I was also experiencing in another building on the same campus have also disappeared as well.