Meraki

Community

Trouble with Wireless Connections from MR33

jscott
Here to help
‎Mar 15 2019 8:23 AM
‎Mar 15 2019 8:23 AM

Trouble with Wireless Connections from MR33

We have a location with a single AP (MR33). There is only a couple clients connecting to this AP during the week. We have recently had tickets where users are unable to connect to the corporate SSID. I swapped out for another spare AP 2 weeks ago and we have reports of the same issues. Below are some logs. I am new to the Meraki world so I am not sure how normal this is. This cycle starts at 8:01am and just continues over and over until 9:27am the same day. Is this normal logs for clients? This is not the only device this happens to at this particular location there are others. But these devices are fine at other locations with the same SSID settings and AP settings. 

 

Mar 14 08:03:24GVLAP007802.1X deauthentication
radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35  more »
Mar 14 08:03:21

GVLAP007

802.11 association
channel: 6, rssi: 5
Mar 14 08:03:05GVLAP007802.11 association
channel: 64, rssi: 33
Mar 14 08:03:05GVLAP007802.11 disassociation
unspecified reason
Mar 14 08:02:52GVLAP007802.11 association
channel: 64, rssi: 34
Mar 14 08:02:51GVLAP007802.11 disassociation
unknown reason
Mar 14 08:02:51GVLAP007802.1X deauthentication
radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35  more »
Mar 14 08:02:33GVLAP007802.11 association
channel: 64, rssi: 31
Mar 14 08:02:33GVLAP007802.11 disassociation
unknown reason
Mar 14 08:02:33GVLAP007802.1X deauthentication
radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35  more »
Mar 14 08:02:15GVLAP007802.11 association
channel: 64, rssi: 30
Mar 14 08:02:15GVLAP007802.11 disassociation
unknown reason
Mar 14 08:02:15GVLAP007802.1X deauthentication
radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35  more »
Mar 14 08:01:57GVLAP007802.11 association
channel: 64, rssi: 35
Mar 14 08:01:57GVLAP007802.11 disassociation
unknown reason
Mar 14 08:01:56GVLAP007802.1X deauthentication
radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35  more »
Mar 14 08:01:38GVLAP007802.1X deauthentication
radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35  more »
Mar 14 08:01:38GVLAP007802.11 association
channel: 64, rssi: 33
0 Kudos
11 Replies 11
NolanHerring
Kind of a big deal
‎Mar 15 2019 8:35 AM
‎Mar 15 2019 8:35 AM

What firmware is the AP running? (use 25.13).

Also if you have Intel NICs on the laptops I would update to 20.120.x.x package.

The deauthentication messages would be the ones to concern me, the rest are normal.

What is acting as your radius server?
Nolan Herring | nolanwifi.com
TwitterLinkedIn
0 Kudos
In response to NolanHerring
jscott
Here to help
‎Mar 15 2019 8:52 AM
‎Mar 15 2019 8:52 AM

Firmware on the AP is 25.13 currently up to date. 

 

Yes these are intel NICs but this is only happening on this particular AP. If it was a NIC issue on the laptop it should be happening at other locations in our enterprise. 

 

Our radius server is a 2012r2 server. 

 

0 Kudos
In response to NolanHerring
jscott
Here to help
‎Mar 15 2019 8:58 AM
‎Mar 15 2019 8:58 AM

You can see for today it's happened many times already. But when this device goes back to where it normally resides it does not happen. SWDAP01 is the AP in questions with device GVLAP007. You can see "deauthentication" around the enterprise is very minimal for other APs. 

 

3/15/2019 10:44RCKAP02FFG_CORPNWBTAB01802.1X deauthentication"radio: 1, vap: 2, client_mac: 98:5F:D3:54:A8:F4"
3/15/2019 8:32PHPAP01FFG_CORPNWBTAB041802.1X deauthentication"radio: 0, vap: 2, client_mac: F0:6E:0B:CF:95:DA"
3/15/2019 8:30SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:30SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:28SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:28SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:27SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:27SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:27SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:27SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:26SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:26SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:26SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:24SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:24SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:23SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:23SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:23SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:23SBHAP01FFG_CORPSBHLAP008802.1X deauthentication"radio: 1, vap: 2, client_mac: 7C:5C:F8:A6:ED:43"
3/15/2019 8:23SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:22SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:22SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:21SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:21LSTAP01FFG_CORPSBHLAP009802.1X deauthentication"radio: 0, vap: 2, client_mac: 80:00:0B:B7:AB:FB"
3/15/2019 8:20SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:20SWDAP01FFG_CORPFFGLAP040802.1X deauthentication"radio: 1, vap: 2, client_mac: 2C:6F:C9:03:88:F9"
3/15/2019 8:20SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:19SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:19SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
3/15/2019 8:19SWDAP01FFG_CORPGVLAP007802.1X deauthentication"radio: 1, vap: 2, client_mac: E4:42:A6:D3:92:35"
0 Kudos
In response to jscott
jscott
Here to help
‎Mar 15 2019 9:19 AM
‎Mar 15 2019 9:19 AM

