[RFC] Auto Connections

[RFC] Auto Connections

[Claudio Takahasi]

Hi guys,

It is time to get opinions from some gurus!

We need to implement automatic connections to implement the Profiles.
At the moment BlueZ supports only dual mode adapters, as consequence
BlueZ needs to start the LE connection. IMHO, it is better to leave
the responsibility to the controller, implementing "selective"
connections will only introduce more code without concrete benefits.
Configuring the controller to autonomously establish connections seems
to be the right approach to proceed.

This topic is NOT about StartDiscovery() + CreateDevice.
StartDiscovery uses active scanning and CreateDevice uses direct
connection establishment. We need a mechanism to automatically connect
to "trusted" devices or devices flagged as "AutoConnect".


My initial idea is: change the LE server socket to report
outgoing(host initiated) connections through the server socket.
Awkward?
To achieve that we need to manage the LE Create Connection(using
whitelist) in the kernel, extend the management interface to control
devices in the whitelist, change the LE Connection Complete Event
handling to get the Role properly.
Pros:
- Controller manage connections
- Flexible to support  connections to "trusted" resolvable address and
passive scanning
- Only one "flow" for the connections: LE server socket
- Maybe we could hide resolvable address from the userspace, mapping
it directly to public or static random
Cons:
- Risky
- Less control of the connection establishment process


Another approach can be to manage the LE connections(using whitelist)
from the userspace. BDADDR_ANY in the destination field(sockaddr_l2)
can be used to define LE connections using white list.
Pros:
- It will not be necessary to extend the management interface now,
address can be added directly to the controller's white list
- Doesn't require changes in the LE server socket
Cons:
- BDADDR_ANY in the destination field has no meaning for Basic Rate
- Needs to expose the resolvable address to the userspace
- Different "flows" for incoming/outgoing connections


Open issue(s):
* How to handle timeouts when sending LE Create Connection
* Passive scanning management


Cheers,
Claudio

Re: [RFC] Auto Connections

[jaikumar Ganesh]

Hey Claudio:
    In general, why do we want let the stack manage auto connections
i.e can you elaborate on "We need to implement automatic connections
to implement the Profiles". Why not let the applications handle auto
connections ?

Thanks

On Fri, Mar 11, 2011 at 1:30 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Hi guys,
>
> It is time to get opinions from some gurus!
>
> We need to implement automatic connections to implement the Profiles.
> At the moment BlueZ supports only dual mode adapters, as consequence
> BlueZ needs to start the LE connection. IMHO, it is better to leave
> the responsibility to the controller, implementing "selective"
> connections will only introduce more code without concrete benefits.
> Configuring the controller to autonomously establish connections seems
> to be the right approach to proceed.
>
> This topic is NOT about StartDiscovery() + CreateDevice.
> StartDiscovery uses active scanning and CreateDevice uses direct
> connection establishment. We need a mechanism to automatically connect
> to "trusted" devices or devices flagged as "AutoConnect".
>
>
> My initial idea is: change the LE server socket to report
> outgoing(host initiated) connections through the server socket.
> Awkward?
> To achieve that we need to manage the LE Create Connection(using
> whitelist) in the kernel, extend the management interface to control
> devices in the whitelist, change the LE Connection Complete Event
> handling to get the Role properly.
> Pros:
> - Controller manage connections
> - Flexible to support  connections to "trusted" resolvable address and
> passive scanning
> - Only one "flow" for the connections: LE server socket
> - Maybe we could hide resolvable address from the userspace, mapping
> it directly to public or static random
> Cons:
> - Risky
> - Less control of the connection establishment process
>
>
> Another approach can be to manage the LE connections(using whitelist)
> from the userspace. BDADDR_ANY in the destination field(sockaddr_l2)
> can be used to define LE connections using white list.
> Pros:
> - It will not be necessary to extend the management interface now,
> address can be added directly to the controller's white list
> - Doesn't require changes in the LE server socket
> Cons:
> - BDADDR_ANY in the destination field has no meaning for Basic Rate
> - Needs to expose the resolvable address to the userspace
> - Different "flows" for incoming/outgoing connections
>
>
> Open issue(s):
> * How to handle timeouts when sending LE Create Connection
> * Passive scanning management
>
>
> Cheers,
> Claudio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] Auto Connections

[jaikumar Ganesh]

Hey Claudio:

