Problem with wireless network - authentication, disassociation, deauthenticatio, radius timeout.....

[GoranP]

Hello,

We have a problem with our wifi network for about a month. Users get randomly disconnected and sometimes is needed more than 10 times to rejoin the network.

We are using as security settings "enterprise with google" and authenticate to the SSID with google email and created app password.

Usually we encounter this tape of error: 

 We do not have radius server and have ipv6 bridging disabled in Meraki options. What is that address that standing here as a address of a radius server ??? I try to ping that address from any AP and its responsive.

From the event log we usually get something like this:

 

I will upload screenshot of my configuration here and i will gladly add more if it is needed.

Access Control:

   

 

     

      

RF Spectrum:

Radio Settings:

   

If anyone has any suggestions or has experienced a similar problem, I would appreciate help. Also, if additional information is needed, I'm here.

Thanks in advance for your time.

[alemabrahao]

Generally hiding SSID is not recommended.

WLANs can operate "hiding" the SSID name, and only answer when a probe request has the explicit SSID included (client knows the name). By default, the SSID is included in the beacons, and APs will reply to null probe requests, providing the SSID name information, even if clients are not pre-configured with it.

Hiding the SSID does not provide additional security, as it is always possible to obtain the SSID name by doing simple attacks, and it has secondary side effects, such as slower association for some client types (for example Apple IOS), or some clients can't work reliably at all in this mode. The only benefit is that it would prevent random association requests from devices trying to connect to it.

It is recommended to enable Broadcast SSID option to have the best interoperability.

[GoranP]

Thanx for the reply,

Our security policy request that we have hidden SSID. Wireless configuration are deployed to the Win and Mac Clients via MDM polices. So the user just need to connect to the wifi already configured and enter app pass.

We also have guest wifi that is not hidden and with security settings configured as "enterprise with Meraki cloud authentication" and we get the exactly same errors.

[alemabrahao]

Also, perform a test disabling 802.11w, disabling Band steering, changing channel Width for manual, and setting It to 40Mhz.

Some legacy devices that do not support 802.11w may not be able to connect to an SSID even if in mixed mode. This may be due to the device improperly handling the advertised information contained within the beacons.

In a high-density environment, a channel width of 20 MHz is a common recommendation to reduce the
number of access points using the same channel.

In certain cases, having dedicated SSID for each band is also recommended to better manage client distribution across bands and also removes the possibility of any compatibility issues that may arise.

Band steering does not work with all clients.

"If certain wireless clients are unable to detect the wireless network they may be using passive scanning. In these cases configure the network to use Dual band operation, not Dual band operation with Band Steering."

[PhilipDAth]

If the issies are most with Windows machines, I would also check for an updated WiFi NIC driver.

Perhaps Windows Update installed a problematic version a month ago.

[GoranP]

Hello,

Yesterday i disabled 802.11w and Band steering and changed to 40Mhz. I will also check NIC driver and wait to see how its going to be today.

Does anybody know what is address of a radius server from the first screenshot ?  

[alemabrahao]

I have no idea.

[GoranP]

I get response about that address from support and they think address is from google radius.

But i got the same error with the same ip address from another guest SSID configured as "enterprise with Meraki cloud authentication".

[GoranP · Accepted solution]

Hello,

For anyone who experience the similar problems, we get the response from Meraki support that this particular IP address is a server address used in Meraki cloud that relays any authentication request. We need to see why the response time is bad.

Next step is to take packet capture and to send it to the support.

Thanx to everyone who read this and tried to help us 🙂