nimble/host: add BLE_SM_SEC_REQ_AUTO_PAIR - #2287
Open
tonywestonuk wants to merge 1 commit into
Open
Conversation
When a peer sends a Security Request and no keys are stored for it, the host immediately replies with a Pairing Request from inside ble_sm_sec_req_rx(). Some peripherals (e.g. the Okida OT-2000 BLE module used in older Glen Dimplex/Stoves ovens) send a Security Request as soon as the connection is established and do not respond to a Pairing Request sent that early; pairing then times out. The same devices pair fine when the central initiates pairing a moment later, which the Core Spec allows (Vol 3, Part H, 2.4.6: the central may initiate pairing in response to a Security Request, it is not required to). Add a syscfg setting BLE_SM_SEC_REQ_AUTO_PAIR (default 1, stock behaviour) mirrored in ble_hs_cfg.sm_sec_req_auto_pair. When cleared, a Security Request from a peer with no stored keys is accepted but no Pairing Request is sent; the application initiates pairing itself with ble_gap_security_initiate(). Store errors other than BLE_HS_ENOENT are still propagated. Peers with stored keys are unaffected.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a peer sends a Security Request and no keys are stored for it, the host immediately replies with a Pairing Request from inside ble_sm_sec_req_rx(). Some peripherals (e.g. the Okida OT-2000 BLE module used in older Glen Dimplex/Stoves ovens) send a Security Request as soon as the connection is established and do not respond to a Pairing Request sent that early; pairing then times out. The same devices pair fine when the central initiates pairing a moment later, which the Core Spec allows (Vol 3, Part H, 2.4.6: the central may initiate pairing in response to a Security Request, it is not required to).
Add a syscfg setting BLE_SM_SEC_REQ_AUTO_PAIR (default 1, stock behaviour) mirrored in ble_hs_cfg.sm_sec_req_auto_pair. When cleared, a Security Request from a peer with no stored keys is accepted but no Pairing Request is sent; the application initiates pairing itself with ble_gap_security_initiate(). Store errors other than BLE_HS_ENOENT are still propagated. Peers with stored keys are unaffected.