On Fri, Mar 11, 2011 at 1:30 PM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> Hi guys,
>
> It is time to get opinions from some gurus!
>
> We need to implement automatic connections to implement the Profiles.
> At the moment BlueZ supports only dual mode adapters, as consequence
> BlueZ needs to start the LE connection. IMHO, it is better to leave
> the responsibility to the controller, implementing "selective"
> connections will only introduce more code without concrete benefits.
> Configuring the controller to autonomously establish connections seems
> to be the right approach to proceed.
>
> This topic is NOT about StartDiscovery() + CreateDevice.
> StartDiscovery uses active scanning and CreateDevice uses direct
> connection establishment. We need a mechanism to automatically connect
> to "trusted" devices or devices flagged as "AutoConnect".
>
>
> My initial idea is: change the LE server socket to report
> outgoing(host initiated) connections through the server socket.
> Awkward?
> To achieve that we need to manage the LE Create Connection(using
> whitelist) in the kernel, extend the management interface to control
> devices in the whitelist, change the LE Connection Complete Event
> handling to get the Role properly.
> Pros:
> - Controller manage connections
> - Flexible to support  connections to "trusted" resolvable address and
> passive scanning
> - Only one "flow" for the connections: LE server socket
> - Maybe we could hide resolvable address from the userspace, mapping
> it directly to public or static random
> Cons:
> - Risky
> - Less control of the connection establishment process
>
>
> Another approach can be to manage the LE connections(using whitelist)
> from the userspace. BDADDR_ANY in the destination field(sockaddr_l2)
> can be used to define LE connections using white list.
> Pros:
> - It will not be necessary to extend the management interface now,
> address can be added directly to the controller's white list
> - Doesn't require changes in the LE server socket
> Cons:
> - BDADDR_ANY in the destination field has no meaning for Basic Rate
> - Needs to expose the resolvable address to the userspace
> - Different "flows" for incoming/outgoing connections
>
>
> Open issue(s):
> * How to handle timeouts when sending LE Create Connection
> * Passive scanning management
>


 In general, why do we want let the stack manage auto connections i.e
can you elaborate on "We need to implement automatic connections to
implement the Profiles". Why not let the applications (which sit above
Bluez) handle auto connections ?

Thanks

>
> Cheers,
> Claudio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: [RFC] Auto Connections

[Gustavo F. Padovan]

Hi Claudio,

* Claudio Takahasi <claudio.takahasi@openbossa.org> [2011-03-11 21:30:09 +0000]:

> Hi guys,
> 
> It is time to get opinions from some gurus!
> 
> We need to implement automatic connections to implement the Profiles.
> At the moment BlueZ supports only dual mode adapters, as consequence
> BlueZ needs to start the LE connection. IMHO, it is better to leave
> the responsibility to the controller, implementing "selective"
> connections will only introduce more code without concrete benefits.
> Configuring the controller to autonomously establish connections seems
> to be the right approach to proceed.
> 
> This topic is NOT about StartDiscovery() + CreateDevice.
> StartDiscovery uses active scanning and CreateDevice uses direct
> connection establishment. We need a mechanism to automatically connect
> to "trusted" devices or devices flagged as "AutoConnect".
> 
> 
> My initial idea is: change the LE server socket to report
> outgoing(host initiated) connections through the server socket.
> Awkward?
> To achieve that we need to manage the LE Create Connection(using
> whitelist) in the kernel, extend the management interface to control
> devices in the whitelist, change the LE Connection Complete Event
> handling to get the Role properly.
> Pros:
> - Controller manage connections
> - Flexible to support  connections to "trusted" resolvable address and
> passive scanning
> - Only one "flow" for the connections: LE server socket
> - Maybe we could hide resolvable address from the userspace, mapping
> it directly to public or static random

This approach have a lot of advantages. It seems the best option to me.

> Cons:
> - Risky

Define risky here.

> - Less control of the connection establishment process

But do we need this control?

-- 
Gustavo F. Padovan
http://profusion.mobi

Re: [RFC] Auto Connections

[Claudio Takahasi]

Hi Gustavo/Jaikumar

On Wed, Mar 16, 2011 at 8:40 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Claudio,
>
> * Claudio Takahasi <claudio.takahasi@openbossa.org> [2011-03-11 21:30:09 +0000]:
>
>> Hi guys,
>>
>> It is time to get opinions from some gurus!
>>
>> We need to implement automatic connections to implement the Profiles.
>> At the moment BlueZ supports only dual mode adapters, as consequence
>> BlueZ needs to start the LE connection. IMHO, it is better to leave
>> the responsibility to the controller, implementing "selective"
>> connections will only introduce more code without concrete benefits.
>> Configuring the controller to autonomously establish connections seems
>> to be the right approach to proceed.
>>
>> This topic is NOT about StartDiscovery() + CreateDevice.
>> StartDiscovery uses active scanning and CreateDevice uses direct
>> connection establishment. We need a mechanism to automatically connect
>> to "trusted" devices or devices flagged as "AutoConnect".
>>
>>
>> My initial idea is: change the LE server socket to report
>> outgoing(host initiated) connections through the server socket.
>> Awkward?
>> To achieve that we need to manage the LE Create Connection(using
>> whitelist) in the kernel, extend the management interface to control
>> devices in the whitelist, change the LE Connection Complete Event
>> handling to get the Role properly.
>> Pros:
>> - Controller manage connections
>> - Flexible to support  connections to "trusted" resolvable address and
>> passive scanning
>> - Only one "flow" for the connections: LE server socket
>> - Maybe we could hide resolvable address from the userspace, mapping
>> it directly to public or static random
>
> This approach have a lot of advantages. It seems the best option to me.
>
>> Cons:
>> - Risky
>
> Define risky here.
More code in the kernel, more time to get the code upstream,
additional verification to avoid insufficient resources when scanning
and connecting, but to me it seems the best approach.

