[jira] [Updated] (MYNEWT-751) BLE Host - Policy for SM key overflow
[ https://issues.apache.org/jira/browse/MYNEWT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-751: --- Description: (Pull request: https://github.com/apache/incubator-mynewt-core/pull/279) The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written. Currently, the host simply fails to persist the record and returns an error code. I propose the following behavior in such a scenario: # Host checks that there is sufficient storage for a bond before it starts a pairing operation. Any currently-active pairing procedures should be included in the total number of bonds. # If there is insufficient space, host notifies application of the issue via a callback. # The callback would return an error code indicating which of the following behaviors to perform: ## Reject the pairing request. ## Proceed with the pairing operation (presumably the application would delete a security record to make room before returning from the callback). was: The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written. Currently, the host simply fails to persist the record and returns an error code. I propose the following behavior in such a scenario: # Host checks that there is sufficient storage for a bond before it starts a pairing operation. Any currently-active pairing procedures should be included in the total number of bonds. # If there is insufficient space, host notifies application of the issue via a callback. # The callback would return an error code indicating which of the following behaviors to perform: ## Reject the pairing request. ## Proceed with the pairing operation (presumably the application would delete a security record to make room before returning from the callback). > BLE Host - Policy for SM key overflow > - > > Key: MYNEWT-751 > URL: https://issues.apache.org/jira/browse/MYNEWT-751 > Project: Mynewt > Issue Type: Bug > Security Level: Public(Viewable by anyone) > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > (Pull request: https://github.com/apache/incubator-mynewt-core/pull/279) > The BLE host needs a way to handle the case where a security store write > fails because the maximum number of entries have already been written. > Currently, the host simply fails to persist the record and returns an error > code. > I propose the following behavior in such a scenario: > # Host checks that there is sufficient storage for a bond before it starts a > pairing operation. Any currently-active pairing procedures should be > included in the total number of bonds. > # If there is insufficient space, host notifies application of the issue via > a callback. > # The callback would return an error code indicating which of the following > behaviors to perform: > ## Reject the pairing request. > ## Proceed with the pairing operation (presumably the application would > delete a security record to make room before returning from the callback). -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (MYNEWT-751) BLE Host - Policy for SM key overflow
[ https://issues.apache.org/jira/browse/MYNEWT-751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christopher Collins updated MYNEWT-751: --- Description: The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written. Currently, the host simply fails to persist the record and returns an error code. I propose the following behavior in such a scenario: # Host checks that there is sufficient storage for a bond before it starts a pairing operation. # If there is insufficient space, host notifies application of the issue via a callback. # The callback would return an error code indicating which of the following behaviors to perform: ## Reject the pairing request. ## Proceed with the pairing operation (presumably the application would delete a security entry to make room before returning from the callback). This raises two issues: # The pre-check for sufficient storage only works if pairing operations are limited to one at a time. Perhaps the check could include pairing operations in progress in the count of written entries. # There isn't an API for the management of persisted security material. The application would probably need the following functions: ** query the system about which bonds are persisted. ** delete a specified bond from persistence. was: The BLE host needs a way to handle the case where a security store write fails because the maximum number of entries have already been written. Currently, the host simply fails to persist the record and returns an error code. I propose the following behavior in such a scenario: # Host checks that there is sufficient storage for a bond before it starts a pairing operation. # If there is insufficient space, host notifies application of the issue via the gap event callback. The callback would specify a new event code that specifically indicates security storage exhaustion. # The gap event callback would return an error code indicating which of the following behaviors to perform: ## Reject the pairing request. ## Proceed with the pairing operation (presumably the application would delete a security entry to make room before returning from the callback). This raises two issues: # The pre-check for sufficient storage only works if pairing operations are limited to one at a time. Perhaps the check could include pairing operations in progress in the count of written entries. # There isn't an API for the management of persisted security material. The application would probably need the following functions: ** query the system about which bonds are persisted. ** delete a specified bond from persistence. > BLE Host - Policy for SM key overflow > - > > Key: MYNEWT-751 > URL: https://issues.apache.org/jira/browse/MYNEWT-751 > Project: Mynewt > Issue Type: Bug > Components: Nimble >Reporter: Christopher Collins >Assignee: Christopher Collins > Fix For: v1_1_0_rel > > > The BLE host needs a way to handle the case where a security store write > fails because the maximum number of entries have already been written. > Currently, the host simply fails to persist the record and returns an error > code. > I propose the following behavior in such a scenario: > # Host checks that there is sufficient storage for a bond before it starts a > pairing operation. > # If there is insufficient space, host notifies application of the issue via > a callback. > # The callback would return an error code indicating which of the following > behaviors to perform: > ## Reject the pairing request. > ## Proceed with the pairing operation (presumably the application would > delete a security entry to make room before returning from the callback). > This raises two issues: > # The pre-check for sufficient storage only works if pairing operations are > limited to one at a time. Perhaps the check could include pairing operations > in progress in the count of written entries. > # There isn't an API for the management of persisted security material. The > application would probably need the following functions: > ** query the system about which bonds are persisted. > ** delete a specified bond from persistence. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
