Ble pairing strategy #222
Ble pairing strategy #222
Conversation
|
Some thoughts:
|
|
I also don't like the solution, it's just a "the best I can do for now" ;)
|
|
If you don't like it either, maybe we leave out auto for now? And just have a yes/no boolean for start_pairing. But at it to both IP and BLE. |
kvaellning
force-pushed
the
ble_pairing_strategy
branch
2 times, most recently
from
1252836 to
17db6d0
Compare
|
Good point. Will remove the Auto option for now. For the sake of convenience, I made it symmetrical for IP accessories, though this can be simplified by evaluating the FF flag. Since I don't have an IP accessory to check against, that's something I wouldn't do. |
|
@jlusiardi If you are okay with the solution for now, I would consider it finished. The improvements with the FeatureFlag may be part of another request. I will now take more time on #223 |
|
I’ll check on the feature stuff tonight or tomorrow morning in my app. The HAP permissions on the characteristic definitely allow unpaired read to it, but I have not yet verified you can actually do that |
From an Apple User's point of view I would also expect that we can read all information to pair an unpaired accessory before pairing. Hence there should be no need for a retry. But since you introduce a new parameter (with a default value though) to At best @los93sol finds out, which piece of information from the discover replies indicates which authenication method. I think I could have gotten the feature flag from |
|
I will change it asap, but this may take until Monday. |
|
Good news, I actually did confirm this previously and confirmed again just now. You can read the value out from the characteristic unpaired. You want the Pairing service (00000055-0000-1000-8000-0026BB765291) and Pairing Feature Flags characteristic (0000004F-0000-1000-8000-0026BB765291). What I did is write a HAP Read request to it and my device gave me back CTRL, TID, STATUS, LEN (2), TLV (3) So once you strip off the PDU, the TLV value is 0x01, 0x01, 0x02 which translates to... Also want to give a big thanks to everyone who's contributed code to understanding this protocol, it has been extremely helpful for me! |
|
Nice! Will update the stuff on Monday! Thanks guys, and have a nice weekend! |
|
This is great news! Thanks @los93sol and i look forward to the updates! |
|
I'll added the service and the characteristic, as well as the CLI implementation (currently only local). |
kvaellning
force-pushed
the
ble_pairing_strategy
branch
3 times, most recently
from
8f4732b to
613cce9
Compare
|
@jlusiardi @Jc2k I finally got it to run. BLE is working fine, IP I cannot check here. Would be nice if someone could comment on this. Note that I discovered by checking that no set "HwAuth" and "SwAuth" feature flags mean that the accessory is not certified. I left this to be treated as software based authentication, since that appears to be the strategy of Apples Home App. |
As defined in the open source HomeKit ADK, both PairSetup and PairSetupWithAuth are available options. The main difference lies in the necessary hardware: PairSetupWithAuth needs an Apple co-processor for the authentication in pairing step M4.
Though not the best solution, the user may specify if a specific strategy for pairing should be used (either try both pairing options, or try one and cope with a possible exception).
Based on the feature flags, the best method for authentication is determined. Note that no supported authentication method (both flags are not set) is treated as "supports software authentication". Having both flags not set may be the case for uncertified accessories, which have neither co-processor nor the MFi authentication token.
The feature flags are now also extracted during the connection process, to avoid unnecessary additional calls to the discovery function.
kvaellning
force-pushed
the
ble_pairing_strategy
branch
from
613cce9 to
1a323d0
Compare
|
Did you run the tests? find_device_ip_and_port was tested before but no tests were changed. I just updated my Master Branch to make sure the tests run ok (which they do now). |
|
Good point, forgot about the tests since I only added the implementation folder to my workspace. D'Oh! |
|
I am already also looking into them |
|
I've got the feature flag and BLE test to run again, but currently it's not checking against authentication method errors. |
kvaellning
force-pushed
the
ble_pairing_strategy
branch
from
52c09e5 to
37ccf59
Compare
Though not the best solution, this implements an "pairing strategy" which, depending on the user preferences, tries to pair automatically (standard), pairs only when an Apple authentication coprocessor is available, or only via software.
Note that the supported pairing mehtod can only be found out after stage M4, that means that at this point a restart of the process is necessary anyway.
Improvement: directly raise an error on verification of M4, but I am not familiar with the implementation, so I'll do it in a brute force way (retry if anything fails).