You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Again, I am encountering the issue where the FileSecurityDb never actually closes the file handle and thus the bonding information never gets flushed to flash...
I have tried both with an LFS instance and a FAT instance on an external SPIFBlockDevice.
This may need its own issue but I really think we need to refactor the FileSecurityDb to operate more like "open, modify, close". In some applications, there isn't always a nice shutdown procedure (eg: hard power off with a switch) and in this case you cannot leave file handles open. That's just asking for corruption.
@paul-szczepanek-arm I will work on a refactor that works for me in the short term and I can do a PR. Do you see any issue with opening and closing the file each time it needs to be modified? Was there a reason (eg: latency) that you chose to originally keep the file open until the database was destroyed?
Currently, the only way the database gets destroyed (and thus the file is closed) is when the Security Manager itself gets destroyed... which I think never ever happens since it is a static singleton (as far as I can see).
I guess it does get deleted in SecurityManager::reset... I'll see if this gets called during BLE shutdown.
EDIT: I cannot find anywhere that SecurityManager::reset gets called by the stack itself. This doesn't seem like a great thing to do during the course of normal BLE operation... I still think we should go to the "open, write, close" tactic with the FileSecurityDb.
EDIT 2:
I now realize why the one method is called preserveBondingStateOnReset but I'm not sure why you must reset the security manager to flush the file. Shouldn't we have some sort of flushBondingState or something that doesn't modify the state of the security manager?
Also, nowhere in the mbed-os-example-ble for security and privacy is SecurityManager::reset called, nor mentioned...
So I added the reset and reinitialization of the security manager upon disconnection and I can now pair with Android/iOS devices and have it persist between power cycles, great.
This definitely needs its own issue at this point, but I wanted to point out (after testing myself) that using the KVStoreSecurityDb, you don't need to call SecurityManager::reset for the bonding information to be saved... so this is an inconsistency in the API.
And here we are!
Sorry @pan-@paul-szczepanek-arm, I know this is probably sending you a bunch of emails after work... 👨💻
Target(s) affected by this defect ?
All BLE targets
Toolchain(s) (name and version) displaying this defect ?
arm-none-eabi-gcc (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599]
What version of Mbed-os are you using (tag or sha) ?
mbed-os-99.99.99
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
Attempt to use the mbed-os-ble-example for security and privacy with the filesystem support enabled. The pairing credentials will not be saved into flash because the example does not call SecurityManager::reset. This is misleading, but more importantly this operation is not desireable. See discussion above.
The text was updated successfully, but these errors were encountered:
Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers. Internal Jira reference: https://jira.arm.com/browse/IOTOSM-3983
Description of defect
Separating this issue conversion from #14654.
Existing discussion quoted below:
And here we are!
Sorry @pan- @paul-szczepanek-arm, I know this is probably sending you a bunch of emails after work... 👨💻
Target(s) affected by this defect ?
All BLE targets
Toolchain(s) (name and version) displaying this defect ?
What version of Mbed-os are you using (tag or sha) ?
mbed-os-99.99.99
What version(s) of tools are you using. List all that apply (E.g. mbed-cli)
How is this defect reproduced ?
Attempt to use the
mbed-os-ble-example
for security and privacy with the filesystem support enabled. The pairing credentials will not be saved into flash because the example does not callSecurityManager::reset
. This is misleading, but more importantly this operation is not desireable. See discussion above.The text was updated successfully, but these errors were encountered: