Android authentication errors

[Tigers]

My work place now has a major issue with Android phones not authenticating

We get at least 6 of these message per work day. 

From the reports I get it is only Android handsets that fail to connect to the SSID. Laptops (HP), iPads, iPhones are so rarely complained about that I tell them to try again and it works.

I have 2 Android phones (mine - Galaxy A8 and work supplied - Galaxy A31) that so rarely connect I have turned off the auto connect as the response is so poor otherwise. [Though to make  a liar of me my A31 connected this morning as I was composing this message]. I have been here since April 2020 and the Androids have always had problems.

The vast majority of work phones are Samsung Galaxies.

I looked at other threads and nothing like our problem leapt out at me.

I have attached the configuration of my A8 & A31.

The A8 config-1 screen showing "Internet may not be available" is the most common screen response.

(There is text in between the last and 2nd last pictures. For some reason I cannot add text after the pictures.)

A8 config-1A8 config-2A8 config-3A31 config-1A31 config-2

I added these pictures in case I have made a glaring config error with my devices that might be solvable with mine and other handsets.

The question i have is what do I do next to resolve these authentication errors? What can the portal tell or not tell me? Both devices are getting an IP address in the same range.

A3 config-3

[CFStevens]

Hi @Tigers, 

I would advise reviewing the client connectivity logs for a given client (Network-wide > Monitor > Clients) in case there are any obvious red flags that we can troubleshoot. After this, I would give the Meraki support team a call while you have someone on site who can reproduce the issue. I would budget 30-60 minutes to troubleshoot this issue. The Meraki NSE will need the MAC address, SSID, and a brief description of what is happening to the end clients. It would certainly be worth mentioning that this is only affecting Android devices. If you have a running history of when the issue happened (maybe after a specific update?) that would also be useful information. After that, working with them to reproduce the issue while we review will be best.