Hi,
I am trying to understand how a BLE connection is established between
my embedded system and an Android phone. I am using bluez 5.9 on a
3.12 kernel on this embedded system; with a CSR chipset.
I set up bluetooth using:
hciconfig hci0 reset
hciconfig hci0 noscan
Then, I use hcitool to set the advertisement and scan data, and I
enable a connectable advertisement with
hcitool -i hci0 cmd 0x08 0x000a 01
I am _not_ using bluetoothd.
With this simple setup, I can connect with an Android phone to my
embedded system.
I check it with:
hcitool -i hci0 con
Which reports one active connection.
I had a look at the hciconfig and hcitool source code (the only tools
I used to setup bluetooth), but could not find where a connection is
accepted.
My question is: where (in the code) is the connection accepted in the
first place?
Thanks!
-- Gilles
PS: my excuses for this repost. I realized that I forgot to set a
subject for the initial version of this e-mail sent on this list
yesterday.
Hi Gilles,
On Sat, Nov 22, 2014, Gilles Gr?goire wrote:
> I still find this a bit surprising: when using an l2capSocket, I still
> have to listen() and accept() the connection. One would expect that
> without anyone accept()'ing, the connection is not accepted!
E.g. ATT uses a fixed L2CAP channel, i.e. there is no L2CAP signaling
involved to establish it. Instead the channel is implicitly available
once the baseband link becomes available (i.e. through the LE Connection
Complete HCI event). There's therefore nothing to accept or reject as as
far as a fixed channel like ATT is concerned. If you were doing
Connection oriented Channels which have an actual L2CAP Connect
request/response pair the socket accept() would indeed map to the L2CAP
Connect Response.
Johan
Arman,
2014-11-21 20:12 GMT+01:00 Arman Uguray <[email protected]>:
> Hi Gilles,
>
>> On Fri, Nov 21, 2014 at 12:03 AM, Gilles Grégoire <[email protected]> wrote:
>> Hi,
>>
>> I am trying to understand how a BLE connection is established between
>> my embedded system and an Android phone. I am using bluez 5.9 on a
>> 3.12 kernel on this embedded system; with a CSR chipset.
>>
>> I set up bluetooth using:
>> hciconfig hci0 reset
>> hciconfig hci0 noscan
>>
>> Then, I use hcitool to set the advertisement and scan data, and I
>> enable a connectable advertisement with
>> hcitool -i hci0 cmd 0x08 0x000a 01
>>
>> I am _not_ using bluetoothd.
>>
>> With this simple setup, I can connect with an Android phone to my
>> embedded system.
>> I check it with:
>> hcitool -i hci0 con
>>
>> Which reports one active connection.
>>
>> I had a look at the hciconfig and hcitool source code (the only tools
>> I used to setup bluetooth), but could not find where a connection is
>> accepted.
>>
>> My question is: where (in the code) is the connection accepted in the
>> first place?
>>
>> Thanks!
>>
>> -- Gilles
>>
>> PS: my excuses for this repost. I realized that I forgot to set a
>> subject for the initial version of this e-mail sent on this list
>> yesterday.
>> --
>> 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
>
> If you're using just hcitool (and someone correct me if I'm wrong)
> then the kernel will accept the connection but won't magically hand it
> over to userland unless someone is listening for incoming connections.
> For that you would have to create an L2CAP socket and listen on it.
> Once a connection is accepted then you can use the returned socket
> just as you would with any UNIX socket over which you can exchange
> data.
This is exactly the kind of answer I was looking for. I could not find
this information anywhere.
I still find this a bit surprising: when using an l2capSocket, I still
have to listen() and accept() the connection. One would expect that
without anyone accept()'ing, the connection is not accepted!
Thanks a lot,
-- Gilles
Hi Gilles,
On Fri, Nov 21, 2014 at 8:12 PM, Arman Uguray <[email protected]> wrote:
> Hi Gilles,
>
>> On Fri, Nov 21, 2014 at 12:03 AM, Gilles Grégoire <[email protected]> wrote:
>> Hi,
>>
>> I am trying to understand how a BLE connection is established between
>> my embedded system and an Android phone. I am using bluez 5.9 on a
>> 3.12 kernel on this embedded system; with a CSR chipset.
>>
>> I set up bluetooth using:
>> hciconfig hci0 reset
>> hciconfig hci0 noscan
>>
>> Then, I use hcitool to set the advertisement and scan data, and I
>> enable a connectable advertisement with
>> hcitool -i hci0 cmd 0x08 0x000a 01
>>
>> I am _not_ using bluetoothd.
>>
>> With this simple setup, I can connect with an Android phone to my
>> embedded system.
>> I check it with:
>> hcitool -i hci0 con
>>
>> Which reports one active connection.
>>
>> I had a look at the hciconfig and hcitool source code (the only tools
>> I used to setup bluetooth), but could not find where a connection is
>> accepted.
>>
>> My question is: where (in the code) is the connection accepted in the
>> first place?
>>
>> Thanks!
>>
>> -- Gilles
>>
>> PS: my excuses for this repost. I realized that I forgot to set a
>> subject for the initial version of this e-mail sent on this list
>> yesterday.
>> --
>> 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
>
> If you're using just hcitool (and someone correct me if I'm wrong)
> then the kernel will accept the connection but won't magically hand it
> over to userland unless someone is listening for incoming connections.
> For that you would have to create an L2CAP socket and listen on it.
> Once a connection is accepted then you can use the returned socket
> just as you would with any UNIX socket over which you can exchange
> data.
>
> You can look at tools/btgatt-server.c for an example of listening for
> incoming LE L2CAP connections on the ATT channel.
>
Or you can use l2test if its possible for you. It would go probably like this:
l2test -r -V le_public -J 4
> Thanks,
> Arman
\Łukasz
> --
> 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
Hi Gilles,
> On Fri, Nov 21, 2014 at 12:03 AM, Gilles Grégoire <[email protected]> wrote:
> Hi,
>
> I am trying to understand how a BLE connection is established between
> my embedded system and an Android phone. I am using bluez 5.9 on a
> 3.12 kernel on this embedded system; with a CSR chipset.
>
> I set up bluetooth using:
> hciconfig hci0 reset
> hciconfig hci0 noscan
>
> Then, I use hcitool to set the advertisement and scan data, and I
> enable a connectable advertisement with
> hcitool -i hci0 cmd 0x08 0x000a 01
>
> I am _not_ using bluetoothd.
>
> With this simple setup, I can connect with an Android phone to my
> embedded system.
> I check it with:
> hcitool -i hci0 con
>
> Which reports one active connection.
>
> I had a look at the hciconfig and hcitool source code (the only tools
> I used to setup bluetooth), but could not find where a connection is
> accepted.
>
> My question is: where (in the code) is the connection accepted in the
> first place?
>
> Thanks!
>
> -- Gilles
>
> PS: my excuses for this repost. I realized that I forgot to set a
> subject for the initial version of this e-mail sent on this list
> yesterday.
> --
> 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
If you're using just hcitool (and someone correct me if I'm wrong)
then the kernel will accept the connection but won't magically hand it
over to userland unless someone is listening for incoming connections.
For that you would have to create an L2CAP socket and listen on it.
Once a connection is accepted then you can use the returned socket
just as you would with any UNIX socket over which you can exchange
data.
You can look at tools/btgatt-server.c for an example of listening for
incoming LE L2CAP connections on the ATT channel.
Thanks,
Arman