to Jaikumar:
The profiles will indirectly manage the connections providing
informations such as connection parameters(interval, window, ...) and
addresses, but the kernel needs to centralize/manage the connections.
We can't allow the profiles to control the connection directly, a
remote can implement more than one profile, maybe with different
constraints. The host can also provide inputs, for instance power
saving profile or maximum number of LE connections.

>
>> - Less control of the connection establishment process
>
> But do we need this control?
Yes, we need. It is not allowed to send more than one LE Create
Connection command to the controller or try to establish a connection
while scanning.
Some controller also doesn't support some state combination, see "LE
read supported states"

Claudio

>
> --
> Gustavo F. Padovan
> http://profusion.mobi
>

Re: [RFC] Auto Connections

[Arun K. Singh]

Hi Claudio,


> to Jaikumar:
> The profiles will indirectly manage the connections providing
> informations such as connection parameters(interval, window, ...) and
> addresses, but the kernel needs to centralize/manage the connections.

As per section 9.3.8, a host can still perform direct connection
establishment procedure
by telling controller to "ignore the White List and process
connectible advertising
packets from a specific single device specified by the Host". Wouldn't
this be same
as letting the host[read profiles] directly manage connections?


> We can't allow the profiles to control the connection directly, a
> remote can implement more than one profile, maybe with different
> constraints. The host can also provide inputs, for instance power
> saving profile or maximum number of LE connections.

Why not? under direct connection establishment procedure, it should be
possible for a host
to establish connection with a remote peer device with host selected connection
configurable parameters. Why should we deprive a bluez host of
establishing such a connection...

Or did I miss something here?

Thanks,
Arun

Re: [RFC] Auto Connections

[Claudio Takahasi]

Hi Arun,

On Mon, Mar 21, 2011 at 10:55 AM, Arun K. Singh <arunkat@gmail.com> wrote:
> Hi Claudio,
>
>
>>
>> >> It is time to get opinions from some gurus!
>> >>
>> >> We need to implement automatic connections to implement the Profiles.
>> >> At the moment BlueZ supports only dual mode adapters, as consequence
>> >> BlueZ needs to start the LE connection. IMHO, it is better to leave
>> >> the responsibility to the controller, implementing "selective"
>> >> connections will only introduce more code without concrete benefits.
>> >> Configuring the controller to autonomously establish connections seems
>> >> to be the right approach to proceed.
>> >>
>> >> This topic is NOT about StartDiscovery() + CreateDevice.
>> >> StartDiscovery uses active scanning and CreateDevice uses direct
>> >> connection establishment. We need a mechanism to automatically connect
>> >> to "trusted" devices or devices flagged as "AutoConnect".
>> >>
>> >>
>> >> My initial idea is: change the LE server socket to report
>> >> outgoing(host initiated) connections through the server socket.
>> >> Awkward?
>> >> To achieve that we need to manage the LE Create Connection(using
>> >> whitelist) in the kernel, extend the management interface to control
>> >> devices in the whitelist, change the LE Connection Complete Event
>> >> handling to get the Role properly.
>> >> Pros:
>> >> - Controller manage connections
>> >> - Flexible to support  connections to "trusted" resolvable address and
>> >> passive scanning
>> >> - Only one "flow" for the connections: LE server socket
>> >> - Maybe we could hide resolvable address from the userspace, mapping
>> >> it directly to public or static random
>> >
>> > This approach have a lot of advantages. It seems the best option to me.
>> >
>> >> Cons:
>> >> - Risky
>> >
>> > Define risky here.
>> More code in the kernel, more time to get the code upstream,
>> additional verification to avoid insufficient resources when scanning
>> and connecting, but to me it seems the best approach.
>>
>> to Jaikumar:
>> The profiles will indirectly manage the connections providing
>> informations such as connection parameters(interval, window, ...) and
>> addresses, but the kernel needs to centralize/manage the connections.
>
>
> As per section 9.3.8, a host can still perform direct connection
> establishment procedure
> by telling controller to "ignore the White List and process connectable
> advertising
> packets from a specific single device specified by the Host". Wouldn't this
> be same
> as letting the host[read profiles] directly manage connections?

