The last time I tested this it didn’t work. I think that was v6.48. The logic seems to be - check the PSK for first rule that matches the MAC address pattern (in this case any Mac), if that fails then fail auth. At the time of my testing it would not then go on to check another rule that also matches the Mac pattern. But I wish it would!
do you run now v6.49.x to test it again?
May it works in v7.x?
When I get a chance I will try it again. I’ve kept a close eye on release notes and I’ve never seen any work on this topic though; sadly I get the impression that MikroTik doesn’t see this as an issue and I don’t think I’ve been able to encourage anyone to see the value in DPSK style functionality. It’s frustrating, we use Ruckus DPSK on loads of client sites and MDUs, I’d love it if we could offer it on Mikrotik as an alternative to Ruckus.
That said it’s not well supported by Ruckus either, you can only do Dynamic VLANs with DPSKs on Virtual SmartZone. These two functions in combination aren’t supported yet on either their cloud platform or in Unleashed, though both are supported separately, so it’s probably just a matter of time.
Excession
Like I stated… I learned the hard way that Mikrotik wireless is not in the same league as Ruckus.
It was a painful (expensive) lesson. Hundreds of hours of custom coding I will never use again. And thousands of dollars out of my pockets as I paid to replace the Tik radios.
While I was seduced by the power and flexibility of routerOS and caps-man, the actual radio performance ain’t there.
For ruckus I went from Zone Directors to Unleashed. Never got into virtual smart zone or cloud. So I my knowledge of those other platforms is limited/non existent.
I broadly agree with you Gotsprings, we too deploy a lot of Ruckus. But I also think there is a place in the Market for MikroTik and have found many places to successfully use their Radios as well.
This isn’t a discussion over who’s better; just an examination of DPSK functionality and if it’s possible to replicate it on MikroTik.
Its the inability for Mikrotik radios to deal with some 2.4 clients at all and especially under any sort of crowded environment, that made the systems crumble.
I have a cambium on my bench right now.
Todays experiment… added a epsk password to my network. Tagged that password with a VLAN tag.
People who use the system password get VLAN 1. People who use the ePSK password get VLAN 254.
You know… what I was being asked to do yesterday.
I get that your experience has told you not to use MikroTik radios, but come on my Man, you’re on a MikroTik forum here; are you jumping on every forum post about setting up a hotspot or configuring caps-man and derailing the conversation buy telling everyone who’s come here for exactly this vendor specific discussion, that they’re using the wrong product? After a point it’s not all that helpful.
You did just prompt me to Google epsk on Cambium though, which was an interesting read, so you’re not all bad! 
Remember… It was Mikrotik who said that their radio wasn’t suitable to busy noisy environments. And just said… “Ohh well” when clients remote controls would show as connected… But not actually work until you cycled the radio.
Ergo why I had to stop using the caps and WAPs.
But now I have decent connectivity with WiFi WAVE2 drivers. Actually matching the other vendors old stuff that was WiFi AC2. But sadly… No wave 2 support on most Mikrotik’s and NONE in caps-mode.
So if I was willing to set up a house full of Audience’s as standalone devices… I could get clients to stay connected.
I confirm same behaviour with 6.49.3 where it check the first 00:00:00:00:00:00 and if failed, does not check other. So close to a working solution…
Feature requested here: Feature request for v7.x - #290 by digit - General - MikroTik community forum
That’s a shame, but thanks for sharing your results.
I don’t think Mikrotik quite get the use case we’re going for here or why we’d like this slight change in the validation behaviour to start with.
Probably isn’t going to change without some campaigning.
I have documented the behaviour and post a feature request there. chime in !
http://forum.mikrotik.com/t/feature-request-for-v7-x/74084/290
Got an answer on my feature request post.
Ruckus have a patent on DPSK… But I don’t think it apply
Cambian have EPSK, which is basically the same thing.
Seems like marketing, rather than technical patent.
Good effort btw.
After using DPSK for years… I can say that EPSK is not the same.
Apple is making DPSK a pain now. The phone warns of security issues if you DON’T USE A RANDOM MAC ADDRESS. So the customer tried to help and flips their MAC to random or private and their DPSK key doesn’t work.
EPSK doesn’t need you to bind a MAC address.
Not only does this “out due” ruckus’s up to 4 devices.
It makes it so that phone didn’t chew up two slots when they flipped between private and device MAC.
I was mildly excited when I saw an option to deny Private MAC addresses in Engenius new cloud architecture. But the product sucked so bad it didn’t merit any more of my time.
We use Ruckus DPSK in the “group DPSK” mode. Like this it doesn’t care about MAC addresses, just that your device knows the PSK for that group. We tend to use it in MDU environments, one DPSK per apartment, landing the user on the associated VLAN for that DPSK.
Ahh…
I came from Standard DPSK… which is now checked off as LIMITED DPSK.
I see the difference now.
But i am trying to escape Ruckus now. 14 months of connectivity issues and the pricing on that H550 is nuts.
AGREED!
when i first started w ros / mt back in the ros 2.9.x days, i wrongly assumed: WOW, mikrotik is so amazing and powerful with routing, thus their wifi products must be similar!
… WRONG! 
.. fast fw 15 years later , and 10,000+ APs (of all kinds/makes) later and… you cant go wrong with Ruckus. Excellent wifi performance, great hardware.
this is not a nock against MT, i LOVE mikrotik. they just dont focus on wifi, like they do on routing - and this was a mis-conception i had, and learned the hard way.
I havent used a mikrotik branded AP to serve end-users in many years now. (they are great when you need some special/unusual wifi one-off setup though - and are GREAT as wifi testing /troubleshooting devices! (but NOT for serving wifi to end-users).
If you want some insight into a devices wifi performance, PRE purchase or PRE-deply- look up the FCC docs to see how the build quality of the APs internals look. (ie the PCB / Shielding, pig-tails to antennas, or lack of). its not just for show / looks. i have found THIS to be a decent indicator.
(more ON topic - the OP of this post, is really referring to dynamic-PSK where you DONT have to pre-provide the devices mac-address. that is what makes true dPSK special. although In my experience, dPSK of any variety is rarely used to serve end-users, in the context this author is referring to.)