Pairing agent with support for peripherals sending Slave Security Request #1133
Conversation
|
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. |
bojanpotocnik
force-pushed
the
pairing
branch
3 times, most recently
from
d49dee6 to
cfd09ba
Compare
|
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 |
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
force-pushed
the
pairing
branch
from
cfd09ba to
dd50aa6
Compare
|
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:
This error is not propagated via D-Bus and BlueZ does not try to re-pair (as it should) in such case. |
|
Opened bluez/bluez#433 for issue mentioned in the previous comment. |
|
I think this feature would be really helpful. Would you be open to merging it after a rebase? I could probably handle the rebase if that helps @bojanpotocnik @dlech |
I've been quite busy lately, so I can't promise a quick review. It has been a while, so I'll want to have a good look at this again. We'll also need to implement support on Windows. We can pull from #1100 for that as well.
The good news is that this has already been implemented in the meantime. |
|
I'm not familiar with the Windows or Android APIs, so I can't really develop or test those versions. |
|
Sure, no problem. |
3 participants
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
UseAsyncExitStackto nest context managers - not applicable in this caseUnregister pairing agent immediately after pairing, not only in__aexit__Check if this is possible on WindowsImplement for WindowsAfter 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 callingpair()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.