-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
BLE: Manual BLE security manager db synchronisation #14824
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -501,11 +501,28 @@ class SecurityManager | |
* Normally all bonding information is lost when device is reset, this requests that the stack | ||
* attempts to save the information and reload it during initialisation. This is not guaranteed. | ||
* | ||
* @note This option is itself saved together with bonding data. When data is read after reset, | ||
* the state of this option decides if data should be restored. If this option has not been saved | ||
* the data will not be restored even if partial data is present. | ||
* | ||
* @param[in] enable if true the stack will attempt to preserve bonding information on reset. | ||
* @return BLE_ERROR_NONE or appropriate error code indicating the failure reason. | ||
*/ | ||
ble_error_t preserveBondingStateOnReset(bool enable); | ||
|
||
/** | ||
* Some or all of bonding information may be stored in memory while in use. This will write | ||
* bonding data to persistent storage. This will have no effect if no persistent storage is enabled. | ||
* | ||
* @note This implicitly also calls preserveBondingStateOnReset(true) inside. | ||
* | ||
* @note Depending on the driver used to implement the storage solution used this may be a disruptive | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe we could use a less ominous tone and instruct the user to prefer calling this function outside of connection otherwise the connection can drop if storage is the internal flash. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Well, this is what it means. Other operations may be affected not just connections. That's why I used generic phrasing. |
||
* operation and may cause active connections to drop due to failed processing deadlines. | ||
* | ||
* @return BLE_ERROR_NONE or appropriate error code indicating the failure reason. | ||
*/ | ||
ble_error_t writeBondingStateToPersistentStorage(); | ||
|
||
//////////////////////////////////////////////////////////////////////////// | ||
// List management | ||
// | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -136,7 +136,7 @@ class FileSecurityDb : public SecurityDb { | |
|
||
virtual void restore(); | ||
|
||
virtual void sync(entry_handle_t db_handle); | ||
virtual void sync(entry_handle_t db_handle = invalid_entry_handle); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What do we gain with the default parameter ? It is an implementation and it won't be called directly by the BLE framework. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So that I don't have to modify existing code. |
||
|
||
virtual void set_restore(bool reload); | ||
|
||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -200,7 +200,7 @@ class KVStoreSecurityDb : public SecurityDb { | |
|
||
virtual void restore(); | ||
|
||
virtual void sync(entry_handle_t db_handle); | ||
virtual void sync(entry_handle_t db_handle = invalid_entry_handle); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Same as above There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. See above. |
||
|
||
virtual void set_restore(bool reload); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My read of this is that
writeBondingStateToPersistentStorage
is effectively a no-op unlesspreserveBondingStateOnReset
is set to true before the reset. What's the rationale behind this?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
preserveBondingStateOnReset is an option that affects behaviour after the reset. Maybe I should've called it loadBondingDataFromPersistentStorageAfterReset
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could
writeBondingStateToPersistentStorage
implicitly setpreserveBondingStateOnReset
? Or is there a reason someone would write the data but not automatically load it after a reset?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a good point. If I can't find a good reason by tomorrow I'll add the call.