There are four Connection Establishment Procedures: Auto, General,
Selective and Direct.
CreateDevice/CreatePairedDevice will use Direct. But after pairing or
create device("known" devices) we need a more transparent procedure. I
am not saying that we will implement straitly Auto procedure, we will
also need to handle the resolvable address, a hybrid approach seems to
be more appropriated.

 We could use Direct procedure, managing(serializing) the connection
establishment implementing logic in the kernel or userspace for the
"known" devices. However, I prefer to transfer the responsibility to
the controller. If I choose connections using whitelist, how the STE
controller prioritizes the advertises? Does directed advertises have a
higher priority?

>
>
>> We can't allow the profiles to control the connection directly, a
>> remote can implement more than one profile, maybe with different
>> constraints.
>
> under direct connection establishment procedure, it should be possible for a
> host
> to establish connection with a remote peer device with host selected
> connection
> configurable parameters. Why should we deprive a bluez host of establishing
> such a connection...
> Or did I miss something here?

At API level, what is the benefit of exposing this option to the API users?

Some profiles define the recommended connection parameters, there is
also the Slave Connection Interval Range AD type that may be used to
in the  connection establishment.

BR,
Claudio

>
>
>
> Thanks,
> Arun
>
>

Re: [RFC] Auto Connections

[Claudio Takahasi]

Hi Arun,

On Wed, Mar 23, 2011 at 7:37 AM, Arun Kumar SINGH
<arunkr.singh@stericsson.com> wrote:
> Hi Claudio,
>
>
>>There are four Connection
>>Establishment Procedures:
>>Auto, General,
>>Selective and Direct.
>>CreateDevice/CreatePairedDev
>>ice will use Direct. But
>>after pairing or
>>create device("known"
>>devices) we need a more
>>transparent procedure. I
>>am not saying that we will
>>implement straitly Auto
>>procedure, we will
>>also need to handle the
>>resolvable address, a hybrid
>>approach seems to
>>be more appropriated.
>>
>> We could use Direct
>>procedure,
>>managing(serializing) the
>>connection
>>establishment implementing
>>logic in the kernel or
>>userspace for the
>>"known" devices. However, I
>>prefer to transfer the
>>responsibility to
>>the controller. If I choose
>>connections using whitelist,
>>how the STE
>>controller prioritizes the
>>advertises? Does directed
>>advertises have a
>>higher priority?
>>
>
> Agreed but not sure whether we have a choice to use both a)auto connection via white-lists and b)direct connection ignoring white-lists - at the same time?
> In my opinion for doing either a) or b) you need to set the intitiator filter plicy to either use white-list or ignore it for direct connection. So, if you eventually implement auto-connection, you may not be able to do direct connect at all unless of course if you change the filter policy everytime. STE controller behaves the same way as per controller spec requirements letting the host decide on the filter policy and act suitably.

Not at the same time, controllers don't allow a second LE Create
Connection command if there is a pending command.
My question about your controller was how it decides in the case that
it receives connectable advertises from more than one remote. Does it
use RSSI(included in the advertise) and/or direct advertises has
higher priority?

>
> Coming back to the connection policy debate, we can as well have this as configurable option in bluetoothd to give a choice whether to use auto connection or direct connect policy by default?
>
> Also all the seven steps you need[9.3.5] for auto connection could either be done from user-space itself. And doing same from user-space would make more sense once the connection policy is configurable in bluetoothd?
>
> Please excuse if these sound too wild ...
Your comments are being very useful! No worries.

We have been discussing internally how to implement the connection
management and new facts came up:
1. If we wanna support GATT over BR/EDR, manage automatically
connections in the kernel will be hard to keep a similar approach for
LE and basic rate.
2. Change the server socket to "notify" local host initiated
connections is also breaking the socket API and requires some nasty
code changes in the kernel.
3. There are a lot of LE kernel patches pending(SM, cache and MTU)

After that we decided to start our first shot managing the connection
is the usespace(as you suggested). Hide the resolvable address is
still possible to be implemented in the kernel if we manage the
advertise kernel cache and passive scanning properly in the kernel.


>
>
>>At API level, what is the
>>benefit of exposing this
>>option to the API users?
>>
>>Some profiles define the
>>recommended connection
>>parameters, there is
>>also the Slave Connection
>>Interval Range AD type that
>>may be used to
>>in the  connection
>>establishment.
>>
>
>
> I don’t have a strong reason to give this option as an API to profiles but considering that a profile may have more flexibiltiy to set the connection parameters etc while initiating a new connection etc. As if this is done by Auto- Connection policy, you may have to set same connection parameters for all devices --something which be undesirable from profile point of view ...
>

At the moment the values are hardcoded in the kernel. Ville sent last
year a proposal to allow changing the connection parameters. We didn't
decide yet we we will use management interface or extend the socket to
pass the connection parameters.

BR,
Claudio.

>
> Thanks,
> Arun
>