Fix CTKD failure introduced by Host RPA generation #528
Conversation
zxzxwu
commented
Aug 9, 2024
•
zxzxwu
commented
- Fix the bug which device doesn't generate a static address by default
- Properly distribute public or random address if no identity address type is set
- Add configurable identity address type and io capabilities
bumble/smp.py
Outdated
| @@ -1079,7 +1079,7 @@ def send_pairing_dhkey_check_command(self) -> None: | |||
|
|
|||
| def send_identity_address_command(self) -> None: | |||
| identity_address = { | |||
| None: self.manager.device.static_address, | |||
| None: self.connection.self_address, | |||
There was a problem hiding this comment.
It doesn't seem right to send an identity address that's not the device's static random or public address.
The spec, BLUETOOTH CORE SPECIFICATION Version 5.4 | Vol 6, Part B Paragraph 1.3 does say "A device's Identity Address is a Public Device Address or Random Static Device Address that it uses in packets it transmits. If a device is using Resolvable Private Addresses, it shall also have an Identity Address.",
so if the connection address is an RPA, that can't be used as an identity address (and the peer would also get confused because they would then be resolving further RPAs from this device as resolving to that connection address.
Can you explain in which way you think this breaks CTKD?
There was a problem hiding this comment.
Consider the following enviroment:
- Bumble has Classic and CTKD over Classic enabled
- Bumble doesn't set preferred identity address type
In this case, Bumble will send its Static Random address as identity address, even in a CTKD over Classic session, which is very confusing to remote device - but scenario commonly exists in most of Bumble's Classic-only examples.
One thing very difficult to handle is that Bumble allows device to have public and random static address simultaneously, so it's hard to tell which one should be considered as identity address unless user always sets the perferred identity address.
There was a problem hiding this comment.
I see. So maybe the right thing here is that if the user doesn't choose static or public identity in the pairing config (default), then the choice should be:
- the public address if it is set (not == ANY)
- else the static random address
If the user wants the static random address even if the controller has a public address, then they should set it explicitly in the PairingConfig.
There was a problem hiding this comment.
Make sense, but not sure what's the impact to existing users.
There was a problem hiding this comment.
Looks good to them.
