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.
--
Brian Gix
[email protected]
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
Hi Claudio,
On Wed, Feb 09, 2011, Claudio Takahasi wrote:
> 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?
> 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.
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
Hi Brian,
On Tue, Feb 8, 2011 at 9:58 PM, Brian Gix <[email protected]> wrote:
>
> 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.
> 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.