* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-26 2:51 UTC (permalink / raw)
To: Brian Redding; +Cc: BlueZ development
In-Reply-To: <000001cb747a$9fd61270$df823750$@org>
Hi Brian,
On Mon, Oct 25, 2010 at 4:27 PM, Brian Redding <bredding@codeaurora.org> wrote:
> Hi Claudio,
>
> Are there still interfaces that need to be added to attribute-api.txt to handle client and server characteristic configuration as well as presentation and aggregate formats? I see those as TODO items but wondered if the APIs for them have been defined yet.
>
> One thing to note on the server API is that a GATT-based profile could specify behavior on a characteristic value that when the characteristic value is read to perform some action in a similar way as a hardware register. It appears that the notes I'm reading in the code thus far only consider changes (or writes) to characteristic values for the watch code.
>
> Also does the current API handle included services?
>
> The Bluetooth SIG is beginning to look at 3rd party application developer API's for both client and servers for various platforms so understanding what is currently defined in BlueZ and what still needs to be added would be useful.
>
> Thanks,
> Brian
> ---
> Brian A. Redding
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
The API to address characteristic descriptors is still being defined.
We are focusing in the advertising and connection management at the
moment. If you have suggestion of how to represent the descriptors in
the attribute API, suggestions are welcome!
There isn't a server API at the moment, we implemented a server for
testing purpose only. But we will need to define it soon.
Which pages/section of the spec describes this read characteristic behavior?
Included services are not supported by our client. How important is
it? It is mandatory for qualification?
Regards,
Claudio.
^ permalink raw reply
* Re: [PATCH 1/2 v2] Bluetooth: Fix system crash caused by del_timer()
From: haijun liu @ 2010-10-26 1:32 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Haijun Liu, linux-bluetooth
In-Reply-To: <20101025110131.GA7721@vigoh>
Hi Gustavo,
>> >> During test session with another vendor's bt stack, found that in
>> >> l2cap_chan_del() using del_timer() caused l2cap_monitor_timeout()
>> >> be called after the sock was freed, so it raised a system crash.
>> >> So I just replaced del_timer() with del_timer_sync() to solve it.
>> >
>> > NAK on this. If you read the del_timer_sync() documentation you can
>> > see that you can't call del_timer_sync() on interrupt context. The
>> > possible solution here is to check in the beginning of
>> > l2cap_monitor_timeout() if your sock is still valid.
>> >
>>
>> You are right, I only considered close() interface, so missed the interrupt
>> context.
>>
>> It's very difficult to check sock valid or not in timeout procedure, since it's
>> an interrupt context, and only can get context from parameter pre-stored,
>> except global variables.
>
> I think you can check for sk == null there.
>
It's a pre-stored parameter, it will not change by itself.
--
Haijun Liu
^ permalink raw reply
* Re: 4.76 possible regression: bluetoothd segfaults when launching bluetooth programs
From: Johan Hedberg @ 2010-10-25 20:40 UTC (permalink / raw)
To: Ilya Basin; +Cc: linux-bluetooth
In-Reply-To: <453819375.20101024163802@gmail.com>
Hi Ilya,
On Sun, Oct 24, 2010, Ilya Basin wrote:
> Program received signal SIGSEGV, Segmentation fault.
> 0xb7d3e653 in strlen () from /lib/libc.so.6
> (gdb) bt
> #0 0xb7d3e653 in strlen () from /lib/libc.so.6
> #1 0xb7e5eb10 in ?? () from /usr/lib/libdbus-1.so.3
> #2 0xb7e4a34b in ?? () from /usr/lib/libdbus-1.so.3
> #3 0xb7e4e7a9 in dbus_message_iter_append_basic () from /usr/lib/libdbus-1.so.3
> #4 0xb7fef03d in append_array_variant ()
> #5 0xb7fef799 in emit_array_property_changed ()
> #6 0xb7fe4de4 in adapter_service_ins_rem ()
> #7 0xb7fd7fb1 in sdp_record_add ()
> #8 0xb7fd79de in service_register_req ()
> #9 0xb7fd5dfc in handle_request ()
> #10 0xb7fd496e in io_session_event ()
> #11 0xb7ef7a2b in ?? () from /usr/lib/libglib-2.0.so.0
> #12 0xb7eb0b72 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
> #13 0xb7eb1350 in ?? () from /usr/lib/libglib-2.0.so.0
> #14 0xb7eb1a1b in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #15 0xb7fd1bbd in main ()
> (gdb)
Unfortunately this doesn't give too much info since you don't seem to
have all debug symbols enabled. Could you try to reproduce this with
latest bluez git. You don't need to install anything but just compile
(./boostrap-configure && make) and run (src/bluetoothd -nd) from the
source tree directly. Then, it'd also be nice if you could use git
bisect to determine the exact commit between 4.69 and 4.76 that
introduced this regression.
Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 2/6] Bluetooth: Add LE connect support
From: Anderson Lizardo @ 2010-10-25 20:33 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth
In-Reply-To: <1288009280-5149-3-git-send-email-ville.tervo@nokia.com>
Hi,
On Mon, Oct 25, 2010 at 8:21 AM, Ville Tervo <ville.tervo@nokia.com> wrote:
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 0b1e460..0944c0c 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -45,6 +45,32 @@
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
>
> +void hci_le_connect(struct hci_conn *conn)
This function could be made static, right? (just noticed this now)
> +{
> + struct hci_dev *hdev = conn->hdev;
> + struct hci_cp_le_create_conn cp;
> +
> + conn->state = BT_CONNECT;
> + conn->out = 1;
> +
> + memset(&cp, 0, sizeof(cp));
> + cp.scan_interval = cpu_to_le16(0x0004);
> + cp.scan_window = cpu_to_le16(0x0004);
> + bacpy(&cp.peer_addr, &conn->dst);
> + cp.conn_interval_min = cpu_to_le16(0x0008);
> + cp.conn_interval_max = cpu_to_le16(0x0100);
> + cp.supervision_timeout = cpu_to_le16(0x0064);
> + cp.min_ce_len = cpu_to_le16(0x0001);
> + cp.max_ce_len = cpu_to_le16(0x0001);
> +
> + hci_send_cmd(hdev, HCI_OP_LE_CREATE_CONN, sizeof(cp), &cp);
> +}
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Brian Redding @ 2010-10-25 19:27 UTC (permalink / raw)
To: 'Claudio Takahasi'; +Cc: 'BlueZ development'
In-Reply-To: <AANLkTinnjXuAOBTY8VZz756VdrDFv0-OVKPNkwWbxi9-@mail.gmail.com>
> GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT
> clients services using D-Bus.
> GATT clients in general will have two pieces:
> 1- UI: Qt, GTK, python, ...
> 2- "module" in the BlueZ for profile specific tasks and D-Bus service
> interface.
> You can find the current attribute API in the file: doc/attribute-api.txt
> Claudio
Hi Claudio,
Are there still interfaces that need to be added to attribute-api.txt to handle client and server characteristic configuration as well as presentation and aggregate formats? I see those as TODO items but wondered if the APIs for them have been defined yet.
One thing to note on the server API is that a GATT-based profile could specify behavior on a characteristic value that when the characteristic value is read to perform some action in a similar way as a hardware register. It appears that the notes I'm reading in the code thus far only consider changes (or writes) to characteristic values for the watch code.
Also does the current API handle included services?
The Bluetooth SIG is beginning to look at 3rd party application developer API's for both client and servers for various platforms so understanding what is currently defined in BlueZ and what still needs to be added would be useful.
Thanks,
Brian
---
Brian A. Redding
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-25 18:54 UTC (permalink / raw)
To: Mike Tsai; +Cc: BlueZ development
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F8440581D@SC1EXMB-MBCL.global.atheros.com>
On Mon, Oct 25, 2010 at 3:16 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
>
> -----Original Message-----
> From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
> Sent: Monday, October 25, 2010 10:56 AM
> To: Mike Tsai
> Cc: BlueZ development
> Subject: Re: [RFC] LE connections and advertising management
>
> On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>>
>> -----Original Message-----
>> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
>> Sent: Monday, October 25, 2010 5:53 AM
>> To: BlueZ development
>> Subject: [RFC] LE connections and advertising management
>>
>> Hi all,
>>
>> Interleave BR/EDR/LE discovery is implemented, the next step in the
>> user space is how to manage advertising and LE connections.
>>
>> Some aspects:
>> 1. Only one LE connection is allowed(per peer), meaning only one
>> GAttrib instance will be allowed otherwise it will not be possible to
>> serialize commands/events
>> 2. The remote/Peripheral can support more than one GATT primary service
>> 3. We are planning to use "direct" connections only, meaning that we
>> will not use whitelist and the application interested must inform the
>> remote address/object to connect to.
>> 4. Kernel manages the connection establishment, currently there isn't
>> a way to change the connection parameters. BMI or ioctls will be
>> required to change the default parameters and also to trigger SMP
>> negotiation.
>>
>>
>> Some ideas:
>> 1. implement a characteristic driver: basically to provide an
>> abstraction to GATT clients. ex: Proximity, Health, ...
>> 2. We don't need to implement Proximity and other GATT clients as a
>> plugin at the moment, it can be enabled automatically by
>> --enable-attrib
>> 3. GATT clients could register a watcher/filter for advertising events
>> 4. GATT clients doesn't need to know ATT, in theory it can handle
>> characteristics only
>> 5. GATT clients needs to control/request LE connections based on the
>> advertisement received
>>
>> An initial draft implementing part of this idea is here:
>> git://git.infradead.org/users/cktakahasi/bluez.git devel
>>
>> Comments?
>>
>> Regards,
>> Claudio
>>>>MT comments,
>>
>> 1. Only one LE connection is allowed(per peer), meaning only one
>> GAttrib instance will be allowed otherwise it will not be possible to
>> serialize commands/events
>>
>>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
> [Claudio Takahasi]
> The master can be connected to more than one slave. But here, I wanna
> emphasize that only one instance of GAtttrib shall be created to
> represent the physical channel between two LE capable devices. GAttrib
> is the abstraction that we created in BlueZ to represent the GATT/ATT
> connection, it is necessary to address multiple applications/profiles
> and queue commands/events.
> [Mike Tsai]
> I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly.
> May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib?
[Claudio Takahasi]
Hi Mike,
At the moment it is not clear to me if an "application handle" will be
needed, maybe we can also hide it from the higher layers. All requests
are serialized and for each request there is a response, the
exceptions are write without response and notification. Each primary
service representation will have an object path, meaning that maybe it
is possible forward the response to the right source based on the last
request and handle information.
GAttrib will not be exposed to the UI. UI needs to access BlueZ GATT
clients services using D-Bus.
GATT clients in general will have two pieces:
1- UI: Qt, GTK, python, ...
2- "module" in the BlueZ for profile specific tasks and D-Bus service
interface.
You can find the current attribute API in the file: doc/attribute-api.txt
Claudio
>
>>
>> 4. GATT clients doesn't need to know ATT, in theory it can handle
>> characteristics only
>>
>>>> You mean both characteristic value and characteristic descriptors of characteristic?
> [Claudio Takahasi]
> Both. For the GATT client role, an interface can be created exporting
> profile specific details.
> Sometimes GATT clients will also need to access some low level information.
> [Mike Tsai]
> Yes, I will really appreciate if you may show me the planned API for this GAttrib,
>
>
> Regards,
> Claudio
>>
>> Regards,
>>
>> Mike
>>
>> --
>> 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
>>
>
--
--
Claudio Takahasi
Instituto Nokia de Tecnologia
Recife - Pernambuco - Brasil
+55 81 30879999
^ permalink raw reply
* Re: [PATCH 2/2] Fix coding style and comment
From: Johan Hedberg @ 2010-10-25 18:50 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1288024124-24492-2-git-send-email-epx@signove.com>
Hi Elvis,
On Mon, Oct 25, 2010, Elvis Pfützenreuter wrote:
> ---
> health/hdp.c | 2 +-
> health/mcap_sync.c | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
This one has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Fix fd comparison
From: Johan Hedberg @ 2010-10-25 18:49 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1288024124-24492-1-git-send-email-epx@signove.com>
Hi Elvis,
On Mon, Oct 25, 2010, Elvis Pfützenreuter wrote:
> ---
> health/hdp.c | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-25 18:16 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTinS-NhD3FhqcnpNRRdHKxn4mm+2zTmysrSeSjW8@mail.gmail.com>
-----Original Message-----
From: Claudio Takahasi [mailto:claudio.takahasi@openbossa.org]
Sent: Monday, October 25, 2010 10:56 AM
To: Mike Tsai
Cc: BlueZ development
Subject: Re: [RFC] LE connections and advertising management
On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Monday, October 25, 2010 5:53 AM
> To: BlueZ development
> Subject: [RFC] LE connections and advertising management
>
> Hi all,
>
> Interleave BR/EDR/LE discovery is implemented, the next step in the
> user space is how to manage advertising and LE connections.
>
> Some aspects:
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
> 2. The remote/Peripheral can support more than one GATT primary service
> 3. We are planning to use "direct" connections only, meaning that we
> will not use whitelist and the application interested must inform the
> remote address/object to connect to.
> 4. Kernel manages the connection establishment, currently there isn't
> a way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
>
>
> Some ideas:
> 1. implement a characteristic driver: basically to provide an
> abstraction to GATT clients. ex: Proximity, Health, ...
> 2. We don't need to implement Proximity and other GATT clients as a
> plugin at the moment, it can be enabled automatically by
> --enable-attrib
> 3. GATT clients could register a watcher/filter for advertising events
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
> 5. GATT clients needs to control/request LE connections based on the
> advertisement received
>
> An initial draft implementing part of this idea is here:
> git://git.infradead.org/users/cktakahasi/bluez.git devel
>
> Comments?
>
> Regards,
> Claudio
>>>MT comments,
>
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
>
>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
[Claudio Takahasi]
The master can be connected to more than one slave. But here, I wanna
emphasize that only one instance of GAtttrib shall be created to
represent the physical channel between two LE capable devices. GAttrib
is the abstraction that we created in BlueZ to represent the GATT/ATT
connection, it is necessary to address multiple applications/profiles
and queue commands/events.
[Mike Tsai]
I see. In order to handle multiple profiles (as multiple applications running on top of the GAttrib) in a single physical link, you will need something like "application handle" to dispatch the response/identification to the appropriate application correctly.
May you refer me to the API document that you are opening to the GATT client(s) from this GAttrib?
>
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
>
>>> You mean both characteristic value and characteristic descriptors of characteristic?
[Claudio Takahasi]
Both. For the GATT client role, an interface can be created exporting
profile specific details.
Sometimes GATT clients will also need to access some low level information.
[Mike Tsai]
Yes, I will really appreciate if you may show me the planned API for this GAttrib,
Regards,
Claudio
>
> Regards,
>
> Mike
>
> --
> 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
>
^ permalink raw reply
* Re: [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-25 17:55 UTC (permalink / raw)
To: Mike Tsai; +Cc: BlueZ development
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F844057B9@SC1EXMB-MBCL.global.atheros.com>
On Mon, Oct 25, 2010 at 2:11 PM, Mike Tsai <Mike.Tsai@atheros.com> wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Monday, October 25, 2010 5:53 AM
> To: BlueZ development
> Subject: [RFC] LE connections and advertising management
>
> Hi all,
>
> Interleave BR/EDR/LE discovery is implemented, the next step in the
> user space is how to manage advertising and LE connections.
>
> Some aspects:
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
> 2. The remote/Peripheral can support more than one GATT primary service
> 3. We are planning to use "direct" connections only, meaning that we
> will not use whitelist and the application interested must inform the
> remote address/object to connect to.
> 4. Kernel manages the connection establishment, currently there isn't
> a way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
>
>
> Some ideas:
> 1. implement a characteristic driver: basically to provide an
> abstraction to GATT clients. ex: Proximity, Health, ...
> 2. We don't need to implement Proximity and other GATT clients as a
> plugin at the moment, it can be enabled automatically by
> --enable-attrib
> 3. GATT clients could register a watcher/filter for advertising events
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
> 5. GATT clients needs to control/request LE connections based on the
> advertisement received
>
> An initial draft implementing part of this idea is here:
> git://git.infradead.org/users/cktakahasi/bluez.git devel
>
> Comments?
>
> Regards,
> Claudio
>>>MT comments,
>
> 1. Only one LE connection is allowed(per peer), meaning only one
> GAttrib instance will be allowed otherwise it will not be possible to
> serialize commands/events
>
>>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
[Claudio Takahasi]
The master can be connected to more than one slave. But here, I wanna
emphasize that only one instance of GAtttrib shall be created to
represent the physical channel between two LE capable devices. GAttrib
is the abstraction that we created in BlueZ to represent the GATT/ATT
connection, it is necessary to address multiple applications/profiles
and queue commands/events.
>
> 4. GATT clients doesn't need to know ATT, in theory it can handle
> characteristics only
>
>>> You mean both characteristic value and characteristic descriptors of characteristic?
[Claudio Takahasi]
Both. For the GATT client role, an interface can be created exporting
profile specific details.
Sometimes GATT clients will also need to access some low level information.
Regards,
Claudio
>
> Regards,
>
> Mike
>
> --
> 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
>
^ permalink raw reply
* RE: [RFC] LE connections and advertising management
From: Mike Tsai @ 2010-10-25 17:11 UTC (permalink / raw)
To: Claudio Takahasi, BlueZ development
In-Reply-To: <AANLkTin8pUACCu4YYuhLpFB7DxCfsYhN3cOpYYaVcTQ6@mail.gmail.com>
-----Original Message-----
From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
Sent: Monday, October 25, 2010 5:53 AM
To: BlueZ development
Subject: [RFC] LE connections and advertising management
Hi all,
Interleave BR/EDR/LE discovery is implemented, the next step in the
user space is how to manage advertising and LE connections.
Some aspects:
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
2. The remote/Peripheral can support more than one GATT primary service
3. We are planning to use "direct" connections only, meaning that we
will not use whitelist and the application interested must inform the
remote address/object to connect to.
4. Kernel manages the connection establishment, currently there isn't
a way to change the connection parameters. BMI or ioctls will be
required to change the default parameters and also to trigger SMP
negotiation.
Some ideas:
1. implement a characteristic driver: basically to provide an
abstraction to GATT clients. ex: Proximity, Health, ...
2. We don't need to implement Proximity and other GATT clients as a
plugin at the moment, it can be enabled automatically by
--enable-attrib
3. GATT clients could register a watcher/filter for advertising events
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
5. GATT clients needs to control/request LE connections based on the
advertisement received
An initial draft implementing part of this idea is here:
git://git.infradead.org/users/cktakahasi/bluez.git devel
Comments?
Regards,
Claudio
>>MT comments,
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
>> You mean the master (or client) can only connect to 1 slave (or server) or a slave can only connect to 1 master?
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
>> You mean both characteristic value and characteristic descriptors of characteristic?
Regards,
Mike
--
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
^ permalink raw reply
* Re: [PATCH] Send a proper configuration when a source doesn't have a first reliable
From: Johan Hedberg @ 2010-10-25 16:29 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1288014239-10832-1-git-send-email-sancane@gmail.com>
Hi,
On Mon, Oct 25, 2010, Santiago Carot-Nemesio wrote:
> ---
> health/hdp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/health/hdp.c b/health/hdp.c
> index fd3b1ca..10f4c5f 100644
> --- a/health/hdp.c
> +++ b/health/hdp.c
> @@ -1026,7 +1026,7 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
> case HDP_NO_PREFERENCE_DC:
> if (app->role == HDP_SINK)
> return MCAP_CONFIGURATION_REJECTED;
> - else if (app->chan_type_set)
> + else if (dev->fr && app->chan_type_set)
> *conf = app->chan_type;
> else
> *conf = HDP_RELIABLE_DC;
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH 2/2] Fix coding style and comment
From: Elvis Pfützenreuter @ 2010-10-25 16:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
In-Reply-To: <1288024124-24492-1-git-send-email-epx@signove.com>
---
health/hdp.c | 2 +-
health/mcap_sync.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index eb27613..7332cd5 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -339,7 +339,7 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
"Can't get sender name");
}
- if (!set_app_path(app)){
+ if (!set_app_path(app)) {
free_application(app);
return g_dbus_create_error(msg,
ERROR_INTERFACE ".HealthError",
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 49661a7..57ba0fd 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -350,7 +350,7 @@ static gboolean initialize_caps(struct mcap_mcl *mcl)
clock_gettime(CLK, &t1);
read_btclock_retry(mcl, &btclock, &btaccuracy);
- /* Do clock read a number of times and measure latency */
+ /* Read clock a number of times and measure latency */
avg = 0;
i = 0;
retries = MAX_RETRIES;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Fix fd comparison
From: Elvis Pfützenreuter @ 2010-10-25 16:28 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
---
health/hdp.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index fd3b1ca..eb27613 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -477,7 +477,7 @@ static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
}
fd = mcap_mdl_get_fd(dc_data->hdp_chann->mdl);
- if (fd <= 0)
+ if (fd < 0)
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
"Cannot get file descriptor");
@@ -568,7 +568,7 @@ static DBusMessage *channel_acquire_continue(struct hdp_tmp_dc_data *data,
}
fd = mcap_mdl_get_fd(data->hdp_chann->mdl);
- if (fd > 0)
+ if (fd >= 0)
return g_dbus_create_reply(data->msg, DBUS_TYPE_UNIX_FD, &fd,
DBUS_TYPE_INVALID);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Provide extra query for vCard single call
From: Johan Hedberg @ 2010-10-25 16:26 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1287997498-2576-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Mon, Oct 25, 2010, Rafal Michalski wrote:
> This patch makes that additional circumstance is recognized - after
> making a call with number that is out of phonebook it can be downloaded
> as a single vCard containing number with OTHER type.
> ---
> plugins/phonebook-tracker.c | 20 ++++++++++++++++++--
> 1 files changed, 18 insertions(+), 2 deletions(-)
Pushed upstream, but I had to fix your coding style first:
> - query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id, id,
> - id, id, id, id, id, id, id,
> + if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0) {
> + query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
> + id, id, id, id, id, id, id, id,
> id, id, id, id, id);
> + } else {
> + query = g_strdup_printf(CONTACTS_OTHER_QUERY_FROM_URI,
> + id, id, id);
> + }
>
> ret = query_tracker(query, PULL_QUERY_COL_AMOUNT, pull_contacts, data);
Single line branches shouldn't use curly braces.
Johan
^ permalink raw reply
* Re: [PATCH 1/1] Fix fd comparison and comment
From: Johan Hedberg @ 2010-10-25 16:22 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <1288013352-23258-1-git-send-email-epx@signove.com>
Hi Elvis,
On Mon, Oct 25, 2010, Elvis Pfützenreuter wrote:
> ---
> health/hdp.c | 6 +++---
> health/mcap_sync.c | 2 +-
> 2 files changed, 4 insertions(+), 4 deletions(-)
Please don't mix coding style cleanup and real bug fixes into a single
patch. I.e. could you please split these up. Thanks.
Johan
^ permalink raw reply
* [PATCH] Send a proper configuration when a source doesn't have a first reliable
From: Santiago Carot-Nemesio @ 2010-10-25 13:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
---
health/hdp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index fd3b1ca..10f4c5f 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -1026,7 +1026,7 @@ static uint8_t hdp_mcap_mdl_conn_req_cb(struct mcap_mcl *mcl, uint8_t mdepid,
case HDP_NO_PREFERENCE_DC:
if (app->role == HDP_SINK)
return MCAP_CONFIGURATION_REJECTED;
- else if (app->chan_type_set)
+ else if (dev->fr && app->chan_type_set)
*conf = app->chan_type;
else
*conf = HDP_RELIABLE_DC;
--
1.7.3.1
^ permalink raw reply related
* Re: [RFC] LE connections and advertising management
From: Anderson Lizardo @ 2010-10-25 13:34 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: BlueZ development
In-Reply-To: <AANLkTin8pUACCu4YYuhLpFB7DxCfsYhN3cOpYYaVcTQ6@mail.gmail.com>
On Mon, Oct 25, 2010 at 8:53 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> 4. Kernel manages the connection establishment, currently there isn't
> a way to change the connection parameters. BMI or ioctls will be
> required to change the default parameters and also to trigger SMP
> negotiation.
Another idea would be to use setsockopt(), like it's currently being
used for HCI filters (see lib/hci.c). E.g.:
hci_filter_clear(&nf);
hci_filter_set_ptype(HCI_EVENT_PKT, &nf);
hci_filter_set_event(EVT_LE_META_EVENT, &nf);
setsockopt(dd, SOL_HCI, HCI_FILTER, &nf, sizeof(nf);
Not sure if the SMP negotiation happens too soon to use it though.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 1/1] Fix fd comparison and comment
From: Elvis Pfützenreuter @ 2010-10-25 13:29 UTC (permalink / raw)
To: linux-bluetooth; +Cc: epx
---
health/hdp.c | 6 +++---
health/mcap_sync.c | 2 +-
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index fd3b1ca..7332cd5 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -339,7 +339,7 @@ static DBusMessage *manager_create_application(DBusConnection *conn,
"Can't get sender name");
}
- if (!set_app_path(app)){
+ if (!set_app_path(app)) {
free_application(app);
return g_dbus_create_error(msg,
ERROR_INTERFACE ".HealthError",
@@ -477,7 +477,7 @@ static void hdp_mdl_reconn_cb(struct mcap_mdl *mdl, GError *err, gpointer data)
}
fd = mcap_mdl_get_fd(dc_data->hdp_chann->mdl);
- if (fd <= 0)
+ if (fd < 0)
reply = g_dbus_create_error(dc_data->msg,
ERROR_INTERFACE ".HealthError",
"Cannot get file descriptor");
@@ -568,7 +568,7 @@ static DBusMessage *channel_acquire_continue(struct hdp_tmp_dc_data *data,
}
fd = mcap_mdl_get_fd(data->hdp_chann->mdl);
- if (fd > 0)
+ if (fd >= 0)
return g_dbus_create_reply(data->msg, DBUS_TYPE_UNIX_FD, &fd,
DBUS_TYPE_INVALID);
diff --git a/health/mcap_sync.c b/health/mcap_sync.c
index 49661a7..57ba0fd 100644
--- a/health/mcap_sync.c
+++ b/health/mcap_sync.c
@@ -350,7 +350,7 @@ static gboolean initialize_caps(struct mcap_mcl *mcl)
clock_gettime(CLK, &t1);
read_btclock_retry(mcl, &btclock, &btaccuracy);
- /* Do clock read a number of times and measure latency */
+ /* Read clock a number of times and measure latency */
avg = 0;
i = 0;
retries = MAX_RETRIES;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 3/6] Bluetooth: Implement the first SMP commands
From: Gustavo F. Padovan @ 2010-10-25 13:03 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth, Vinicius Costa Gomes
In-Reply-To: <1287791820-22693-4-git-send-email-anderson.briglia@openbossa.org>
Hi Vinicius,
* Anderson Briglia <anderson.briglia@openbossa.org> [2010-10-22 19:56:57 -0400]:
> From: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
>
> These simple commands will allow the SMP procedure to be started
> and terminated with a not supported error. This is the first step
> toward something useful.
>
> Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
> ---
> net/bluetooth/l2cap.c | 117 +++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 117 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index 1ac44f4..ba87c84 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -54,6 +54,7 @@
> #include <net/bluetooth/bluetooth.h>
> #include <net/bluetooth/hci_core.h>
> #include <net/bluetooth/l2cap.h>
> +#include <net/bluetooth/smp.h>
>
> #define VERSION "2.15"
>
> @@ -307,6 +308,85 @@ static void l2cap_chan_del(struct sock *sk, int err)
> }
> }
>
> +static struct sk_buff *smp_build_cmd(struct l2cap_conn *conn, u8 code,
> + u16 dlen, void *data)
Call this l2cap_smp_build_cmd()
> +{
> + struct sk_buff *skb;
> + struct l2cap_hdr *lh;
> + int len;
> +
> + len = L2CAP_HDR_SIZE + 1 + dlen;
> +
> + if (len > conn->mtu)
> + return NULL;
> +
> + skb = bt_skb_alloc(len, GFP_ATOMIC);
> + if (!skb)
> + return NULL;
> +
> + lh = (struct l2cap_hdr *) skb_put(skb, L2CAP_HDR_SIZE);
> + lh->len = cpu_to_le16(1 + dlen);
cpu_to_le16(len - L2CAP_HDR_SIZE) here
> + lh->cid = cpu_to_le16(L2CAP_CID_SMP);
> +
> + memcpy(skb_put(skb, 1), &code, 1);
> +
> + memcpy(skb_put(skb, dlen), data, dlen);
> +
> + return skb;
> +}
> +
> +static inline void smp_send_cmd(struct l2cap_conn *conn, u8 code, u16 len, void *data)
and this l2cap_smp_send_cmd.
> +{
> + struct sk_buff *skb = smp_build_cmd(conn, code, len, data);
> +
> + BT_DBG("code 0x%2.2x", code);
> +
> + if (!skb)
> + return;
> +
> + hci_send_acl(conn->hcon, skb, 0);
> +}
> +
> +static int smp_conn_security(struct l2cap_conn *conn, __u8 sec_level)
> +{
l2cap_smp_conn_security() here.
> + __u8 authreq;
> +
> + BT_DBG("conn %p hcon %p level 0x%2.2x", conn, conn->hcon, sec_level);
> +
> + switch (sec_level) {
> + case BT_SECURITY_MEDIUM:
> + /* Encrypted, no MITM protection */
> + authreq = 0x01;
> + break;
> +
> + case BT_SECURITY_HIGH:
> + /* Bonding, MITM protection */
> + authreq = 0x05;
> + break;
> +
> + case BT_SECURITY_LOW:
> + default:
> + return 1;
> + }
> +
> + if (conn->hcon->link_mode & HCI_LM_MASTER) {
> + struct smp_cmd_pairing cp;
> + cp.io_capability = 0x00;
> + cp.oob_flag = 0x00;
> + cp.max_key_size = 16;
> + cp.init_key_dist = 0x00;
> + cp.resp_key_dist = 0x00;
> + cp.auth_req = authreq;
> + smp_send_cmd(conn, SMP_CMD_PAIRING_REQ, sizeof(cp), &cp);
> + } else {
> + struct smp_cmd_security_req cp;
> + cp.auth_req = authreq;
> + smp_send_cmd(conn, SMP_CMD_SECURITY_REQ, sizeof(cp), &cp);
> + }
> +
> + return 0;
> +}
> +
> /* Service level security */
> static inline int l2cap_check_security(struct sock *sk)
> {
> @@ -4562,6 +4642,43 @@ done:
> return 0;
> }
>
> +static inline void smp_sig_channel(struct l2cap_conn *conn, struct sk_buff *skb)
l2cap_smp_sig_channel()
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* [RFC] LE connections and advertising management
From: Claudio Takahasi @ 2010-10-25 12:53 UTC (permalink / raw)
To: BlueZ development
Hi all,
Interleave BR/EDR/LE discovery is implemented, the next step in the
user space is how to manage advertising and LE connections.
Some aspects:
1. Only one LE connection is allowed(per peer), meaning only one
GAttrib instance will be allowed otherwise it will not be possible to
serialize commands/events
2. The remote/Peripheral can support more than one GATT primary service
3. We are planning to use "direct" connections only, meaning that we
will not use whitelist and the application interested must inform the
remote address/object to connect to.
4. Kernel manages the connection establishment, currently there isn't
a way to change the connection parameters. BMI or ioctls will be
required to change the default parameters and also to trigger SMP
negotiation.
Some ideas:
1. implement a characteristic driver: basically to provide an
abstraction to GATT clients. ex: Proximity, Health, ...
2. We don't need to implement Proximity and other GATT clients as a
plugin at the moment, it can be enabled automatically by
--enable-attrib
3. GATT clients could register a watcher/filter for advertising events
4. GATT clients doesn't need to know ATT, in theory it can handle
characteristics only
5. GATT clients needs to control/request LE connections based on the
advertisement received
An initial draft implementing part of this idea is here:
git://git.infradead.org/users/cktakahasi/bluez.git devel
Comments?
Regards,
Claudio
^ permalink raw reply
* Re: [PATCH] bluetooth: Fix NULL pointer dereference issue
From: Yuri Ershov @ 2010-10-25 12:23 UTC (permalink / raw)
To: ext Gustavo F. Padovan
Cc: marcel, davem, jprvita, linux-bluetooth, ville.tervo,
andrei.emeltchenko
In-Reply-To: <20101022135859.GA15476@vigoh>
[-- Attachment #1: Type: text/plain, Size: 1732 bytes --]
Hello Gustavo,
The problem appears in case of multiple connect-transfer-disconnect
sequence (e.g. by using l2test). The conditions are the following:
There are 2 BT devices. The first one listens and receives (l2test -r),
the second one makes "connect-disconnect-connect..." sequence (l2test -c
-b 1000 -i hci0 -P 10 <addr>). After some time this will cause the race
between functions bt_accept_dequeue and l2cap_chan_del. The fail sequence:
struct sock *bt_accept_dequeue(struct sock *parent, struct socket *newsock)
{
...
list_for_each_safe(p, n, &bt_sk(parent)->accept_q) {
sk = (struct sock *) list_entry(p, struct bt_sock, accept_q);
lock_sock(sk);
In this time the function l2cap_chan_del sets the socket state to
BT_CLOSED, unlinks and kills the socket.
/* FIXME: Is this check still needed */
if (sk->sk_state == BT_CLOSED) {
release_sock(sk);
bt_accept_unlink(sk);
continue;
}
...
release_sock(sk);
}
return NULL;
}
Regards,
Yuri
ext Gustavo F. Padovan wrote:
> Hi Yuri,
>
> * Yuri Ershov <ext-yuri.ershov@nokia.com> [2010-10-21 20:08:58 +0400]:
>
>
>> This patch fixes NULL pointer dereference at running test with
>> connect-transfer-disconnect in loop. Sometimes sk_state is
>> BT_CLOSED and sk_refcnt equal to 0, so there is oops in
>> bt_accept_unlink. In normal case removed block is not used.
>>
>
> Question here is: Why sk_refcnt is 0 at that point of the code? The
> socket should be destroyed if it ref is 0, but it wasn't, so something
> in another point of the code went is wrong. "Sometimes" is not a good
> description of the problem, you have to show why that happened.
>
>
[-- Attachment #2: Type: text/html, Size: 2746 bytes --]
^ permalink raw reply
* [PATCH 6/6] Bluetooth: Do not send disconn comand over LE links
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
l2cap over LE links can be disconnected without sending
disconnect command first.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
net/bluetooth/l2cap.c | 15 ++++++++++-----
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 3913ba5..2da613b 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -873,6 +873,8 @@ static void l2cap_sock_kill(struct sock *sk)
static void __l2cap_sock_close(struct sock *sk, int reason)
{
+ struct l2cap_conn *conn;
+
BT_DBG("sk %p state %d socket %p", sk, sk->sk_state, sk->sk_socket);
switch (sk->sk_state) {
@@ -882,8 +884,10 @@ static void __l2cap_sock_close(struct sock *sk, int reason)
case BT_CONNECTED:
case BT_CONFIG:
- if (sk->sk_type == SOCK_SEQPACKET ||
- sk->sk_type == SOCK_STREAM) {
+ conn = l2cap_pi(sk)->conn;
+ if ((sk->sk_type == SOCK_SEQPACKET ||
+ sk->sk_type == SOCK_STREAM) &&
+ conn->hcon->type != LE_LINK) {
struct l2cap_conn *conn = l2cap_pi(sk)->conn;
l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
@@ -893,9 +897,10 @@ static void __l2cap_sock_close(struct sock *sk, int reason)
break;
case BT_CONNECT2:
- if (sk->sk_type == SOCK_SEQPACKET ||
- sk->sk_type == SOCK_STREAM) {
- struct l2cap_conn *conn = l2cap_pi(sk)->conn;
+ conn = l2cap_pi(sk)->conn;
+ if ((sk->sk_type == SOCK_SEQPACKET ||
+ sk->sk_type == SOCK_STREAM) &&
+ conn->hcon->type != LE_LINK) {
struct l2cap_conn_rsp rsp;
__u16 result;
--
1.7.1
^ permalink raw reply related
* [PATCH 5/6] Bluetooth: Add server socket support for LE connection
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
Add support for LE server sockets.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/l2cap.h | 1 +
net/bluetooth/hci_event.c | 10 +++-
net/bluetooth/l2cap.c | 101 +++++++++++++++++++++++++++++++++++++++--
3 files changed, 105 insertions(+), 7 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index cc3a140..cba4423 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -38,6 +38,7 @@
#define L2CAP_DEFAULT_MAX_PDU_SIZE 1009 /* Sized for 3-DH5 packet */
#define L2CAP_DEFAULT_ACK_TO 200
#define L2CAP_LOCAL_BUSY_TRIES 12
+#define L2CAP_LE_DEFAULT_MTU 23
#define L2CAP_CONN_TIMEOUT (40000) /* 40 seconds */
#define L2CAP_INFO_TIMEOUT (4000) /* 4 seconds */
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index da23502..464d0cc 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1914,8 +1914,14 @@ static inline void hci_le_conn_complete_evt(struct hci_dev *hdev, struct sk_buff
hci_dev_lock(hdev);
conn = hci_conn_hash_lookup_ba(hdev, LE_LINK, &ev->bdaddr);
- if (!conn)
- goto unlock;
+ if (!conn) {
+ conn = hci_conn_add(hdev, LE_LINK, &ev->bdaddr);
+ if (!conn) {
+ BT_ERR("No memory for new connection");
+ hci_dev_unlock(hdev);
+ return;
+ }
+ }
if (ev->status) {
hci_proto_connect_cfm(conn, ev->status);
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 18643af..3913ba5 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -82,6 +82,8 @@ static struct sk_buff *l2cap_build_cmd(struct l2cap_conn *conn,
static int l2cap_ertm_data_rcv(struct sock *sk, struct sk_buff *skb);
+static void l2cap_le_conn_ready(struct l2cap_conn *conn);
+
/* ---- L2CAP timers ---- */
static void l2cap_sock_timeout(unsigned long arg)
{
@@ -228,8 +230,16 @@ static void __l2cap_chan_add(struct l2cap_conn *conn, struct sock *sk, struct so
l2cap_pi(sk)->conn = conn;
if (sk->sk_type == SOCK_SEQPACKET || sk->sk_type == SOCK_STREAM) {
- /* Alloc CID for connection-oriented socket */
- l2cap_pi(sk)->scid = l2cap_alloc_cid(l);
+ if (conn->hcon->type == LE_LINK) {
+ /* LE connection */
+ l2cap_pi(sk)->omtu = L2CAP_LE_DEFAULT_MTU;
+ l2cap_pi(sk)->scid = L2CAP_CID_LE_DATA;
+ l2cap_pi(sk)->dcid = L2CAP_CID_LE_DATA;
+ } else {
+ /* Alloc CID for connection-oriented socket */
+ l2cap_pi(sk)->scid = l2cap_alloc_cid(l);
+ l2cap_pi(sk)->omtu = L2CAP_DEFAULT_MTU;
+ }
} else if (sk->sk_type == SOCK_DGRAM) {
/* Connectionless socket */
l2cap_pi(sk)->scid = L2CAP_CID_CONN_LESS;
@@ -612,6 +622,9 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
BT_DBG("conn %p", conn);
+ if (!conn->hcon->out && conn->hcon->type == LE_LINK)
+ l2cap_le_conn_ready(conn);
+
read_lock(&l->lock);
for (sk = l->head; sk; sk = l2cap_pi(sk)->next_c) {
@@ -694,7 +707,8 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon, u8 status)
spin_lock_init(&conn->lock);
rwlock_init(&conn->chan_list.lock);
- setup_timer(&conn->info_timer, l2cap_info_timeout,
+ if (hcon->type != LE_LINK)
+ setup_timer(&conn->info_timer, l2cap_info_timeout,
(unsigned long) conn);
conn->disc_reason = 0x13;
@@ -796,6 +810,37 @@ static void l2cap_sock_destruct(struct sock *sk)
skb_queue_purge(&sk->sk_write_queue);
}
+static inline struct sock *l2cap_get_sock_by_cid(int state, __le16 cid, bdaddr_t *src)
+{
+ struct sock *s;
+ struct sock *sk = NULL, *sk1 = NULL;
+ struct hlist_node *node;
+
+ read_lock(&l2cap_sk_list.lock);
+ sk_for_each(sk, node, &l2cap_sk_list.head) {
+ if (state && sk->sk_state != state)
+ continue;
+
+ if (l2cap_pi(sk)->dcid == cid) {
+ /* Exact match. */
+ if (!bacmp(&bt_sk(sk)->src, src))
+ break;
+
+ /* Closest match */
+ if (!bacmp(&bt_sk(sk)->src, BDADDR_ANY))
+ sk1 = sk;
+ }
+ }
+
+ s = node ? sk : sk1;
+
+ if (s)
+ bh_lock_sock(s);
+ read_unlock(&l2cap_sk_list.lock);
+
+ return s;
+}
+
static void l2cap_sock_cleanup_listen(struct sock *parent)
{
struct sock *sk;
@@ -1008,7 +1053,7 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
len = min_t(unsigned int, sizeof(la), alen);
memcpy(&la, addr, len);
- if (la.l2_cid)
+ if (la.l2_cid && la.l2_psm)
return -EINVAL;
lock_sock(sk);
@@ -1050,6 +1095,9 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
l2cap_pi(sk)->sec_level = BT_SECURITY_SDP;
}
+ if (la.l2_cid)
+ l2cap_pi(sk)->dcid = la.l2_cid;
+
write_unlock_bh(&l2cap_sk_list.lock);
done:
@@ -1267,7 +1315,7 @@ static int l2cap_sock_listen(struct socket *sock, int backlog)
goto done;
}
- if (!l2cap_pi(sk)->psm) {
+ if (!l2cap_pi(sk)->psm && !l2cap_pi(sk)->dcid) {
bdaddr_t *src = &bt_sk(sk)->src;
u16 psm;
@@ -1377,6 +1425,49 @@ static int l2cap_sock_getname(struct socket *sock, struct sockaddr *addr, int *l
return 0;
}
+static void l2cap_le_conn_ready(struct l2cap_conn *conn)
+{
+ struct l2cap_chan_list *list = &conn->chan_list;
+ struct sock *parent, *uninitialized_var(sk);
+
+ BT_DBG("");
+
+ /* Check if we have socket listening on cid */
+ parent = l2cap_get_sock_by_cid(BT_LISTEN, 0x04, conn->src);
+ if (!parent)
+ goto clean;
+
+ /* Check for backlog size */
+ if (sk_acceptq_is_full(parent)) {
+ BT_DBG("backlog full %d", parent->sk_ack_backlog);
+ goto clean;
+ }
+
+ sk = l2cap_sock_alloc(sock_net(parent), NULL, BTPROTO_L2CAP, GFP_ATOMIC);
+ if (!sk)
+ goto clean;
+
+ write_lock_bh(&list->lock);
+
+ hci_conn_hold(conn->hcon);
+
+ l2cap_sock_init(sk, parent);
+ bacpy(&bt_sk(sk)->src, conn->src);
+ bacpy(&bt_sk(sk)->dst, conn->dst);
+
+ __l2cap_chan_add(conn, sk, parent);
+
+ l2cap_sock_set_timer(sk, sk->sk_sndtimeo);
+
+ sk->sk_state = BT_CONNECTED;
+ parent->sk_data_ready(parent, 0);
+
+ write_unlock_bh(&list->lock);
+
+clean:
+ bh_unlock_sock(parent);
+}
+
static int __l2cap_wait_ack(struct sock *sk)
{
DECLARE_WAITQUEUE(wait, current);
--
1.7.1
^ permalink raw reply related
* [PATCH 4/6] Bluetooth: Add LE connection support to L2CAP
From: Ville Tervo @ 2010-10-25 12:21 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Ville Tervo
In-Reply-To: <1288009280-5149-1-git-send-email-ville.tervo@nokia.com>
Add basic LE connection support to L2CAP. LE
connection can be created by specifying cid
in struct sockaddr_l2
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
include/net/bluetooth/l2cap.h | 3 +++
net/bluetooth/l2cap.c | 32 ++++++++++++++++++++++++--------
2 files changed, 27 insertions(+), 8 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index c819c8b..cc3a140 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -160,6 +160,9 @@ struct l2cap_conn_rsp {
/* channel indentifier */
#define L2CAP_CID_SIGNALING 0x0001
#define L2CAP_CID_CONN_LESS 0x0002
+#define L2CAP_CID_LE_DATA 0x0004
+#define L2CAP_CID_LE_SIGNALING 0x0005
+#define L2CAP_CID_SMP 0x0006
#define L2CAP_CID_DYN_START 0x0040
#define L2CAP_CID_DYN_END 0xffff
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 6f931cc..18643af 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -617,6 +617,12 @@ static void l2cap_conn_ready(struct l2cap_conn *conn)
for (sk = l->head; sk; sk = l2cap_pi(sk)->next_c) {
bh_lock_sock(sk);
+ if (conn->hcon->type == LE_LINK) {
+ l2cap_sock_clear_timer(sk);
+ sk->sk_state = BT_CONNECTED;
+ sk->sk_state_change(sk);
+ }
+
if (sk->sk_type != SOCK_SEQPACKET &&
sk->sk_type != SOCK_STREAM) {
l2cap_sock_clear_timer(sk);
@@ -675,7 +681,11 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon, u8 status)
BT_DBG("hcon %p conn %p", hcon, conn);
- conn->mtu = hcon->hdev->acl_mtu;
+ if (hcon->hdev->le_mtu && hcon->type == LE_LINK)
+ conn->mtu = hcon->hdev->le_mtu;
+ else
+ conn->mtu = hcon->hdev->acl_mtu;
+
conn->src = &hcon->hdev->bdaddr;
conn->dst = &hcon->dst;
@@ -1102,8 +1112,13 @@ static int l2cap_do_connect(struct sock *sk)
}
}
- hcon = hci_connect(hdev, ACL_LINK, dst,
+ if (l2cap_pi(sk)->dcid == L2CAP_CID_LE_DATA)
+ hcon = hci_connect(hdev, LE_LINK, dst,
+ l2cap_pi(sk)->sec_level, auth_type);
+ else
+ hcon = hci_connect(hdev, ACL_LINK, dst,
l2cap_pi(sk)->sec_level, auth_type);
+
if (!hcon)
goto done;
@@ -1154,13 +1169,13 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr, int al
len = min_t(unsigned int, sizeof(la), alen);
memcpy(&la, addr, len);
- if (la.l2_cid)
+ if (la.l2_cid && la.l2_psm)
return -EINVAL;
lock_sock(sk);
if ((sk->sk_type == SOCK_SEQPACKET || sk->sk_type == SOCK_STREAM)
- && !la.l2_psm) {
+ && !(la.l2_psm || la.l2_cid)) {
err = -EINVAL;
goto done;
}
@@ -1202,14 +1217,15 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr, int al
/* PSM must be odd and lsb of upper byte must be 0 */
if ((__le16_to_cpu(la.l2_psm) & 0x0101) != 0x0001 &&
- sk->sk_type != SOCK_RAW) {
+ sk->sk_type != SOCK_RAW && !la.l2_cid) {
err = -EINVAL;
goto done;
}
- /* Set destination address and psm */
+ /* Set destination address and psm or cid */
bacpy(&bt_sk(sk)->dst, &la.l2_bdaddr);
l2cap_pi(sk)->psm = la.l2_psm;
+ l2cap_pi(sk)->dcid = la.l2_cid;
err = l2cap_do_connect(sk);
if (err)
@@ -4525,7 +4541,7 @@ static int l2cap_connect_cfm(struct hci_conn *hcon, u8 status)
BT_DBG("hcon %p bdaddr %s status %d", hcon, batostr(&hcon->dst), status);
- if (hcon->type != ACL_LINK)
+ if (!(hcon->type == ACL_LINK || hcon->type == LE_LINK))
return -EINVAL;
if (!status) {
@@ -4554,7 +4570,7 @@ static int l2cap_disconn_cfm(struct hci_conn *hcon, u8 reason)
{
BT_DBG("hcon %p reason %d", hcon, reason);
- if (hcon->type != ACL_LINK)
+ if (!(hcon->type == ACL_LINK || hcon->type == LE_LINK))
return -EINVAL;
l2cap_conn_del(hcon, bt_err(reason));
--
1.7.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox