Force security request when watch reports a bond but link won't encrypt#289
Open
gmarull wants to merge 1 commit into
Open
Force security request when watch reports a bond but link won't encrypt#289gmarull wants to merge 1 commit into
gmarull wants to merge 1 commit into
Conversation
When the user forgets the pairing on the phone, the watch still holds its copy of the bond, so the connection address resolves and the watch reports paired=true in the Pebble Pairing Service connectivity status (since pebbleos 916fdbf17, which derives it from the persistent bond store). On iOS, isBonded() has no backing API and is hardcoded to true, so the needs-pairing check concludes "already paired" and never requests pairing. The link then sits unencrypted: the watch's kernel LE client (and thus PPoG) is gated on encryption, the phone's PPoG handshake times out after ~12s, and the app tears down and reconnects in an endless loop with nobody ever initiating SMP. Detect the stalemate: when the watch says paired but the link hasn't encrypted shortly after connection setup, write the pairing trigger with forceSecurityRequest. The watch then sends an SM security request, and the phone either silently re-encrypts (keys present) or starts a fresh pairing (keys lost), which also makes the watch drop its stale bond via the repeat-pairing path. Falls back to reading the trigger characteristic for watches without a writeable trigger, and waits for the watch's encryption-change connectivity notification to confirm. This doesn't touch createBond(), so it cannot reintroduce the Android bond-reject reconnect storm fixed by pebbleos 916fdbf17 (FIRM-2212). Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: Gerard Marull-Paretas <gerard@teslabs.com>
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 the user forgets the pairing on the phone, the watch still holds its copy of the bond, so the connection address resolves and the watch reports paired=true in the Pebble Pairing Service connectivity status (since pebbleos 916fdbf17, which derives it from the persistent bond store). On iOS, isBonded() has no backing API and is hardcoded to true, so the needs-pairing check concludes "already paired" and never requests pairing. The link then sits unencrypted: the watch's kernel LE client (and thus PPoG) is gated on encryption, the phone's PPoG handshake times out after ~12s, and the app tears down and reconnects in an endless loop with nobody ever initiating SMP.
Detect the stalemate: when the watch says paired but the link hasn't encrypted shortly after connection setup, write the pairing trigger with forceSecurityRequest. The watch then sends an SM security request, and the phone either silently re-encrypts (keys present) or starts a fresh pairing (keys lost), which also makes the watch drop its stale bond via the repeat-pairing path. Falls back to reading the trigger characteristic for watches without a writeable trigger, and waits for the watch's encryption-change connectivity notification to confirm.
This doesn't touch createBond(), so it cannot reintroduce the Android bond-reject reconnect storm fixed by pebbleos 916fdbf17 (FIRM-2212).
Fixes MOB-9335
Note: NOT tested