Kernal/User space change for LE Random Addresses
One other change that is needed, which I don't really know how to attack is remote devices with Random Addresses. There is at least one team here at UPF with a device with a Random Address which cannot be connected to with either Vinicius' or the bluetooth-next kernal tips, because the connection HCI command only specifies Public Addresses as the remote address type.
I am not at all knowledgable about sockets, but I assume that a new Socket option needs to be defined that specifies address type.
I can get around this inelegantly by building a secondary kernel which hard-codes the address type to Random, and then dual booting into that kernel for random address only remote devices.
I would love if someone who knows the bluez socket option handling (both kernel and user space) could fix this, otherwise I will try to muddle along on my own.
Signature · 4 lines
Brian Gix [email protected] Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Brian,
Quoted 7 lines · Brian Gix
One other change that is needed, which I don't really know how to attack is remote devices with Random Addresses. There is at least one team here at UPF with a device with a Random Address which cannot be connected to with either Vinicius' or the bluetooth-next kernal tips, because the connection HCI command only specifies Public Addresses as the remote address type.
We are already working on it. We discussed yesterday an approach to address this issue.
An address/advertising cache will be added in the kernel, if the given address is found in the cache the two most significant bits will be checked to infer the address type, otherwise the fallback will be BR/EDR. For BR/EDR L2CAP SOCK_SEQPACKET sockets PSM is always provided, we can also use this information to distinguish BR/EDR from LE address if an advertising has not been detected previously.
Quoted 10 lines
I am not at all knowledgable about sockets, but I assume that a new Socket option needs to be defined that specifies address type.
I can get around this inelegantly by building a secondary kernel which hard-codes the address type to Random, and then dual booting into that kernel for random address only remote devices.
I would love if someone who knows the bluez socket option handling (both kernel and user space) could fix this, otherwise I will try to muddle along on my own.
I suggest to build a secondary kernel while we are working on it.
BR,
Claudio.
Hi Claudio,
Quoted 3 lines · Claudio Takahasi
An address/advertising cache will be added in the kernel, if the given address is found in the cache the two most significant bits will be checked to infer the address type,
For the public vs random address detection you need to use the address type info in the advertising report. Only when you've determined that the address is random will the two bits make sense. So far the only use I can think of for these bits is to determine whether it's useful to try to perform a lookup in our IRK list (e.g. for a non-resolvable private key that wouldn't make sense). Are there any other uses?
Quoted 4 lines
otherwise the fallback will be BR/EDR. For BR/EDR L2CAP
SOCK_SEQPACKETsockets PSM is always provided, we can also use this information to distinguish BR/EDR from LE address if an advertising has not been detected previously.
I think we could still keep the current CID based decision on the kernel side. If the CID implies LE but we don't have a match for the address in the cache we just return an error to user space.
Johan