Skip to content
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

Pairing agent with support for peripherals sending Slave Security Request #1133

Draft
wants to merge 4 commits into
base: pairing-agent
Choose a base branch
from

Conversation

bojanpotocnik
Copy link
Contributor

@bojanpotocnik bojanpotocnik commented Nov 21, 2022

As discussed in #1100, the desire of that PR is to provide stable implementation for programmatic pairing using Pin or Passkey Entry pairing methods.
However, rare BLE devices can utilize advanced security features, requiring more refined (and bug-risky) operations considering pairing process. I cannot push to that branch, so I'm leaving this PR in Draft state, based to the feature branch of #1100. Here I would try to add BlueZ and Windows support for pairing with such devices.


Original implementation of this PR using method of "pre-registering" the pairing agent is archived in https://github.com/bojanpotocnik/bleak/tree/archive/develop/pairing/preregister_agent

  • [Y] Use AsyncExitStack to nest context managers - not applicable in this case
  • [_] Unregister pairing agent immediately after pairing, not only in __aexit__
  • [Y] Check if this is possible on Windows
  • [_] Implement for Windows

After some testing, I discovered that some time can pass between peripheral device sending Slave Security Request and central responding with Pairing Request, so executing connect(), then registering the pairing agent, then calling pair() is fine. However, if the central tries to perform GATT Service Discovery instead of responding to Slave Security Request, the connection will be dropped. This is solved by postoping service discovery until pairing is finished.

@bojanpotocnik
Copy link
Contributor Author

I've tested on Windows yesterday and successfully paired the device - however there were many code changes/tweaks, so I'll try to extract what exactly is the changing factor for Windows.

@dlech
Copy link
Collaborator

dlech commented Nov 22, 2022

I like the direction this is going.

On Windows, I don't think we can skip discovering services on connect, otherwise the device may not actually connect.

Perhaps, instead of adding the skip_discovering_services option, we could have an option to pair on connect? In the backend connect() method, this would call the OS API to pair instead of connect (if not already paired?) and then get the services.

Add #noqa to suppress "N802 PEP8 Function name should be lowercase"
warnings. `@method(name=)` parameter could be used to have lowercase
methods still connected to correct pascal-case D-Bus methods, however
using exact names in Python makes it clear that these methods are bonded
to the D-Bus interface.
This is achieved by passing ``pairing_callbacks`` to the ``BleakClient``
constructor instead of manually calling ``pair()`` method.
@bojanpotocnik
Copy link
Contributor Author

bojanpotocnik commented Nov 25, 2022

Moved previous solution to https://github.com/bojanpotocnik/bleak/tree/archive/develop/pairing/skip_service_discovery and implemented your suggestion. Windows implementation in progress.

Now I'm trying to solve this case:

  1. Devices pair/bond.
  2. Remote device removed the bond data.
  3. BlueZ attempts to connect (Pair is True because central does not know that remote deleted the bond data)
  4. Connection fails with PIN or Key Missing + Authentication Failure (btmon)

This error is not propagated via D-Bus and BlueZ does not try to re-pair (as it should) in such case.

@bojanpotocnik
Copy link
Contributor Author

Opened bluez/bluez#433 for issue mentioned in the previous comment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants