topic General disconnection from WiFi in ExtremeWireless (WiNG)

General disconnection from WiFi

adf10 — Wed, 12 Oct 2022 19:47:21 GMT

Hello

We have a warehouse with 133 APs (mix of AP6521, AP7522 and AP7532) connected to RFS4000 controller running WiNG OS 5.9.1.10, we have 2 SSIDs active on different VLANs tunneled to the RFS4000 and sent to the core switch via physical ports.

We had an event where all the WiFi Clients from all the APs and all the SSIDs got disconnected and in about one minute or two devices start reconnecting again. I was checking the uptime and all devices (controller and Access Points) were not rebooted since all show several days uptime. Also Checked logs and I didn't see any sign of massive disconnection at the event time. None of the network (wired) devices lost connection (teams meeting, intranet sessions, etc.)

I would like to know what could have caused this massive disconnection on all the devices on the warehouse. Could you provide any hint about what can I check? I would like to know the source of it in order to avoid it happenning again.

Thank you in advance for all your help.

Alex.

Re: General disconnection from WiFi

Karol_Radosovsk — Thu, 13 Oct 2022 12:44:28 GMT

I suppose, you are using Layer 2 (MAC) adoption (MINT Level 1) together with tunelling. In such a scenario, besides all the traffic going through an RFS (bottleneck), the RFS is also doing the RF-Domain manager (it usually takes over, once it is in the same broadcast domain, even if APs are "allowed" to become rfd-mgr.) It is not recommended to use MINT links level 1 (MLCP VLAN) once there is 100 and more APs in 1 RF/broadcast domain. I would strongly recommend moving to local bridging (yes, you'd need to reconfigure all the switches' ports) and eventually also consider using Layer 3 (IP) / Mint link Level 2 adoption. Check out the corresponding passages in the WING best practices document available for download somewhere within support pages. P.S. I would also suggest groupping same-type APs into different RF-domains, if they are also physically placed within different locations/parts of the warehouse. And get rid of AP6521, this is a low-end device, not really suited for serious warehouse/enterprise operation. AP75xx are "good workhorses", they can serve for quite a time, especially given the current supply issues with newer series. (AP7522 are still available in the second-hand market). Good luck!

Re: General disconnection from WiFi

rmu — Thu, 13 Oct 2022 16:00:32 GMT

you say, all clients lost the connection. do they lost the ip connection or really the wlan association?

If all lost the wlan association, do you use tkip encryption on the ssids?

by default, if there are tkip-countermeasure errors, the wing setup blocks the bad client for a minute and kicks out all others to re-associate/authenticate.

maybe there are messages in the log for this.

also i suggest to set the time to 1h (1min is defined by the standard)

rmu

Re: General disconnection from WiFi

adf10 — Thu, 13 Oct 2022 17:29:45 GMT

Hello

Thank you for your answer, as a matter of fact we are using TKIP authentication on one of our SSIDs the other use WPA2 and we exclude WPA2-TKIP. All clients lost wlan association at the time of the issue (both SSIDs)

I searched the logs but I didn't see any signs of countermeasures, however a few days ago we changed the security key on the WPA2 SSID and on the logs I saw many disassociations due to failed key (4 way handshake timeout)

I'm not shure if this could be triggering the countermeasures or not.

However, regarding the Counter measure hold time setting. What does this setting exactly do, because when the general disconnection event took place it took about a minute (but no more than 2 minutes, actually nobody exactly know) to everybody be able to reassociate again; on PDTs it automatically reassociate but on certain Laptops it was necesary to manually reconnect to SSID

My concern is that this setting could increase the time the system takes to recover and allow the clients to reconnect again given the disconnection event takes place again (god forbid).

Thank you in advance for your help.

Best,

Alex

Re: General disconnection from WiFi

adf10 — Thu, 13 Oct 2022 17:52:37 GMT

Hello Karol,

Thank you for your answer. We are thinking on moving to local bridging and mint link level 2 but I think it will have to wait after december due to high season.

On the other hand, appreciate the advice regarding the max number of APs per RF domain. I'm aware that traditional limit was 24 but with the new firmwares I saw it accepting more and perform very well, and considering Domain manager is the RFS I felt like covered but were not aware of the recommended maximum.

We are slowly trying to get rid of AP6521 but management prefers to purchase the new models rather than getting second-hand market, even though on pandemics we were forced to get quite some, as you mention there are still important issues with the newer series supply.

Best,

Alex

Re: General disconnection from WiFi

ckelly — Mon, 17 Oct 2022 13:58:14 GMT

The RFS4000 rated for a maximum adoption of either:

144 layer-3 adopted APs operating with locally bridged WLANs (All APs are dual radio models)
36 adopted APs with WLANs operating with MiNT level-2 tunneled WLANs (Your configuration)
128 layer-2 MiNT level-1 adopted APs with locally bridged WLANs (all APs are dual radio models)
64 layer-2 MiNT level-1 adopted APs with locally bridged WLANs (mix of single and dual radio model APs)

If you do in fact have 133 APs all operating with MiNT level-2 tunneling tunneled WLANs, the controller is operating far out of spec (max of 36 APs supported) and beyond its rated and tested capability.

And just FYI, all of the hardware WiNG controllers you find will have AP adoption specs that cut the maximum AP adoption limit in half when using tunneling mode (RFS4000 is slightly different being a lesser powerful model).