Devices not authenticating to SSID

[jctech2025]

Hi All,

I'm new to the community and I wanted to reach out about an issue I recently had.  I'm hoping I have the right place.  One of our clients has a location where they primarily connect using wifi.  Recently they raised an issue where when they were in a certain location, the newly deployed iPhones would loose connection after about 30 minutes.  I walked through the building and tested connection using my MacBook as well as one of the iPhones.  Never lost wifi connection.

I then took the iPhone and placed it near the AP in question.  I checked logging in the Meraki dashboard and found that the AP was broadcasting the SSID however every time the client would try to associate there would be disauthentication packets in the logs.  I rebooted the AP and after that the iPhones started to associate with the AP.

Anyone seen this where the SSID is broadcasting but authentication throws this in logs?  All other SSID's being broadcasted and authenticated fine.

[alemabrahao]

This is very relative, what is the AP model and firmware version? What type of authentication is used?

Are 802.11r and 802.11w enabled?

How is the minimum bitrate configuration?

[jctech2025]

Hi, 

Model: MR32

Firmware: 26.8.3

Authentication is PSK

I'm not able to find the bitrate, where would I see that in the dashboard?  Thanks

[alemabrahao]

Well, reading your description better, I would recommend you to open a support case. There are some known issues and bugs in this version, but I don't see any relation to your case.

 

Important notice

• This upgrade (and the security fixes contained within) is only applicable to the MR12, MR16, MR18, MR24, MR26, MR32, MR34, MR62, MR66, and MR72 access points. Any other models configured to upgrade to this version will operate on MR 26.8.1.

Security fixes

• CVE-2020-24588 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-24587 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-24586 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26145 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26144 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26140 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26143 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26139 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26146 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26147 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)
• CVE-2020-26142 - https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-wifi-faf-22epcEWu (Wi-Fi 4 MRs/Wi-Fi 5 Wave 1 MRs)

Known issues

• Downstream VOIP RTP Packet Loss (MR42/MR42E/MR52/MR53/MR53E/MR84)
• Sporadic packet loss & instability on Layer 3 roaming & Teleworker VPN SSID's (All MRs)
• Reduced aggregate upload throughput on 2.4GHz radio for Windows clients (Wi-Fi 6 MRs)
• EAPOL Key 3 is not sent from AP in the CE regulatory domain to 802.11b/g clients on PSK SSIDs (Wi-Fi 6 MRs)

[jctech2025]

I looked at what you provided and I'll keep this in mind.  All the APs in the building are the same model.  I don't recall seeing this activity with an ap before.  I was hoping there would be more details in the logs on why the authentication failed for only one ssid. Any thoughts there?

[alemabrahao]

Yes, I suggest you open a support case.

[jctech2025]

Alright, is there a place to open a case through the community or would I have to go another route?

[CFStevens]

Hey @jctech2025 ,

As suggested, it would be worth opening a support case with Meraki while someone is on-site and can reproduce the issue. You can open a support case through the Dashboard by navigating to the top right "?" icon. Select it, then select Get help > Still need help? > Submit a case. 

It would be worth reviewing your client logs while we can reproduce the issue, and possibly reviewing your RF profiles considering  the issue goes away on reboot. However, you are running an older firmware version which might be at play as well. 

[jctech2025]

Hi,

Thanks for the update about where to submit the case.  The interesting thing is the issue has not happened since I rebooted the AP.  To the older firmware, yeah they are trying to make things as inexpensive as possible.  As far as client logs, where would I see those?  The only logs I know how to see are the overall event logs for the aps themselves.

[CFStevens]

Hey @jctech2025 

I completely understand (the want for cost savings, as well as the issue never happening when you need it do 😛 ). 

Your firmware version unfortunately isn't going to show the logs we will need to better understand the client roaming behavior, however, Meraki NSE's will likely be able to review back-end logs to help piece together whatever is happening. 

[jctech2025]

Ah, alright so the firmware version is a limitation.  So you're a Meraki person eh?  If I was to submit a case what information would I add as the issue is not currently happening?

[CFStevens]

Hey @jctech2025 ,

I am indeed a Meraki person!

It would likely be better to give us a call than to open a ticket. However, we could take down as many details about the event as possible and hide the case until you call in at a later time. In that instance, we would likely want to know the following at a minimum:

Date issue happened:

Time issue happened:

MAC address or Hostname of client:

SSID name:

Network name:

Brief description about the behavior as seen from the client's perspective:

What seems to resolve the issue (if any):

What changed around that time (regardless if it seems relevant at the present time):

However, if I was in your shoes, I would advise whoever is on site to immediately call the Meraki Support team when the issue happens again. I would set aside 20 to 40 minutes out of their day to troubleshoot. We would want the same info as above, but we would also want to have the Meraki NSEs review logs, review configurations, and possibly pull packet captures while the test client on site tries to reproduce the issue. 

[jctech2025]

I am just now seeing your post 🤣, cool you're a Meraki person, even better!  I am signing off for the day.  I'm in PST zone, I'll look at your post when I am back online tomorrow.  Thanks again!

[jctech2025]

I am the dedicated IT person for the company.  I would be fine to have a call with the Meraki team when the issue happens again.  It's a weird scenario in that it was only one SSID that wasn't being broadcasted at the time.  I know the specific AP that it happened with and if it does come up again even with another AP I'll for sure reach out.

Another bit of curiosity though, if the current AP doesn't provide extensive logging due to the version of the firmware, and my assumption is that the AP sends logging traffic to the NSE?, how are you able to see more extensive logging than that on my end?  Curiosity there.

[CFStevens]

Hey @jctech2025, 

Yes, please give us a call once it happens again and we would be happy to assist. 

As for the logging, we don't actually have the extensive logging either, but a Meraki NSE may be able to better interpret the logs they do have available in a more meaningful way.