* Re: Changes in HDP API
From: José Antonio Santos Cadenas @ 2010-08-04 17:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinO4=BjcNP5uyi_nX0axaBth7aUAhgOoFdPKrY2@mail.gmail.com>
Hi,
El Wednesday 04 August 2010 18:45:50 Luiz Augusto von Dentz escribió:
> Hi,
>
> On Wed, Aug 4, 2010 at 4:54 PM, José Antonio Santos Cadenas
>
> <santoscadenas@gmail.com> wrote:
> >> This has 2 main advantages:
> >>
> >> 1. Anyone can request to connect not only applications which holds
> >> local endpoints
> >
> > How can you guess the remote end point to connect to if you don't have a
> > local end point?
>
> There is no endpoints involved in this case, bluetooth applet/agent
> has knowledge only of the device so bluetoothd will need to figure out
> all the matching endpoint and make sure local endpoint get notified
> about the available channels, so responding your question there is
> nothing to guess it all about matching the endpoints if there is no
> match it just fails after the discover as simple as that.
Sorry but I don't understand the answer. I think that the daemon needs to
guess the remote end point to connect to when the user performs a connection
of a data channel to a device (I mean the mdepid where the data channel will
be connected). In HDP each data channel can be configured in a specific way
(reliable or streaming) and is connected for an specific usage (that's the
data type parameter in the SDP record) so you have to specify this during the
connection of the channel.
An other thing to solve is the way that the data channel deletion is notified
if there is no associated agent, I mean, if you just do a Connect without
registering an agent first. This kind of events are supposed to be received by
the agent. An other special issue of HDP, data channels can be open or closed
but they are still active because reconnections are possible and this implies
no disconnection for the application layer.
>
> At least that is the idea around connect/disconnect in gnome-bluetooth
> and N900 bluetooth application does have a similar design.
I don't know how this is exactly working (I'll have a deeper look), but I
guess that only one agent is allowed. I think that will be great to have
multiple agents in HDP because more than one application can be using HDP at
the same time. I don't know if with only one agent this can be solved.
Regards
Jose.
^ permalink raw reply
* [PATCH 5/7] Fix in logic to write EIR when SDP records are changed.
From: Inga Stotland @ 2010-08-04 17:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel
Whenever SDP service record is added/deleted/modified check for whether
class of device needs to be updated as well. If the update is
needed, proceed as before: new EIR will be written subsequently.
If the class of device is already present, just update EIR and return.
---
src/adapter.c | 69 ++++++++++++++++++++++++++++++--------------------------
1 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 4615326..b735bdd 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -206,6 +206,34 @@ void clear_found_devices_list(struct btd_adapter *adapter)
adapter->found_devices = NULL;
}
+static void update_ext_inquiry_response(struct btd_adapter *adapter)
+{
+ uint8_t fec = 0, data[240];
+ struct hci_dev *dev = &adapter->dev;
+ int dd;
+
+ if (!(dev->features[6] & LMP_EXT_INQ))
+ return;
+
+ memset(data, 0, sizeof(data));
+
+ dd = hci_open_dev(adapter->dev_id);
+ if (dd < 0)
+ return;
+
+ if (dev->ssp_mode > 0)
+ create_ext_inquiry_response((char *) dev->name,
+ adapter->tx_power,
+ adapter->services, data);
+
+ if (hci_write_ext_inquiry_response(dd, fec, data,
+ HCI_REQ_TIMEOUT) < 0)
+ error("Can't write extended inquiry response: %s (%d)",
+ strerror(errno), errno);
+
+ hci_close_dev(dd);
+}
+
static int adapter_set_service_classes(struct btd_adapter *adapter,
uint8_t value)
{
@@ -216,11 +244,16 @@ static int adapter_set_service_classes(struct btd_adapter *adapter,
adapter->wanted_cod &= 0x00ffff;
adapter->wanted_cod |= (value << 16);
- /* If we already have the CoD we want or the cache is enabled or an
- * existing CoD write is in progress just bail out */
- if (adapter->current_cod == adapter->wanted_cod ||
- adapter->cache_enable || adapter->pending_cod)
+ /* If the cache is enabled or an existing CoD write is in progress
+ * just bail out */
+ if (adapter->cache_enable || adapter->pending_cod)
+ return 0;
+
+ /* If we already have the CoD we want, update EIR and return */
+ if (adapter->current_cod == adapter->wanted_cod) {
+ update_ext_inquiry_response(adapter);
return 0;
+ }
DBG("Changing service classes to 0x%06x", adapter->wanted_cod);
@@ -818,34 +851,6 @@ static DBusMessage *set_pairable_timeout(DBusConnection *conn,
return dbus_message_new_method_return(msg);
}
-static void update_ext_inquiry_response(struct btd_adapter *adapter)
-{
- uint8_t fec = 0, data[240];
- struct hci_dev *dev = &adapter->dev;
- int dd;
-
- if (!(dev->features[6] & LMP_EXT_INQ))
- return;
-
- memset(data, 0, sizeof(data));
-
- dd = hci_open_dev(adapter->dev_id);
- if (dd < 0)
- return;
-
- if (dev->ssp_mode > 0)
- create_ext_inquiry_response((char *) dev->name,
- adapter->tx_power,
- adapter->services, data);
-
- if (hci_write_ext_inquiry_response(dd, fec, data,
- HCI_REQ_TIMEOUT) < 0)
- error("Can't write extended inquiry response: %s (%d)",
- strerror(errno), errno);
-
- hci_close_dev(dd);
-}
-
void adapter_set_class_complete(bdaddr_t *bdaddr, uint8_t status)
{
uint8_t class[3];
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 7/7] Add service UUIDs from EIR to device properties in "Device Found" signal.
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel, Inga Stotland
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
---
src/adapter.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++++--
src/adapter.h | 4 +-
src/dbus-hci.c | 6 ++--
3 files changed, 108 insertions(+), 8 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index c142a4a..9310896 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2749,8 +2749,100 @@ static void emit_device_found(const char *path, const char *address,
g_dbus_send_message(connection, signal);
}
+static char **get_eir_uuids(uint8_t *eir_data, size_t *uuid_count)
+{
+ uint8_t len = 0;
+ char **uuid_buf = NULL;
+ char **uuids;
+ size_t total = 0;
+ size_t uuid16_count = 0;
+ size_t uuid32_count = 0;
+ size_t uuid128_count = 0;
+ uint8_t *uuid16;
+ uint8_t *uuid32;
+ uint8_t *uuid128;
+ uuid_t service;
+ int i;
+
+ while (len < EIR_DATA_LENGTH) {
+ uint8_t type = eir_data[1];
+ uint8_t field_len = eir_data[0];
+
+ switch (type) {
+ case EIR_UUID16_SOME:
+ case EIR_UUID16_ALL:
+ uuid16_count = field_len / 2;
+ uuid16 = &eir_data[2];
+ break;
+ case EIR_UUID32_SOME:
+ case EIR_UUID32_ALL:
+ uuid32_count = field_len / 4;
+ uuid32 = &eir_data[2];
+ break;
+ case EIR_UUID128_SOME:
+ case EIR_UUID128_ALL:
+ uuid128_count = field_len / 16;
+ uuid128 = &eir_data[2];
+ break;
+ }
+
+ len += field_len + 1;
+ eir_data += field_len + 1;
+ }
+
+ total = uuid16_count + uuid32_count + uuid128_count;
+ *uuid_count = total;
+
+ if (!total)
+ return NULL;
+
+ uuid_buf = g_new0(char *, total + 1);
+
+ if (!uuid_buf)
+ return NULL;
+
+ uuids = uuid_buf;
+
+ /* Generate uuids in SDP format (EIR data is Little Endian) */
+ service.type = SDP_UUID16;
+ for (i = 0; i < uuid16_count; i++) {
+ uint16_t val16 = uuid16[1];
+
+ val16 = (val16<<8) + uuid16[0];
+ service.value.uuid16 = val16;
+ *uuids++ = bt_uuid2string(&service);
+ uuid16 += 2;
+ }
+
+ service.type = SDP_UUID32;
+ for (i = 0; i < uuid32_count; i++) {
+ uint32_t val32 = uuid32[3];
+ int k;
+
+ for (k = 2; k >= 0; k--)
+ val32 = (val32 << 8) + uuid32[k];
+
+ service.value.uuid32 = val32;
+ *uuids++ = bt_uuid2string(&service);
+ uuid32 += 4;
+ }
+
+ service.type = SDP_UUID128;
+ for (i = 0; i < uuid128_count; i++) {
+ int k;
+
+ for (k = 0; k < 16; k++)
+ service.value.uuid128.data[k] = uuid128[16 - k - 1];
+
+ *uuids++ = bt_uuid2string(&service);
+ uuid128 += 16;
+ }
+
+ return uuid_buf;
+}
+
void adapter_emit_device_found(struct btd_adapter *adapter,
- struct remote_dev_info *dev)
+ struct remote_dev_info *dev, uint8_t *eir_data)
{
struct btd_device *device;
char peer_addr[18], local_addr[18];
@@ -2758,6 +2850,8 @@ 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 = 0;
ba2str(&dev->bdaddr, peer_addr);
ba2str(&adapter->bdaddr, local_addr);
@@ -2777,6 +2871,10 @@ void adapter_emit_device_found(struct btd_adapter *adapter,
} else
alias = g_strdup(dev->alias);
+ /* Extract UUIDs from extended inquiry response if any*/
+ if (eir_data != NULL)
+ uuids = get_eir_uuids(eir_data, &uuid_count);
+
emit_device_found(adapter->path, paddr,
"Address", DBUS_TYPE_STRING, &paddr,
"Class", DBUS_TYPE_UINT32, &dev->class,
@@ -2786,15 +2884,17 @@ 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,
NULL);
g_free(alias);
+ g_strfreev(uuids);
}
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
- name_status_t name_status)
+ name_status_t name_status, uint8_t *eir_data)
{
struct remote_dev_info *dev, match;
@@ -2833,7 +2933,7 @@ done:
adapter->found_devices = g_slist_sort(adapter->found_devices,
(GCompareFunc) dev_rssi_cmp);
- adapter_emit_device_found(adapter, dev);
+ adapter_emit_device_found(adapter, dev, eir_data);
}
int adapter_remove_found_device(struct btd_adapter *adapter, bdaddr_t *bdaddr)
diff --git a/src/adapter.h b/src/adapter.h
index 8226514..a7eca0e 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -113,10 +113,10 @@ struct remote_dev_info *adapter_search_found_devices(struct btd_adapter *adapter
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
- name_status_t name_status);
+ name_status_t name_status, uint8_t *eir_data);
int adapter_remove_found_device(struct btd_adapter *adapter, bdaddr_t *bdaddr);
void adapter_emit_device_found(struct btd_adapter *adapter,
- struct remote_dev_info *dev);
+ struct remote_dev_info *dev, uint8_t *eir_data);
void adapter_update_oor_devices(struct btd_adapter *adapter);
void adapter_mode_changed(struct btd_adapter *adapter, uint8_t scan_mode);
void adapter_setname_complete(bdaddr_t *local, uint8_t status);
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index b83506f..6d27caa 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -515,7 +515,7 @@ void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
if (dev) {
adapter_update_found_devices(adapter, peer, rssi, class,
NULL, NULL, dev->legacy,
- NAME_NOT_REQUIRED);
+ NAME_NOT_REQUIRED, data);
return;
}
@@ -566,7 +566,7 @@ void hcid_dbus_inquiry_result(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
/* add in the list to track name sent/pending */
adapter_update_found_devices(adapter, peer, rssi, class, name, alias,
- legacy, name_status);
+ legacy, name_status, data);
g_free(name);
g_free(alias);
@@ -642,7 +642,7 @@ void hcid_dbus_remote_name(bdaddr_t *local, bdaddr_t *peer, uint8_t status,
if (dev_info) {
g_free(dev_info->name);
dev_info->name = g_strdup(name);
- adapter_emit_device_found(adapter, dev_info);
+ adapter_emit_device_found(adapter, dev_info, NULL);
}
if (device)
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 6/7] Handle arrays in device properties dictionary.
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel, Inga Stotland
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
---
src/adapter.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index b735bdd..c142a4a 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2700,6 +2700,7 @@ static void append_dict_valist(DBusMessageIter *iter,
DBusMessageIter dict;
const char *key;
int type;
+ int n_elements;
void *val;
dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY,
@@ -2711,7 +2712,13 @@ static void append_dict_valist(DBusMessageIter *iter,
while (key) {
type = va_arg(var_args, int);
val = va_arg(var_args, void *);
- dict_append_entry(&dict, key, type, val);
+ if (type == DBUS_TYPE_ARRAY) {
+ n_elements = va_arg(var_args, int);
+ if (n_elements > 0)
+ dict_append_array(&dict, key, DBUS_TYPE_STRING,
+ val, n_elements);
+ } else
+ dict_append_entry(&dict, key, type, val);
key = va_arg(var_args, char *);
}
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 4/7] Support for adding UUID128 to extended inquiry response
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
Whenever SDP service record is added/deleted/modified check for whether
class of device needs to be updated as well. If the update is
needed, proceed as before: new EIR will be written subsequently.
If the class of device is already present, just update EIR and return.
---
src/adapter.c | 69 ++++++++++++++++++++++++++++++--------------------------
1 files changed, 37 insertions(+), 32 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 4615326..b735bdd 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -206,6 +206,34 @@ void clear_found_devices_list(struct btd_adapter *adapter)
adapter->found_devices = NULL;
}
+static void update_ext_inquiry_response(struct btd_adapter *adapter)
+{
+ uint8_t fec = 0, data[240];
+ struct hci_dev *dev = &adapter->dev;
+ int dd;
+
+ if (!(dev->features[6] & LMP_EXT_INQ))
+ return;
+
+ memset(data, 0, sizeof(data));
+
+ dd = hci_open_dev(adapter->dev_id);
+ if (dd < 0)
+ return;
+
+ if (dev->ssp_mode > 0)
+ create_ext_inquiry_response((char *) dev->name,
+ adapter->tx_power,
+ adapter->services, data);
+
+ if (hci_write_ext_inquiry_response(dd, fec, data,
+ HCI_REQ_TIMEOUT) < 0)
+ error("Can't write extended inquiry response: %s (%d)",
+ strerror(errno), errno);
+
+ hci_close_dev(dd);
+}
+
static int adapter_set_service_classes(struct btd_adapter *adapter,
uint8_t value)
{
@@ -216,11 +244,16 @@ static int adapter_set_service_classes(struct btd_adapter *adapter,
adapter->wanted_cod &= 0x00ffff;
adapter->wanted_cod |= (value << 16);
- /* If we already have the CoD we want or the cache is enabled or an
- * existing CoD write is in progress just bail out */
- if (adapter->current_cod == adapter->wanted_cod ||
- adapter->cache_enable || adapter->pending_cod)
+ /* If the cache is enabled or an existing CoD write is in progress
+ * just bail out */
+ if (adapter->cache_enable || adapter->pending_cod)
+ return 0;
+
+ /* If we already have the CoD we want, update EIR and return */
+ if (adapter->current_cod == adapter->wanted_cod) {
+ update_ext_inquiry_response(adapter);
return 0;
+ }
DBG("Changing service classes to 0x%06x", adapter->wanted_cod);
@@ -818,34 +851,6 @@ static DBusMessage *set_pairable_timeout(DBusConnection *conn,
return dbus_message_new_method_return(msg);
}
-static void update_ext_inquiry_response(struct btd_adapter *adapter)
-{
- uint8_t fec = 0, data[240];
- struct hci_dev *dev = &adapter->dev;
- int dd;
-
- if (!(dev->features[6] & LMP_EXT_INQ))
- return;
-
- memset(data, 0, sizeof(data));
-
- dd = hci_open_dev(adapter->dev_id);
- if (dd < 0)
- return;
-
- if (dev->ssp_mode > 0)
- create_ext_inquiry_response((char *) dev->name,
- adapter->tx_power,
- adapter->services, data);
-
- if (hci_write_ext_inquiry_response(dd, fec, data,
- HCI_REQ_TIMEOUT) < 0)
- error("Can't write extended inquiry response: %s (%d)",
- strerror(errno), errno);
-
- hci_close_dev(dd);
-}
-
void adapter_set_class_complete(bdaddr_t *bdaddr, uint8_t status)
{
uint8_t class[3];
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 4/7] Support for adding UUID128 to extended inquiry response
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel, Inga Stotland
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
---
src/sdpd-service.c | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 63 insertions(+), 0 deletions(-)
diff --git a/src/sdpd-service.c b/src/sdpd-service.c
index 5c56e2d..26ab9a5 100644
--- a/src/sdpd-service.c
+++ b/src/sdpd-service.c
@@ -49,6 +49,8 @@
#include "manager.h"
#include "adapter.h"
+#define SIZEOF_UUID128 16
+
static sdp_record_t *server = NULL;
static uint16_t did_vendor = 0x0000;
@@ -174,6 +176,63 @@ static void update_svclass_list(const bdaddr_t *src)
}
+static void eir_generate_uuid128(sdp_list_t *list,
+ uint8_t *ptr, uint16_t *eir_len)
+{
+ int i, k, index = 0;
+ uint16_t len = *eir_len;
+ uint8_t *uuid128;
+ gboolean truncated = FALSE;
+
+ /* Store UUIDs in place, skip 2 bytes to write type and length later */
+ uuid128 = ptr + 2;
+
+ for (; list; list = list->next) {
+ sdp_record_t *rec = (sdp_record_t *) list->data;
+ uint8_t *uuid128_data = rec->svclass.value.uuid128.data;
+
+ if (rec->svclass.type != SDP_UUID128)
+ continue;
+
+ /* Stop if not enough space to put next UUID128 */
+ if ((len + 2 + SIZEOF_UUID128) > EIR_DATA_LENGTH) {
+ truncated = TRUE;
+ break;
+ }
+
+ /* Check for duplicates, EIR data is Little Endian */
+ for (i = 0; i < index; i++) {
+ for (k = 0; k < SIZEOF_UUID128; k++) {
+ if (uuid128[i * SIZEOF_UUID128 + k] !=
+ uuid128_data[SIZEOF_UUID128 - k])
+ break;
+ }
+ if (k == SIZEOF_UUID128)
+ break;
+ }
+
+ if (i < index)
+ continue;
+
+ /* EIR data is Little Endian */
+ for (k = 0; k < SIZEOF_UUID128; k++)
+ uuid128[index * SIZEOF_UUID128 + k] =
+ uuid128_data[SIZEOF_UUID128 - 1 - k];
+
+ len += SIZEOF_UUID128;
+ index++;
+ }
+
+ if (index > 0 || truncated) {
+ /* EIR Data length */
+ ptr[0] = (index * SIZEOF_UUID128) + 1;
+ /* EIR Data type */
+ ptr[1] = truncated ? EIR_UUID128_SOME : EIR_UUID128_ALL;
+ len += 2;
+ *eir_len = len;
+ }
+}
+
void create_ext_inquiry_response(const char *name,
int8_t tx_power, sdp_list_t *services,
uint8_t *data)
@@ -271,6 +330,10 @@ void create_ext_inquiry_response(const char *name,
*ptr++ = (uuid16[i] & 0xff00) >> 8;
}
}
+
+ /* Group all UUID128 types */
+ if (eir_len <= EIR_DATA_LENGTH - 2)
+ eir_generate_uuid128(services, ptr, &eir_len);
}
void register_public_browse_group(void)
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 3/7] Clean up code that generates extended inquiry response.
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel, Inga Stotland
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
---
src/sdpd-service.c | 44 +++++++++++++++++++++++++++++---------------
1 files changed, 29 insertions(+), 15 deletions(-)
diff --git a/src/sdpd-service.c b/src/sdpd-service.c
index 35e333d..5c56e2d 100644
--- a/src/sdpd-service.c
+++ b/src/sdpd-service.c
@@ -180,35 +180,41 @@ void create_ext_inquiry_response(const char *name,
{
sdp_list_t *list = services;
uint8_t *ptr = data;
- uint16_t uuid[24];
+ uint16_t eir_len = 0;
+ uint16_t uuid16[EIR_DATA_LENGTH / 2];
int i, index = 0;
+ gboolean truncated = FALSE;
if (name) {
int len = strlen(name);
+ /* EIR Data type */
if (len > 48) {
len = 48;
- ptr[1] = 0x08;
+ ptr[1] = EIR_NAME_SHORT;
} else
- ptr[1] = 0x09;
+ ptr[1] = EIR_NAME_COMPLETE;
+ /* EIR Data length */
ptr[0] = len + 1;
memcpy(ptr + 2, name, len);
- ptr += len + 2;
+ eir_len += (len + 2);
+ ptr += (len + 2);
}
if (tx_power != 0) {
*ptr++ = 2;
- *ptr++ = 0x0a;
+ *ptr++ = EIR_TX_POWER;
*ptr++ = (uint8_t) tx_power;
+ eir_len += 3;
}
if (did_vendor != 0x0000) {
uint16_t source = 0x0002;
*ptr++ = 9;
- *ptr++ = 0x10;
+ *ptr++ = EIR_DEVICE_ID;
*ptr++ = (source & 0x00ff);
*ptr++ = (source & 0xff00) >> 8;
*ptr++ = (did_vendor & 0x00ff);
@@ -217,10 +223,10 @@ void create_ext_inquiry_response(const char *name,
*ptr++ = (did_product & 0xff00) >> 8;
*ptr++ = (did_version & 0x00ff);
*ptr++ = (did_version & 0xff00) >> 8;
+ eir_len += 10;
}
- ptr[1] = 0x03;
-
+ /* Group all UUID16 types */
for (; list; list = list->next) {
sdp_record_t *rec = (sdp_record_t *) list->data;
@@ -233,28 +239,36 @@ void create_ext_inquiry_response(const char *name,
if (rec->svclass.value.uuid16 == PNP_INFO_SVCLASS_ID)
continue;
- if (index > 23) {
- ptr[1] = 0x02;
+ /* Stop if not enough space to put next UUID16 */
+ if ((eir_len + 2 + sizeof(uint16_t)) > EIR_DATA_LENGTH) {
+ truncated = TRUE;
break;
}
+ /* Check for duplicates */
for (i = 0; i < index; i++)
- if (uuid[i] == rec->svclass.value.uuid16)
+ if (uuid16[i] == rec->svclass.value.uuid16)
break;
if (i < index)
continue;
- uuid[index++] = rec->svclass.value.uuid16;
+ uuid16[index++] = rec->svclass.value.uuid16;
+ eir_len += sizeof(uint16_t);
}
if (index > 0) {
- ptr[0] = (index * 2) + 1;
+ /* EIR Data length */
+ ptr[0] = (index * sizeof(uint16_t)) + 1;
+ /* EIR Data type */
+ ptr[1] = truncated ? EIR_UUID16_SOME : EIR_UUID16_ALL;
+
ptr += 2;
+ eir_len += 2;
for (i = 0; i < index; i++) {
- *ptr++ = (uuid[i] & 0x00ff);
- *ptr++ = (uuid[i] & 0xff00) >> 8;
+ *ptr++ = (uuid16[i] & 0x00ff);
+ *ptr++ = (uuid16[i] & 0xff00) >> 8;
}
}
}
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 2/7] Minor fix when skipping duplicate UUID16 from EIR.
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel, Inga Stotland
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
---
src/sdpd-service.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/src/sdpd-service.c b/src/sdpd-service.c
index cdbb4f4..35e333d 100644
--- a/src/sdpd-service.c
+++ b/src/sdpd-service.c
@@ -242,7 +242,7 @@ void create_ext_inquiry_response(const char *name,
if (uuid[i] == rec->svclass.value.uuid16)
break;
- if (i == index - 1)
+ if (i < index)
continue;
uuid[index++] = rec->svclass.value.uuid16;
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH 1/7] Spec constants for Extended Inquiry Response field types
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel, Inga Stotland
In-Reply-To: <1280941655-14313-1-git-send-email-ingas@codeaurora.org>
---
src/sdpd.h | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/src/sdpd.h b/src/sdpd.h
index e93b0b6..5bab869 100644
--- a/src/sdpd.h
+++ b/src/sdpd.h
@@ -34,6 +34,19 @@
#define SDPDBG(fmt...)
#endif
+#define EIR_DATA_LENGTH 240
+
+#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 */
+#define EIR_UUID32_ALL 0x05 /* 32-bit UUID, all listed */
+#define EIR_UUID128_SOME 0x06 /* 128-bit UUID, more available */
+#define EIR_UUID128_ALL 0x07 /* 128-bit UUID, all listed */
+#define EIR_NAME_SHORT 0x08 /* shortened local name */
+#define EIR_NAME_COMPLETE 0x09 /* complete local name */
+#define EIR_TX_POWER 0x0A /* transmit power level */
+#define EIR_DEVICE_ID 0x10 /* device ID */
+
typedef struct request {
bdaddr_t device;
bdaddr_t bdaddr;
--
1.7.2
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* [PATCH v7 0/7] Enhanced support for extended inquiry response
From: Inga Stotland @ 2010-08-04 17:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: rshaffer, johan.hedberg, marcel
EIR needs to be updated whenever local SDP record database changes.
Previously, when an SDP record was added/removed/updated, EIR would
be written in callback fired off HCI "Command Complete" event set off by
"Write Class Of Device" command. However, if the class of device did not
need to be updated, the EIR write was not happening either. This
implementation has been augmented to write new EIR when modification
in SDP database does not lead to updating of class of device.
Added support for UUID128 service descriptors in local EIR.
Service UUIDs are written to "device properties" dictionary when emitting
"Device Found" signal. This allows peek at available services offered by
a remote device without establishing SDP connection.
--
Inga Stotland
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Changes in HDP API
From: Luiz Augusto von Dentz @ 2010-08-04 16:45 UTC (permalink / raw)
To: José Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <201008041554.27451.santoscadenas@gmail.com>
Hi,
On Wed, Aug 4, 2010 at 4:54 PM, José Antonio Santos Cadenas
<santoscadenas@gmail.com> wrote:
>> This has 2 main advantages:
>>
>> 1. Anyone can request to connect not only applications which holds
>> local endpoints
>
> How can you guess the remote end point to connect to if you don't have a local
> end point?
There is no endpoints involved in this case, bluetooth applet/agent
has knowledge only of the device so bluetoothd will need to figure out
all the matching endpoint and make sure local endpoint get notified
about the available channels, so responding your question there is
nothing to guess it all about matching the endpoints if there is no
match it just fails after the discover as simple as that.
At least that is the idea around connect/disconnect in gnome-bluetooth
and N900 bluetooth application does have a similar design.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Bluetooth: Check result code for l2cap info rsp
From: Marcel Holtmann @ 2010-08-04 14:27 UTC (permalink / raw)
To: Ville Tervo; +Cc: linux-bluetooth, padovan
In-Reply-To: <1280904213-2097-1-git-send-email-ville.tervo@nokia.com>
Hi Ville,
> Check result code in l2cap information response. Othervise
> the response code would read invalid feature mask and access
> invalid memory.
>
> Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/l2cap.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Don't send RFC for Basic Mode if only it is supported
From: Marcel Holtmann @ 2010-08-04 14:27 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth, Gustavo F. Padovan
In-Reply-To: <1280890169-8880-1-git-send-email-gustavo@padovan.org>
Hi Gustavo,
> If the remote side doesn't support Enhanced Retransmission Mode neither
> Streaming Mode, we shall not send the RFC option.
> Some devices that only supports Basic Mode do not understanding the RFC
> option. This patch fix the regression found with that devices.
>
> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
> ---
> net/bluetooth/l2cap.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
patch has been applied. Thanks.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 5/7] Fix in logic to write EIR when SDP records are changed.
From: Johan Hedberg @ 2010-08-04 14:09 UTC (permalink / raw)
To: Inga Stotland; +Cc: linux-bluetooth, rshaffer, marcel
In-Reply-To: <1280880237-2296-6-git-send-email-ingas@codeaurora.org>
Hi Inga,
On Tue, Aug 03, 2010, Inga Stotland wrote:
> +static void update_ext_inquiry_response(struct btd_adapter *adapter);
Is this forward declaration really necessary? Would it be possible to
get rid of it by rearranging the static functions in this file (i.e.
move update_ext_inquiry_response higher up in the file)?
Johan
^ permalink raw reply
* Reg: L2cap Security And Role Switch
From: Prabhakaran M.C @ 2010-08-04 14:08 UTC (permalink / raw)
To: linux-bluetooth
Hello All,
Whenever L2cap security is HIGH and remote device does role switch,
Bluez accepts the Role switch and L2cap disconnects the channel
because of HIGH security.
For PAN profile, I would like to keep the L2cap security to HIGH
since it involves internet browsing but the Widcomm stack always does
a role switch in PAN connection and Bluez disconnects l2cap channel.
Can someone please point in specification about the l2cap security
level and Role switch relation. I tried to find out this but I could
not get this behavior described in specification. Please provide your
comments and inputs. Thanks in Advance.
Thanks,
Prabhakaran.
^ permalink raw reply
* Re: [PATCH 4/7] Support for adding UUID128 to extended inquiry response
From: Johan Hedberg @ 2010-08-04 14:08 UTC (permalink / raw)
To: Inga Stotland; +Cc: linux-bluetooth, rshaffer, marcel
In-Reply-To: <1280880237-2296-5-git-send-email-ingas@codeaurora.org>
Hi Inga,
On Tue, Aug 03, 2010, Inga Stotland wrote:
> - ptr[1] = (truncated) ? EIR_UUID16_SOME : EIR_UUID16_ALL;
> + ptr[1] = truncated ? EIR_UUID16_SOME : EIR_UUID16_ALL;
And here's the fix I mentioned in the previous email that shouldn't be
needed to begin with.
Johan
^ permalink raw reply
* Re: [PATCH 3/7] Clean up code that generates extended inquiry response.
From: Johan Hedberg @ 2010-08-04 14:07 UTC (permalink / raw)
To: Inga Stotland; +Cc: linux-bluetooth, rshaffer, marcel
In-Reply-To: <1280880237-2296-4-git-send-email-ingas@codeaurora.org>
Hi Inga,
The patches are starting to look pretty good. A couple more coding style
issues though (in this and a few consequtive emails):
On Tue, Aug 03, 2010, Inga Stotland wrote:
> + ptr[1] = (truncated) ? EIR_UUID16_SOME : EIR_UUID16_ALL;
Another patch in your patch set "fixes" this and removes the parenthesis
around truncated. Could you just fix it in this patch itself. In general
patches with fixes to other patches that aren't yet upstream should be
avoided by redoing the the first patch that caused the need for a fix to
begin with.
Johan
^ permalink raw reply
* Re: Changes in HDP API
From: José Antonio Santos Cadenas @ 2010-08-04 13:54 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTima=oJ4mPMkfPCNPjsqhxX0drGBDURXBMaLrJ1C@mail.gmail.com>
Hello,
El Wednesday 04 August 2010 15:09:49 Luiz Augusto von Dentz escribió:
> Hi,
>
> On Wed, Aug 4, 2010 at 10:49 AM, Jose Antonio Santos Cadenas
>
> <santoscadenas@gmail.com> wrote:
> > This patch makes some changes in the HDP API based in the conversation
> > that I had yesterday with Luiz and Elvis.
> >
> > I still have a doubt about the notification of devices in the agent. Luiz
> > commented that with this API the Agent and the Application could not be
> > in different processes, is this a problem?
> >
> > An other open issue is: if we notify when a device is discovered and
> > suitable for connect with an application and when a devices is removed
> > (or becomes not suitable for connect). I think that we already need
> > something like the patch that we start discussing yesterday, something
> > that can be called by the user in order to force a new service discovery
> > and notifies the driver that will notify the agent. Of course we can
> > avoid this not notifying the suitable devices and just letting to try
> > the connection against all the devices (if there is no matching service
> > it will fail). What do you think?
> >
> > Regards.
>
> Lets say you want the pairing agent to connect right after pairing or
> directly via applet, these applications has zero knowledge of what
> endpoints the devices has, that why I suggest something simpler, so we
> might only need e.g. HealthDevice which the applet can say, please
> connect to this device so it calls e.g. HealthDevice.Connect(), this
> basically will start a discovery of the health endpoints on
> bluetoothd, then it matches with local endpoints (HealthApplication),
> create the channels which are informed to the HealthAgent which can
> then acquire the file descriptor.
I like this approach more than the previous one. But I still have one
question. I write it further down.
>
> This has 2 main advantages:
>
> 1. Anyone can request to connect not only applications which holds
> local endpoints
How can you guess the remote end point to connect to if you don't have a local
end point?
> 2. There is no need to fetch the services, discovery will take place
> every time the application attempt to connect.
I agree with this one. Less discovery implies less traffic and less battery
consumption and bandwidth.
Regards.
^ permalink raw reply
* Re: Changes in HDP API
From: Luiz Augusto von Dentz @ 2010-08-04 13:09 UTC (permalink / raw)
To: Jose Antonio Santos Cadenas; +Cc: linux-bluetooth
In-Reply-To: <1280908152-3743-1-git-send-email-santoscadenas@gmail.com>
Hi,
On Wed, Aug 4, 2010 at 10:49 AM, Jose Antonio Santos Cadenas
<santoscadenas@gmail.com> wrote:
> This patch makes some changes in the HDP API based in the conversation that I
> had yesterday with Luiz and Elvis.
>
> I still have a doubt about the notification of devices in the agent. Luiz
> commented that with this API the Agent and the Application could not be in
> different processes, is this a problem?
>
> An other open issue is: if we notify when a device is discovered and suitable
> for connect with an application and when a devices is removed (or becomes not
> suitable for connect). I think that we already need something like the patch
> that we start discussing yesterday, something that can be called by the user
> in order to force a new service discovery and notifies the driver that will
> notify the agent. Of course we can avoid this not notifying the suitable
> devices and just letting to try the connection against all the devices (if
> there is no matching service it will fail). What do you think?
>
> Regards.
Lets say you want the pairing agent to connect right after pairing or
directly via applet, these applications has zero knowledge of what
endpoints the devices has, that why I suggest something simpler, so we
might only need e.g. HealthDevice which the applet can say, please
connect to this device so it calls e.g. HealthDevice.Connect(), this
basically will start a discovery of the health endpoints on
bluetoothd, then it matches with local endpoints (HealthApplication),
create the channels which are informed to the HealthAgent which can
then acquire the file descriptor.
This has 2 main advantages:
1. Anyone can request to connect not only applications which holds
local endpoints
2. There is no need to fetch the services, discovery will take place
every time the application attempt to connect.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: MCAP patches
From: José Antonio Santos Cadenas @ 2010-08-04 9:02 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1280304015-9230-1-git-send-email-sancane@gmail.com>
Hi all,
Wednesday 28 July 2010 10:00:09 Santiago Carot-Nemesio wrote:
> Hello,
> Next are the patches that we have prepared for MCAP.
> Git can be cloned from git://gitorious.org/bluez-mcap-hdp/mcap-hdp.git
>
> Regards.
Any comments about this patches?
Regards.
^ permalink raw reply
* [PATCH] Changes in HDP API.
From: Jose Antonio Santos Cadenas @ 2010-08-04 7:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In-Reply-To: <1280908152-3743-1-git-send-email-santoscadenas@gmail.com>
Now the connection is made directly to a device and bluetoothd daemon
guess the PSM connection and the MDEPID based on the data get from the
SDP record.
---
doc/health-api.txt | 33 +++++++++++++--------------------
1 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/doc/health-api.txt b/doc/health-api.txt
index f469df3..aa462bd 100644
--- a/doc/health-api.txt
+++ b/doc/health-api.txt
@@ -47,12 +47,12 @@ Methods:
--------------------------------------------------------------------------------
Service org.bluez
-Interface org.bluez.HealthApplication
-Object path [variable prefix]/health_app_ZZZZ
+Interface org.bluez.HealthDevice
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX
Methods:
- void Echo(object service)
+ void Echo(object application)
Sends an echo petition to the remote service. Returns True if
response matches with the buffer sent. If some error is detected
@@ -61,7 +61,7 @@ Methods:
Possible errors: org.bluez.Error.InvalidArguments
org.bluez.Error.OutOfRange
- object CreateChannel(object service, string type)
+ object CreateChannel(object application, string type)
Creates a new data channel with the indicated config to the
remote Service.
@@ -74,18 +74,12 @@ Methods:
Possible errors: org.bluez.Error.InvalidArguments
org.bluez.Error.HealthError
- void DestroyChannel(object channel)
+ void DestroyChannel(object application)
Destroys the data channel object.
Possible errors: org.bluez.Error.InvalidArguments
- orb.bluez.Error.NotFound
-
---------------------------------------------------------------------------------
-
-Service org.bluez
-Interface org.bluez.HealthService
-Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/hdp_YYYY
+ org.bluez.Error.NotFound
--------------------------------------------------------------------------------
@@ -142,18 +136,17 @@ Methods:
to unregister the agent, because when this method gets called it
has already been unregistered.
- void ServiceDiscovered(object service)
+ void DeviceDiscovered(object device)
This method is called when a device containing an HDP
- application is paired or when the method Update of the
- HealthManager is called and new HealthServices are discovered.
- The method will be called once for each HealthService.
+ application is paired and is suitable for connect with the
+ application that registered this agent.
- void ServiceRemoved(object service)
+ void DeviceRemoved(object device)
- This is called if during an Update some HealthServices
- have disappeared. The method is called once for each removed
- HealthService.
+ This method is called if a device that was suitable for
+ connecting with the application becomes not suitable for
+ connecting with the application.
void ChannelConnected(object channel)
--
1.7.0.4
^ permalink raw reply related
* Changes in HDP API
From: Jose Antonio Santos Cadenas @ 2010-08-04 7:49 UTC (permalink / raw)
To: linux-bluetooth
This patch makes some changes in the HDP API based in the conversation that I
had yesterday with Luiz and Elvis.
I still have a doubt about the notification of devices in the agent. Luiz
commented that with this API the Agent and the Application could not be in
different processes, is this a problem?
An other open issue is: if we notify when a device is discovered and suitable
for connect with an application and when a devices is removed (or becomes not
suitable for connect). I think that we already need something like the patch
that we start discussing yesterday, something that can be called by the user
in order to force a new service discovery and notifies the driver that will
notify the agent. Of course we can avoid this not notifying the suitable
devices and just letting to try the connection against all the devices (if
there is no matching service it will fail). What do you think?
Regards.
Jose.
^ permalink raw reply
* [PATCH] Bluetooth: Check result code for l2cap info rsp
From: Ville Tervo @ 2010-08-04 6:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: padovan, marcel, Ville Tervo
Check result code in l2cap information response. Othervise
the response code would read invalid feature mask and access
invalid memory.
Signed-off-by: Ville Tervo <ville.tervo@nokia.com>
---
net/bluetooth/l2cap.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 0f34e12..3e3cd9d 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -3348,6 +3348,15 @@ static inline int l2cap_information_rsp(struct l2cap_conn *conn, struct l2cap_cm
del_timer(&conn->info_timer);
+ if (result != L2CAP_IR_SUCCESS) {
+ conn->info_state |= L2CAP_INFO_FEAT_MASK_REQ_DONE;
+ conn->info_ident = 0;
+
+ l2cap_conn_start(conn);
+
+ return 0;
+ }
+
if (type == L2CAP_IT_FEAT_MASK) {
conn->feat_mask = get_unaligned_le32(rsp->data);
--
1.7.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Don't send RFC for Basic Mode if only it is supported
From: Ville Tervo @ 2010-08-04 6:18 UTC (permalink / raw)
To: ext Marcel Holtmann
Cc: Gustavo F. Padovan, linux-bluetooth@vger.kernel.org,
Gustavo F. Padovan
In-Reply-To: <1280886991.12579.98.camel@localhost.localdomain>
On Wed, Aug 04, 2010 at 03:56:31AM +0200, ext Marcel Holtmann wrote:
> Hi Ville,
>
> > > On 07/29/2010 09:00 PM, ext Gustavo F. Padovan wrote:
> > > >From: Gustavo F. Padovan<padovan@profusion.mobi>
> > > >
> > > >If the remote side doesn't support Enhanced Retransmission Mode neither
> > > >Streaming Mode, we shall not send the RFC option.
> > > >Some devices that only supports Basic Mode do not understanding the RFC
> > > >option. This patch fix the regression found with that devices.
> > >
> > >
> > > Yes this is better. After some research i found out that quite many
> > > old devices are not handling properly unknown options.
> >
> > Nice, we can put this upstream, do you agree?
> >
> > >
> > > However I found another regression. And this kind of patch is needed
> > > also. Otherwise the info rsp code is reading feat_mask from failed
> > > response (and does invalid memory access).
> > >
> > >
> > > diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> > > index 0f34e12..1e174a4 100644
> > > --- a/net/bluetooth/l2cap.c
> > > +++ b/net/bluetooth/l2cap.c
> > > @@ -3348,6 +3348,13 @@ static inline int
> > > l2cap_information_rsp(struct l2cap_conn *conn, struct l2cap_cm
> > >
> > > del_timer(&conn->info_timer);
> > >
> > > + if (result != L2CAP_IR_SUCCESS) {
> > > + conn->info_state |= L2CAP_INFO_FEAT_MASK_REQ_DONE;
> > > + conn->info_ident = 0;
> > > + l2cap_conn_start(conn);
> > > + return 0;
> > > + }
> > > +
> > > if (type == L2CAP_IT_FEAT_MASK) {
> > > conn->feat_mask = get_unaligned_le32(rsp->data);
> > >
> >
> > Ack. Send a proper GIT patch then we can push this fix.
>
> am I getting this proper patch or not?
Yes.
--
Ville
^ permalink raw reply
* [PATCH] Bluetooth: Don't send RFC for Basic Mode if only it is supported
From: Gustavo F. Padovan @ 2010-08-04 2:49 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, Gustavo F. Padovan
From: Gustavo F. Padovan <padovan@profusion.mobi>
If the remote side doesn't support Enhanced Retransmission Mode neither
Streaming Mode, we shall not send the RFC option.
Some devices that only supports Basic Mode do not understanding the RFC
option. This patch fix the regression found with that devices.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9ba1e8e..0f34e12 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2527,6 +2527,10 @@ done:
if (pi->imtu != L2CAP_DEFAULT_MTU)
l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
+ if (!(pi->conn->feat_mask & L2CAP_FEAT_ERTM) &&
+ !(pi->conn->feat_mask & L2CAP_FEAT_STREAMING))
+ break;
+
rfc.mode = L2CAP_MODE_BASIC;
rfc.txwin_size = 0;
rfc.max_transmit = 0;
@@ -2534,6 +2538,8 @@ done:
rfc.monitor_timeout = 0;
rfc.max_pdu_size = 0;
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
+ (unsigned long) &rfc);
break;
case L2CAP_MODE_ERTM:
@@ -2546,6 +2552,9 @@ done:
if (L2CAP_DEFAULT_MAX_PDU_SIZE > pi->conn->mtu - 10)
rfc.max_pdu_size = cpu_to_le16(pi->conn->mtu - 10);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
+ (unsigned long) &rfc);
+
if (!(pi->conn->feat_mask & L2CAP_FEAT_FCS))
break;
@@ -2566,6 +2575,9 @@ done:
if (L2CAP_DEFAULT_MAX_PDU_SIZE > pi->conn->mtu - 10)
rfc.max_pdu_size = cpu_to_le16(pi->conn->mtu - 10);
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
+ (unsigned long) &rfc);
+
if (!(pi->conn->feat_mask & L2CAP_FEAT_FCS))
break;
@@ -2577,9 +2589,6 @@ done:
break;
}
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_RFC, sizeof(rfc),
- (unsigned long) &rfc);
-
/* FIXME: Need actual value of the flush timeout */
//if (flush_to != L2CAP_DEFAULT_FLUSH_TO)
// l2cap_add_conf_opt(&ptr, L2CAP_CONF_FLUSH_TO, 2, pi->flush_to);
--
1.7.1.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