Verify whether a connection may access ANOS opcodes.
This callback is OPTIONAL.
The ANOS by default verifies the opcode access in the following way:
- Checks if the opcode is supported (defined by the DULT specification), otherwise rejects with the Invalid_command status.
- Checks if the DULT user is in the DULT_NEAR_OWNER_STATE_MODE_SEPARATED state, otherwise rejects with the Invalid_command status.
- Checks if the opcode precondition is met, otherwise rejects with the status specific to the opcode specification.
By implementing this callback, the network can customize the opcode access verification in the following way:
- Checks if the opcode is supported (defined by the network specification), otherwise rejects with the Invalid_command status.
- Checks if the opcode is in the Non-owner Control group and the DULT user is in the DULT_NEAR_OWNER_STATE_MODE_SEPARATED state, otherwise rejects with the Invalid_command status.
- Checks if the opcode precondition is met, otherwise rejects with the status specific to the opcode specification.
- Checks if the access_verify callback allows the access, otherwise rejects with the Invalid_state status.
Granting the access to opcodes outside of the DULT_NEAR_OWNER_STATE_MODE_SEPARATED state is a deviation from the DULT specification; ensure the policy matches the network specification implemented on top of DULT.
This callback can be used to grant access to ANOS opcodes related to the Accessory Information opcode group for the purposes of the accessory association with the owner device.
- Parameters
-
| [in] | conn | Pointer to the Bluetooth connection. |
- Returns
- true to grant access to ANOS opcodes, false to deny it.