10.2r4 firmware causing AP650's to lose connectivity?

[KevinP1]

Okay, I don’t know what’s happening here but this isn’t looking pretty. All of our AP650’s are losing connectivity multiple times throughout the day. 

Look at this! Some AP’s will only do this once or twice and others are doing it often, like this ? There’s nothing indicating any type of error or issue. We didn’t have this problem on firmware 10.09rb.

I have a case open with GTAC, but are we the only ones seeing this issue?

[jose_gonzalez]

I only use beam forming outdoors on 5ghz.  My clients are campus like with 17,000+ APs, mostly in HiveManager (seems impossible to manage large amounts of APs in XIQ right now). I urge all clients to 5ghz.  I have safety net disabled and weak SNR enabled, 19db for 1-to-1 areas, 10db otherwise. Settings designed to optimize performance in a high-density WLAN enabled and the lowest allowed radio rate is 18Mbps.  This is all designed to keep clients from making dumb decisions and connecting / sticking to far away access points.  This recipe greatly reduced the amount of ‘low wifi signal’ tickets.  At Any time of day, if I pick a random AP and watch the ‘show log buffer’ - not a minute goes by without several messages ‘client denied access due to weak SNR’.

In addition I only allow APs to update each other via the backhaul (layer 2), instead of the default over the air and backhaul, and reduced the beacon frames to 200TUs.  Inter-station wireless traffic is disabled.  All this to free up the airtime for actual client traffic.

As expected, this means any network printer, TV connected device, must be wired.  Any supported MDNS (bonjour) discoverable devices must be wired.  MDNS routing is handled by the switches.  No dinky Internet-of-things devices, everything must be Enterprise.

[dstarkman]

I assume you mean radio profile because MU-MIMO is only set on the radio profile. I can give that a shot.

[KevinP1]

@dstarkman 

In your device template, just for testing purposes, disable MU-MIMO; I see that it’s active.

This command should provide you with info on why the clients weren’t connecting:

show client-monitor info

[dstarkman]

@kevin.piazza 

I have the device power set at auto and I guess because I’m using 48 it sets the power at max 17. WiFi adapters are set to default so they are powering I guess however they are powering I’m guessing it’s just set to auto. The only thing I changed after the first time is I went into the driver and set the power mode not to sleep just in case but it didn’t do anything because the fact that I’m running the Windows 10 laptop in its power mode and no sleep is keeping everything running anyway. 

The AP is literally 30 feet from the laptops. Believe it or not as you can see from the photo they don’t drop since they have been connected for 140 hours. It’s not fast but it works. 

I would love to be able to switch to 10.3.1 but if I can’t get newer laptops to connect to the AP and stay connected I’m scared like hell to get 7 year old forklift mounted radios and voice picking headsets to stay connected and those are the device where if they don’t work they question my worth to the company even if I’ve been here for 20 years. 

[KevinP1]

@dstarkman Those SNRs are beautiful, LOL! I could see those devices dropping, based on what I’ve experienced; I those two devices above your two test clients . I know that on 10.3r1, from what you were saying, the clients would keep dropping, it’s possible, 100% assumption here, that something has changed in the firmware. The SDK in 10.3r1 is newer than previous releases, and I know a lot of things were fixed/addressed.

Where is your AP located in that room and what are the power transmission levels set at? On those devices, do you have the WiFi adapter power levels to 100% and low-medium for roaming? I’m assuming these are Windows devices.