-
Notifications
You must be signed in to change notification settings - Fork 364
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
Repeat pairing #287
Repeat pairing #287
Conversation
Hi, |
Yes, this does apply to a security level increase. The application has to do a little more work, though. Specifically, the application needs to compare the properties of the current bond to those of the imminent secure link. E.g.,
I do think the application needs this level of control, though. If there is a good default behavior, we can supply it as a library function. |
We would persist the authenticated flag if either peer supported authentication. We should only persist it if both support it.
If a device is already bonded, ;he host should not allow the same device to pair again. Currently, the host blindly proceeds with the pairing operation. This should not be allowed because the second peer could be an imposter masquerading as the original. New behavior in such a scenario: 1. Host notifies application of the duplicate pairing attempt via the gap event callback. The callback specifies a new event code (BLE_GAP_EVENT_REPEAT_PAIRING) that specifically indicates a duplicate pairing attempt. 2. The gap event callback returns an error code indicating which of the following behaviors to perform: a. Retry: Return BLE_GAP_REPEAT_PAIRING_RETRY after deleting the conflicting bond. The stack will verify the bond has been deleted and continue the pairing procedure. If the bond is still present, this event will be reported again. b. Ignore: Return BLE_GAP_REPEAT_PAIRING_IGNORE. The stack will silently ignore the pairing request.
ac9e02f
to
79fcf1d
Compare
I'm having the same issue with pairing. When is this PR expected to be merged? |
This pull request addresses the issue identified in MYNEWT-750 (https://issues.apache.org/jira/browse/MYNEWT-750).
This PR incorporates changes from another PR: 277 (#277). Therefore, this PR should only be merged after 277.