Can CAPsMAN Access List `CAPs Access Rule` matching work with multiple rules that use `MAC Address` wildcard with different `Private Passphrase`?
We use the CAPsMAN Access List `MAC Address`, `SSID Regexp` and `Private Passphrase` to individually control device access by matching each device's MAC and a generated unique passphrase.
When we are on boarding a new device, we add a rule with no MAC into the access list with the new device's passphrase.
We then look in the registration table for the new device when it is connected and update the access list entry with the MAC address, so that it locks that passphrase to that device.
This works fine until somebody doesn't complete the on boarding process and we now have multiple devices that are trying to connect that aren't already in the list.
This causes all the devices that aren't explicitly in the access list, even if they have the incorrect passphrase, to appear in the registration table (briefly) for that rule, so we cannot determine which device is the one we are on boarding.
I think we can get around this by waiting for the `Uptime` value in the registration table being sufficiently long that a connection with incorrect passphrase would have been disconnected, so assuming that works, we move on to the next problem:
No device will ever connect to subsequent rule after the first MAC wildcard entries, even if they match all conditions in a later CAPs Access Rule.
My observation leads me to assume that this is the sequence of events within CAPsMAN:
- Device tries to connect to SSID
- Device MAC matches `MAC address` [blank]
- Device SSID matches `SSID Regexp`
- Device added to Registration Table
- CAPsMAN realises they have the wrong Private Passphrase
- Device access denied
- Device removed from Registration Table
- Device does not get checked against any further Access List entries
Note: the helpdesk see all this through a web interface that does everything through API calls for us.