Question

Problems with old WLAN Clients after changing the WLAN infrastructure



Show first post

31 replies

Userlevel 5

Hi Florian,

Here is my response to your questions. 

so i got news from the employees of the plant today. I configured two of the forklifts into the “stapler” ssid with 5 Ghz turned off and set all the settings you suggested. It seems like one of the forklifts isn’t able to be used now anymore (worked after i configured it to the ssid and waited about 20 mins) and the other one is also experiencing way more disconnects than before. I am trying to get some better answers from the employees.

(Ovais) When you enabled the Staples SSID on 2.4GHz, did you either disable or moved other SSIDs to 5GHz at that time? if not, then based on the utilization stats that I mentioned in my previous post, enabling Staples SSID on 2.4GHz while other SSIDs were also broadcasted in 2.4GHz band won’t make any difference. We want to reduce the utilization on 2.4GHz, and the only way to do it is to reduce th eno. of SSIDs on it, because you already have 16 APs per channel in 2.4GHz spectrum. 

Is this somehow bugged or do i missunderstand something in this view? Why did it not use any of the 2,4 Ghz channels?

(Ovais) From the screenshots, looks like the clients were still connecting to 5GHz. Make sure when you disabled SSID on the 5GHz radio and updated the configuration on the APs, they actually took it. You can verify that by selecting an AP Actions>Advanced>CLI Access then use the command “show interface”, this will show you the SSID mapping on the AP radios. Use it to verify that APs are still not broadcasting Staples SSID in 5GHz, if they are, then you probably need to push a “Full Configuration update” instead of “Delta update”, which will cause APs to reboot. 

 

What happened exactly in the red marked and other times? It seems the client is connected to the ap but doesnt show any dbm or usage. I got these on every terminal throughout the day. And of course the error messages about “wron static ip or default gateway”

(Ovais) This to me looks like the same utilization issue that I had explained earlier, the same channel is being used by many APs and the mgmt. overhead traffic increases so much that the clients do not get a transmit opportunity. This was seen in the .pcap files you shared as well.  

 

There’s also a really high amount of “station is deauthenticated from thru SSID” messages. How do i interpret them correctly?

 

One of the causes could be interference, but I'd like to get detailed messages on the rejection. Could you SSH into the AP you are testing on and run the following commands?

_debug auth basic

_debug auth verbose

Then try to connect to this AP a couple more times to replicate the issue. Once that is done, please collect tech data and send that to me. Feel free to email it directly to me at mqayyum@extremenetworks.com.

To collect tech data, go to Tools> Utilities> Get tech data> Check the box next to the device> Get tech data (blue button at the top of the page this time).

 

Regards,

Ovais  

Hello Orvais,

 

thanks for your response. The Problem here is that it’s difficult from my point of view to make changes to the main SSID (PPSK). The employees there are already exasperated by the situation, if changes make it worse, it grows. I think you know what i mean.

 

I disabled 5 Ghz in the SSID settings of the policy and checked it via show int. The ssid is not broadcasted on 5 Ghz. I did not make any changes to the other SSIDs:

I see that many of our mobile devices are also in 2.4 Ghz. But they are spread across the plant. 

So the only way to decrease the utilization would be to make room in the 2,4 Ghz for the terminals? I could try to disable it on MDM and 802.1x - but that would probably cause some issues with the mobile devices and notebooks at the plant.  

I will send you the tech data to the e-mail. I am on holidays next week so dont wonder if i i am not responding.

 

Thanks so much again for your assistance!

Userlevel 5

Hi Florian,

The tech dump shows data that points to CCI, you have to address co-channel interference in the network. See following.


2021-03-22 13:31:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 13:25:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 13:00:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 12:36:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 11:01:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 10:46:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 10:24:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 10:19:48 err     ah_dcd: wifi1: A high interference alert was raised.
2021-03-22 09:37:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 09:06:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 08:56:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 08:34:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 08:27:48 err     ah_dcd: wifi1: A high interference alert was raised.
2021-03-22 08:25:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 08:09:48 err     ah_dcd: wifi1: A high interference alert was raised.
2021-03-22 08:06:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 07:57:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 07:40:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 07:34:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 07:01:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 06:52:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 06:20:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 06:12:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 05:52:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 05:13:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 04:59:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 02:28:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 02:11:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 02:00:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 01:50:48 err     ah_dcd: wifi0: A high interference alert was raised.
2021-03-22 01:44:48 err     ah_dcd: wifi0: A high interference alert was raised.

Remove non-wireless VLANs off the APs switch ports, you've got an mDNS storm being spread to the wireless network from the wired network.

In addition, you can now also disable Weak SNR suppression and Safety Net in the radio profiles.

 

Regards,

Ovais

 

 

Hello Orvais,

could the full water boxes alsocause the interferences? 

 

And i am only using WLAN VLANs on the Switch Ports. We segmented our client vlans pretty broad to get every client department covered (logistics, production, IT, office, etc.). So we got around 35 client VLANs. Currently on the switch port there are 39 VLANs configured. We got this configured on all our plants and the others do not seem to cause so much trouble (Hivemanager Classic).

 

I will try to get Weak SNR and Safety Net disabled. Could I try something else to get this solved? 

 

Thanks in advance. :)

 

Userlevel 5

Hi Florian,

Water blocks radio waves in general; it happens to be particularly good at absorbing radio waves near 2.4 GHz frequency. If you have shelves full of water bottles/boxes, they would cause signal loss but NOT Co-Channel Interference (CCI).

In Co-Channel Interference, APs on the same channel will hear each other and defer. For example, if AP-1 on channel 6 hears the preamble transmission of a nearby AP-2, also transmitting on channel 6, AP-1 will defer and cannot transmit at the same time. Likewise, all the clients associated to AP-1 must also defer transmission if they hear the preamble transmission of AP-2. All these deferrals create medium contention overhead and consume valuable airtime because you have two basic service sets on the same channel that can hear each other.

 

Co-Channel interfence can’t be completely avoided but it can be managed with a proper WiFi design.

1- In some cases, you can move SSIDs away from 2.4GHz to 5GHz, 5GHz will provide a lot more channels and there will be a lot less chance of CCI.    

2- In other cases, turning off 2.4GHz radios on some APs help. If the coverage is good, turning some 2.4GHz radios off on the APs will help reduce CCI. Before this is done, a proper site survey should be conducted to detrmine which 2.4GHz radios can be turned off to avoid converage holes.  

3- Another major cause of CCI is the WiFI clients themeselves, more importantly the ones always on the move, but this can’t be avoided in your environment.  

I would recommend you to contact the system integrator and ask them to perform a WiFi survey to determine the best way of reducing CCI in your network. They might need to change some AP placements/reduce the no. of 2.4GHz radios/implement a better channel plan etc. But there is a way to manage the CCI.

Let us know if you need further assistance.

Regards,

Ovais    

Hello Orvais,

 

we will contact our serice partner next week and let them do a proper analysis of the situation and hopefuly get to fix this.

 

Something i noticed today after i installed v10.3.1 and disabled Weak SNR Supression / Safety Net, the aps seemed to choose their channels pretty bad:

I instantly got a high amount of Channel Interference messages in XIQ. But why are they doing this? I thought there would be some sort of automation which prevends such bad channel selection. Or is this the “normal case” after doing a reboot on all aps? Never noticed this before. 

 

Edit: never mind. They now set their channels much better. Guess they need their time to check neighbors, etc.

Reply