ā01-22-2021 05:33 PM
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?
ā03-26-2021 07:58 PM
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.
ā03-26-2021 07:58 PM
I assume you mean radio profile because MU-MIMO is only set on the radio profile. I can give that a shot.
ā03-26-2021 07:56 PM
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
ā03-26-2021 07:54 PM
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.
ā03-26-2021 07:39 PM
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.