Hi Everyone and a very happy Monday to you,
Just wanted to let this group know that we've just rolled out Wireless Health globally to all wireless customers. You can find details on our blog here: https://meraki.cisco.com/blog/2018/05/meraki-wireless-health-now-available/.
We'd love to get your thoughts and feedback as we continue to iterate on this cool new tool, so please leave a comment here, make a wish within dashboard, or use the link in the blog post.
Thanks I've started using it and I am enjoying it so far 🙂
Thanks for updating. I see that our org has this feature now available. How is this feature update supported with older access point models?
What model APs are you thinking of, in particular? And are you concerned with the ability of the APs to run the new firmware, with technical support for Wireless Health, or something else?
Generally, we've rolled out WH to all existing wireless customers — since you can see the tool in your dashboard, you should be able to use it and access it without any issues (with the usual caveat that Wireless Health is still in beta).
Thanks for your reply.
My question was just a general type of inquiry regarding partners and customers running typically MR18, MR32.
Our 1st line team are very happy with this as they can now easily tell when Layer 8 errors occur and pass them back to the service desk for user reboots.
@Adooslike most people in this thread, I haven't heard of any issues. One other thing I have noticed is that my 'failed connections' are filled with mobile devices and not laptops. This would support our thinking that the issues are just when a client authenticates on one AP but is moving and completes authentication on a different AP. An iPhone or iPad is more likely to be moving as authentication takes place as opposed to a laptop that is more than likely sitting on a table in a conference room.
Yep @EClap5 I found that after reading the thread and having a poke around the dashboard. Certainly handy seeing the auth issues. iPhones love to try and connect to wireless networks it seems.
Can someone help with the usage? I can see the devices that fail authentication but there's no reason they should be failing, or at least the ones I know of have been online multiple times over the last day.
Here's a snip of the results, should I be concerned of this issue?
|Tue May 22, 2018, 13:08:20||DESKTOP-HMVDC4C||G Building||LHSStudent||Authentication||type='WPA-PSK auth fail' associated='false' radio='1' vap='0'|
|Status:||associated since May 22 13:09|
Active Directory splash (revoke)
Authorized 6 days ago. Expires in 24 days.
|User:||***************** (sign-on splash)|
|Device type:||Microsoft Windows 10|
|Capabilities:||802.11ac - 2.4 and 5 GHz details »|
|IPv6 address (link-local):||fe80:0:0:0:6838:5ad1:1b81:783d|
Spoke to some folks here and turns out we sometimes see errors like this when there is a PSK + AD Splash SSID enabled, and a roaming client starts its association on one AP, but walks away and causes the EAPOL handshake to time out. We end up logging it as a failure from the AP, but once the client settles down they successfully connect.
If this doesn't seem likely as your use case, it might be worth reaching out to Support — there may be some other underlying issue.
@Emily- I seem to have a ton of PSK auth fails with one of our SSIDs that we use for work devices, which all have a wifi profile pushed down from the Meraki MDM. With the wifi profile on the device, I would think most authentication issues would be moot since the device connects automatically without user intervention.
Is there something like what you mentioned for AD + splash networks that might be the culprit in my case? In my largest network, I see about 3800 authentication issues with this particular SSID.
@EClap5 I'm seeing something similar.
Our laptops have the SSID and PSK preconfigured so the user does not even type it in.
I see "WPA-PSK auth fail" and when I investigate, the device is actually connected and the user is not noticing a problem.
It has been noted that users moving between APs when 802.11X is in use will create failures as authentication doesn't complete before the user has roamed to another AP.
At home I get failures on when regular WPA2, but that's my APs are too close together and a couple of specific devices are switching between the APs (those devices which insist on sticking to their original AP don't error.)
Yes I would separate my APs except my wife already complains about the mostly hidden cat5 cable
Just like to share that I have presented this feature to our main customer (store chain) and we're both please with it.
So far, it as been a great tool to quickly pin-point the problem that affect specific users.
Before that, it took some time to cross information from different sources in order to prove those specific clients that the problem wasn't "the wifi sucks!"
Good job, guys!
Especially with the facility to view stats between two specified dates/times.
It's not unusual for us to get a fault raised for a perceived issue from a quite some time earlier (two weeks plus is not uncommon.)
After using the wireless health yesterday to attempt to resolve a latency issue - I would like to suggest that there be further information available in the Wireless Health - Packet Latency tab.
Seeing the average latency per AP is nice, but doesn't provide enough information to do much with. Similarly with the device types, and especially when the AP shows a high average latency, but the device types doesn't come anywhere near that value (where did the missing latency go?).
I would like it if I could choose an AP from the Packet Latency page, and be shown more information about the specific clients that are contributing to the displayed average.
Looking at the Wireless Health area for failed connections, I am seeing a lot of 802.1X auth fail with different num_eap='xx' values, is there a way to find out what these values represent, have done a google search and it does not show much on it? do they represent the type of error they user is getting or the number of times they have tried to connect with a problem?
It is a good initial trouble shooting tool for when users complain about wireless problems.