* Re: Pull request git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
From: Johan Hedberg @ 2010-11-19 16:50 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimQB+-odX2Yw+gxrdd2SBajxZ3nswtffW+L-g9_@mail.gmail.com>
Hi Luiz,
On Fri, Nov 19, 2010, Luiz Augusto von Dentz wrote:
> Those changes fixes several issues when doing a Device.Disconnect
> while some audio profile is still connecting. I did some cleanups to
> make it easier to track references and reuse more code, and also did a
> lot o testing to make sure it doesn't cause any regression for cases
> where the client is using Media API or unix socket.
>
> The following changes since commit 55685d2037d33ed29ed7365150fd14b5326690fb:
>
> Fix minor typo (2010-11-19 17:39:15 +0200)
>
> are available in the git repository at:
> git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
>
> Luiz Augusto von Dentz (9):
> Cleanup a2dp setup code
> Cleanup a2dp_cancel code
> Fix not removing all timers when user request to disconnect audio
> Fix abort not being send when the state is idle
> Fix reference count of a2dp stream setup
> Add debug logs for state changes on sink
> Fix possible crashes when attempting to connect avdtp
> Fix not dropping avdtp session reference when cancelling stream setup
> Fix not indicating disconnected state when connecting to avdtp
>
> audio/a2dp.c | 258 +++++++++++++++++++++++++------------------------------
> audio/avdtp.c | 26 +++---
> audio/device.c | 36 ++++----
> audio/sink.c | 13 +++
> 4 files changed, 163 insertions(+), 170 deletions(-)
Thanks! The patches have been pushed upstream.
Johan
^ permalink raw reply
* Pull request git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
From: Luiz Augusto von Dentz @ 2010-11-19 16:31 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Those changes fixes several issues when doing a Device.Disconnect
while some audio profile is still connecting. I did some cleanups to
make it easier to track references and reuse more code, and also did a
lot o testing to make sure it doesn't cause any regression for cases
where the client is using Media API or unix socket.
The following changes since commit 55685d2037d33ed29ed7365150fd14b5326690fb:
Fix minor typo (2010-11-19 17:39:15 +0200)
are available in the git repository at:
git://gitorious.org/~vudentz/bluez/vudentzs-clone.git for-upstream
Luiz Augusto von Dentz (9):
Cleanup a2dp setup code
Cleanup a2dp_cancel code
Fix not removing all timers when user request to disconnect audio
Fix abort not being send when the state is idle
Fix reference count of a2dp stream setup
Add debug logs for state changes on sink
Fix possible crashes when attempting to connect avdtp
Fix not dropping avdtp session reference when cancelling stream setup
Fix not indicating disconnected state when connecting to avdtp
audio/a2dp.c | 258 +++++++++++++++++++++++++------------------------------
audio/avdtp.c | 26 +++---
audio/device.c | 36 ++++----
audio/sink.c | 13 +++
4 files changed, 163 insertions(+), 170 deletions(-)
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH v2 2/2] Avoid reallocations of services UUID array
From: Johan Hedberg @ 2010-11-19 15:30 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1290178759-9270-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Fri, Nov 19, 2010, Anderson Lizardo wrote:
> The array of service UUIDs used by the DeviceFound signal contains the
> same information from the GSList of services. Instead of reallocating
> this array on each signal, store it on the remote_dev_info structure and
> only reallocate it if there are new UUIDs.
> ---
> src/adapter.c | 18 +++++++++---------
> src/adapter.h | 3 ++-
> 2 files changed, 11 insertions(+), 10 deletions(-)
This one has also been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Merge service UUIDs from different BR/EDR EIR data
From: Johan Hedberg @ 2010-11-19 15:29 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth
In-Reply-To: <1290178241-8358-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Fri, Nov 19, 2010, Anderson Lizardo wrote:
> For LE devices, service UUIDs present in advertising data are merged
> into a single list. This change makes the same thing for BR/EDR devices.
> ---
> src/adapter.c | 6 ------
> 1 files changed, 0 insertions(+), 6 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Extract flags from advertising data
From: Johan Hedberg @ 2010-11-19 15:28 UTC (permalink / raw)
To: Bruna Moreira; +Cc: linux-bluetooth
In-Reply-To: <1290175048-16026-1-git-send-email-bruna.moreira@openbossa.org>
Hi Bruna,
On Fri, Nov 19, 2010, Bruna Moreira wrote:
> These flags will be used to decide if GATT service discovery will happen
> over LE (for single mode devices) or BR/EDR (for dual mode and non-LE
> devices).
> ---
> src/adapter.c | 14 ++++++++++++++
> src/adapter.h | 1 +
> src/sdpd.h | 10 ++++++++++
> 3 files changed, 25 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Johan Hedberg @ 2010-11-19 15:25 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1290173697-20097-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Fri, Nov 19, 2010, Sheldon Demario wrote:
> Sub-procedure used to read a Characteristic Value when the client
> only knows the characteristic UUID and doesn't know the handle.
> More than one handle and attribute value pair can be returned,
> it is up to the user define the handles range based on the service
> handles range.
>
> Usage example:
> $gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
> ---
> attrib/gatt.c | 15 ++++++++++++---
> attrib/gatt.h | 4 ++++
> attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] hciattach: send hci commands after hci socket bring up
From: Johan Hedberg @ 2010-11-19 15:24 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1290145903-11452-1-git-send-email-suraj@atheros.com>
Hi,
On Fri, Nov 19, 2010, Suraj Sumangala wrote:
> This patch makes The Atheros AR300x specific initialization code
> to send power management command over HCI socket after bringing up
> the device.
>
> ---
> tools/hciattach_ath3k.c | 10 ++++++++--
> 1 files changed, 8 insertions(+), 2 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH] Add command line option to change BCSP rate
From: Johan Hedberg @ 2010-11-19 15:23 UTC (permalink / raw)
To: Wade Brown; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <6EBC2ED6C3CFDC428167C1FF4764F0710A96D8BE9A1A@SJEXBEC1.research.us.panasonic.com>
Hi,
On Thu, Nov 18, 2010, Wade Brown wrote:
> Currently when using bccmd to do any communication, the UART is always
> opened at 38.4kbps. Once the CSR has been initialized to any other
> speed, bccmd can no longer communicate with with the radio (unless by
> resetting it through rfkill). This patch adds a -b option allowing a
> user to manually set a different speed, with the default 38400 still in
> place.
>
> Usage example:
> $bccmd -t BCSP -b 921600 -d /dev/ttyHS1 chiprev
>
> ---
> tools/bccmd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
> tools/csr.h | 3 ++-
> tools/csr_bcsp.c | 4 ++--
> 3 files changed, 44 insertions(+), 8 deletions(-)
The patch seems fine to me but I can't figure out how to apply it either
due to your mail client or your mail server. It's not sent inline and
the attachment isn't a complete git patch as such. Additionally there's
some strange winmail.dat attachment in the mail. Could you try resending
e.g. using git send-email?
Johan
^ permalink raw reply
* [PATCH v2 2/2] Avoid reallocations of services UUID array
From: Anderson Lizardo @ 2010-11-19 14:59 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
The array of service UUIDs used by the DeviceFound signal contains the
same information from the GSList of services. Instead of reallocating
this array on each signal, store it on the remote_dev_info structure and
only reallocate it if there are new UUIDs.
---
src/adapter.c | 18 +++++++++---------
src/adapter.h | 3 ++-
2 files changed, 11 insertions(+), 10 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c650a63..4fe8276 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -204,6 +204,7 @@ static void dev_info_free(struct remote_dev_info *dev)
g_free(dev->alias);
g_slist_foreach(dev->services, (GFunc) g_free, NULL);
g_slist_free(dev->services);
+ g_strfreev(dev->uuids);
g_free(dev);
}
@@ -2964,7 +2965,6 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
dbus_bool_t paired = FALSE;
dbus_int16_t rssi = dev->rssi;
char *alias;
- char **uuids = NULL;
size_t uuid_count;
ba2str(&dev->bdaddr, peer_addr);
@@ -2977,9 +2977,11 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
/* Extract UUIDs from extended inquiry response if any */
dev->services = get_eir_uuids(eir_data, eir_length, dev->services);
uuid_count = g_slist_length(dev->services);
-
- if (dev->services)
- uuids = strlist2array(dev->services);
+ if (dev->services && dev->uuid_count != uuid_count) {
+ g_strfreev(dev->uuids);
+ dev->uuids = strlist2array(dev->services);
+ dev->uuid_count = uuid_count;
+ }
if (dev->le) {
emit_device_found(adapter->path, paddr,
@@ -2987,9 +2989,8 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"RSSI", DBUS_TYPE_INT16, &rssi,
"Name", DBUS_TYPE_STRING, &dev->name,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
- NULL);
- g_strfreev(uuids);
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids,
+ dev->uuid_count, NULL);
return;
}
@@ -3013,11 +3014,10 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"Alias", DBUS_TYPE_STRING, &alias,
"LegacyPairing", DBUS_TYPE_BOOLEAN, &dev->legacy,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids, dev->uuid_count,
NULL);
g_free(alias);
- g_strfreev(uuids);
}
static struct remote_dev_info *get_found_dev(struct btd_adapter *adapter,
diff --git a/src/adapter.h b/src/adapter.h
index 4af69b3..955bb9a 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -70,7 +70,8 @@ struct remote_dev_info {
dbus_bool_t legacy;
name_status_t name_status;
gboolean le;
- /* LE adv data */
+ char **uuids;
+ size_t uuid_count;
GSList *services;
uint8_t evt_type;
uint8_t bdaddr_type;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] Avoid reallocations of services UUID array
From: Anderson Lizardo @ 2010-11-19 14:53 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1290178241-8358-2-git-send-email-anderson.lizardo@openbossa.org>
On Fri, Nov 19, 2010 at 10:50 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> The array of service UUIDs used by the DeviceFound signal contains the
> same information from the GSList of services. Instead of reallocating
> this array on each signal, store it on the remote_dev_info structure and
> only reallocate it if there are new UUIDs.
Oops, just noticed I forgot to free the dev->uuids array. Will send a
fixed patch ASAP.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 2/2] Avoid reallocations of services UUID array
From: Anderson Lizardo @ 2010-11-19 14:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1290178241-8358-1-git-send-email-anderson.lizardo@openbossa.org>
The array of service UUIDs used by the DeviceFound signal contains the
same information from the GSList of services. Instead of reallocating
this array on each signal, store it on the remote_dev_info structure and
only reallocate it if there are new UUIDs.
---
src/adapter.c | 17 ++++++++---------
src/adapter.h | 3 ++-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c650a63..1e51d11 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2964,7 +2964,6 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
dbus_bool_t paired = FALSE;
dbus_int16_t rssi = dev->rssi;
char *alias;
- char **uuids = NULL;
size_t uuid_count;
ba2str(&dev->bdaddr, peer_addr);
@@ -2977,9 +2976,11 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
/* Extract UUIDs from extended inquiry response if any */
dev->services = get_eir_uuids(eir_data, eir_length, dev->services);
uuid_count = g_slist_length(dev->services);
-
- if (dev->services)
- uuids = strlist2array(dev->services);
+ if (dev->services && dev->uuid_count != uuid_count) {
+ g_strfreev(dev->uuids);
+ dev->uuids = strlist2array(dev->services);
+ dev->uuid_count = uuid_count;
+ }
if (dev->le) {
emit_device_found(adapter->path, paddr,
@@ -2987,9 +2988,8 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"RSSI", DBUS_TYPE_INT16, &rssi,
"Name", DBUS_TYPE_STRING, &dev->name,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
- NULL);
- g_strfreev(uuids);
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids,
+ dev->uuid_count, NULL);
return;
}
@@ -3013,11 +3013,10 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
"Alias", DBUS_TYPE_STRING, &alias,
"LegacyPairing", DBUS_TYPE_BOOLEAN, &dev->legacy,
"Paired", DBUS_TYPE_BOOLEAN, &paired,
- "UUIDs", DBUS_TYPE_ARRAY, &uuids, uuid_count,
+ "UUIDs", DBUS_TYPE_ARRAY, &dev->uuids, dev->uuid_count,
NULL);
g_free(alias);
- g_strfreev(uuids);
}
static struct remote_dev_info *get_found_dev(struct btd_adapter *adapter,
diff --git a/src/adapter.h b/src/adapter.h
index 4af69b3..955bb9a 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -70,7 +70,8 @@ struct remote_dev_info {
dbus_bool_t legacy;
name_status_t name_status;
gboolean le;
- /* LE adv data */
+ char **uuids;
+ size_t uuid_count;
GSList *services;
uint8_t evt_type;
uint8_t bdaddr_type;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/2] Merge service UUIDs from different BR/EDR EIR data
From: Anderson Lizardo @ 2010-11-19 14:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
For LE devices, service UUIDs present in advertising data are merged
into a single list. This change makes the same thing for BR/EDR devices.
---
src/adapter.c | 6 ------
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 8136229..c650a63 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3004,12 +3004,6 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
} else
alias = g_strdup(dev->alias);
- if (dev->services) {
- g_slist_foreach(dev->services, (GFunc) g_free, NULL);
- g_slist_free(dev->services);
- dev->services = NULL;
- }
-
emit_device_found(adapter->path, paddr,
"Address", DBUS_TYPE_STRING, &paddr,
"Class", DBUS_TYPE_UINT32, &dev->class,
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Extract flags from advertising data
From: Bruna Moreira @ 2010-11-19 13:57 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Bruna Moreira
These flags will be used to decide if GATT service discovery will happen
over LE (for single mode devices) or BR/EDR (for dual mode and non-LE
devices).
---
src/adapter.c | 14 ++++++++++++++
src/adapter.h | 1 +
src/sdpd.h | 10 ++++++++++
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 8136229..648d2a8 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3053,6 +3053,18 @@ static struct remote_dev_info *get_found_dev(struct btd_adapter *adapter,
return dev;
}
+static uint8_t extract_eir_flags(uint8_t *eir_data)
+{
+ if (eir_data[0] == 0)
+ return 0;
+
+ if (eir_data[1] != EIR_FLAGS)
+ return 0;
+
+ /* For now, only one octet is used for flags */
+ return eir_data[2];
+}
+
void adapter_update_device_from_info(struct btd_adapter *adapter,
le_advertising_info *info)
{
@@ -3084,6 +3096,8 @@ void adapter_update_device_from_info(struct btd_adapter *adapter,
g_free(dev->name);
dev->name = tmp_name;
}
+
+ dev->flags = extract_eir_flags(info->data);
}
/* FIXME: check if other information was changed before emitting the
diff --git a/src/adapter.h b/src/adapter.h
index 4af69b3..3a67539 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -74,6 +74,7 @@ struct remote_dev_info {
GSList *services;
uint8_t evt_type;
uint8_t bdaddr_type;
+ uint8_t flags;
};
struct hci_dev {
diff --git a/src/sdpd.h b/src/sdpd.h
index 5bab869..a46ad3c 100644
--- a/src/sdpd.h
+++ b/src/sdpd.h
@@ -36,6 +36,7 @@
#define EIR_DATA_LENGTH 240
+#define EIR_FLAGS 0x01 /* flags */
#define EIR_UUID16_SOME 0x02 /* 16-bit UUID, more available */
#define EIR_UUID16_ALL 0x03 /* 16-bit UUID, all listed */
#define EIR_UUID32_SOME 0x04 /* 32-bit UUID, more available */
@@ -47,6 +48,15 @@
#define EIR_TX_POWER 0x0A /* transmit power level */
#define EIR_DEVICE_ID 0x10 /* device ID */
+/* Flags Descriptions */
+#define EIR_LIM_DISC 0x01 /* LE Limited Discoverable Mode */
+#define EIR_GEN_DISC 0x02 /* LE General Discoverable Mode */
+#define EIR_BREDR_UNSUP 0x04 /* BR/EDR Not Supported */
+#define EIR_SIM_CONTROLLER 0x08 /* Simultaneous LE and BR/EDR to Same
+ Device Capable (Controller) */
+#define EIR_SIM_HOST 0x10 /* Simultaneous LE and BR/EDR to Same
+ Device Capable (Host) */
+
typedef struct request {
bdaddr_t device;
bdaddr_t bdaddr;
--
1.7.0.4
^ permalink raw reply related
* [PATCH v2] Implement Characteristic Value Read using UUID in the gatttool
From: Sheldon Demario @ 2010-11-19 13:34 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
Sub-procedure used to read a Characteristic Value when the client
only knows the characteristic UUID and doesn't know the handle.
More than one handle and attribute value pair can be returned,
it is up to the user define the handles range based on the service
handles range.
Usage example:
$gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
---
attrib/gatt.c | 15 ++++++++++++---
attrib/gatt.h | 4 ++++
attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 2c87daf..bca8b49 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -74,13 +74,22 @@ guint gatt_discover_primary(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
GAttribResultFunc func, gpointer user_data)
{
- uint8_t pdu[ATT_DEFAULT_MTU];
uuid_t uuid;
- guint16 plen;
sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
- plen = enc_read_by_type_req(start, end, &uuid, pdu, sizeof(pdu));
+ return gatt_read_char_by_uuid(attrib, start, end, &uuid, func,
+ user_data);
+}
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data)
+{
+ uint8_t pdu[ATT_DEFAULT_MTU];
+ guint16 plen;
+
+ plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
if (plen == 0)
return 0;
diff --git a/attrib/gatt.h b/attrib/gatt.h
index 4e7d88b..1e1e628 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -41,3 +41,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
GDestroyNotify notify, gpointer user_data);
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data);
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index e961431..d0ef6d3 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -398,10 +398,49 @@ done:
g_main_loop_quit(event_loop);
}
+static void char_read_by_uuid_cb(guint8 status, const guint8 *pdu,
+ guint16 plen, gpointer user_data)
+{
+ struct att_data_list *list;
+ int i;
+
+ if (status != 0) {
+ g_printerr("Read characteristics by UUID failed: %s\n",
+ att_ecode2str(status));
+ goto done;
+ }
+
+ list = dec_read_by_type_resp(pdu, plen);
+ if (list == NULL)
+ goto done;
+
+ for (i = 0; i < list->num; i++) {
+ uint8_t *value = list->data[i];
+ int j;
+
+ g_print("handle: 0x%04x \t value: ", att_get_u16(value));
+ value += 2;
+ for (j = 0; j < list->len - 2; j++, value++)
+ g_print("%02x ", *value);
+ g_print("\n");
+ }
+
+ att_data_list_free(list);
+
+done:
+ g_main_loop_quit(event_loop);
+}
+
static gboolean characteristics_read(gpointer user_data)
{
GAttrib *attrib = user_data;
+ if (opt_uuid != NULL) {
+ gatt_read_char_by_uuid(attrib, opt_start, opt_end, opt_uuid,
+ char_read_by_uuid_cb, attrib);
+ return FALSE;
+ }
+
if (opt_handle <= 0) {
g_printerr("A valid handle is required\n");
g_main_loop_quit(event_loop);
--
1.7.3.2
^ permalink raw reply related
* Re: New Broadcom chip in W510
From: Lu Ran @ 2010-11-19 6:08 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <201009190926.51131.hephooey@gmail.com>
Hi,
I have made some progress today, appearently 28 is ENOSPC, meaning the usb
host controller does not have enough bandwidth for the device. Indeed when I
unplug my usb mouse I can have playback (mic is still missing with ENOSPC). Is
there a way to reduce the package size from btusb, the mouse is the only
device I can remove, there are a internal camera and figure print reader always
connected.
--
Best Regards,
LR
On Sunday 19 September 2010 09:26:51 Lu Ran wrote:
> Hi all,
>
> I am having trouble to make my headset work in my new W510, it works fine
> in an T61, with has almost identical software and setup with the new W510.
> The only difference is I am now using a pure 64 bit system, while the old
> T61 is a 32 bit one, and the bluetooth chip is different. the id of the
> chip in T61 is 0A5C:2110, while W510 has a chip from Broadcom with id
> 0A5C:217F. I noticed there is a SCO fix for 0A5C:2110 in btusb.c. I tried
> to copy the line and change the id to 0A5C:217F, but nothing changes. The
> headset can pair with the laptop with no problem, but there seems to be no
> data transmition. And I get a lot error messages in dmesg output like
> this:
>
> btusb_submit_isoc_urb: hci0 urb ffff880060136e00 submission failed (28)
>
> and
>
> btusb_send_frame: hci0 urb ffff8801320e1a00 submission failed
>
> the output of "hciconfig hci0 version" is
>
> hci0: Type: BR/EDR Bus: USB
> BD Address: 70:F3:95:34:2F:29 ACL MTU: 1021:8 SCO MTU: 64:8
> HCI Version: 2.1 (0x4) Revision: 0x168
> LMP Version: 2.1 (0x4) Subversion: 0x4203
> Manufacturer: Broadcom Corporation (15)
>
> And the output of "lsusb -v" is in the attachment. I will try to provide
> any other information you need to analyse the problem.
^ permalink raw reply
* [PATCH] hciattach: send hci commands after hci socket bring up
From: Suraj Sumangala @ 2010-11-19 5:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jothikumar.Mothilal, Suraj Sumangala
This patch makes The Atheros AR300x specific initialization code
to send power management command over HCI socket after bringing up
the device.
---
tools/hciattach_ath3k.c | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
diff --git a/tools/hciattach_ath3k.c b/tools/hciattach_ath3k.c
index b891506..70ade30 100644
--- a/tools/hciattach_ath3k.c
+++ b/tools/hciattach_ath3k.c
@@ -884,6 +884,8 @@ int ath3k_post(int fd, int pm)
int dev_id, dd;
struct timespec tm = { 0, 50000 };
+ sleep(1);
+
dev_id = ioctl(fd, HCIUARTGETDEVICE, 0);
if (dev_id < 0) {
perror("cannot get device id");
@@ -896,11 +898,15 @@ int ath3k_post(int fd, int pm)
return dd;
}
- sleep(2);
+ if (ioctl(dd, HCIDEVUP, dev_id) < 0 && errno != EALREADY) {
+ perror("hci down:Power management Disabled");
+ hci_close_dev(dd);
+ return -1;
+ }
/* send vendor specific command with Sleep feature Enabled */
if (hci_send_cmd(dd, OGF_VENDOR_CMD, HCI_SLEEP_CMD_OCF, 1, &pm) < 0)
- perror("Power management Disabled");
+ perror("PM command failed, power management Disabled");
nanosleep(&tm, NULL);
hci_close_dev(dd);
--
1.7.0.4
^ permalink raw reply related
* How to control the bluetooth connetion time
From: Roc Bai @ 2010-11-19 2:02 UTC (permalink / raw)
To: linux-bluetooth
Hi, All:
When i pair my phone with the PC, i have to quickly input the PIN code
with the linux-2.6.35.1 kernel. But i can do it slowly with linux-2.6.26
kernel. All the application and library are same. So i think the waiting
timeout is changed, but i cann't find the changement. I hope get your help
on the issue. Thanks very much!
My hcid version is 3.36.
Best Regards
Bai Shuwei
--
Thinking before action, but you are wasting time if you don't do action.
^ permalink raw reply
* [PATCH] Add command line option to change BCSP rate
From: Wade Brown @ 2010-11-19 2:01 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
[-- Attachment #1: Type: text/plain, Size: 5073 bytes --]
Currently when using bccmd to do any communication, the UART is always
opened at 38.4kbps. Once the CSR has been initialized to any other
speed, bccmd can no longer communicate with with the radio (unless by
resetting it through rfkill). This patch adds a -b option allowing a
user to manually set a different speed, with the default 38400 still in
place.
Usage example:
$bccmd -t BCSP -b 921600 -d /dev/ttyHS1 chiprev
---
tools/bccmd.c | 45 ++++++++++++++++++++++++++++++++++++++++-----
tools/csr.h | 3 ++-
tools/csr_bcsp.c | 4 ++--
3 files changed, 44 insertions(+), 8 deletions(-)
diff --git a/tools/bccmd.c b/tools/bccmd.c
index 686e858..5cb9255 100644
--- a/tools/bccmd.c
+++ b/tools/bccmd.c
@@ -59,7 +59,7 @@
#define CSR_TYPE_ARRAY CSR_TYPE_COMPLEX
#define CSR_TYPE_BDADDR CSR_TYPE_COMPLEX
-static inline int transport_open(int transport, char *device)
+static inline int transport_open(int transport, char *device, speed_t
bcsp_rate)
{
switch (transport) {
case CSR_TRANSPORT_HCI:
@@ -69,7 +69,7 @@ static inline int transport_open(int transport, char
*device)
return csr_open_usb(device);
#endif
case CSR_TRANSPORT_BCSP:
- return csr_open_bcsp(device);
+ return csr_open_bcsp(device, bcsp_rate);
case CSR_TRANSPORT_H4:
return csr_open_h4(device);
case CSR_TRANSPORT_3WIRE:
@@ -1109,6 +1109,7 @@ static void usage(void)
printf("Options:\n"
"\t-t <transport> Select the transport\n"
"\t-d <device> Select the device\n"
+ "\t-b <bcsp rate> Select the bcsp transfer rate\n"
"\t-h, --help Display help\n"
"\n");
@@ -1137,6 +1138,7 @@ static void usage(void)
static struct option main_options[] = {
{ "transport", 1, 0, 't' },
{ "device", 1, 0, 'd' },
+ { "bcsprate", 1, 0, 'b'},
{ "help", 0, 0, 'h' },
{ 0, 0, 0, 0 }
};
@@ -1145,8 +1147,9 @@ int main(int argc, char *argv[])
{
char *device = NULL;
int i, err, opt, transport = CSR_TRANSPORT_HCI;
+ speed_t bcsp_rate = B38400;
- while ((opt=getopt_long(argc, argv, "+t:d:i:h", main_options, NULL)) !
= EOF) {
+ while ((opt=getopt_long(argc, argv, "+t:d:i:b:h", main_options,
NULL)) != EOF) {
switch (opt) {
case 't':
if (!strcasecmp(optarg, "hci"))
@@ -1171,7 +1174,39 @@ int main(int argc, char *argv[])
case 'i':
device = strdup(optarg);
break;
-
+ case 'b':
+ switch (atoi(optarg)) {
+ case 9600: bcsp_rate = B9600; break;
+ case 19200: bcsp_rate = B19200; break;
+ case 38400: bcsp_rate = B38400; break;
+ case 57600: bcsp_rate = B57600; break;
+ case 115200: bcsp_rate = B115200; break;
+ case 230400: bcsp_rate = B230400; break;
+ case 460800: bcsp_rate = B460800; break;
+ case 500000: bcsp_rate = B500000; break;
+ case 576000: bcsp_rate = B576000; break;
+ case 921600: bcsp_rate = B921600; break;
+ case 1000000: bcsp_rate = B1000000; break;
+ case 1152000: bcsp_rate = B1152000; break;
+ case 1500000: bcsp_rate = B1500000; break;
+ case 2000000: bcsp_rate = B2000000; break;
+#ifdef B2500000
+ case 2500000: bcsp_rate = B2500000; break;
+#endif
+#ifdef B3000000
+ case 3000000: bcsp_rate = B3000000; break;
+#endif
+#ifdef B3500000
+ case 3500000: bcsp_rate = B3500000; break;
+#endif
+#ifdef B4000000
+ case 4000000: bcsp_rate = B4000000; break;
+#endif
+ default:
+ printf("Unknown BCSP baud rate specified, defaulting to 38400bps
\n");
+ bcsp_rate = B38400;
+ }
+ break;
case 'h':
default:
usage();
@@ -1188,7 +1223,7 @@ int main(int argc, char *argv[])
exit(1);
}
- if (transport_open(transport, device) < 0)
+ if (transport_open(transport, device, bcsp_rate) < 0)
exit(1);
if (device)
diff --git a/tools/csr.h b/tools/csr.h
index 1d70491..8b94d7b 100644
--- a/tools/csr.h
+++ b/tools/csr.h
@@ -22,6 +22,7 @@
*/
#include <stdint.h>
+#include <termios.h>
#define CSR_VARID_PS_CLR_ALL 0x000b /* valueless */
#define CSR_VARID_PS_FACTORY_SET 0x000c /* valueless */
@@ -519,7 +520,7 @@ int csr_read_usb(uint16_t varid, uint8_t *value,
uint16_t length);
int csr_write_usb(uint16_t varid, uint8_t *value, uint16_t length);
void csr_close_usb(void);
-int csr_open_bcsp(char *device);
+int csr_open_bcsp(char *device, speed_t bcsp_rate);
int csr_read_bcsp(uint16_t varid, uint8_t *value, uint16_t length);
int csr_write_bcsp(uint16_t varid, uint8_t *value, uint16_t length);
void csr_close_bcsp(void);
diff --git a/tools/csr_bcsp.c b/tools/csr_bcsp.c
index e551311..df247a2 100644
--- a/tools/csr_bcsp.c
+++ b/tools/csr_bcsp.c
@@ -46,7 +46,7 @@ static uint8_t send_buffer[512];
static struct ubcsp_packet receive_packet;
static uint8_t receive_buffer[512];
-int csr_open_bcsp(char *device)
+int csr_open_bcsp(char *device, speed_t bcsp_rate)
{
struct termios ti;
uint8_t delay, activity = 0x00;
@@ -84,7 +84,7 @@ int csr_open_bcsp(char *device)
ti.c_cc[VMIN] = 1;
ti.c_cc[VTIME] = 0;
- cfsetospeed(&ti, B38400);
+ cfsetospeed(&ti, bcsp_rate);
if (tcsetattr(fd, TCSANOW, &ti) < 0) {
fprintf(stderr, "Can't change port settings: %s (%d)\n",
--
1.7.0.4
--
Wade Brown
[-- Attachment #2: winmail.dat --]
[-- Type: application/ms-tnef, Size: 4916 bytes --]
^ permalink raw reply related
* compat-wireless-2.6.37-rc2 is out
From: Luis R. Rodriguez @ 2010-11-18 23:52 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-wireless, linux-bluetooth
Just pushed out the compat-wireless-2.6.37-rc2 release. This is a
vanilla release.
http://wireless.kernel.org/en/users/Download/stable
Luis
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Automate remote name requests
From: Gustavo F. Padovan @ 2010-11-18 21:31 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, Johan Hedberg
In-Reply-To: <1290111749-8968-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
* johan.hedberg@gmail.com <johan.hedberg@gmail.com> [2010-11-18 22:22:29 +0200]:
> From: Johan Hedberg <johan.hedberg@nokia.com>
>
> In Bluetooth there are no automatic updates of remote device names when
> they get changed on the remote side. Instead, it is a good idea to do a
> manual name request when a new connection gets created (for whatever
> reason) since at this point it is very cheap (no costly baseband
> connection creation needed just for the sake of the name request).
>
> So far userspace has been responsible for this extra name request but
> tighter control is needed in order not to flood Bluetooth controllers
> with two many commands during connection creation. It has been shown
> that some controllers simply fail to function correctly if they get too
> many (almost) simultaneous commands during connection creation. The
> simplest way to acheive better control of these commands is to move
> their sending completely to the kernel side.
>
> This patch inserts name requests into the sequence of events that the
> kernel performs during connection creation. It does this after the
> remote features have been successfully requested and before any pending
> authentication requests are performed. The code will work sub-optimally
> with userspace versions that still do the name requesting themselves (it
> shouldn't break anything though) so it is recommended to combine this
> with a userspace software version that doesn't have automated name
> requests.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
> ---
> net/bluetooth/hci_event.c | 72 +++++++++++++++++++++++++++++++++-----------
> 1 files changed, 54 insertions(+), 18 deletions(-)
Both patches have been applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Implement Characteristic Value Read using UUID in the gatttool
From: Johan Hedberg @ 2010-11-18 21:16 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1290113736-9432-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Thu, Nov 18, 2010, Sheldon Demario wrote:
> Sub-procedure used to read a Characteristic Value when the client
> only knows the characteristic UUID and doesn't know the handle.
> More than one handle and attribute value pair can be returned,
> it is up to the user define the handles range based on the service
> handles range.
>
> Usage example:
> $gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
> ---
> attrib/gatt.c | 13 ++++++++++++-
> attrib/gatt.h | 4 ++++
> attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 1 deletions(-)
Doesn't compile:
attrib/gatt.c: In function ‘gatt_discover_char’:
attrib/gatt.c:79: error: unused variable ‘plen’
attrib/gatt.c:77: error: unused variable ‘pdu’
make[1]: *** [attrib/gatt.o] Error 1
Always check your patches against ./bootstrap-configure
Furthermore, there's at least one coding style issue:
> +guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
> + uuid_t *uuid, GAttribResultFunc func,
> + gpointer user_data)
The lines after the first one should all have the same indentation, i.e.
the third one has one tab too much.
Johan
^ permalink raw reply
* [PATCH] Implement Characteristic Value Read using UUID in the gatttool
From: Sheldon Demario @ 2010-11-18 20:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sheldon Demario
Sub-procedure used to read a Characteristic Value when the client
only knows the characteristic UUID and doesn't know the handle.
More than one handle and attribute value pair can be returned,
it is up to the user define the handles range based on the service
handles range.
Usage example:
$gatttool --char-read --uuid=2a00 -i hcix -b xx:xx:xx:xx:xx:xx
---
attrib/gatt.c | 13 ++++++++++++-
attrib/gatt.h | 4 ++++
attrib/gatttool.c | 39 +++++++++++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 1 deletions(-)
diff --git a/attrib/gatt.c b/attrib/gatt.c
index 2c87daf..72c6f5f 100644
--- a/attrib/gatt.c
+++ b/attrib/gatt.c
@@ -80,7 +80,18 @@ guint gatt_discover_char(GAttrib *attrib, uint16_t start, uint16_t end,
sdp_uuid16_create(&uuid, GATT_CHARAC_UUID);
- plen = enc_read_by_type_req(start, end, &uuid, pdu, sizeof(pdu));
+ return gatt_read_char_by_uuid(attrib, start, end, &uuid, func,
+ user_data);
+}
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data)
+{
+ uint8_t pdu[ATT_DEFAULT_MTU];
+ guint16 plen;
+
+ plen = enc_read_by_type_req(start, end, uuid, pdu, sizeof(pdu));
if (plen == 0)
return 0;
diff --git a/attrib/gatt.h b/attrib/gatt.h
index 4e7d88b..1e1e628 100644
--- a/attrib/gatt.h
+++ b/attrib/gatt.h
@@ -41,3 +41,7 @@ guint gatt_find_info(GAttrib *attrib, uint16_t start, uint16_t end,
guint gatt_write_cmd(GAttrib *attrib, uint16_t handle, uint8_t *value, int vlen,
GDestroyNotify notify, gpointer user_data);
+
+guint gatt_read_char_by_uuid(GAttrib *attrib, uint16_t start, uint16_t end,
+ uuid_t *uuid, GAttribResultFunc func,
+ gpointer user_data);
diff --git a/attrib/gatttool.c b/attrib/gatttool.c
index e961431..d0ef6d3 100644
--- a/attrib/gatttool.c
+++ b/attrib/gatttool.c
@@ -398,10 +398,49 @@ done:
g_main_loop_quit(event_loop);
}
+static void char_read_by_uuid_cb(guint8 status, const guint8 *pdu,
+ guint16 plen, gpointer user_data)
+{
+ struct att_data_list *list;
+ int i;
+
+ if (status != 0) {
+ g_printerr("Read characteristics by UUID failed: %s\n",
+ att_ecode2str(status));
+ goto done;
+ }
+
+ list = dec_read_by_type_resp(pdu, plen);
+ if (list == NULL)
+ goto done;
+
+ for (i = 0; i < list->num; i++) {
+ uint8_t *value = list->data[i];
+ int j;
+
+ g_print("handle: 0x%04x \t value: ", att_get_u16(value));
+ value += 2;
+ for (j = 0; j < list->len - 2; j++, value++)
+ g_print("%02x ", *value);
+ g_print("\n");
+ }
+
+ att_data_list_free(list);
+
+done:
+ g_main_loop_quit(event_loop);
+}
+
static gboolean characteristics_read(gpointer user_data)
{
GAttrib *attrib = user_data;
+ if (opt_uuid != NULL) {
+ gatt_read_char_by_uuid(attrib, opt_start, opt_end, opt_uuid,
+ char_read_by_uuid_cb, attrib);
+ return FALSE;
+ }
+
if (opt_handle <= 0) {
g_printerr("A valid handle is required\n");
g_main_loop_quit(event_loop);
--
1.7.3.2
^ permalink raw reply related
* [PATCH 2/2] Bluetooth: Automate remote name requests
From: johan.hedberg @ 2010-11-18 20:22 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <1290111749-8968-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@nokia.com>
In Bluetooth there are no automatic updates of remote device names when
they get changed on the remote side. Instead, it is a good idea to do a
manual name request when a new connection gets created (for whatever
reason) since at this point it is very cheap (no costly baseband
connection creation needed just for the sake of the name request).
So far userspace has been responsible for this extra name request but
tighter control is needed in order not to flood Bluetooth controllers
with two many commands during connection creation. It has been shown
that some controllers simply fail to function correctly if they get too
many (almost) simultaneous commands during connection creation. The
simplest way to acheive better control of these commands is to move
their sending completely to the kernel side.
This patch inserts name requests into the sequence of events that the
kernel performs during connection creation. It does this after the
remote features have been successfully requested and before any pending
authentication requests are performed. The code will work sub-optimally
with userspace versions that still do the name requesting themselves (it
shouldn't break anything though) so it is recommended to combine this
with a userspace software version that doesn't have automated name
requests.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/hci_event.c | 72 +++++++++++++++++++++++++++++++++-----------
1 files changed, 54 insertions(+), 18 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 9c6d9bc..4165895 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -677,11 +677,9 @@ static void hci_cs_set_conn_encrypt(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
-static int hci_request_outgoing_auth(struct hci_dev *hdev,
+static int hci_outgoing_auth_needed(struct hci_dev *hdev,
struct hci_conn *conn)
{
- struct hci_cp_auth_requested cp;
-
if (conn->state != BT_CONFIG || !conn->out)
return 0;
@@ -694,15 +692,35 @@ static int hci_request_outgoing_auth(struct hci_dev *hdev,
conn->sec_level != BT_SECURITY_HIGH)
return 0;
- cp.handle = __cpu_to_le16(conn->handle);
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
-
return 1;
}
static void hci_cs_remote_name_req(struct hci_dev *hdev, __u8 status)
{
+ struct hci_cp_remote_name_req *cp;
+ struct hci_conn *conn;
+
BT_DBG("%s status 0x%x", hdev->name, status);
+
+ /* If successful wait for the name req complete event before
+ * checking for the need to do authentication */
+ if (!status)
+ return;
+
+ cp = hci_sent_cmd_data(hdev, HCI_OP_REMOTE_NAME_REQ);
+ if (!cp)
+ return;
+
+ hci_dev_lock(hdev);
+
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &cp->bdaddr);
+ if (conn && hci_outgoing_auth_needed(hdev, conn)) {
+ struct hci_cp_auth_requested cp;
+ cp.handle = __cpu_to_le16(conn->handle);
+ hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
+ }
+
+ hci_dev_unlock(hdev);
}
static void hci_cs_read_remote_features(struct hci_dev *hdev, __u8 status)
@@ -1113,9 +1131,23 @@ static inline void hci_auth_complete_evt(struct hci_dev *hdev, struct sk_buff *s
static inline void hci_remote_name_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
+ struct hci_ev_remote_name *ev = (void *) skb->data;
+ struct hci_conn *conn;
+
BT_DBG("%s", hdev->name);
hci_conn_check_pending(hdev);
+
+ hci_dev_lock(hdev);
+
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
+ if (conn && hci_outgoing_auth_needed(hdev, conn)) {
+ struct hci_cp_auth_requested cp;
+ cp.handle = __cpu_to_le16(conn->handle);
+ hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
+ }
+
+ hci_dev_unlock(hdev);
}
static inline void hci_encrypt_change_evt(struct hci_dev *hdev, struct sk_buff *skb)
@@ -1179,7 +1211,6 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
{
struct hci_ev_remote_features *ev = (void *) skb->data;
struct hci_conn *conn;
- int auth_requested;
BT_DBG("%s status %d", hdev->name, ev->status);
@@ -1204,12 +1235,15 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
goto unlock;
}
- if (!ev->status)
- auth_requested = hci_request_outgoing_auth(hdev, conn);
- else
- auth_requested = 0;
+ if (!ev->status) {
+ struct hci_cp_remote_name_req cp;
+ memset(&cp, 0, sizeof(cp));
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pscan_rep_mode = 0x02;
+ hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ, sizeof(cp), &cp);
+ }
- if (!auth_requested) {
+ if (!hci_outgoing_auth_needed(hdev, conn)) {
conn->state = BT_CONNECTED;
hci_proto_connect_cfm(conn, ev->status);
hci_conn_put(conn);
@@ -1667,7 +1701,6 @@ static inline void hci_remote_ext_features_evt(struct hci_dev *hdev, struct sk_b
{
struct hci_ev_remote_ext_features *ev = (void *) skb->data;
struct hci_conn *conn;
- int auth_requested;
BT_DBG("%s", hdev->name);
@@ -1689,12 +1722,15 @@ static inline void hci_remote_ext_features_evt(struct hci_dev *hdev, struct sk_b
if (conn->state != BT_CONFIG)
goto unlock;
- if (!ev->status)
- auth_requested = hci_request_outgoing_auth(hdev, conn);
- else
- auth_requested = 0;
+ if (!ev->status) {
+ struct hci_cp_remote_name_req cp;
+ memset(&cp, 0, sizeof(cp));
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pscan_rep_mode = 0x02;
+ hci_send_cmd(hdev, HCI_OP_REMOTE_NAME_REQ, sizeof(cp), &cp);
+ }
- if (!auth_requested) {
+ if (!hci_outgoing_auth_needed(hdev, conn)) {
conn->state = BT_CONNECTED;
hci_proto_connect_cfm(conn, ev->status);
hci_conn_put(conn);
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/2] Bluetooth: Create a unified authentication request function
From: johan.hedberg @ 2010-11-18 20:22 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Johan Hedberg
From: Johan Hedberg <johan.hedberg@nokia.com>
This patch adds a single function that's responsible for requesting
authentication for outgoing connections. This is preparation for the
next patch which will add automated name requests and thereby move the
authentication requests to a different location.
Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
---
net/bluetooth/hci_event.c | 54 +++++++++++++++++++++++++++++++++-----------
1 files changed, 40 insertions(+), 14 deletions(-)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 8430276..9c6d9bc 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -677,6 +677,29 @@ static void hci_cs_set_conn_encrypt(struct hci_dev *hdev, __u8 status)
hci_dev_unlock(hdev);
}
+static int hci_request_outgoing_auth(struct hci_dev *hdev,
+ struct hci_conn *conn)
+{
+ struct hci_cp_auth_requested cp;
+
+ if (conn->state != BT_CONFIG || !conn->out)
+ return 0;
+
+ if (conn->sec_level == BT_SECURITY_SDP)
+ return 0;
+
+ /* Only request authentication for SSP connections or non-SSP
+ * devices with sec_level HIGH */
+ if (!(hdev->ssp_mode > 0 && conn->ssp_mode > 0) &&
+ conn->sec_level != BT_SECURITY_HIGH)
+ return 0;
+
+ cp.handle = __cpu_to_le16(conn->handle);
+ hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
+
+ return 1;
+}
+
static void hci_cs_remote_name_req(struct hci_dev *hdev, __u8 status)
{
BT_DBG("%s status 0x%x", hdev->name, status);
@@ -1156,6 +1179,7 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
{
struct hci_ev_remote_features *ev = (void *) skb->data;
struct hci_conn *conn;
+ int auth_requested;
BT_DBG("%s status %d", hdev->name, ev->status);
@@ -1177,12 +1201,15 @@ static inline void hci_remote_features_evt(struct hci_dev *hdev, struct sk_buff
cp.page = 0x01;
hci_send_cmd(hdev, HCI_OP_READ_REMOTE_EXT_FEATURES,
sizeof(cp), &cp);
- } else if (!ev->status && conn->out &&
- conn->sec_level == BT_SECURITY_HIGH) {
- struct hci_cp_auth_requested cp;
- cp.handle = ev->handle;
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED, sizeof(cp), &cp);
- } else {
+ goto unlock;
+ }
+
+ if (!ev->status)
+ auth_requested = hci_request_outgoing_auth(hdev, conn);
+ else
+ auth_requested = 0;
+
+ if (!auth_requested) {
conn->state = BT_CONNECTED;
hci_proto_connect_cfm(conn, ev->status);
hci_conn_put(conn);
@@ -1640,6 +1667,7 @@ static inline void hci_remote_ext_features_evt(struct hci_dev *hdev, struct sk_b
{
struct hci_ev_remote_ext_features *ev = (void *) skb->data;
struct hci_conn *conn;
+ int auth_requested;
BT_DBG("%s", hdev->name);
@@ -1661,14 +1689,12 @@ static inline void hci_remote_ext_features_evt(struct hci_dev *hdev, struct sk_b
if (conn->state != BT_CONFIG)
goto unlock;
- if (!ev->status && hdev->ssp_mode > 0 &&
- conn->ssp_mode > 0 && conn->out &&
- conn->sec_level != BT_SECURITY_SDP) {
- struct hci_cp_auth_requested cp;
- cp.handle = ev->handle;
- hci_send_cmd(hdev, HCI_OP_AUTH_REQUESTED,
- sizeof(cp), &cp);
- } else {
+ if (!ev->status)
+ auth_requested = hci_request_outgoing_auth(hdev, conn);
+ else
+ auth_requested = 0;
+
+ if (!auth_requested) {
conn->state = BT_CONNECTED;
hci_proto_connect_cfm(conn, ev->status);
hci_conn_put(conn);
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH v2 2/6] Add Find By Type Value Response encoding/decoding functions
From: Johan Hedberg @ 2010-11-18 20:01 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1290102524-26493-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Thu, Nov 18, 2010, Claudio Takahasi wrote:
> Find by type operation is used by Discover Primary Service by Service
> UUID. Find By Type Value Response shall contain one or more group handles.
> ---
> attrib/att.c | 46 ++++++++++++++++++++++++++++++++++++++++++++++
> attrib/att.h | 7 +++++++
> 2 files changed, 53 insertions(+), 0 deletions(-)
Thanks for the update. This and the rest of your patches have been
pushed upstream.
Johan
^ permalink raw reply
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