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
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
Hi Gustavo/Jaikumar
On Wed, Mar 16, 2011 at 8:40 PM, Gustavo F. Padovan
<[email protected]> wrote:
> Hi Claudio,
>
> * Claudio Takahasi <[email protected]> [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
>
Hi Claudio,
* Claudio Takahasi <[email protected]> [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
Hey Claudio:
On Fri, Mar 11, 2011 at 1:30 PM, Claudio Takahasi
<[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>
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
<[email protected]> 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 [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
>