Thread (6 messages) flat view 6 messages, 4 authors, 2011-03-21

Re: [RFC] Auto Connections

From: jaikumar Ganesh <hidden>
Date: 2011-03-16 02:57:22

Hey Claudio:

On Fri, Mar 11, 2011 at 1:30 PM, Claudio Takahasi
[off-list ref] 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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help