LE Connection issues

LE Connection issues

[Ganir, Chen]

Hi everyone.

I've tried investigating the LE connection procedure a bit, and I came up with some issues. For example, you MUST first scan for devices even if you have a device already paired, in order to connect to it. This is not the case for BR/EDR devices, where you can turn on the host, and try to connect to the paired device immediately. This has a major impact on user experience. I believe that the only relevant information from the advertising data is the address type, which can be sent to the host, and used later when trying to connect to the device again. I believe there were some discussions regarding this issue a while back, but I cannot recall what was done about this.

In addition, a call for brd_device_add_attio_callback may fail immediately (without even calling the connect/disconnect callbacks) if the device is not present in the advertising cache (fail with error "no route to device"). This also results in a bad user experience, since a user may think that the host is trying to connect to the peer, while in fact the host failed and did not indicate this failure to the user. Since LE does not define a connection timeout, we have a problem here, since we failed on implementation and not spec issue, and we did not inform the user of this error.

Did anyone else encounter these issues, or has anything to comment about these issues ?

Thanks,
Chen Ganir.

Re: LE Connection issues

[Brian Gix]

Hi Chen,

On 12/5/2011 7:38 AM, Ganir, Chen wrote:
> Hi everyone.
>
> I've tried investigating the LE connection procedure a bit, and I came up with some issues. For example, you MUST first scan for devices even if you have a device already paired, in order to connect to it. This is not the case for BR/EDR devices, where you can turn on the host, and try to connect to the paired device immediately. This has a major impact on user experience. I believe that the only relevant information from the advertising data is the address type, which can be sent to the host, and used later when trying to connect to the device again. I believe there were some discussions regarding this issue a while back, but I cannot recall what was done about this.
>
> In addition, a call for brd_device_add_attio_callback may fail immediately (without even calling the connect/disconnect callbacks) if the device is not present in the advertising cache (fail with error "no route to device"). This also results in a bad user experience, since a user may think that the host is trying to connect to the peer, while in fact the host failed and did not indicate this failure to the user. Since LE does not define a connection timeout, we have a problem here, since we failed on implementation and not spec issue, and we did not inform the user of this error.
>
> Did anyone else encounter these issues, or has anything to comment about these issues ?


I have definitely dealt with the same issue, and it has indeed been 
raised here.  I am equally unclear as to if it has been fully resolved, 
but Johan has made some changes to the MGMT interface to create an 
Address Type bit field, and package it along with the Address into a 
struct called mgmt_addr_info, which is now used in the device found 
event, connect failed event and pair device command.

I would like to further extend the usage of this structure to replace 
the simple bdaddr in the mgmt_link_key_info struct, so that once a 
device has been paired, the kernel's database of Link keys will have a 
copy of the address type.  This might not be a perfect fit, because not 
all devices will support LTK's (opting instead perhaps for the CSRK, if 
the usage model does not support links that remain open indefinitely). 
However, if a "trusted relationship" (i.e. Paired) has been established, 
I think some sort of key must exist, and each of these keys is 
associated with a particular bdaddr, and the kernel will need to be 
aware of it, which gives us the opportunity to make that connection (and 
differentiation) between BR/LE-Public/LE-Random

Johan has made the Address type be a bit field, such that the current 3 
recognized types are "BR/EDR", "Public LE", and "Random LE".


-- 
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum

Re: LE Connection issues

[Claudio Takahasi]

Hi Chen,

On Mon, Dec 5, 2011 at 12:38 PM, Ganir, Chen <chen.ganir@ti.com> wrote:
> Hi everyone.
>
> I've tried investigating the LE connection procedure a bit, and I came up with some issues. For example, you MUST first scan for devices even if you have a device already paired, in order to connect to it. This is not the case for BR/EDR devices, where you can turn on the host, and try to connect to the paired device immediately. This has a major impact on user experience. I believe that the only relevant information from the advertising data is the address type, which can be sent to the host, and used later when trying to connect to the device again. I believe there were some discussions regarding this issue a while back, but I cannot recall what was done about this.
>
> In addition, a call for brd_device_add_attio_callback may fail immediately (without even calling the connect/disconnect callbacks) if the device is not present in the advertising cache (fail with error "no route to device"). This also results in a bad user experience, since a user may think that the host is trying to connect to the peer, while in fact the host failed and did not indicate this failure to the user. Since LE does not define a connection timeout, we have a problem here, since we failed on implementation and not spec issue, and we did not inform the user of this error.
>
> Did anyone else encounter these issues, or has anything to comment about these issues ?

We don't have a final decision yet, but there are some suggestions.
The fact is we need to have a functional implementation, even it is
not the final solution. Andre Guedes has some patches to trigger
scanning before each connect(if the address is not found in the
cache). Search for "[PATCH 0/4] LE connection improvements" in the
mailing list. However, considering that BlueZ will act as central it
is necessary to use whitelist during the connection establishment to
avoid the penalty for non connectable devices.

IMO connections should not be triggered intermediately for paired
devices. We need to provide more flexibility to allow apps/profiles
controlling connections. Definitively, btd_device_add_attio_callback
needs to be improved. We can't keep the timeout in the kernel since
timeouts are defined by profiles.

L2CAP config timeout ~40 seconds for LE connections should be
removed(discussed in Prague). Passive/background scanning if there is
at least one key available or a socket/connect pending is still open,
we need to discuss if it is feasible or not.

BR,
Claudio