Installed for test on small MR45 network.
Can confirm that problem with not reporting latency on MR45 is solved.
To be confirmed if thy solved the problem with hanging MR45 scanning radio (resulting in not shown Meraki peers in RF Spectrum and showing only foreigns on AP working channel)
Unfortunately the problem with Failed PSK / 802.1x authentications it stil there.
Storming that beach right now 😉
Thanks for the heads up!
P.S.: What a pity:
“Note: Currently, the NBAR integration on MR access points is not supported in Combined networks, nor is it supported in wireless-only networks using a mix of NBAR-compatible and non-NBAR-compatible MR devices. Additionally, networks bound to templates of any network type are not supported at the moment.“ 😕
I'm going to update to 27.1 at my home "lab" tonight fingers crossed tomorrow because a 100% uptime is expected at home 😉
Using 3 MR33 and 1 MR32 ap's I expect the mr32 to be unavailable after the upgrade.
Time for a mr46 upgrade in the living room so AX testing can also be done 😄
I liked the look of the new features, especially NBAR. However, being able to enable it only if all APs are 802.11ax and if the network is wireless only (not combined) is %$^%&"£*(
I upgraded my home MR55 and four work sites where all APs are 802.11ac wave2 or newer but won't be able to see the feature as all are combined networks. The only wirelsss only networks I have have some older APs in them 👿
"Wired clients connected to MR30H LAN ports are unable to pass unicast traffic (MR30H)" <- This is pretty bad (and yes, it is there, just verified on two different MR30H). Personally I think its pretty bad to release a software with a bug so serious for an AP where that feature is pretty much its reason for existence.
Does anyone on the inside have any info on this bug ?
How far along are they to fix it ? Because support is no help on this at all.
Not that the previous version was much better.
Strange stuff was going on there.
Two things I noted after upgrading:
@NolanHerring: makes sense. Seems like I was stuck with my current setup where I have a „specific MAC to PSK“-binding. If you take out the MAC address out of that equation, it‘s getting logical. Thanks for the heads up!
@thomasthomsen: Oh shoot, yes. You reminded me about that discussion in an ISE call. Kudos to you too!
WPA3 and iPSK does not "mix". I think they are trying for a solution (at least on the Cisco Classic side with ISE), but because of the way you do the new authentication it might not be possible (as far as I remember).
Thats properly why there is no WPA3 option there (yet, hopefully).
@Roger_Beurskens Does the MR32 show 27.1 on its own page as it somewhat confusingly shows an MR32 with 27.1 and that isn't supposed to happen...
Deployed for 5x MR52 and 1x MR84 with a successful WPA3 Personal test.
Why we cannot combine "Identity PSK without Radius" with WPA3 Personal ?
It makes sense to have the following :
- a single SSID with WPA3 in transition mode allowing WPA2 with PFM enabled
- by default devices are set to a guest vlan using Identity PSK without Radius with default password
- a different password for Identity PSK will apply another policy with a different Vlan for other users
This currently what I am doing without WPA3 and Identity PSK where default setting map the user to a guest vlan and manually I apply a different group policy to map the user into another vlan...
Small update about MR45 bug that causes scanning radio to become unoperational after some period of operation time.
With this release problem become more severe for 5GHz band - the scanning radio stops operating few hours after reboot while the 2,4Ghz still being operable.
This bug causes AP not being able to show Meraki neighbours in local status page, broadcast neighbor information to clients and scan other AP on channels different than current operational channel.
I’m actually seeing the same scanning radio behavior on MR56 — after a day or so of uptime all 5GHz neighbors disappear from the list.
Testing it on my home lab for now...
At least false authentication errors "Client entered wrong password." seem to have been resolved.
In my network the 27.1 did not solve the "bad password" problem. I'm still getting those on PSK network but also on 802.1x one as "authentication errors". (The same on 26.6.1, 26.7)
I've been with TAC on it for a long time without any clear solution. They say those are not real authentication errors but rather interpretation of events by wireless health module.
That is what TAC says, but I'm not convinced.
In my case those errors happen when clients roam (not on every single roam) - and when they happen I can see clients roaming much slower or with trouble. TAC says that the authentication errors is a outcome of bad roam not the cause.
I can see it only on iOS clients.
@NolanHerring I’ve seen it a lot on PSK SSIDs on MR33. Can’t remember since when, but after wireless health was released, I was trying to investigate the Authentication errors.
Issue was seen on a lot of clients, even those who never changed their psk password. Obviously false positives, giving misinformation in the reports.
@PawelG i don’t thing it is roaming. I’ve seen it on single AP networks with static clients.
@antonis_sp - yep, it might be disassociation/association process not roaming.
In my case - sometimes devices really pop-up a window saying that the password is wrong (PSK and 802.1x). Entering the old one always work... so I don't think that all of them are false-positives or it is just more complicated scenario.
About the graphs:
They look great. I do see spikes of latency up to 1000ms for silent clients. So I believe latency is counted for sleeping clients that sporadically wake up to receive and send packets.
About the false positives:
Yes you have alot of 'incomplete roams' where you can see low SNR and an unsuccesful authentication. Maybe they should just add a new kind of category for incomplete roams and have them optionally filtered out so it does not look so bad for a data oriented wireless network. The system should detect the client immediately probes and associates to another AP.
They are going in the right direction and I'm hoping they'll reach anything close to the detail DNA Center offers.
There for example you have the timeline but not with errors but all the events. So roaming (re-assoc), auth and 4way or less handshake and the total ms it took to do the actual roam together with the airtime, SNR, retransmit stats.
So I assume this means there will be no way to have a single template with pre and post wave2 APs if we want to keep them on the latest 26.x and 27.x firmwares?
I expect you have to leave them in an other network..
AP's in the same network run the same firmware.
With some testing at my home lab, 3 MR33's AND my mr32 are on 27.1
Enabling iPSK on my primary SSID makes my MR32 unusable.
It does transmit the SSID but no authentication is possible.
Networks aren't really my issue. Surprisingly I only have 1 network that has a mix of pre and post wave2 APs. I have a mix of pre and post wave2 branch networks which I just recently consolidated into a single combined template though. There seems to be no way to set different firmwares for templated networks. Not sure if Meraki will add a per network firmware override option for templated networks. It is a bit annoying as some of these devices still have 4+ years of support left.
So now that any Wave1 (MR32 etc) are firmware locked to v26.99 or below, how do Meraki plan to rollout updates, security fixes or new features to these ? They (MR32) still have until July 2014 until end of support
The MR32 was still on sale just over 3 years ago, are Meraki saying that's it, 3 years development from end of sale, go buy some new AP's if you want new development for your networks ?
How can I apply new features to my networks that have a mix both Wave1 and Wave2 AP's ?
If I roll out new firmware that includes new features, how will I know in advance if those features will work on older models ?
Do Meraki plan to swap out the older Wave1 AP's free of charge for new Wave2 ones?
@pjc26.x will continue to get security and functional fixes, just not new major features. Hence the support up to 26.99 when we are only on 26.8.1 at the moment. I think that if you configure a network that has a mix of devices with 27.x then the newer devices will get 27.x and the older ones will get the latest 26.x. Obviously you cannot use new functional features that rely on 27.x.
We have been doing a bit of rationalising and have been replacing the 802.11ac Wave 1 APs at sites with only a few with Wave 2 APs from sites where most are Wave 1, thereby allowing us to use the new features in the now all Wave 2 sites if required.