Also this happens with pretty much any device that tries to connect to this AP. 

0 Kudos
In response to jscott
PhilipDAth
Kind of a big deal
Kind of a big deal
‎Mar 15 2019 12:39 PM
‎Mar 15 2019 12:39 PM

To me this is showing clients authenticating/deauthenicating.  Are you using WPA2-Enterprise mode?  If so, is this AP correctly configured in the RADIUS server?  Is the RADIUS server showing any logs?

 

You should take a look at Wireless/Wireless Health and see what it reports.

 

It is possible you are being attacked and someone is sending de-auth frames.  Check out Wireless/Air Marshall.  You don't want to see any Rouge SSIDs, spoofs or malicious broadcasts.

0 Kudos
In response to PhilipDAth
PhilipDAth
Kind of a big deal
Kind of a big deal
‎Mar 15 2019 12:40 PM
‎Mar 15 2019 12:40 PM

Also is the MR33 being powered by a 30W 802.3at switch, an 802.3at power injector or a power cube?

 

If you are only using 802.3af they can retard their performance.  If you go Wireless/Access Points it will report its power source.

0 Kudos
In response to PhilipDAth
jscott
Here to help
‎May 8 2019 8:09 AM
‎May 8 2019 8:09 AM

Hi I am still having this issue. Some more testing I have done and logs I have seen. 

 

From our RADIUS server I noticed while a client had been having issues connecting to this trouble AP, there was an event generated.

 

Event 13, NPS

A RADIUS message was received from the invalid RADIUS client IP address 172.x.x.x. 

 

After searching this event, it notes that the client in NPS may be using a hostname instead of IP. It was not, we set the Meraki APs all in NPS with their IP address. The IP is correct. I decided to completely remove from NPS and re-add. Today I am again having trouble with clients connecting to this AP. 

 

3 of the last 5 requests did not receive responses.
Req. ID Client MAC Server IP Request type Response type RTT (ms) Ago (s)
1639c:30:5b:26:0c:17x.x.x.xAccess Request––393
1649c:30:5b:26:0c:17x.x.x.xAccess RequestAccess Challenge30364
1659c:30:5b:26:0c:17x.x.x.xAccess Request––364
1669c:30:5b:26:0c:17x.x.x.xAccess RequestAccess Challenge30346
1679c:30:5b:26:0c:17x.x.x.xAccess Request––346

 

This is intermittent. Yesterday this same laptop could not get connected. I rebooted the AP several times and made the changes in NPS and nothing worked. Today it is happening again, but I have one laptop that was connected successfully after 20 minutes of trying.

 

0 Kudos
In response to jscott
ISTeam
New here
‎Jun 5 2019 2:48 PM
‎Jun 5 2019 2:48 PM

jscott,

 

Did you resolve this?  We are standing up a new site today and see the exact same issue.  15 other offices work just fine.

0 Kudos
In response to PhilipDAth
jscott
Here to help
‎Mar 15 2019 2:23 PM
‎Mar 15 2019 2:23 PM

There are no logs from the RADIUS server except positive logs, where I can see audits for successful RADIUS requests from this particular laptop during this particular time frame I posted. 

 

Yes we are using WPA2-Enterprise mode. 

 

There are no rogue SSIDs reported in Wireless>Air Marshal for the last week. There are no Spoofs or Malicious Broadcasts reported for the last week. I work for several different banks. We take security very seriously. I would have known about anything like this ahead of time and/or been alerted already. 

 

Power for the AP is PoE 802.3af. It is plugged directly into a brand new Cisco 2960-L switch. The issues were happening before that though when it was using a PoE injector to get power. It has not changed since removing that. 

 

 

 

 

0 Kudos
In response to jscott
jscott
Here to help
‎Mar 20 2019 7:34 AM
‎Mar 20 2019 7:34 AM

Another note, this particular AP is not mounted on a ceiling. It is sitting on a shelf. 

In response to jscott
jscott
Here to help
‎Mar 27 2019 1:15 PM
‎Mar 27 2019 1:15 PM

Anybody have any other thoughts?

0 Kudos
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels
© 2024 Cisco Systems, Inc.