* Re: [PATCH BlueZ 1/2] shared/gatt-client: Remove services after Service Changed indication
From: Luiz Augusto von Dentz @ 2017-04-25 18:21 UTC (permalink / raw)
To: Marcin Kraglak; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1493121371-29377-1-git-send-email-marcin.kraglak@tieto.com>
Hi Marcin,
On Tue, Apr 25, 2017 at 2:56 PM, Marcin Kraglak
<marcin.kraglak@tieto.com> wrote:
> Clear services in range of Service Changed indication.
> From specification, Version 4.2 [Vol 3, Part G] 2.5.2 Attribute Caching:
> "The client, upon receiving a Handle Value Indication containing the range of
> affected Attribute Handles, shall consider the attribute cache invalid over
> the affected Attribute Handle range".
> ---
> src/shared/gatt-client.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/src/shared/gatt-client.c b/src/shared/gatt-client.c
> index 0134721..7d23702 100644
> --- a/src/shared/gatt-client.c
> +++ b/src/shared/gatt-client.c
> @@ -1475,8 +1475,6 @@ static void service_changed_complete(struct discovery_op *op, bool success,
> util_debug(client->debug_callback, client->debug_data,
> "Failed to discover services within changed range - "
> "error: 0x%02x", att_ecode);
> -
> - gatt_db_clear_range(client->db, start_handle, end_handle);
> }
>
> /* Notify the upper layer of changed services */
> @@ -1514,7 +1512,8 @@ static void service_changed_failure(struct discovery_op *op)
> {
> struct bt_gatt_client *client = op->client;
>
> - gatt_db_clear_range(client->db, op->start, op->end);
> + util_debug(client->debug_callback, client->debug_data,
> + "Failed to process Service Changed");
> }
>
> static void process_service_changed(struct bt_gatt_client *client,
> @@ -1523,6 +1522,8 @@ static void process_service_changed(struct bt_gatt_client *client,
> {
> struct discovery_op *op;
>
> + gatt_db_clear_range(client->db, start_handle, end_handle);
> +
> op = discovery_op_create(client, start_handle, end_handle,
> service_changed_complete,
> service_changed_failure);
> --
> 2.4.3
The code used to do exactly that, but it turn out it very inefficient
with devices that just loose the entire database when rebooted so we
started doing cache validation so we don't remove the services upfront
but check if the service range has changed so we prevent rediscovering
everything.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] Bluetooth: allocate data for kpp on heap
From: Szymon Janc @ 2017-04-25 17:38 UTC (permalink / raw)
To: Salvatore Benedetto
Cc: gustavo, linux-bluetooth, herbert, marcel, johan.hedberg
In-Reply-To: <1493135987-2618-1-git-send-email-salvatore.benedetto@intel.com>
Hi,
On Tuesday, 25 April 2017 08:59:47 PDT Salvatore Benedetto wrote:
> Bluetooth would crash when computing ECDH keys with kpp
> if VMAP_STACK is enabled. Fix by allocating data passed
> to kpp on heap.
>
> Fixes: 58771c1c ("Bluetooth: convert smp and selftest to crypto kpp
> API")
> Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
> ---
> net/bluetooth/ecdh_helper.c | 6 ++++--
> net/bluetooth/selftest.c | 16 +++++++++++-----
> 2 files changed, 15 insertions(+), 7 deletions(-)
>
> diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
> index b6d9aa1..8018447 100644
> --- a/net/bluetooth/ecdh_helper.c
> +++ b/net/bluetooth/ecdh_helper.c
> @@ -59,7 +59,7 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8
> private_key[32], struct ecdh p;
> struct ecdh_completion result;
> struct scatterlist src, dst;
> - u8 tmp[64];
> + u8 *tmp = kmalloc(64, GFP_KERNEL);
Should this be checked for null?
> u8 *buf;
> unsigned int buf_len;
> int err = -ENOMEM;
> @@ -68,7 +68,7 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8
> private_key[32], if (IS_ERR(tfm)) {
> pr_err("alg: kpp: Failed to load tfm for kpp: %ld\n",
> PTR_ERR(tfm));
> - return false;
> + goto free_tmp;
> }
>
> req = kpp_request_alloc(tfm, GFP_KERNEL);
> @@ -128,6 +128,8 @@ bool compute_ecdh_secret(const u8 public_key[64], const
> u8 private_key[32], kpp_request_free(req);
> free_kpp:
> crypto_free_kpp(tfm);
> +free_tmp:
> + kfree(tmp);
> return (err == 0);
> }
>
> diff --git a/net/bluetooth/selftest.c b/net/bluetooth/selftest.c
> index efef281..9a72f8f 100644
> --- a/net/bluetooth/selftest.c
> +++ b/net/bluetooth/selftest.c
> @@ -142,18 +142,24 @@ static int __init test_ecdh_sample(const u8
> priv_a[32], const u8 priv_b[32], const u8 pub_a[64], const u8 pub_b[64],
> const u8 dhkey[32])
> {
> - u8 dhkey_a[32], dhkey_b[32];
> + u8 *dhkey_a = kmalloc(64, GFP_KERNEL);
> + u8 *dhkey_b = &dhkey_a[32];
> + int ret = 0;
>
> compute_ecdh_secret(pub_b, priv_a, dhkey_a);
> compute_ecdh_secret(pub_a, priv_b, dhkey_b);
>
> - if (memcmp(dhkey_a, dhkey, 32))
> - return -EINVAL;
> + if (memcmp(dhkey_a, dhkey, 32)) {
> + ret = -EINVAL;
> + goto out;
> + }
>
> if (memcmp(dhkey_b, dhkey, 32))
> - return -EINVAL;
> + ret = -EINVAL;
>
> - return 0;
> +out:
> + kfree(dhkey_a);
> + return ret;
> }
>
> static char test_ecdh_buffer[32];
--
pozdrawiam
Szymon Janc
^ permalink raw reply
* Re: [PATCH] Bluetooth: allocate data for kpp on heap
From: Marcel Holtmann @ 2017-04-25 17:28 UTC (permalink / raw)
To: Salvatore Benedetto
Cc: Gustavo F. Padovan, Linux Bluetooth, Herbert Xu, Johan Hedberg
In-Reply-To: <1493135987-2618-1-git-send-email-salvatore.benedetto@intel.com>
Hi Salvatore,
> Bluetooth would crash when computing ECDH keys with kpp
> if VMAP_STACK is enabled. Fix by allocating data passed
> to kpp on heap.
>
> Fixes: 58771c1c ("Bluetooth: convert smp and selftest to crypto kpp
> API")
> Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
> ---
> net/bluetooth/ecdh_helper.c | 6 ++++--
> net/bluetooth/selftest.c | 16 +++++++++++-----
> 2 files changed, 15 insertions(+), 7 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: SENDING GATT NOTIFICATION USING DBUS
From: sayandasgupta12 @ 2017-04-25 16:23 UTC (permalink / raw)
To: Barry Byford; +Cc: Bluez mailing list
In-Reply-To: <CAAu3APa3nWu_t+aRREFbQ3-VfLhJWLhgqmSadhMec57rbyw7SQ@mail.gmail.com>
Hi Barry,
I did look at it. But I want a solution in C and not python. I am not
conversant with Python. How do it convert this into C. I am a beginner
in bluez. Can you help me on this .
On Tue, Apr 25, 2017 at 7:59 PM, Barry Byford <31baz66@gmail.com> wrote:
> Hello,
>
> On 25 April 2017 at 11:43, sayandasgupta12@gmail.com
> <sayandasgupta12@gmail.com> wrote:
>> I am trying to send GATT notification in bluez 5.43 using DBUS. But
>> currently the gatt-service.c doesn't provide any details how to send
>> it using DBUS. Currently
>>
>> static DBusMessage *chr_start_notify(DBusConnection *conn, DBusMessage
>> *msg, void *user_data)
>>
>> return g_dbus_create_error(msg, DBUS_ERROR_NOT_SUPPORTED, "Not Supported")
>>
>>
>> is given like this as no characteristic supports notification in the
>> given code. But I am trying to build a custom service which has
>> notifiable characteristics. How should i handle it. What should be the
>> code that i need to write inside char_start_notify to achieve it.
>
> Have you taken a look at test/example-gatt-server?
>
> The notifications are done with the PropertiesChanged signal on the
> value of the characteristic
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n121
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server#n200
>
> And in the example are issued with:
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server#n297
> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server#n399
>
> Hope that helps
>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Bluetooth: allocate data for kpp on heap
From: Salvatore Benedetto @ 2017-04-25 15:59 UTC (permalink / raw)
To: gustavo, linux-bluetooth
Cc: herbert, marcel, johan.hedberg, Salvatore Benedetto
Bluetooth would crash when computing ECDH keys with kpp
if VMAP_STACK is enabled. Fix by allocating data passed
to kpp on heap.
Fixes: 58771c1c ("Bluetooth: convert smp and selftest to crypto kpp
API")
Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
---
net/bluetooth/ecdh_helper.c | 6 ++++--
net/bluetooth/selftest.c | 16 +++++++++++-----
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
index b6d9aa1..8018447 100644
--- a/net/bluetooth/ecdh_helper.c
+++ b/net/bluetooth/ecdh_helper.c
@@ -59,7 +59,7 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8 private_key[32],
struct ecdh p;
struct ecdh_completion result;
struct scatterlist src, dst;
- u8 tmp[64];
+ u8 *tmp = kmalloc(64, GFP_KERNEL);
u8 *buf;
unsigned int buf_len;
int err = -ENOMEM;
@@ -68,7 +68,7 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8 private_key[32],
if (IS_ERR(tfm)) {
pr_err("alg: kpp: Failed to load tfm for kpp: %ld\n",
PTR_ERR(tfm));
- return false;
+ goto free_tmp;
}
req = kpp_request_alloc(tfm, GFP_KERNEL);
@@ -128,6 +128,8 @@ bool compute_ecdh_secret(const u8 public_key[64], const u8 private_key[32],
kpp_request_free(req);
free_kpp:
crypto_free_kpp(tfm);
+free_tmp:
+ kfree(tmp);
return (err == 0);
}
diff --git a/net/bluetooth/selftest.c b/net/bluetooth/selftest.c
index efef281..9a72f8f 100644
--- a/net/bluetooth/selftest.c
+++ b/net/bluetooth/selftest.c
@@ -142,18 +142,24 @@ static int __init test_ecdh_sample(const u8 priv_a[32], const u8 priv_b[32],
const u8 pub_a[64], const u8 pub_b[64],
const u8 dhkey[32])
{
- u8 dhkey_a[32], dhkey_b[32];
+ u8 *dhkey_a = kmalloc(64, GFP_KERNEL);
+ u8 *dhkey_b = &dhkey_a[32];
+ int ret = 0;
compute_ecdh_secret(pub_b, priv_a, dhkey_a);
compute_ecdh_secret(pub_a, priv_b, dhkey_b);
- if (memcmp(dhkey_a, dhkey, 32))
- return -EINVAL;
+ if (memcmp(dhkey_a, dhkey, 32)) {
+ ret = -EINVAL;
+ goto out;
+ }
if (memcmp(dhkey_b, dhkey, 32))
- return -EINVAL;
+ ret = -EINVAL;
- return 0;
+out:
+ kfree(dhkey_a);
+ return ret;
}
static char test_ecdh_buffer[32];
--
2.7.4
^ permalink raw reply related
* Re: SENDING GATT NOTIFICATION USING DBUS
From: Barry Byford @ 2017-04-25 14:29 UTC (permalink / raw)
To: sayandasgupta12@gmail.com; +Cc: Bluez mailing list
In-Reply-To: <CAF6QkFKyKtJA-TVQnpDCb1inrSMXLkSd14WNJzRREAZbTnf-Ng@mail.gmail.com>
Hello,
On 25 April 2017 at 11:43, sayandasgupta12@gmail.com
<sayandasgupta12@gmail.com> wrote:
> I am trying to send GATT notification in bluez 5.43 using DBUS. But
> currently the gatt-service.c doesn't provide any details how to send
> it using DBUS. Currently
>
> static DBusMessage *chr_start_notify(DBusConnection *conn, DBusMessage
> *msg, void *user_data)
>
> return g_dbus_create_error(msg, DBUS_ERROR_NOT_SUPPORTED, "Not Supported")
>
>
> is given like this as no characteristic supports notification in the
> given code. But I am trying to build a custom service which has
> notifiable characteristics. How should i handle it. What should be the
> code that i need to write inside char_start_notify to achieve it.
Have you taken a look at test/example-gatt-server?
The notifications are done with the PropertiesChanged signal on the
value of the characteristic
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/gatt-api.txt#n121
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server#n200
And in the example are issued with:
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server#n297
https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/test/example-gatt-server#n399
Hope that helps
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH BlueZ 2/2] core/gatt-client: Add support for Includes property
From: Marcin Kraglak @ 2017-04-25 11:56 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1493121371-29377-1-git-send-email-marcin.kraglak@tieto.com>
Add implementation of Includes property in GATT service interface.
---
src/gatt-client.c | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 136 insertions(+), 8 deletions(-)
diff --git a/src/gatt-client.c b/src/gatt-client.c
index 114981c..15219e2 100644
--- a/src/gatt-client.c
+++ b/src/gatt-client.c
@@ -72,6 +72,15 @@ struct service {
bt_uuid_t uuid;
char *path;
struct queue *chrcs;
+ struct queue *incl_services;
+};
+
+struct incl_service {
+ uint16_t handle;
+ uint16_t start_handle;
+ uint16_t end_handle;
+ struct service *service;
+ struct service *incl_service;
};
typedef bool (*async_dbus_op_complete_t)(void *data);
@@ -1398,10 +1407,39 @@ static gboolean service_get_primary(const GDBusPropertyTable *property,
return TRUE;
}
+static void append_incl_service_path(void *data, void *user_data)
+{
+ struct incl_service *incl_service = data;
+ DBusMessageIter *array = user_data;
+
+ if (!incl_service->incl_service)
+ return;
+
+ dbus_message_iter_append_basic(array, DBUS_TYPE_OBJECT_PATH,
+ &incl_service->incl_service->path);
+}
+
+static gboolean service_get_includes(const GDBusPropertyTable *property,
+ DBusMessageIter *iter, void *data)
+{
+ struct service *service = data;
+ DBusMessageIter array;
+
+ dbus_message_iter_open_container(iter, DBUS_TYPE_ARRAY, "{o}", &array);
+
+ queue_foreach(service->incl_services, append_incl_service_path, &array);
+
+ dbus_message_iter_close_container(iter, &array);
+
+ return TRUE;
+
+}
+
static const GDBusPropertyTable service_properties[] = {
{ "UUID", "s", service_get_uuid },
{ "Device", "o", service_get_device },
{ "Primary", "b", service_get_primary },
+ { "Includes", "ao", service_get_includes },
{ }
};
@@ -1410,10 +1448,40 @@ static void service_free(void *data)
struct service *service = data;
queue_destroy(service->chrcs, NULL); /* List should be empty here */
+ queue_destroy(service->incl_services, NULL);
g_free(service->path);
free(service);
}
+static bool match_service_handle(const void *a, const void *b)
+{
+ const struct service *service = a;
+ uint16_t start_handle = PTR_TO_UINT(b);
+
+ return service->start_handle == start_handle;
+}
+
+static void add_included_service(struct gatt_db_attribute *attrib,
+ void *user_data)
+{
+ struct service *service = user_data;
+ struct incl_service *incl_service;
+ struct btd_gatt_client *client = service->client;
+
+ incl_service = new0(struct incl_service, 1);
+ incl_service->service = service;
+
+ gatt_db_attribute_get_incl_data(attrib, &incl_service->handle,
+ &incl_service->start_handle,
+ &incl_service->end_handle);
+
+ incl_service->incl_service = queue_find(client->services,
+ match_service_handle,
+ UINT_TO_PTR(incl_service->start_handle));
+
+ queue_push_tail(service->incl_services, incl_service);
+}
+
static struct service *service_create(struct gatt_db_attribute *attr,
struct btd_gatt_client *client)
{
@@ -1423,6 +1491,7 @@ static struct service *service_create(struct gatt_db_attribute *attr,
service = new0(struct service, 1);
service->chrcs = queue_new();
+ service->incl_services = queue_new();
service->client = client;
gatt_db_attribute_get_service_data(attr, &service->start_handle,
@@ -1434,6 +1503,8 @@ static struct service *service_create(struct gatt_db_attribute *attr,
service->path = g_strdup_printf("%s/service%04x", device_path,
service->start_handle);
+ gatt_db_service_foreach_incl(attr, add_included_service, service);
+
if (!g_dbus_register_interface(btd_get_dbus_connection(), service->path,
GATT_SERVICE_IFACE,
NULL, NULL,
@@ -1459,6 +1530,63 @@ static struct service *service_create(struct gatt_db_attribute *attr,
return service;
}
+static void incl_service_on_unregister(void *data, void *user_data)
+{
+ struct incl_service *incl_service = (struct incl_service *) data;
+ struct service *service = (struct service *) user_data;
+
+ if (incl_service->incl_service == service) {
+ incl_service->incl_service = NULL;
+
+ g_dbus_emit_property_changed(btd_get_dbus_connection(),
+ incl_service->service->path,
+ GATT_SERVICE_IFACE,
+ "Includes");
+ }
+}
+
+static void incl_service_on_register(void *data, void *user_data)
+{
+ struct incl_service *incl_service = (struct incl_service *) data;
+ struct service *service = (struct service *) user_data;
+
+ if (!incl_service->incl_service &&
+ incl_service->start_handle == service->start_handle) {
+ incl_service->incl_service = service;
+
+ g_dbus_emit_property_changed(btd_get_dbus_connection(),
+ incl_service->service->path,
+ GATT_SERVICE_IFACE,
+ "Includes");
+ }
+}
+
+struct foreach_incl_service_data {
+ queue_foreach_func_t func;
+ void *user_data;
+};
+
+static void incl_service_cb(void *data, void *user_data)
+{
+ struct service *service = (struct service *) data;
+ struct foreach_incl_service_data *incl_data =
+ (struct foreach_incl_service_data *) user_data;
+
+ queue_foreach(service->incl_services, incl_data->func,
+ incl_data->user_data);
+}
+
+static void client_foreach_incl_service(struct btd_gatt_client *client,
+ queue_foreach_func_t func, void *user_data)
+{
+ struct foreach_incl_service_data incl_data = {
+ .user_data = user_data,
+ .func = func,
+ };
+
+ queue_foreach(client->services, incl_service_cb, &incl_data);
+}
+
static void unregister_service(void *data)
{
struct service *service = data;
@@ -1466,6 +1594,11 @@ static void unregister_service(void *data)
DBG("Removing GATT service: %s", service->path);
queue_remove_all(service->chrcs, NULL, NULL, unregister_characteristic);
+ queue_remove_all(service->incl_services, NULL, NULL, free);
+
+ /* Make sure that no one included service points to this one */
+ client_foreach_incl_service(service->client,
+ incl_service_on_unregister, service);
g_dbus_unregister_interface(btd_get_dbus_connection(), service->path,
GATT_SERVICE_IFACE);
@@ -1564,6 +1697,9 @@ static void export_service(struct gatt_db_attribute *attr, void *user_data)
return;
}
+ /* Check if any included service points to this one */
+ client_foreach_incl_service(client, incl_service_on_register, service);
+
queue_push_tail(client->services, service);
}
@@ -1691,14 +1827,6 @@ void btd_gatt_client_service_added(struct btd_gatt_client *client,
export_service(attrib, client);
}
-static bool match_service_handle(const void *a, const void *b)
-{
- const struct service *service = a;
- uint16_t start_handle = PTR_TO_UINT(b);
-
- return service->start_handle == start_handle;
-}
-
void btd_gatt_client_service_removed(struct btd_gatt_client *client,
struct gatt_db_attribute *attrib)
{
--
2.4.3
^ permalink raw reply related
* [PATCH BlueZ 1/2] shared/gatt-client: Remove services after Service Changed indication
From: Marcin Kraglak @ 2017-04-25 11:56 UTC (permalink / raw)
To: linux-bluetooth
Clear services in range of Service Changed indication.
>From specification, Version 4.2 [Vol 3, Part G] 2.5.2 Attribute Caching:
"The client, upon receiving a Handle Value Indication containing the range of
affected Attribute Handles, shall consider the attribute cache invalid over
the affected Attribute Handle range".
---
src/shared/gatt-client.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/src/shared/gatt-client.c b/src/shared/gatt-client.c
index 0134721..7d23702 100644
--- a/src/shared/gatt-client.c
+++ b/src/shared/gatt-client.c
@@ -1475,8 +1475,6 @@ static void service_changed_complete(struct discovery_op *op, bool success,
util_debug(client->debug_callback, client->debug_data,
"Failed to discover services within changed range - "
"error: 0x%02x", att_ecode);
-
- gatt_db_clear_range(client->db, start_handle, end_handle);
}
/* Notify the upper layer of changed services */
@@ -1514,7 +1512,8 @@ static void service_changed_failure(struct discovery_op *op)
{
struct bt_gatt_client *client = op->client;
- gatt_db_clear_range(client->db, op->start, op->end);
+ util_debug(client->debug_callback, client->debug_data,
+ "Failed to process Service Changed");
}
static void process_service_changed(struct bt_gatt_client *client,
@@ -1523,6 +1522,8 @@ static void process_service_changed(struct bt_gatt_client *client,
{
struct discovery_op *op;
+ gatt_db_clear_range(client->db, start_handle, end_handle);
+
op = discovery_op_create(client, start_handle, end_handle,
service_changed_complete,
service_changed_failure);
--
2.4.3
^ permalink raw reply related
* SENDING GATT NOTIFICATION USING DBUS
From: sayandasgupta12 @ 2017-04-25 10:43 UTC (permalink / raw)
To: linux-bluetooth
I am trying to send GATT notification in bluez 5.43 using DBUS. But
currently the gatt-service.c doesn't provide any details how to send
it using DBUS. Currently
static DBusMessage *chr_start_notify(DBusConnection *conn, DBusMessage
*msg, void *user_data)
return g_dbus_create_error(msg, DBUS_ERROR_NOT_SUPPORTED, "Not Supported")
is given like this as no characteristic supports notification in the
given code. But I am trying to build a custom service which has
notifiable characteristics. How should i handle it. What should be the
code that i need to write inside char_start_notify to achieve it.
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix user channel for 32bit userspace on 64bit kernel
From: Marcel Holtmann @ 2017-04-25 2:53 UTC (permalink / raw)
To: Szymon Janc; +Cc: Linux Bluetooth, Marko Kiiskila
In-Reply-To: <20170425012504.30505-1-szymon.janc@codecoup.pl>
Hi Szymon,
> Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
> defined as 0x80000000. This results in sendmsg failure if used from 32bit
> userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
> in flags check in hci_sock_sendmsg.
>
> Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
> Signed-off-by: Marko Kiiskila <marko@runtime.io>
> ---
> net/bluetooth/hci_sock.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH] Bluetooth: Fix user channel for 32bit userspace on 64bit kernel
From: Szymon Janc @ 2017-04-25 1:25 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc, Marko Kiiskila
Running 32bit userspace on 64bit kernel results in MSG_CMSG_COMPAT being
defined as 0x80000000. This results in sendmsg failure if used from 32bit
userspace running on 64bit kernel. Fix this by accounting for MSG_CMSG_COMPAT
in flags check in hci_sock_sendmsg.
Signed-off-by: Szymon Janc <szymon.janc@codecoup.pl>
Signed-off-by: Marko Kiiskila <marko@runtime.io>
---
net/bluetooth/hci_sock.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index f64d656..e9d3e1b 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -1680,7 +1680,8 @@ static int hci_sock_sendmsg(struct socket *sock, struct msghdr *msg,
if (msg->msg_flags & MSG_OOB)
return -EOPNOTSUPP;
- if (msg->msg_flags & ~(MSG_DONTWAIT|MSG_NOSIGNAL|MSG_ERRQUEUE))
+ if (msg->msg_flags &
+ ~(MSG_DONTWAIT|MSG_NOSIGNAL|MSG_ERRQUEUE|MSG_CMSG_COMPAT))
return -EINVAL;
if (len < 4 || len > HCI_MAX_FRAME_SIZE)
--
2.9.3
^ permalink raw reply related
* Re: GATT Server: DBus GATT Services not advertised/exported
From: Olivier MARTIN @ 2017-04-24 21:23 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Barry Byford, Bluez mailing list
In-Reply-To: <CABBYNZK-2xr2n6B_JCD7uXkvHPLDsj5N-3Md=w6J_JUO7VXP7Q@mail.gmail.com>
Hi again,
forget about what I said in my previous email. I thought was an
incompatibility between Bluez and the Ubuntu 16.04 Linux kernel. But
after coming back on Bluez v5.37 + additional patchset to add DBus GATT
Application support - these following patches:
d41a7bf shared/att: Fix not notifying the callback
8d3e9ca core/gatt-database: Don't always wait for response
98bf7ec gdbus/client: Use g_dbus_send_message if callback is not set
b960430 test/example-gatt-server: Don't order objects
9175f5e gatt-database: Fix GATT object ordering
2ba5a6c shared/gatt-client: Fix not detecting BT_ATT_SECURITY_AUTO
24dc645 core/gatt-client: Fix printing errors if experimental is
disabled
75c0728 shared/gatt-client: Fix not clearing database after discovery
6b86c86 tools/btgatt-client: Fix write-value byte parsing
bdd8b3e tools/avinfo: Fix big endian build
cb1bccf test: Fix scripts to run with python 3
7124468 shared/gatt-client: Fix regression
e4acec5 core/device: Fix not clearing Attributes before storing
0001c4c core/device: Fix not reseting database if attributes cannot be
loaded
118633b core/device: Fix log when loading characteristic fails
166d698 shared/gatt-client: Rename tmp_queue to svcs
6f211c6 shared/gatt-client: Add debug log if characteristic cannot be
added
757eef5 client: Fix removing all devices
ad68605 obexd: client: Fix memory leaks
63774ba adapter: Fix memory leak
29e2531 tools/gatt-service: Add missing methods
06ed769 tools/gatt-service: Add missing properties
e76fad8 tools/gatt-service: Fix using RegisterService
f0e5192 client: Fix not detecting connections when starting
6a1f8e6 shared/gatt-client: Fix crash unregistering notification
1561910 shared/gatt-client: Fix bogus asserts
fee0020 core/gatt-client: Fix not being able to cancel notifications
0d9b55c shared/gatt-client: Fix not resetting request id
3213d1a shared/gatt-client: Make read_long_value more robust
54ecf66 monitor/avctp: Print <empty> if folder lenght is 0
28a582b audio/avrcp: Fix not always requesting capabilities
ca5a188 tools/btmgmt: Fix canceling pairing
6304273 client: Update remove command to support removing all devices
4c3c78b test: Add device discovery filter
cdc9435 core/gatt-database: Fix possible memory leaks
cd94d49 gdbus/client: Always call ready callback
758d2b4 test/example-gatt-server: Make use of RegisterApplication
60ebf90 core/gatt-database: Implement Application API
ae78365 doc/gatt-api: Make proper use of ObjectManager
218969a doc: fix typos in mgmt-api.txt
56776af Release 5.37
I still see the long duration during "Discovering Services" while
connecting with Android.
I added the various log (Bluez + btmon) with the steps I used in this
Github gist:
https://gist.github.com/oliviermartin/bef59f3bb9a6e5e2bf2dea5178c429e4
I do not have any suspicious message in 'dmesg'. I have not changed any
kernel settings to increase bluetooth debug messaging - can I?
I also noticed many time with Android "BLE Scanner", it fails to read
the Bluez GATT server characteristics when I request reading readable
characteristics.
What I find suspicious (but I am not a Bluetooth expert) is that there
are many error messages of this type in btmon log during the Discovering
Services done by the Android phone:
< ACL Data TX: Handle 64 flags 0x00 dlen 9
[hci0]
ATT: Error Response (0x01) len 4
Read By Type Request (0x08)
Handle: 0x000a
Error: Attribute Not Found (0x0a)
My bluetooth adapter Asus BT400 in 'dmesg':
[ 19.153383] Bluetooth: hci0: BCM20702A1 (001.002.014) build 1467
[ 19.169343] Bluetooth: hci0: Broadcom Bluetooth Device
Any idea?
On 20.04.2017 13:31, Luiz Augusto von Dentz wrote:
> Hi Oliver,
>
> On Thu, Apr 20, 2017 at 2:20 AM, Olivier MARTIN <olivier@labapart.com>
> wrote:
>> I am back on the thread.
>> What I noticed last week when I tried on Android phone with both "BLE
>> Scanner" and "Nordic Connect", discovering GATT services is really
>> really
>> slow (it takes 2 min to discover all `example-gatt-server` GATT
>> services) on
>> Nexus 4 with Android 5.1.1 and Ubuntu 16.04 with Bluez v5.44 for the
>> GATT
>> server. I am using the Asus USB-BT400 (Broadcom chipset).
>>
>> I did more investigation this evening but I have not done any
>> progress.
>> I tried with `example-gatt-server` started by the user and root and no
>> change in the poor performance.
>>
>> I do not know what is taking so long but for instance it takes many
>> seconds
>> to execute this part:
>>
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x005e
>> end: 0x0061
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0060
>> end: 0x0061
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0061
>> end:
>> 0x0061
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0062
>> end: 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0062
>> end: 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x006e
>> end: 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0065
>> end:
>> 0x0067
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0066
>> end:
>> 0x0067
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0067
>> end:
>> 0x0067
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006a
>> end:
>> 0x006c
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006b
>> end:
>> 0x006c
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006c
>> end:
>> 0x006c
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x006f
>> end:
>> 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0070
>> end:
>> 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0071
>> end:
>> 0x0071
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0072
>> end: 0x0079
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0072
>> end: 0x0079
>> bluetoothd[12913]: src/device.c:gatt_debug() Read By Type - start:
>> 0x0079
>> end: 0x0079
>> bluetoothd[12913]: src/device.c:gatt_debug() Find Info - start: 0x0077
>> end:
>> 0x0077
>
> You should be able to see their timings in HCI with btmon, or just use
> journalctl if are thinking there is a delay in processing the packets
> but I think that is not the case. These many Find Info does indeed
> looks odd, and there are even repeated range.
>
>>
>>
>>
>> On 14.04.2017 20:31, Barry Byford wrote:
>>>
>>> Hello Olivier,
>>>
>>> On 14 April 2017 at 19:14, Olivier MARTIN <olivier@labapart.com>
>>> wrote:
>>>>
>>>> Thanks Barry, setting 'ControllerMode = le' in
>>>> /etc/bluetooth/main.conf
>>>> fixed my issue. I can now see the GATT services.
>>>
>>>
>>> Good news!
>>>
>>>> But I guess my adapter now only works as BLE adapter and will ignore
>>>> the
>>>> non-LE devices.
>>>> In the comment of /etc/bluetooth/main.conf it is written the adapter
>>>> should
>>>> be by default set as 'dual'.
>>>>
>>>> Is it a bug in Bluez? Why GATT services are not exposed while using
>>>> the
>>>> default value for 'ControllerMode'?
>>>
>>>
>>> This issue has come up before and was discuss here:
>>> http://marc.info/?l=linux-bluetooth&m=146071596012263&w=2
>>>
>>>
>>>
>>>
>>>> On 14.04.2017 14:30, Barry Byford wrote:
>>>>>
>>>>>
>>>>> Hello Olivier,
>>>>>
>>>>>
>>>>> On 14 April 2017 at 12:01, Olivier MARTIN <olivier@labapart.com>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> You are right Barry, `example-advertisement` seems to work well (I
>>>>>> installed
>>>>>> and tried Nordic nRF Connect and I can see the expected
>>>>>> advertisemet
>>>>>> data).
>>>>>
>>>>>
>>>>>
>>>>> Excellent!
>>>>>
>>>>>
>>>>>> But I cannot still manage to get `example-gatt-server` :-(
>>>>>> I am sure I got it working last year with an older version of
>>>>>> Bluez.
>>>>>> But
>>>>>> I
>>>>>> cannot make it work with Bluez v5.44.
>>>>>
>>>>>
>>>>>
>>>>> OK, I've taken a look at "example-gatt-server" and have it
>>>>> working...
>>>>>
>>>>>>
>>>>>> My testing procedure:
>>>>>>
>>>>>> 1. [Laptop] First terminal: Start `sudo ./src/bluetoothd -E -n -d`
>>>>>> 2. [Laptop] Second terminal: Start unmodified Bluez
>>>>>> ./test/example-gatt-server
>>>>>> 3. [Laptop] Third terminal: Ensure the adapter is "Powered: yes"
>>>>>> and
>>>>>> "Discoverable: yes"
>>>>>
>>>>>
>>>>>
>>>>> OK, I've done this slightly different (details below). However, the
>>>>> first thing I did was edit "/etc/bluetooth/main.conf"
>>>>> I added the following line to the end of the file:
>>>>>
>>>>> ControllerMode = le
>>>>>
>>>>> Then I did the following:
>>>>> 1. [SBC1:T1] sudo ./src/bluetoothd -E -n -d
>>>>> 2. [SBC1:T2] ./example-gatt-server
>>>>> 3. [SBC1:T3] ./example-advertisement
>>>>>
>>>>>
>>>>>>
>>>>>> 4. [Android] Connect using Nordic nRF Connect (I also tried with
>>>>>> "BLE
>>>>>> Scanner") and check I see the exposed GATT services by
>>>>>> `example-gatt-server`
>>>>>> Unfortunately, I can only see:
>>>>>> - Generic Access Service (0x1800)
>>>>>> - Generic Attribute Service (0x1801)
>>>>>>
>>>>>
>>>>> I've used bluetoothctl on SBC2 to connect and read the battery
>>>>> values
>>>>> that the GATT server is counting down.
>>>>>
>>>>> $ bluetoothctl
>>>>> [NEW] Controller 00:00:00:00:5A:AD linaro-alip [default]
>>>>> [bluetooth]# scan on
>>>>> Discovery started
>>>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: yes
>>>>> [NEW] Device B8:27:EB:22:57:E0 BluezeroLight
>>>>> [bluetooth]# scan off
>>>>> Discovery stopped
>>>>> [CHG] Controller 00:00:00:00:5A:AD Discovering: no
>>>>> [bluetooth]# connect B8:27:EB:22:57:E0
>>>>> Attempting to connect to B8:27:EB:22:57:E0
>>>>> [CHG] Device B8:27:EB:22:57:E0 Connected: yes
>>>>> Connection successful
>>>>> [...snip...]
>>>>> [NEW] Primary Service
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a
>>>>> 0000180f-0000-1000-8000-00805f9b34fb
>>>>> Battery Service
>>>>> [NEW] Characteristic
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> 00002a19-0000-1000-8000-00805f9b34fb
>>>>> Battery Level
>>>>> [...snip...]
>>>>> [CHG] Device B8:27:EB:22:57:E0 ServicesResolved: yes
>>>>> [BluezeroLight]# select-attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> [BluezeroLight:/service000a/char000b]# read
>>>>> Attempting to read
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x46
>>>>> 46 F
>>>>> [BluezeroLight:/service000a/char000b]# notify on
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> Notifying:
>>>>> yes
>>>>> Notify started
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x46
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x44
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x42
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x40
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b Value:
>>>>> 0x3e
>>>>> [BluezeroLight:/service000a/char000b]# notify off
>>>>> [CHG] Attribute
>>>>> /org/bluez/hci0/dev_B8_27_EB_22_57_E0/service000a/char000b
>>>>> Notifying:
>>>>> no
>>>>> Notify stopped
>>>>>
>>>>>
>>>>> That seems to be working then. When I didn't have "ControllerMode =
>>>>> le" set then I did see it be unpredictable if it successfully
>>>>> connected or not.
>>>>> This also worked connecting with the nRF app.
>>>>>
>>>>>
>>>>> Does that work for you?
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> If I had to suspect Bluez code, I will guess there is something
>>>>>> missing
>>>>>> around here:
>>>>>>
>>>>>> bluetoothd[20429]: src/device.c:gatt_server_init() #
>>>>>> gatt_server_init
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() Primary services
>>>>>> found: 2
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0001, end:
>>>>>> 0x0005,
>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() start: 0x0014, end:
>>>>>> 0xffff,
>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>> bluetoothd[20429]: src/device.c:gatt_debug() Registered handler
>>>>>> for
>>>>>> "Service
>>>>>> Changed": 0
>>>>>> bluetoothd[20429]: src/device.c:gatt_client_ready_cb() status:
>>>>>> success,
>>>>>> error: 0
>>>>>>
>>>>>> As Bluez daemon does not get the GATT services from Buez GATT
>>>>>> Database.
>>>>>> But
>>>>>> it might be me who miss a step...
>>>>>>
>>>>>>
>>>>>> On 14.04.2017 12:37, Barry Byford wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> example-advertisementHello Oliver,
>>>>>>>
>>>>>>>
>>>>>>> On 14 April 2017 at 11:03, Olivier MARTIN <olivier@labapart.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Thanks for replying my message Barry,
>>>>>>>>
>>>>>>>> Sorry, I forgot to mention but I start Bluez daemon with `sudo
>>>>>>>> ./src/bluetoothd -E -n -d` (after stopping the bluetooth
>>>>>>>> service). So
>>>>>>>> I
>>>>>>>> already run it with sudo and experimental option.
>>>>>>>>
>>>>>>>> I am not sure to understand what you mean by "this kind of error
>>>>>>>> message".
>>>>>>>> Because I do not see any error message in the log I provided.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> OK, that was bad on my part. I read it as complaining that there
>>>>>>> were
>>>>>>> too many advertisements. Looking again that wasn't what it was
>>>>>>> say.
>>>>>>> Apologies.
>>>>>>>
>>>>>>>>
>>>>>>>> Any other idea?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> I am by Linux Single Board Computers (SBC) today so I'm able to
>>>>>>> run
>>>>>>> what you are running and can show you what I'm seeing. I'll focus
>>>>>>> on
>>>>>>> example-advertisement first as example-gatt-server doesn't change
>>>>>>> the
>>>>>>> advertisements.
>>>>>>>
>>>>>>> I've started the BlueZ daemon with "./src/bluetoothd -E -n -d"
>>>>>>>
>>>>>>> In another shell when I start "./example-advertisement" I see the
>>>>>>> following in the output:
>>>>>>>
>>>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode() sending Set
>>>>>>> Powered command for index 0
>>>>>>> bluetoothd[2325]: src/adapter.c:property_set_mode_complete()
>>>>>>> Success
>>>>>>> (0x00)
>>>>>>> bluetoothd[2325]: src/adapter.c:new_settings_callback() Settings:
>>>>>>> 0x00000ad1
>>>>>>> bluetoothd[2325]: src/adapter.c:settings_changed() Changed
>>>>>>> settings:
>>>>>>> 0x00000001
>>>>>>> bluetoothd[2325]: src/adapter.c:adapter_start() adapter
>>>>>>> /org/bluez/hci0 has been enabled
>>>>>>> bluetoothd[2325]: src/adapter.c:trigger_passive_scanning()
>>>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>>>> RegisterAdvertisement
>>>>>>> bluetoothd[2325]: src/advertising.c:client_create() Adding proxy
>>>>>>> for
>>>>>>> /org/bluez/example/advertisement0
>>>>>>> bluetoothd[2325]: src/advertising.c:register_advertisement()
>>>>>>> Registered advertisement at path
>>>>>>> /org/bluez/example/advertisement0
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>>>> ServiceUUID: 180D
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_uuids() Adding
>>>>>>> ServiceUUID: 180F
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_manufacturer_data()
>>>>>>> Adding
>>>>>>> ManufacturerData for ffff
>>>>>>> bluetoothd[2325]: src/advertising.c:parse_service_data() Adding
>>>>>>> ServiceData for 9999
>>>>>>> bluetoothd[2325]: src/advertising.c:refresh_advertisement()
>>>>>>> Refreshing
>>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>>> bluetoothd[2325]: src/advertising.c:add_adv_callback()
>>>>>>> Advertisement
>>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>>
>>>>>>>
>>>>>>> On a second SBC, at the command line I run "bluetoothctl" and do
>>>>>>> "scan
>>>>>>> on". Once my first SBC is found I do "scan off". I then do "info
>>>>>>> B8:27:EB:22:57:E0" (this is the address of the first SBC) which
>>>>>>> gives
>>>>>>> the following output:
>>>>>>>
>>>>>>> [bluetooth]# info B8:27:EB:22:57:E0
>>>>>>> Device B8:27:EB:22:57:E0
>>>>>>> Alias: B8-27-EB-22-57-E0
>>>>>>> Paired: no
>>>>>>> Trusted: no
>>>>>>> Blocked: no
>>>>>>> Connected: no
>>>>>>> LegacyPairing: no
>>>>>>> UUID: Heart Rate
>>>>>>> (0000180d-0000-1000-8000-00805f9b34fb)
>>>>>>> UUID: Battery Service
>>>>>>> (0000180f-0000-1000-8000-00805f9b34fb)
>>>>>>> ManufacturerData Key: 0xffff
>>>>>>> ManufacturerData Value: 0x00
>>>>>>> ManufacturerData Value: 0x01
>>>>>>> ManufacturerData Value: 0x02
>>>>>>> ManufacturerData Value: 0x03
>>>>>>> ManufacturerData Value: 0x04
>>>>>>> ServiceData Key: 00009999-0000-1000-8000-00805f9b34fb
>>>>>>> ServiceData Value: 0x00
>>>>>>> ServiceData Value: 0x01
>>>>>>> ServiceData Value: 0x02
>>>>>>> ServiceData Value: 0x03
>>>>>>> ServiceData Value: 0x04
>>>>>>>
>>>>>>>
>>>>>>> I've also done a scan from my Android phone (using the Nordic nRF
>>>>>>> Connect app) and can see the advertisements also (just hard to
>>>>>>> share
>>>>>>> that information on here).
>>>>>>>
>>>>>>> Does that help?
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 13.04.2017 19:59, Barry Byford wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hello Olivier,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 13 April 2017 at 12:14, Olivier MARTIN
>>>>>>>>> <olivier@labapart.com>
>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>> I am having issue to advertise/export GATT services exposed
>>>>>>>>>> through
>>>>>>>>>> DBus
>>>>>>>>>> API. I tried `./test/example-gatt-server`. And I also tried to
>>>>>>>>>> merge
>>>>>>>>>> `./test/example-advertisement` into
>>>>>>>>>> `./test/example-gatt-server`.
>>>>>>>>>> But
>>>>>>>>>> in
>>>>>>>>>> both cases I only see the two compulsory GATT services:
>>>>>>>>>> - Generic Access Service (0x1800)
>>>>>>>>>> - Generic Attribute Service (0x1801)
>>>>>>>>>>
>>>>>>>>>> I am using Bluez v5.44. And I also tried Bluez v5.37.
>>>>>>>>>>
>>>>>>>>>> GATT Services seem to be discovered by Bluez (note: I added
>>>>>>>>>> additional
>>>>>>>>>> debug
>>>>>>>>>> statement all prefixed with '#'):
>>>>>>>>>>
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app()
>>>>>>>>>> #
>>>>>>>>>> manager_register_app
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_app() #
>>>>>>>>>> create_app
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:manager_register_app()
>>>>>>>>>> Registering
>>>>>>>>>> application: :1.404:/
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>>>> RegisterAdvertisement
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:client_create() Adding
>>>>>>>>>> proxy
>>>>>>>>>> for
>>>>>>>>>> /org/bluez/example/advertisement0
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:register_advertisement()
>>>>>>>>>> Registered
>>>>>>>>>> advertisement at path /org/bluez/example/advertisement0
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0/char2, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char0/desc0, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char2/desc3, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char2, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service1/char0, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char1, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0/char1, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char1/desc3, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char1/desc2, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0/char0, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2, iface: org.bluez.GattService1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service1, iface: org.bluez.GattService1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service0, iface: org.bluez.GattService1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char0/desc1, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char2/desc2, iface:
>>>>>>>>>> org.bluez.GattDescriptor1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:proxy_added_cb() Object
>>>>>>>>>> received:
>>>>>>>>>> /org/bluez/example/service2/char0, iface:
>>>>>>>>>> org.bluez.GattCharacteristic1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() #
>>>>>>>>>> client_ready_cb
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>>> create_service
>>>>>>>>>> from /org/bluez/example/service2
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>>> create_service
>>>>>>>>>> from /org/bluez/example/service1
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:create_service() #
>>>>>>>>>> create_service
>>>>>>>>>> from /org/bluez/example/service0
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_app() #
>>>>>>>>>> database_add_app
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service()
>>>>>>>>>> #
>>>>>>>>>> database_add_service
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored
>>>>>>>>>> CEP
>>>>>>>>>> value
>>>>>>>>>> in
>>>>>>>>>> the database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>>>> Created
>>>>>>>>>> CEP
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored
>>>>>>>>>> CEP
>>>>>>>>>> value
>>>>>>>>>> in
>>>>>>>>>> the database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>>>> Created
>>>>>>>>>> CEP
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:cep_write_cb() Stored
>>>>>>>>>> CEP
>>>>>>>>>> value
>>>>>>>>>> in
>>>>>>>>>> the database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_cep()
>>>>>>>>>> Created
>>>>>>>>>> CEP
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added()
>>>>>>>>>> #
>>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service()
>>>>>>>>>> #
>>>>>>>>>> database_add_service
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc()
>>>>>>>>>> Created
>>>>>>>>>> CCC
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added()
>>>>>>>>>> #
>>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_service()
>>>>>>>>>> #
>>>>>>>>>> database_add_service
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:database_add_ccc()
>>>>>>>>>> Created
>>>>>>>>>> CCC
>>>>>>>>>> entry
>>>>>>>>>> for characteristic
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:gatt_db_service_added()
>>>>>>>>>> #
>>>>>>>>>> gatt_db_service_added: GATT Service added to local database
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:client_ready_cb() GATT
>>>>>>>>>> application
>>>>>>>>>> registered: :1.404:/
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids()
>>>>>>>>>> Adding
>>>>>>>>>> ServiceUUID: 180D
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_uuids()
>>>>>>>>>> Adding
>>>>>>>>>> ServiceUUID: 180F
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_manufacturer_data()
>>>>>>>>>> Adding
>>>>>>>>>> ManufacturerData for ffff
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:parse_service_data()
>>>>>>>>>> Adding
>>>>>>>>>> ServiceData
>>>>>>>>>> for 9999
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:refresh_advertisement()
>>>>>>>>>> Refreshing
>>>>>>>>>> advertisement: /org/bluez/example/advertisement0
>>>>>>>>>> bluetoothd[16877]: src/advertising.c:add_adv_callback()
>>>>>>>>>> Advertisement
>>>>>>>>>> registered: /org/bluez/example/advertisement0
>>>>>>>>>>
>>>>>>>>>> I start `./test/example-gatt-server` as a normal user. But
>>>>>>>>>> Bluez
>>>>>>>>>> does
>>>>>>>>>> not
>>>>>>>>>> seem to have any permission issue with it.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Building from source I've seen something similar if I've used
>>>>>>>>> sudo
>>>>>>>>> for
>>>>>>>>> the
>>>>>>>>> make.
>>>>>>>>>
>>>>>>>>> To compile and install I use sudo for the install only:
>>>>>>>>>
>>>>>>>>> make -j 4 && sudo make install
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I am using 'BLE scanner' on Android to discover the GATT
>>>>>>>>>> services.
>>>>>>>>>> But
>>>>>>>>>> I
>>>>>>>>>> think the problem is coming from Bluez. When I connect the
>>>>>>>>>> Android
>>>>>>>>>> device
>>>>>>>>>> to
>>>>>>>>>> Bluez, I can see this log:
>>>>>>>>>>
>>>>>>>>>> bluetoothd[16877]: src/adapter.c:connected_callback() hci0
>>>>>>>>>> device
>>>>>>>>>> 98:D6:F7:31:7B:0D connected eir_len 14
>>>>>>>>>> bluetoothd[16877]: src/gatt-database.c:connect_cb() New
>>>>>>>>>> incoming
>>>>>>>>>> BR/EDR
>>>>>>>>>> ATT
>>>>>>>>>> connection
>>>>>>>>>> bluetoothd[16877]: attrib/gattrib.c:g_attrib_ref() 0x98cd908:
>>>>>>>>>> g_attrib_ref=1
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() # load_gatt_db:
>>>>>>>>>> Restoring
>>>>>>>>>> 98:D6:F7:31:7B:0D gatt database from file
>>>>>>>>>> '/var/lib/bluetooth/5C:F3:70:6A:D9:3C/cache/98:D6:F7:31:7B:0D'
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db_impl() #
>>>>>>>>>> load_gatt_db_impl
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>>>> loading
>>>>>>>>>> service: 0x0001, end: 0x0005, uuid:
>>>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_service() # load_service:
>>>>>>>>>> loading
>>>>>>>>>> service: 0x0014, end: 0xffff, uuid:
>>>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>>>> characteristic
>>>>>>>>>> handle:
>>>>>>>>>> 0x0002, value handle: 0x0003, properties 0x0020 uuid:
>>>>>>>>>> 00002a05-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>>>> characteristic
>>>>>>>>>> handle:
>>>>>>>>>> 0x0015, value handle: 0x0016, properties 0x0002 uuid:
>>>>>>>>>> 00002a00-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_chrc() loading
>>>>>>>>>> characteristic
>>>>>>>>>> handle:
>>>>>>>>>> 0x0017, value handle: 0x0018, properties 0x0002 uuid:
>>>>>>>>>> 00002a01-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:load_gatt_db() List GATT
>>>>>>>>>> Primaries
>>>>>>>>>> before
>>>>>>>>>> being free:
>>>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary
>>>>>>>>>> UUID:
>>>>>>>>>> 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:print_primary() - Primary
>>>>>>>>>> UUID:
>>>>>>>>>> 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:gap_accept() GAP profile
>>>>>>>>>> accept
>>>>>>>>>> (98:D6:F7:31:7B:0D)
>>>>>>>>>> bluetoothd[16877]: src/service.c:change_state() 0x98c98e0:
>>>>>>>>>> device
>>>>>>>>>> 98:D6:F7:31:7B:0D profile gap-profile state changed:
>>>>>>>>>> disconnected
>>>>>>>>>> ->
>>>>>>>>>> connected (0)
>>>>>>>>>> bluetoothd[16877]:
>>>>>>>>>> src/gatt-client.c:btd_gatt_client_connected()
>>>>>>>>>> Device
>>>>>>>>>> connected.
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_server_init() #
>>>>>>>>>> gatt_server_init
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>>>> found:
>>>>>>>>>> 2
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001,
>>>>>>>>>> end:
>>>>>>>>>> 0x0005,
>>>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014,
>>>>>>>>>> end:
>>>>>>>>>> 0xffff,
>>>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Registered
>>>>>>>>>> handler for
>>>>>>>>>> "Service
>>>>>>>>>> Changed": 0
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_client_ready_cb() status:
>>>>>>>>>> success,
>>>>>>>>>> error: 0
>>>>>>>>>> bluetoothd[16877]: src/device.c:register_gatt_services() #
>>>>>>>>>> register_gatt_services
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_primary() # add_primary
>>>>>>>>>> bluetoothd[16877]: src/device.c:add_gatt_service() #
>>>>>>>>>> add_gatt_service:
>>>>>>>>>> UUID:00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:btd_gatt_client_ready()
>>>>>>>>>> GATT
>>>>>>>>>> client
>>>>>>>>>> ready
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:create_services()
>>>>>>>>>> Exporting
>>>>>>>>>> objects
>>>>>>>>>> for
>>>>>>>>>> GATT services: 98:D6:F7:31:7B:0D
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:service_create() Exported
>>>>>>>>>> GATT
>>>>>>>>>> service:
>>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001
>>>>>>>>>> bluetoothd[16877]: src/gatt-client.c:characteristic_create()
>>>>>>>>>> Exported
>>>>>>>>>> GATT
>>>>>>>>>> characteristic:
>>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D/service0001/char0002
>>>>>>>>>> bluetoothd[16877]: src/device.c:device_svc_resolved()
>>>>>>>>>> /org/bluez/hci0/dev_98_D6_F7_31_7B_0D err 0
>>>>>>>>>> bluetoothd[16877]: src/device.c:store_gatt_db() #
>>>>>>>>>> store_gatt_db
>>>>>>>>>> bluetoothd[16877]: src/device.c:store_service() #
>>>>>>>>>> store_service
>>>>>>>>>> bluetoothd[16877]: src/device.c:store_service() #
>>>>>>>>>> store_service
>>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_device_name_cb()
>>>>>>>>>> GAP
>>>>>>>>>> Device
>>>>>>>>>> Name:
>>>>>>>>>> Nexus 4
>>>>>>>>>> bluetoothd[16877]: profiles/gap/gas.c:read_appearance_cb() GAP
>>>>>>>>>> Appearance:
>>>>>>>>>> 0x0000
>>>>>>>>>>
>>>>>>>>>> I also reduced DBus 'TestAdvertisement' interface to only
>>>>>>>>>> expose
>>>>>>>>>> one
>>>>>>>>>> GATT
>>>>>>>>>> Service as many BLE adapter got a limitation in the size of
>>>>>>>>>> the
>>>>>>>>>> advertisement packet:
>>>>>>>>>> class TestAdvertisement(Advertisement):
>>>>>>>>>>
>>>>>>>>>> def __init__(self, bus, index):
>>>>>>>>>> Advertisement.__init__(self, bus, index, 'peripheral')
>>>>>>>>>> #self.add_service_uuid('180D') # HeartRate
>>>>>>>>>> self.add_service_uuid('180F') # Battery
>>>>>>>>>> #self.add_manufacturer_data(0xffff, [0x00, 0x01, 0x02,
>>>>>>>>>> 0x03,
>>>>>>>>>> 0x04])
>>>>>>>>>> #self.add_service_data('9999', [0x00, 0x01, 0x02,
>>>>>>>>>> 0x03,
>>>>>>>>>> 0x04])
>>>>>>>>>> self.include_tx_power = True
>>>>>>>>>>
>>>>>>>>>> My concern is mainly these lines:
>>>>>>>>>>
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() Primary services
>>>>>>>>>> found:
>>>>>>>>>> 2
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0001,
>>>>>>>>>> end:
>>>>>>>>>> 0x0005,
>>>>>>>>>> uuid: 00001801-0000-1000-8000-00805f9b34fb
>>>>>>>>>> bluetoothd[16877]: src/device.c:gatt_debug() start: 0x0014,
>>>>>>>>>> end:
>>>>>>>>>> 0xffff,
>>>>>>>>>> uuid: 00001800-0000-1000-8000-00805f9b34fb
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> I've seen this kind of error message when I've had a failure of
>>>>>>>>> a
>>>>>>>>> previous script and the Bluetooth daemon is in some unknown
>>>>>>>>> state.
>>>>>>>>> At
>>>>>>>>> this point it is worth restarting the bluetooth service with:
>>>>>>>>> sudo service bluetooth restart
>>>>>>>>>
>>>>>>>>> You will see in the advertising DBus API documentation that it
>>>>>>>>> is
>>>>>>>>> still in experimental mode in 5.44.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> https://git.kernel.org/pub/scm/bluetooth/bluez.git/tree/doc/advertising-api.txt#n78
>>>>>>>>>
>>>>>>>>> This means that you need to make sure bluetoothd is started in
>>>>>>>>> experimental mode. Have you done this?
>>>>>>>>> You can check with "sudo service bluetooth status"
>>>>>>>>>
>>>>>>>>> Experimental can be switched on by default in the
>>>>>>>>> bluetooth.service
>>>>>>>>> file
>>>>>>>>>
>>>>>>>>> Edit /lib/systemd/system/bluetooth.service file to add
>>>>>>>>> --experimental
>>>>>>>>> flag
>>>>>>>>> e.g:
>>>>>>>>>
>>>>>>>>> sudo sed -i '/^ExecStart.*bluetoothd\s*$/ s/$/ --experimental/'
>>>>>>>>> /lib/systemd/system/bluetooth.service
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I have not found the code that export GATT Services from GATT
>>>>>>>>>> Database
>>>>>>>>>> to
>>>>>>>>>> the BLE central.
>>>>>>>>>>
>>>>>>>>>> From my search on Internet, it looks I am not the only one who
>>>>>>>>>> is
>>>>>>>>>> having
>>>>>>>>>> this issue
>>>>>>>>>> I am happy to share/test anything that could help to make some
>>>>>>>>>> progress.
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> Olivier
>>>>>>>>>> --
>>>>>>>>>> To unsubscribe from this list: send the line "unsubscribe
>>>>>>>>>> linux-bluetooth"
>>>>>>>>>> in
>>>>>>>>>> the body of a message to majordomo@vger.kernel.org
>>>>>>>>>> More majordomo info at
>>>>>>>>>> http://vger.kernel.org/majordomo-info.html
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe
>> linux-bluetooth"
>> in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: pull request: bluetooth-next 2017-04-22
From: David Miller @ 2017-04-24 18:06 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, netdev
In-Reply-To: <20170422131302.GA17928@x1c>
From: Johan Hedberg <johan.hedberg@gmail.com>
Date: Sat, 22 Apr 2017 16:13:02 +0300
> Here are some more Bluetooth patches (and one 802.15.4 patch) in the
> bluetooth-next tree targeting the 4.12 kernel. Most of them are pure
> fixes.
>
> Please let me know if there are any issues pulling. Thanks.
Pulled, thank you.
^ permalink raw reply
* Re: [PATCH v3] Bluetooth: convert smp and selftest to crypto kpp API
From: Marcel Holtmann @ 2017-04-24 16:59 UTC (permalink / raw)
To: Salvatore Benedetto
Cc: Gustavo F. Padovan, Linux Bluetooth, Herbert Xu, Johan Hedberg
In-Reply-To: <1493036000-30800-1-git-send-email-salvatore.benedetto@intel.com>
Hi Salvatore,
> * Convert both smp and selftest to crypto kpp API
> * Remove module ecc as no more required
> * Add ecdh_helper functions for wrapping kpp async calls
>
> This patch has been tested *only* with selftest, which is called on
> module loading.
>
> Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
> ---
>
> Somehow I forgot to send this patch.
>
> Changes from v2
> - Based on bluetooth-next
> - Update code to latest API: remove crypto_kpp_set_params and use
> crypto_ecdh_encode_key
> - Removed include guards from internal header as requested by Johan
> - Added CRYPTO_ECDH dependecy to bluetooth Kconfig
> - Rename compute_ecdh_shared_secret and generate_ecdh_key_pair to
> compute_ecdh_secret and generate_ecdh_keys respectively
>
> net/bluetooth/Kconfig | 1 +
> net/bluetooth/Makefile | 2 +-
> net/bluetooth/ecc.c | 816 --------------------------------------------
> net/bluetooth/ecc.h | 54 ---
> net/bluetooth/ecdh_helper.c | 223 ++++++++++++
> net/bluetooth/ecdh_helper.h | 27 ++
> net/bluetooth/selftest.c | 6 +-
> net/bluetooth/smp.c | 8 +-
> 8 files changed, 259 insertions(+), 878 deletions(-)
> delete mode 100644 net/bluetooth/ecc.c
> delete mode 100644 net/bluetooth/ecc.h
> create mode 100644 net/bluetooth/ecdh_helper.c
> create mode 100644 net/bluetooth/ecdh_helper.h
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH v3] Bluetooth: convert smp and selftest to crypto kpp API
From: Salvatore Benedetto @ 2017-04-24 12:13 UTC (permalink / raw)
To: gustavo, linux-bluetooth
Cc: herbert, marcel, johan.hedberg, Salvatore Benedetto
* Convert both smp and selftest to crypto kpp API
* Remove module ecc as no more required
* Add ecdh_helper functions for wrapping kpp async calls
This patch has been tested *only* with selftest, which is called on
module loading.
Signed-off-by: Salvatore Benedetto <salvatore.benedetto@intel.com>
---
Somehow I forgot to send this patch.
Changes from v2
- Based on bluetooth-next
- Update code to latest API: remove crypto_kpp_set_params and use
crypto_ecdh_encode_key
- Removed include guards from internal header as requested by Johan
- Added CRYPTO_ECDH dependecy to bluetooth Kconfig
- Rename compute_ecdh_shared_secret and generate_ecdh_key_pair to
compute_ecdh_secret and generate_ecdh_keys respectively
net/bluetooth/Kconfig | 1 +
net/bluetooth/Makefile | 2 +-
net/bluetooth/ecc.c | 816 --------------------------------------------
net/bluetooth/ecc.h | 54 ---
net/bluetooth/ecdh_helper.c | 223 ++++++++++++
net/bluetooth/ecdh_helper.h | 27 ++
net/bluetooth/selftest.c | 6 +-
net/bluetooth/smp.c | 8 +-
8 files changed, 259 insertions(+), 878 deletions(-)
delete mode 100644 net/bluetooth/ecc.c
delete mode 100644 net/bluetooth/ecc.h
create mode 100644 net/bluetooth/ecdh_helper.c
create mode 100644 net/bluetooth/ecdh_helper.h
diff --git a/net/bluetooth/Kconfig b/net/bluetooth/Kconfig
index 06c31b9..68f951b 100644
--- a/net/bluetooth/Kconfig
+++ b/net/bluetooth/Kconfig
@@ -13,6 +13,7 @@ menuconfig BT
select CRYPTO_CMAC
select CRYPTO_ECB
select CRYPTO_SHA256
+ select CRYPTO_ECDH
help
Bluetooth is low-cost, low-power, short-range wireless technology.
It was designed as a replacement for cables and other short-range
diff --git a/net/bluetooth/Makefile b/net/bluetooth/Makefile
index 4bfaa19..5d0a113 100644
--- a/net/bluetooth/Makefile
+++ b/net/bluetooth/Makefile
@@ -13,7 +13,7 @@ bluetooth_6lowpan-y := 6lowpan.o
bluetooth-y := af_bluetooth.o hci_core.o hci_conn.o hci_event.o mgmt.o \
hci_sock.o hci_sysfs.o l2cap_core.o l2cap_sock.o smp.o lib.o \
- ecc.o hci_request.o mgmt_util.o
+ ecdh_helper.o hci_request.o mgmt_util.o
bluetooth-$(CONFIG_BT_BREDR) += sco.o
bluetooth-$(CONFIG_BT_HS) += a2mp.o amp.o
diff --git a/net/bluetooth/ecc.c b/net/bluetooth/ecc.c
deleted file mode 100644
index e1709f8..0000000
--- a/net/bluetooth/ecc.c
+++ /dev/null
@@ -1,816 +0,0 @@
-/*
- * Copyright (c) 2013, Kenneth MacKay
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met:
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-#include <linux/random.h>
-
-#include "ecc.h"
-
-/* 256-bit curve */
-#define ECC_BYTES 32
-
-#define MAX_TRIES 16
-
-/* Number of u64's needed */
-#define NUM_ECC_DIGITS (ECC_BYTES / 8)
-
-struct ecc_point {
- u64 x[NUM_ECC_DIGITS];
- u64 y[NUM_ECC_DIGITS];
-};
-
-typedef struct {
- u64 m_low;
- u64 m_high;
-} uint128_t;
-
-#define CURVE_P_32 { 0xFFFFFFFFFFFFFFFFull, 0x00000000FFFFFFFFull, \
- 0x0000000000000000ull, 0xFFFFFFFF00000001ull }
-
-#define CURVE_G_32 { \
- { 0xF4A13945D898C296ull, 0x77037D812DEB33A0ull, \
- 0xF8BCE6E563A440F2ull, 0x6B17D1F2E12C4247ull }, \
- { 0xCBB6406837BF51F5ull, 0x2BCE33576B315ECEull, \
- 0x8EE7EB4A7C0F9E16ull, 0x4FE342E2FE1A7F9Bull } \
-}
-
-#define CURVE_N_32 { 0xF3B9CAC2FC632551ull, 0xBCE6FAADA7179E84ull, \
- 0xFFFFFFFFFFFFFFFFull, 0xFFFFFFFF00000000ull }
-
-static u64 curve_p[NUM_ECC_DIGITS] = CURVE_P_32;
-static struct ecc_point curve_g = CURVE_G_32;
-static u64 curve_n[NUM_ECC_DIGITS] = CURVE_N_32;
-
-static void vli_clear(u64 *vli)
-{
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++)
- vli[i] = 0;
-}
-
-/* Returns true if vli == 0, false otherwise. */
-static bool vli_is_zero(const u64 *vli)
-{
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++) {
- if (vli[i])
- return false;
- }
-
- return true;
-}
-
-/* Returns nonzero if bit bit of vli is set. */
-static u64 vli_test_bit(const u64 *vli, unsigned int bit)
-{
- return (vli[bit / 64] & ((u64) 1 << (bit % 64)));
-}
-
-/* Counts the number of 64-bit "digits" in vli. */
-static unsigned int vli_num_digits(const u64 *vli)
-{
- int i;
-
- /* Search from the end until we find a non-zero digit.
- * We do it in reverse because we expect that most digits will
- * be nonzero.
- */
- for (i = NUM_ECC_DIGITS - 1; i >= 0 && vli[i] == 0; i--);
-
- return (i + 1);
-}
-
-/* Counts the number of bits required for vli. */
-static unsigned int vli_num_bits(const u64 *vli)
-{
- unsigned int i, num_digits;
- u64 digit;
-
- num_digits = vli_num_digits(vli);
- if (num_digits == 0)
- return 0;
-
- digit = vli[num_digits - 1];
- for (i = 0; digit; i++)
- digit >>= 1;
-
- return ((num_digits - 1) * 64 + i);
-}
-
-/* Sets dest = src. */
-static void vli_set(u64 *dest, const u64 *src)
-{
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++)
- dest[i] = src[i];
-}
-
-/* Returns sign of left - right. */
-static int vli_cmp(const u64 *left, const u64 *right)
-{
- int i;
-
- for (i = NUM_ECC_DIGITS - 1; i >= 0; i--) {
- if (left[i] > right[i])
- return 1;
- else if (left[i] < right[i])
- return -1;
- }
-
- return 0;
-}
-
-/* Computes result = in << c, returning carry. Can modify in place
- * (if result == in). 0 < shift < 64.
- */
-static u64 vli_lshift(u64 *result, const u64 *in,
- unsigned int shift)
-{
- u64 carry = 0;
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++) {
- u64 temp = in[i];
-
- result[i] = (temp << shift) | carry;
- carry = temp >> (64 - shift);
- }
-
- return carry;
-}
-
-/* Computes vli = vli >> 1. */
-static void vli_rshift1(u64 *vli)
-{
- u64 *end = vli;
- u64 carry = 0;
-
- vli += NUM_ECC_DIGITS;
-
- while (vli-- > end) {
- u64 temp = *vli;
- *vli = (temp >> 1) | carry;
- carry = temp << 63;
- }
-}
-
-/* Computes result = left + right, returning carry. Can modify in place. */
-static u64 vli_add(u64 *result, const u64 *left,
- const u64 *right)
-{
- u64 carry = 0;
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++) {
- u64 sum;
-
- sum = left[i] + right[i] + carry;
- if (sum != left[i])
- carry = (sum < left[i]);
-
- result[i] = sum;
- }
-
- return carry;
-}
-
-/* Computes result = left - right, returning borrow. Can modify in place. */
-static u64 vli_sub(u64 *result, const u64 *left, const u64 *right)
-{
- u64 borrow = 0;
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++) {
- u64 diff;
-
- diff = left[i] - right[i] - borrow;
- if (diff != left[i])
- borrow = (diff > left[i]);
-
- result[i] = diff;
- }
-
- return borrow;
-}
-
-static uint128_t mul_64_64(u64 left, u64 right)
-{
- u64 a0 = left & 0xffffffffull;
- u64 a1 = left >> 32;
- u64 b0 = right & 0xffffffffull;
- u64 b1 = right >> 32;
- u64 m0 = a0 * b0;
- u64 m1 = a0 * b1;
- u64 m2 = a1 * b0;
- u64 m3 = a1 * b1;
- uint128_t result;
-
- m2 += (m0 >> 32);
- m2 += m1;
-
- /* Overflow */
- if (m2 < m1)
- m3 += 0x100000000ull;
-
- result.m_low = (m0 & 0xffffffffull) | (m2 << 32);
- result.m_high = m3 + (m2 >> 32);
-
- return result;
-}
-
-static uint128_t add_128_128(uint128_t a, uint128_t b)
-{
- uint128_t result;
-
- result.m_low = a.m_low + b.m_low;
- result.m_high = a.m_high + b.m_high + (result.m_low < a.m_low);
-
- return result;
-}
-
-static void vli_mult(u64 *result, const u64 *left, const u64 *right)
-{
- uint128_t r01 = { 0, 0 };
- u64 r2 = 0;
- unsigned int i, k;
-
- /* Compute each digit of result in sequence, maintaining the
- * carries.
- */
- for (k = 0; k < NUM_ECC_DIGITS * 2 - 1; k++) {
- unsigned int min;
-
- if (k < NUM_ECC_DIGITS)
- min = 0;
- else
- min = (k + 1) - NUM_ECC_DIGITS;
-
- for (i = min; i <= k && i < NUM_ECC_DIGITS; i++) {
- uint128_t product;
-
- product = mul_64_64(left[i], right[k - i]);
-
- r01 = add_128_128(r01, product);
- r2 += (r01.m_high < product.m_high);
- }
-
- result[k] = r01.m_low;
- r01.m_low = r01.m_high;
- r01.m_high = r2;
- r2 = 0;
- }
-
- result[NUM_ECC_DIGITS * 2 - 1] = r01.m_low;
-}
-
-static void vli_square(u64 *result, const u64 *left)
-{
- uint128_t r01 = { 0, 0 };
- u64 r2 = 0;
- int i, k;
-
- for (k = 0; k < NUM_ECC_DIGITS * 2 - 1; k++) {
- unsigned int min;
-
- if (k < NUM_ECC_DIGITS)
- min = 0;
- else
- min = (k + 1) - NUM_ECC_DIGITS;
-
- for (i = min; i <= k && i <= k - i; i++) {
- uint128_t product;
-
- product = mul_64_64(left[i], left[k - i]);
-
- if (i < k - i) {
- r2 += product.m_high >> 63;
- product.m_high = (product.m_high << 1) |
- (product.m_low >> 63);
- product.m_low <<= 1;
- }
-
- r01 = add_128_128(r01, product);
- r2 += (r01.m_high < product.m_high);
- }
-
- result[k] = r01.m_low;
- r01.m_low = r01.m_high;
- r01.m_high = r2;
- r2 = 0;
- }
-
- result[NUM_ECC_DIGITS * 2 - 1] = r01.m_low;
-}
-
-/* Computes result = (left + right) % mod.
- * Assumes that left < mod and right < mod, result != mod.
- */
-static void vli_mod_add(u64 *result, const u64 *left, const u64 *right,
- const u64 *mod)
-{
- u64 carry;
-
- carry = vli_add(result, left, right);
-
- /* result > mod (result = mod + remainder), so subtract mod to
- * get remainder.
- */
- if (carry || vli_cmp(result, mod) >= 0)
- vli_sub(result, result, mod);
-}
-
-/* Computes result = (left - right) % mod.
- * Assumes that left < mod and right < mod, result != mod.
- */
-static void vli_mod_sub(u64 *result, const u64 *left, const u64 *right,
- const u64 *mod)
-{
- u64 borrow = vli_sub(result, left, right);
-
- /* In this case, p_result == -diff == (max int) - diff.
- * Since -x % d == d - x, we can get the correct result from
- * result + mod (with overflow).
- */
- if (borrow)
- vli_add(result, result, mod);
-}
-
-/* Computes result = product % curve_p
- from http://www.nsa.gov/ia/_files/nist-routines.pdf */
-static void vli_mmod_fast(u64 *result, const u64 *product)
-{
- u64 tmp[NUM_ECC_DIGITS];
- int carry;
-
- /* t */
- vli_set(result, product);
-
- /* s1 */
- tmp[0] = 0;
- tmp[1] = product[5] & 0xffffffff00000000ull;
- tmp[2] = product[6];
- tmp[3] = product[7];
- carry = vli_lshift(tmp, tmp, 1);
- carry += vli_add(result, result, tmp);
-
- /* s2 */
- tmp[1] = product[6] << 32;
- tmp[2] = (product[6] >> 32) | (product[7] << 32);
- tmp[3] = product[7] >> 32;
- carry += vli_lshift(tmp, tmp, 1);
- carry += vli_add(result, result, tmp);
-
- /* s3 */
- tmp[0] = product[4];
- tmp[1] = product[5] & 0xffffffff;
- tmp[2] = 0;
- tmp[3] = product[7];
- carry += vli_add(result, result, tmp);
-
- /* s4 */
- tmp[0] = (product[4] >> 32) | (product[5] << 32);
- tmp[1] = (product[5] >> 32) | (product[6] & 0xffffffff00000000ull);
- tmp[2] = product[7];
- tmp[3] = (product[6] >> 32) | (product[4] << 32);
- carry += vli_add(result, result, tmp);
-
- /* d1 */
- tmp[0] = (product[5] >> 32) | (product[6] << 32);
- tmp[1] = (product[6] >> 32);
- tmp[2] = 0;
- tmp[3] = (product[4] & 0xffffffff) | (product[5] << 32);
- carry -= vli_sub(result, result, tmp);
-
- /* d2 */
- tmp[0] = product[6];
- tmp[1] = product[7];
- tmp[2] = 0;
- tmp[3] = (product[4] >> 32) | (product[5] & 0xffffffff00000000ull);
- carry -= vli_sub(result, result, tmp);
-
- /* d3 */
- tmp[0] = (product[6] >> 32) | (product[7] << 32);
- tmp[1] = (product[7] >> 32) | (product[4] << 32);
- tmp[2] = (product[4] >> 32) | (product[5] << 32);
- tmp[3] = (product[6] << 32);
- carry -= vli_sub(result, result, tmp);
-
- /* d4 */
- tmp[0] = product[7];
- tmp[1] = product[4] & 0xffffffff00000000ull;
- tmp[2] = product[5];
- tmp[3] = product[6] & 0xffffffff00000000ull;
- carry -= vli_sub(result, result, tmp);
-
- if (carry < 0) {
- do {
- carry += vli_add(result, result, curve_p);
- } while (carry < 0);
- } else {
- while (carry || vli_cmp(curve_p, result) != 1)
- carry -= vli_sub(result, result, curve_p);
- }
-}
-
-/* Computes result = (left * right) % curve_p. */
-static void vli_mod_mult_fast(u64 *result, const u64 *left, const u64 *right)
-{
- u64 product[2 * NUM_ECC_DIGITS];
-
- vli_mult(product, left, right);
- vli_mmod_fast(result, product);
-}
-
-/* Computes result = left^2 % curve_p. */
-static void vli_mod_square_fast(u64 *result, const u64 *left)
-{
- u64 product[2 * NUM_ECC_DIGITS];
-
- vli_square(product, left);
- vli_mmod_fast(result, product);
-}
-
-#define EVEN(vli) (!(vli[0] & 1))
-/* Computes result = (1 / p_input) % mod. All VLIs are the same size.
- * See "From Euclid's GCD to Montgomery Multiplication to the Great Divide"
- * https://labs.oracle.com/techrep/2001/smli_tr-2001-95.pdf
- */
-static void vli_mod_inv(u64 *result, const u64 *input, const u64 *mod)
-{
- u64 a[NUM_ECC_DIGITS], b[NUM_ECC_DIGITS];
- u64 u[NUM_ECC_DIGITS], v[NUM_ECC_DIGITS];
- u64 carry;
- int cmp_result;
-
- if (vli_is_zero(input)) {
- vli_clear(result);
- return;
- }
-
- vli_set(a, input);
- vli_set(b, mod);
- vli_clear(u);
- u[0] = 1;
- vli_clear(v);
-
- while ((cmp_result = vli_cmp(a, b)) != 0) {
- carry = 0;
-
- if (EVEN(a)) {
- vli_rshift1(a);
-
- if (!EVEN(u))
- carry = vli_add(u, u, mod);
-
- vli_rshift1(u);
- if (carry)
- u[NUM_ECC_DIGITS - 1] |= 0x8000000000000000ull;
- } else if (EVEN(b)) {
- vli_rshift1(b);
-
- if (!EVEN(v))
- carry = vli_add(v, v, mod);
-
- vli_rshift1(v);
- if (carry)
- v[NUM_ECC_DIGITS - 1] |= 0x8000000000000000ull;
- } else if (cmp_result > 0) {
- vli_sub(a, a, b);
- vli_rshift1(a);
-
- if (vli_cmp(u, v) < 0)
- vli_add(u, u, mod);
-
- vli_sub(u, u, v);
- if (!EVEN(u))
- carry = vli_add(u, u, mod);
-
- vli_rshift1(u);
- if (carry)
- u[NUM_ECC_DIGITS - 1] |= 0x8000000000000000ull;
- } else {
- vli_sub(b, b, a);
- vli_rshift1(b);
-
- if (vli_cmp(v, u) < 0)
- vli_add(v, v, mod);
-
- vli_sub(v, v, u);
- if (!EVEN(v))
- carry = vli_add(v, v, mod);
-
- vli_rshift1(v);
- if (carry)
- v[NUM_ECC_DIGITS - 1] |= 0x8000000000000000ull;
- }
- }
-
- vli_set(result, u);
-}
-
-/* ------ Point operations ------ */
-
-/* Returns true if p_point is the point at infinity, false otherwise. */
-static bool ecc_point_is_zero(const struct ecc_point *point)
-{
- return (vli_is_zero(point->x) && vli_is_zero(point->y));
-}
-
-/* Point multiplication algorithm using Montgomery's ladder with co-Z
- * coordinates. From http://eprint.iacr.org/2011/338.pdf
- */
-
-/* Double in place */
-static void ecc_point_double_jacobian(u64 *x1, u64 *y1, u64 *z1)
-{
- /* t1 = x, t2 = y, t3 = z */
- u64 t4[NUM_ECC_DIGITS];
- u64 t5[NUM_ECC_DIGITS];
-
- if (vli_is_zero(z1))
- return;
-
- vli_mod_square_fast(t4, y1); /* t4 = y1^2 */
- vli_mod_mult_fast(t5, x1, t4); /* t5 = x1*y1^2 = A */
- vli_mod_square_fast(t4, t4); /* t4 = y1^4 */
- vli_mod_mult_fast(y1, y1, z1); /* t2 = y1*z1 = z3 */
- vli_mod_square_fast(z1, z1); /* t3 = z1^2 */
-
- vli_mod_add(x1, x1, z1, curve_p); /* t1 = x1 + z1^2 */
- vli_mod_add(z1, z1, z1, curve_p); /* t3 = 2*z1^2 */
- vli_mod_sub(z1, x1, z1, curve_p); /* t3 = x1 - z1^2 */
- vli_mod_mult_fast(x1, x1, z1); /* t1 = x1^2 - z1^4 */
-
- vli_mod_add(z1, x1, x1, curve_p); /* t3 = 2*(x1^2 - z1^4) */
- vli_mod_add(x1, x1, z1, curve_p); /* t1 = 3*(x1^2 - z1^4) */
- if (vli_test_bit(x1, 0)) {
- u64 carry = vli_add(x1, x1, curve_p);
- vli_rshift1(x1);
- x1[NUM_ECC_DIGITS - 1] |= carry << 63;
- } else {
- vli_rshift1(x1);
- }
- /* t1 = 3/2*(x1^2 - z1^4) = B */
-
- vli_mod_square_fast(z1, x1); /* t3 = B^2 */
- vli_mod_sub(z1, z1, t5, curve_p); /* t3 = B^2 - A */
- vli_mod_sub(z1, z1, t5, curve_p); /* t3 = B^2 - 2A = x3 */
- vli_mod_sub(t5, t5, z1, curve_p); /* t5 = A - x3 */
- vli_mod_mult_fast(x1, x1, t5); /* t1 = B * (A - x3) */
- vli_mod_sub(t4, x1, t4, curve_p); /* t4 = B * (A - x3) - y1^4 = y3 */
-
- vli_set(x1, z1);
- vli_set(z1, y1);
- vli_set(y1, t4);
-}
-
-/* Modify (x1, y1) => (x1 * z^2, y1 * z^3) */
-static void apply_z(u64 *x1, u64 *y1, u64 *z)
-{
- u64 t1[NUM_ECC_DIGITS];
-
- vli_mod_square_fast(t1, z); /* z^2 */
- vli_mod_mult_fast(x1, x1, t1); /* x1 * z^2 */
- vli_mod_mult_fast(t1, t1, z); /* z^3 */
- vli_mod_mult_fast(y1, y1, t1); /* y1 * z^3 */
-}
-
-/* P = (x1, y1) => 2P, (x2, y2) => P' */
-static void xycz_initial_double(u64 *x1, u64 *y1, u64 *x2, u64 *y2,
- u64 *p_initial_z)
-{
- u64 z[NUM_ECC_DIGITS];
-
- vli_set(x2, x1);
- vli_set(y2, y1);
-
- vli_clear(z);
- z[0] = 1;
-
- if (p_initial_z)
- vli_set(z, p_initial_z);
-
- apply_z(x1, y1, z);
-
- ecc_point_double_jacobian(x1, y1, z);
-
- apply_z(x2, y2, z);
-}
-
-/* Input P = (x1, y1, Z), Q = (x2, y2, Z)
- * Output P' = (x1', y1', Z3), P + Q = (x3, y3, Z3)
- * or P => P', Q => P + Q
- */
-static void xycz_add(u64 *x1, u64 *y1, u64 *x2, u64 *y2)
-{
- /* t1 = X1, t2 = Y1, t3 = X2, t4 = Y2 */
- u64 t5[NUM_ECC_DIGITS];
-
- vli_mod_sub(t5, x2, x1, curve_p); /* t5 = x2 - x1 */
- vli_mod_square_fast(t5, t5); /* t5 = (x2 - x1)^2 = A */
- vli_mod_mult_fast(x1, x1, t5); /* t1 = x1*A = B */
- vli_mod_mult_fast(x2, x2, t5); /* t3 = x2*A = C */
- vli_mod_sub(y2, y2, y1, curve_p); /* t4 = y2 - y1 */
- vli_mod_square_fast(t5, y2); /* t5 = (y2 - y1)^2 = D */
-
- vli_mod_sub(t5, t5, x1, curve_p); /* t5 = D - B */
- vli_mod_sub(t5, t5, x2, curve_p); /* t5 = D - B - C = x3 */
- vli_mod_sub(x2, x2, x1, curve_p); /* t3 = C - B */
- vli_mod_mult_fast(y1, y1, x2); /* t2 = y1*(C - B) */
- vli_mod_sub(x2, x1, t5, curve_p); /* t3 = B - x3 */
- vli_mod_mult_fast(y2, y2, x2); /* t4 = (y2 - y1)*(B - x3) */
- vli_mod_sub(y2, y2, y1, curve_p); /* t4 = y3 */
-
- vli_set(x2, t5);
-}
-
-/* Input P = (x1, y1, Z), Q = (x2, y2, Z)
- * Output P + Q = (x3, y3, Z3), P - Q = (x3', y3', Z3)
- * or P => P - Q, Q => P + Q
- */
-static void xycz_add_c(u64 *x1, u64 *y1, u64 *x2, u64 *y2)
-{
- /* t1 = X1, t2 = Y1, t3 = X2, t4 = Y2 */
- u64 t5[NUM_ECC_DIGITS];
- u64 t6[NUM_ECC_DIGITS];
- u64 t7[NUM_ECC_DIGITS];
-
- vli_mod_sub(t5, x2, x1, curve_p); /* t5 = x2 - x1 */
- vli_mod_square_fast(t5, t5); /* t5 = (x2 - x1)^2 = A */
- vli_mod_mult_fast(x1, x1, t5); /* t1 = x1*A = B */
- vli_mod_mult_fast(x2, x2, t5); /* t3 = x2*A = C */
- vli_mod_add(t5, y2, y1, curve_p); /* t4 = y2 + y1 */
- vli_mod_sub(y2, y2, y1, curve_p); /* t4 = y2 - y1 */
-
- vli_mod_sub(t6, x2, x1, curve_p); /* t6 = C - B */
- vli_mod_mult_fast(y1, y1, t6); /* t2 = y1 * (C - B) */
- vli_mod_add(t6, x1, x2, curve_p); /* t6 = B + C */
- vli_mod_square_fast(x2, y2); /* t3 = (y2 - y1)^2 */
- vli_mod_sub(x2, x2, t6, curve_p); /* t3 = x3 */
-
- vli_mod_sub(t7, x1, x2, curve_p); /* t7 = B - x3 */
- vli_mod_mult_fast(y2, y2, t7); /* t4 = (y2 - y1)*(B - x3) */
- vli_mod_sub(y2, y2, y1, curve_p); /* t4 = y3 */
-
- vli_mod_square_fast(t7, t5); /* t7 = (y2 + y1)^2 = F */
- vli_mod_sub(t7, t7, t6, curve_p); /* t7 = x3' */
- vli_mod_sub(t6, t7, x1, curve_p); /* t6 = x3' - B */
- vli_mod_mult_fast(t6, t6, t5); /* t6 = (y2 + y1)*(x3' - B) */
- vli_mod_sub(y1, t6, y1, curve_p); /* t2 = y3' */
-
- vli_set(x1, t7);
-}
-
-static void ecc_point_mult(struct ecc_point *result,
- const struct ecc_point *point, u64 *scalar,
- u64 *initial_z, int num_bits)
-{
- /* R0 and R1 */
- u64 rx[2][NUM_ECC_DIGITS];
- u64 ry[2][NUM_ECC_DIGITS];
- u64 z[NUM_ECC_DIGITS];
- int i, nb;
-
- vli_set(rx[1], point->x);
- vli_set(ry[1], point->y);
-
- xycz_initial_double(rx[1], ry[1], rx[0], ry[0], initial_z);
-
- for (i = num_bits - 2; i > 0; i--) {
- nb = !vli_test_bit(scalar, i);
- xycz_add_c(rx[1 - nb], ry[1 - nb], rx[nb], ry[nb]);
- xycz_add(rx[nb], ry[nb], rx[1 - nb], ry[1 - nb]);
- }
-
- nb = !vli_test_bit(scalar, 0);
- xycz_add_c(rx[1 - nb], ry[1 - nb], rx[nb], ry[nb]);
-
- /* Find final 1/Z value. */
- vli_mod_sub(z, rx[1], rx[0], curve_p); /* X1 - X0 */
- vli_mod_mult_fast(z, z, ry[1 - nb]); /* Yb * (X1 - X0) */
- vli_mod_mult_fast(z, z, point->x); /* xP * Yb * (X1 - X0) */
- vli_mod_inv(z, z, curve_p); /* 1 / (xP * Yb * (X1 - X0)) */
- vli_mod_mult_fast(z, z, point->y); /* yP / (xP * Yb * (X1 - X0)) */
- vli_mod_mult_fast(z, z, rx[1 - nb]); /* Xb * yP / (xP * Yb * (X1 - X0)) */
- /* End 1/Z calculation */
-
- xycz_add(rx[nb], ry[nb], rx[1 - nb], ry[1 - nb]);
-
- apply_z(rx[0], ry[0], z);
-
- vli_set(result->x, rx[0]);
- vli_set(result->y, ry[0]);
-}
-
-static void ecc_bytes2native(const u8 bytes[ECC_BYTES],
- u64 native[NUM_ECC_DIGITS])
-{
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++) {
- const u8 *digit = bytes + 8 * (NUM_ECC_DIGITS - 1 - i);
-
- native[NUM_ECC_DIGITS - 1 - i] =
- ((u64) digit[0] << 0) |
- ((u64) digit[1] << 8) |
- ((u64) digit[2] << 16) |
- ((u64) digit[3] << 24) |
- ((u64) digit[4] << 32) |
- ((u64) digit[5] << 40) |
- ((u64) digit[6] << 48) |
- ((u64) digit[7] << 56);
- }
-}
-
-static void ecc_native2bytes(const u64 native[NUM_ECC_DIGITS],
- u8 bytes[ECC_BYTES])
-{
- int i;
-
- for (i = 0; i < NUM_ECC_DIGITS; i++) {
- u8 *digit = bytes + 8 * (NUM_ECC_DIGITS - 1 - i);
-
- digit[0] = native[NUM_ECC_DIGITS - 1 - i] >> 0;
- digit[1] = native[NUM_ECC_DIGITS - 1 - i] >> 8;
- digit[2] = native[NUM_ECC_DIGITS - 1 - i] >> 16;
- digit[3] = native[NUM_ECC_DIGITS - 1 - i] >> 24;
- digit[4] = native[NUM_ECC_DIGITS - 1 - i] >> 32;
- digit[5] = native[NUM_ECC_DIGITS - 1 - i] >> 40;
- digit[6] = native[NUM_ECC_DIGITS - 1 - i] >> 48;
- digit[7] = native[NUM_ECC_DIGITS - 1 - i] >> 56;
- }
-}
-
-bool ecc_make_key(u8 public_key[64], u8 private_key[32])
-{
- struct ecc_point pk;
- u64 priv[NUM_ECC_DIGITS];
- unsigned int tries = 0;
-
- do {
- if (tries++ >= MAX_TRIES)
- return false;
-
- get_random_bytes(priv, ECC_BYTES);
-
- if (vli_is_zero(priv))
- continue;
-
- /* Make sure the private key is in the range [1, n-1]. */
- if (vli_cmp(curve_n, priv) != 1)
- continue;
-
- ecc_point_mult(&pk, &curve_g, priv, NULL, vli_num_bits(priv));
- } while (ecc_point_is_zero(&pk));
-
- ecc_native2bytes(priv, private_key);
- ecc_native2bytes(pk.x, public_key);
- ecc_native2bytes(pk.y, &public_key[32]);
-
- return true;
-}
-
-bool ecdh_shared_secret(const u8 public_key[64], const u8 private_key[32],
- u8 secret[32])
-{
- u64 priv[NUM_ECC_DIGITS];
- u64 rand[NUM_ECC_DIGITS];
- struct ecc_point product, pk;
-
- get_random_bytes(rand, ECC_BYTES);
-
- ecc_bytes2native(public_key, pk.x);
- ecc_bytes2native(&public_key[32], pk.y);
- ecc_bytes2native(private_key, priv);
-
- ecc_point_mult(&product, &pk, priv, rand, vli_num_bits(priv));
-
- ecc_native2bytes(product.x, secret);
-
- return !ecc_point_is_zero(&product);
-}
diff --git a/net/bluetooth/ecc.h b/net/bluetooth/ecc.h
deleted file mode 100644
index 8d6a2f4..0000000
--- a/net/bluetooth/ecc.h
+++ /dev/null
@@ -1,54 +0,0 @@
-/*
- * Copyright (c) 2013, Kenneth MacKay
- * All rights reserved.
- *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are
- * met:
- * * Redistributions of source code must retain the above copyright
- * notice, this list of conditions and the following disclaimer.
- * * Redistributions in binary form must reproduce the above copyright
- * notice, this list of conditions and the following disclaimer in the
- * documentation and/or other materials provided with the distribution.
- *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- * HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
-/* Create a public/private key pair.
- * Outputs:
- * public_key - Will be filled in with the public key.
- * private_key - Will be filled in with the private key.
- *
- * Returns true if the key pair was generated successfully, false
- * if an error occurred. The keys are with the LSB first.
- */
-bool ecc_make_key(u8 public_key[64], u8 private_key[32]);
-
-/* Compute a shared secret given your secret key and someone else's
- * public key.
- * Note: It is recommended that you hash the result of ecdh_shared_secret
- * before using it for symmetric encryption or HMAC.
- *
- * Inputs:
- * public_key - The public key of the remote party
- * private_key - Your private key.
- *
- * Outputs:
- * secret - Will be filled in with the shared secret value.
- *
- * Returns true if the shared secret was generated successfully, false
- * if an error occurred. Both input and output parameters are with the
- * LSB first.
- */
-bool ecdh_shared_secret(const u8 public_key[64], const u8 private_key[32],
- u8 secret[32]);
diff --git a/net/bluetooth/ecdh_helper.c b/net/bluetooth/ecdh_helper.c
new file mode 100644
index 0000000..9613699
--- /dev/null
+++ b/net/bluetooth/ecdh_helper.c
@@ -0,0 +1,223 @@
+/*
+ * ECDH helper functions - KPP wrappings
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation;
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ * CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ * ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
+ * COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
+ * SOFTWARE IS DISCLAIMED.
+ */
+#include "ecdh_helper.h"
+
+#include <linux/random.h>
+#include <linux/scatterlist.h>
+#include <crypto/kpp.h>
+#include <crypto/ecdh.h>
+
+struct ecdh_completion {
+ struct completion completion;
+ int err;
+};
+
+static void ecdh_complete(struct crypto_async_request *req, int err)
+{
+ struct ecdh_completion *res = req->data;
+
+ if (err == -EINPROGRESS)
+ return;
+
+ res->err = err;
+ complete(&res->completion);
+}
+
+static inline void swap_digits(u64 *in, u64 *out, unsigned int ndigits)
+{
+ int i;
+
+ for (i = 0; i < ndigits; i++)
+ out[i] = __swab64(in[ndigits - 1 - i]);
+}
+
+bool compute_ecdh_secret(const u8 public_key[64], const u8 private_key[32],
+ u8 secret[32])
+{
+ struct crypto_kpp *tfm;
+ struct kpp_request *req;
+ struct ecdh p;
+ struct ecdh_completion result;
+ struct scatterlist src, dst;
+ u8 tmp[64];
+ u8 *buf;
+ unsigned int buf_len;
+ int err = -ENOMEM;
+
+ tfm = crypto_alloc_kpp("ecdh", CRYPTO_ALG_INTERNAL, 0);
+ if (IS_ERR(tfm)) {
+ pr_err("alg: kpp: Failed to load tfm for kpp: %ld\n",
+ PTR_ERR(tfm));
+ return false;
+ }
+
+ req = kpp_request_alloc(tfm, GFP_KERNEL);
+ if (!req)
+ goto free_kpp;
+
+ init_completion(&result.completion);
+
+ /* Security Manager Protocol holds digits in litte-endian order
+ * while ECC API expect big-endian data
+ */
+ swap_digits((u64 *)private_key, (u64 *)tmp, 4);
+ p.key = (char *)tmp;
+ p.key_size = 32;
+ /* Set curve_id */
+ p.curve_id = ECC_CURVE_NIST_P256;
+ buf_len = crypto_ecdh_key_len(&p);
+ buf = kmalloc(buf_len, GFP_KERNEL);
+ if (!buf) {
+ pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
+ buf_len);
+ goto free_req;
+ }
+ crypto_ecdh_encode_key(buf, buf_len, &p);
+
+ /* Set A private Key */
+ err = crypto_kpp_set_secret(tfm, (void *)buf, buf_len);
+ if (err)
+ goto free_all;
+
+ swap_digits((u64 *)public_key, (u64 *)tmp, 4); /* x */
+ swap_digits((u64 *)&public_key[32], (u64 *)&tmp[32], 4); /* y */
+
+ sg_init_one(&src, tmp, 64);
+ sg_init_one(&dst, secret, 32);
+ kpp_request_set_input(req, &src, 64);
+ kpp_request_set_output(req, &dst, 32);
+ kpp_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ ecdh_complete, &result);
+ err = crypto_kpp_compute_shared_secret(req);
+ if (err == -EINPROGRESS) {
+ wait_for_completion(&result.completion);
+ err = result.err;
+ }
+ if (err < 0) {
+ pr_err("alg: ecdh: compute shared secret failed. err %d\n",
+ err);
+ goto free_all;
+ }
+
+ swap_digits((u64 *)secret, (u64 *)tmp, 4);
+ memcpy(secret, tmp, 32);
+
+free_all:
+ kzfree(buf);
+free_req:
+ kpp_request_free(req);
+free_kpp:
+ crypto_free_kpp(tfm);
+ return (err == 0);
+}
+
+bool generate_ecdh_keys(u8 public_key[64], u8 private_key[32])
+{
+ struct crypto_kpp *tfm;
+ struct kpp_request *req;
+ struct ecdh p;
+ struct ecdh_completion result;
+ struct scatterlist dst;
+ u8 tmp[64];
+ u8 *buf;
+ unsigned int buf_len;
+ int err = -ENOMEM;
+ const unsigned short max_tries = 16;
+ unsigned short tries = 0;
+
+ tfm = crypto_alloc_kpp("ecdh", CRYPTO_ALG_INTERNAL, 0);
+ if (IS_ERR(tfm)) {
+ pr_err("alg: kpp: Failed to load tfm for kpp: %ld\n",
+ PTR_ERR(tfm));
+ return false;
+ }
+
+ req = kpp_request_alloc(tfm, GFP_KERNEL);
+ if (!req)
+ goto free_kpp;
+
+ init_completion(&result.completion);
+
+ /* Set curve_id */
+ p.curve_id = ECC_CURVE_NIST_P256;
+ p.key_size = 32;
+ buf_len = crypto_ecdh_key_len(&p);
+ buf = kmalloc(buf_len, GFP_KERNEL);
+ if (!buf) {
+ pr_err("alg: kpp: Failed to allocate %d bytes for buf\n",
+ buf_len);
+ goto free_req;
+ }
+
+ do {
+ if (tries++ >= max_tries)
+ goto free_all;
+
+ get_random_bytes(private_key, 32);
+
+ /* Set private Key */
+ p.key = (char *)private_key;
+ crypto_ecdh_encode_key(buf, buf_len, &p);
+ err = crypto_kpp_set_secret(tfm, buf, buf_len);
+ if (err)
+ goto free_all;
+
+ sg_init_one(&dst, tmp, 64);
+ kpp_request_set_output(req, &dst, 64);
+ kpp_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
+ ecdh_complete, &result);
+
+ err = crypto_kpp_generate_public_key(req);
+
+ if (err == -EINPROGRESS) {
+ wait_for_completion(&result.completion);
+ err = result.err;
+ }
+
+ /* Private key is not valid. Regenerate */
+ if (err == -EINVAL)
+ continue;
+
+ if (err < 0)
+ goto free_all;
+ else
+ break;
+
+ } while (true);
+
+ /* Keys are handed back in little endian as expected by Security
+ * Manager Protocol
+ */
+ swap_digits((u64 *)tmp, (u64 *)public_key, 4); /* x */
+ swap_digits((u64 *)&tmp[32], (u64 *)&public_key[32], 4); /* y */
+ swap_digits((u64 *)private_key, (u64 *)tmp, 4);
+ memcpy(private_key, tmp, 32);
+
+free_all:
+ kzfree(buf);
+free_req:
+ kpp_request_free(req);
+free_kpp:
+ crypto_free_kpp(tfm);
+ return (err == 0);
+}
diff --git a/net/bluetooth/ecdh_helper.h b/net/bluetooth/ecdh_helper.h
new file mode 100644
index 0000000..726a500
--- /dev/null
+++ b/net/bluetooth/ecdh_helper.h
@@ -0,0 +1,27 @@
+/*
+ * ECDH helper functions - KPP wrappings
+ *
+ * Copyright (C) 2017 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation;
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ * OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ * IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ * CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ * ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS,
+ * COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS
+ * SOFTWARE IS DISCLAIMED.
+ */
+#include <linux/types.h>
+
+bool compute_ecdh_secret(const u8 pub_a[64], const u8 priv_b[32],
+ u8 secret[32]);
+bool generate_ecdh_keys(u8 public_key[64], u8 private_key[32]);
diff --git a/net/bluetooth/selftest.c b/net/bluetooth/selftest.c
index dc688f1..efef281 100644
--- a/net/bluetooth/selftest.c
+++ b/net/bluetooth/selftest.c
@@ -26,7 +26,7 @@
#include <net/bluetooth/bluetooth.h>
#include <net/bluetooth/hci_core.h>
-#include "ecc.h"
+#include "ecdh_helper.h"
#include "smp.h"
#include "selftest.h"
@@ -144,8 +144,8 @@ static int __init test_ecdh_sample(const u8 priv_a[32], const u8 priv_b[32],
{
u8 dhkey_a[32], dhkey_b[32];
- ecdh_shared_secret(pub_b, priv_a, dhkey_a);
- ecdh_shared_secret(pub_a, priv_b, dhkey_b);
+ compute_ecdh_secret(pub_b, priv_a, dhkey_a);
+ compute_ecdh_secret(pub_a, priv_b, dhkey_b);
if (memcmp(dhkey_a, dhkey, 32))
return -EINVAL;
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index fae391f..40e921a 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -31,7 +31,7 @@
#include <net/bluetooth/l2cap.h>
#include <net/bluetooth/mgmt.h>
-#include "ecc.h"
+#include "ecdh_helper.h"
#include "smp.h"
#define SMP_DEV(hdev) \
@@ -570,7 +570,7 @@ int smp_generate_oob(struct hci_dev *hdev, u8 hash[16], u8 rand[16])
} else {
while (true) {
/* Generate local key pair for Secure Connections */
- if (!ecc_make_key(smp->local_pk, smp->local_sk))
+ if (!generate_ecdh_keys(smp->local_pk, smp->local_sk))
return -EIO;
/* This is unlikely, but we need to check that
@@ -1896,7 +1896,7 @@ static u8 sc_send_public_key(struct smp_chan *smp)
} else {
while (true) {
/* Generate local key pair for Secure Connections */
- if (!ecc_make_key(smp->local_pk, smp->local_sk))
+ if (!generate_ecdh_keys(smp->local_pk, smp->local_sk))
return SMP_UNSPECIFIED;
/* This is unlikely, but we need to check that
@@ -2670,7 +2670,7 @@ static int smp_cmd_public_key(struct l2cap_conn *conn, struct sk_buff *skb)
SMP_DBG("Remote Public Key X: %32phN", smp->remote_pk);
SMP_DBG("Remote Public Key Y: %32phN", smp->remote_pk + 32);
- if (!ecdh_shared_secret(smp->remote_pk, smp->local_sk, smp->dhkey))
+ if (!compute_ecdh_secret(smp->remote_pk, smp->local_sk, smp->dhkey))
return SMP_UNSPECIFIED;
SMP_DBG("DHKey %32phN", smp->dhkey);
--
2.7.4
^ permalink raw reply related
* Re: bluetooth 6lowpan interfaces are not virtual anymore
From: Luiz Augusto von Dentz @ 2017-04-24 10:35 UTC (permalink / raw)
To: Alexander Aring
Cc: Network Development, Jukka Rissanen, linux-wpan@vger.kernel.org,
Linux Bluetooth, Michael Richardson
In-Reply-To: <f3c04860-651e-c9f3-e7ab-db609d105436@pengutronix.de>
Hi Alex,
On Wed, Apr 19, 2017 at 8:43 PM, Alexander Aring <aar@pengutronix.de> wrote:
> Hi,
>
> at first I want to clarify what my definition of virtual and non virtual
> interface is:
>
> - virtual interfaces: has no queue(s)
> - non virtual interfaces: has a queue(s)
>
> I did some "big" ASCII graphic what I think it will do now.
> At first the virtual interface:
>
> --- snip ---
>
> Transmit side only! Case of virtual interface.
>
> IPv6 Stack
>
> +-----------------------------+
> | IPv6 Packet (ND, etc) |
> +--------------+--------------+
> |
> -------------------------+---------------------------------
> 6LoWPAN Interface |
> |
> +--------------v--------------+
> | Adaptation (IPv6 to 6Lo) |
> +--------------+--------------+
> +--------------------------+
> |
> | -----------------------------------------------------------
> Link|Layer (802.15.4/hci_dev/etc)
> |
> | SKB Queue (With kind of discipline)
> | +----------------+---------------+-------------+
> +-----------> SKB1 | SKBN | ... +----+
> +----------------+---------------+-------------+ |
> |
> |
> ------------------------------------------------------------ |
> Real Transeiver Hardware |
> +----------------------------+
> |
> +------------------------v-----------------------+
> | Framebuffers (YOUR hardware resource) |
> +------------------------------------------------+
>
> --- snap ---
>
> The non virtual interface:
>
> --- snip ---
>
> Transmit side only! Case of non virtual interface.
>
> IPv6 Stack
>
> +-----------------------------+
> | IPv6 Packet (ND, etc) |
> +--------------+--------------+
> |
> -------------------------+---------------------------------
> 6LoWPAN Interface |
> |
> +--------------------------+
> | /> Will be queued if you stop the queue
> | SKB Queue (With kind of discipline) /-- Because Link Layer is full/software limitation
> | +----------------+---------------+-------------+
> +-----------> SKB1 | SKBN | ... +----+
> +----------------+---------------+-------------+ |
> |
> +------------------------------------+
> |
> +--------------v--------------+
> | Adaptation (IPv6 to 6Lo) |
> +--------------+--------------+
> +--------------------------+
> |
> | -----------------------------------------------------------
> Link|Layer (802.15.4/hci_dev/etc)
> | -> software limitation (tx credits?)
> | SKB Queue (With kind of discipline) ---/ Right position to make different handling (for virtual case).
> | +----------------+---------------+------------/+
> +-----------> SKB1 | SKBN | ... +----+
> +----------------+---------------+-------------+ |
> |
> |
> ------------------------------------------------------------ |
> Real Transeiver Hardware |
> +----------------------------+
> |
> +------------------------v-----------------------+
> | Framebuffers (YOUR hardware resource) |
> +------------------------------------------------+
>
>
> --- snap ---
>
> Adding a queue to a interface which does a protocol translation only is
> in my opinion: wrong.
>
> At least if you want to try to make a more efficient qdisc handling,
> means dropping skb's in queue when userspace sends too much. You will
> change it back, control two queues seems to be difficult.
It is wrong only if you look at 6LoWPAN interface as being owned by
6lowpan modules, but it doesn't, in fact it won't anything by itself
so it basically acts as a library to that perform 6LoWPAN operation on
the packet level, thus why it is possible to switch from virtual to
real interface. Also in terms of 15.4, the 6LoWPAN interfaces you
depicted above is also no controlled by 6LoWPAN itself, in fact it
seeems to represent links in 15.4, and I also assume these links may
not use 6LoWPAN.
> On 04/18/2017 12:43 PM, Luiz Augusto von Dentz wrote:
>> Hi Alex,
>>
>> On Mon, Apr 17, 2017 at 8:56 PM, Alexander Aring <aar@pengutronix.de> wrote:
>>> Hi,
>>>
>>> bluetooth-next contains patches which introduces a queue for bluetooth
>>> 6LoWPAN interfaces. [0]
>>>
>>> At first, the current behaviour is now that 802.15.4 6LoWPAN interfaces
>>> are virtual and bluetooth 6LoWPAN interfaces are not virtual anymore.
>>> To have a different handling in both subsystems is _definitely_ wrong.
>>
>> Well 15.4 and Bluetooth have very different handling, iirc in 15.4 you
>> do have a real interface which has, in fact, queueing support:
>>
>> net/mac802154/iface.c:ieee802154_if_setup:
>> dev->tx_queue_len = 300;
>>
>
> Is l2cap_chan_send a call with is synchronized which wait for it so
> after that the "l2cap bluetooth *frame*. etc." is send?
>
> I looked at the code [0]. It will queue it in some skb queue, so far I
> see. Hard to see it in this code, but I see some queueing and workqueue
> scheduling [1] in the function which will be called by l2cap_chan_send.
There is a tx_queue per channel but that doesn't mean there is a per
channel and introducing one when we can use the net qdisc support
seems useless to me.
> This queue should have the same meaning like our queue in IEEE
> 802.15.4 interface which you mentioned above.
> At this point, we have no difference. There exists already a queue for
> your real transeiver hardware.
The queue here is per channel, btw the queue size is not decided by us
it is the remote side that provides the tx credits so to some extend
the tx_queue is actually the remote queue in case of CoC. When testing
this it was quite clear this does not work in practice, with IPv6 at
least, because the remote side may not have enough credits for a
single packet (MPS * tx_credits < MTU) which means without proper
queueing support we would be dropping every packet.
>>> What does the 6LoWPAN interface?
>>>
>>> It will do a protocol change (an adaptation, because 6LoWPAN should
>>> provide the same functionality as IPv6) from IPv6 to 6LoWPAN (tx) and
>>> vice versa for (rx). In my opinion this should be handled as a virtual
>>> interface and not as an interface with a queue.
>>
>> Then we need a real netif for Bluetooth as well, one that does
>> queueing since introducing for l2cap_chan makes no sense when most of
>> time the userspace has a socket which does its own queueing. Btw, I
>> have the opinion that doing a second interface just to make Bluetooth
>> behave like 15.4 is very wasteful since we don't have any other
>> network support except for bnep, which in fact does the same thing
>> regarding queueing.
>>
>
> If bnep just generates some ethernet frames and you put L2CAP around,
> then it should be virtual too. If it queue skbs for sending out for the
> hci_dev. Then it ends in a similar queue handling like "non virtual
> 6LoWPAN interface".
BNEP does not use the same L2CAP channel mode, in fact there is no
queueing whatsoever since it use basic mode, and considering it has
been working for this long I don't think there is a real problem in it
using the net qdisc infra, actually I don't quite get this virtual to
non-virtual complaint, IMO this is only valid if you do have a
tunnel-like design where there are multiple interfaces involved so
there is no point in having qdisc enabled in all of them but we only
have one interface in Bluetooth.
> What you mean with second interface? At least you need a capable
> net_device interface to offer an IP connection from userspace.
>
>>> What makes a queue on 6LoWPAN interfaces?
>>>
>>> It will queue IPv6 packets which waits for it adaptation (the protocol
>>> change) with some additional qdisc handling.
>>> If finally the xmit_do callback will occur it will replace IPv6 header
>>> with 6LoWPAN, etc. After that it should be queued into some queue on
>>> link layer side which should be do the transmit finally.
>>
>> In case of Bluetooth it does the Link Layer using L2CAP, which is not
>> exactly at Link Layer, in fact it is one of the major problems of
>> having this in Kernel space since it is similar of doing IP over TCP
>> tunnel.
>>
>
> aha, but this has nothing to do to decide that you have a 6LoWPAN queue,
> or? I think this is one reason why you want a "6lowtun" interface. To
> handle L2CAP in userspace.
Indeed it is one of main reasons.
>>> Why I think bluetooth introduced a queue handling on 6LoWPAN interfaces?
>>>
>>> Because I think they don't like their own *qdisc* handling on their link
>>> layer interface. I write *qdisc* here because, they have no net_devices
>>> and use some kind of own qdisc handling.
>>
>> No we don't, and except we do change the whole architecture of
>> Bluetooth to work as a net_device I don't think we can have a similar
>> design as 15.4. Anyway Bluetooth is not really designed to carry IP,
>> the L2CAP and other profiles above are mostly a Bluetooth thing so
>> having a net_device would not buy us much more than queueing for bnep
>> and ipsp.
>>
>
> At least, having a queue and don't put anything anymore into the queue
> when "tx credits" is at zero (because queue is full). _Is_ a kind of
> qdisc handling.
The tx_credits operate at L2CAP segment level (MPS), so it is at a
completely different level, there are no guarantees the credits will
attend to a single IP packet.
In case you are curious when testing with qdisc disabled the interface
will basically turn down as soon as there are no credits left which
makes even pings be dropped.
>>> My question: is this correct?
>>>
>>> How to fix that (In my opinion):
>>>
>>> So commit [0] says something "out of credits" that's what I think it's
>>> the *qdisc* handling. If you cannot queue anymore -> you need to drop
>>> it. If you don't like how the current behaviour is, you need to change
>>> your *qdisc* handling on your link layer interface. Introducing queue at
>>> 6LoWPAN interfaces will introduce "buffer bloating".
>>
>> That is not what the code comments says, eg. netif_stop_queue:
>>
>> * Stop upper layers calling the device hard_start_xmit routine.
>> * Used for flow control when transmit resources are unavailable.
>>
>
> This comments are correct so long you operate on "real hardware
> resources" which 6LoWPAN interfaces doesn't do. In case so far I see, it
> will call l2cap_chan_send which putting some L2CAP protocol on it (to
> provide data) and somewhere queue it for transmit to fill "real hardware
> resources" e.g. framebuffers.
The interface in question is created by Bluetooth 6lowpan module, the
TX and RX is responsibility of the implementation of the interface
which I assume it to avoid leaking this sort of details to 6LoWPAN
itself or having yet another level of indirection where the 6LoWPAN
would need to define another API/callbacks to interface with the
modules trying to use it.
> Your "resource" which is unavailable is the link layer queue, but this
> is just a software limitation by bluetooth, which you can change by
> software to make a different handling, than just adding more software queues.
>
> What _virtual_ 6LoWPAN interface does is:
>
> Input: IPv6 -> Output: 6LoWPAN, without any queueing in front of that.
>
>> The fact 15.4, and bnep, uses these APIs makes me believe this is the
>> proper way of using qdisc handling, the only difference here is at
>> what level we would be using them.
>>
>
> On 15.4 we use it for link layer interface queue, but we don't put
> another queue in 6LoWPAN. See my aboves ASCII arts which shows the
> different when 6LoWPAN is virtual and not virtual.
>
> ---
>
> We have already qdisc problems in our case. In 15.4 it "just works" for
> now, but we need more handling there to send not garbage if one frame
> gets dropped there, see [2].
>
> In my opinion, if bluetooth people will hit similar issues, you will
> change it back that 6LoWPAN has no queue anymore. Otherwise it will very
> hard to decide which skbs you drop or not - because you need to deal
> with two queues.
>
> To make 6LoWPAN non virtual anymore and just adding a queue will occur
> that you don't drop much anymore... but the queue at link layer
> (hci_dev) will work as before and this occurs buffer bloating only.
>
>>> ---
>>>
>>> I don't care what bluetooth does with the 6LoWPAN interface. If bluetooth
>>> people wants such behaviour, then I am okay with that.
>>>
>>> I will bookmark this mail for the time when somebody reverts it to a
>>> virtual interface again. I think somebody will change it again, or maybe
>>> somebody will argument why we need a queue here.
>>
>> From what I could grasp from the code except if 6LoWPAN start creating
>> its own interface, which it doesn't currently, it should never assume
>> any specific behavior for an interface. 6LoWPAN right now only have
>> helper functions which the interface code call on TX/RX, and by
>> looking at code under 15.4 the only thing we would be doing is to set
>> skb->dev = wdev; (wdev being the real device) as Bluetooth don't use
>> 6lowpan fragmentation.
>>
>
> yep, there is a lot of work do make a better framework, but has nothing
> do to why bluetooth introduced a second queue on 6lowpan interfaces.
>
>> Btw, another big different in terms of design that it seems 15.4 does
>> create interfaces to each and every link, in Bluetooth the interface
>> is per adapter so it is in fact multi-link, I guess in practice 15.4
>> shall only have one 6lowpan link since it is connected to mesh, but in
>> Bluetooth we may have more than one Link and I don't think it would be
>> a good idea to have each of these links as a different interface,
>> especially not with the same mac address as it seems to be what 15.4
>> code is doing:
>>
>> /* Set the lowpan hardware address to the wpan hardware address. */
>> memcpy(ldev->dev_addr, wdev->dev_addr, IEEE802154_ADDR_LEN);
>>
>
> Of course we need the same mac address there (at first), because we
> have an address filter on hardware.
>
> (Be aware that you _cannot_ change the mac address (dev->dev_addr) while IP
> capable net device is up. They assume the mac address is read only if net
> device is up.)
>
> There is currently an idea to provide multiple links, but then hardware
> need to go into promiscuous mode (disable address filtering) but then we
> will lose some hardware offloading stuff e.g. ACK handling.
> If we have that, we can provide multiple links with different mac
> addresses, at least this will be handled as multiple wpan interfaces for
> one PHY.
We do need multi-link from the start, and it has been decided it
wouldn't be with multiple interfaces but with a single one.
>> So at least with IPSP/RFC-7668 the topology is completely different
>> from what we can see in 15.4, it may happen that this changes with
>> upcoming changes to Bluetooth, adding yet another topology that we
>> will need to support. Personally I wouldn't mind if 15.4 and Bluetooth
>> had more in common, at least at 6lowpan level, so we wouldn't have the
>> need to create separated modules just to deal with their differences,
>> but in reality, these technologies are competing for the same market
>> so I don't think it will happen, unfortunately.
>>
>
> You already have separated modules, this is .e.g IPHC stuff and 6lowpan
> specific implementation for bluetooth. In net/bluetooth/6lowpan.c you
> can put your changes for make specific bluetooth handling.
>
> This discussion moved currently to a more complex question about how to
> make the whole 6lowpan architecture...
>
> I think I tried to explain so much as possible what a queue on top of
> 6lowpan interface will do, at least if you want to make a better queue
> handling (when dropping skb's inside the queue(s)) then you will fail
> and revert that change (I think). But then I can say "I told you so" :-)
>
> - Alex
>
> [0] http://lxr.free-electrons.com/source/net/bluetooth/l2cap_core.c#L2455
> [1] http://lxr.free-electrons.com/source/net/bluetooth/hci_core.c#L3490
> [2] http://www.spinics.net/lists/linux-wpan/msg03679.html
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: Regression in bluez 5.44, bluetoothd crashes
From: Luke McKee @ 2017-04-24 10:16 UTC (permalink / raw)
To: Konrad Zapalowicz, linux-bluetooth
In-Reply-To: <20170424082524.GD1084@annapurna>
You sound like a legend even though I'm a gentoo.org user working on
our bugs mostly ;)
https://bugs.gentoo.org/show_bug.cgi?id=613224
I have a nagging problem bluetooth requesting EDR to a device that
only supports EDR (high bandwidth) transport for communications for
connectionless mode (ADR from memory) not SCO.
Looking at the HCI dump it really looks like a linux bluetooth bug,
not a embedded firmware issue.
https://www.spinics.net/lists/linux-bluetooth/msg69931.html
On 24 April 2017 at 15:25, Konrad Zapalowicz
<konrad.zapalowicz@canonical.com> wrote:
> On 04/06, Luiz Augusto von Dentz wrote:
>> Hi Konrad,
>>
>> On Thu, Apr 6, 2017 at 3:51 PM, Konrad Zapalowicz
>> <konrad.zapalowicz@canonical.com> wrote:
>> > Hey,
>> >
>> > I see a regression in 5.44 when testing Sony SBH52 headset. It fails to
>> > connect profiles but the worst thing is that the bluetoothd crashes
>> > (logs below).
>> >
>> > I have git bisect'ed it down to the commit f2483bbfd. It works fine if
>> > I remove it.
>>
>> That is because the very next patch fix it:
>>
>> commit 4a8c33b1f76edf2dfe33b9956014cc2746ae71d8
>> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>> Date: Mon Nov 14 13:30:09 2016 +0200
>>
>> core/adapter: Fix using wrong address type to listen ATT
>>
>> bdaddr_type shall only matter for controllers supporting LE otherwise
>> it may cause BDADDR_BREDR to be used for things like LE ATT socket
>> listen breaking reconnections.
>>
>
> Is your suggestion that I might be missing the above patch? I have it
> included, I'm using regular 5.44 release.
>
>> > Stacktrace:
>> >
>> > (gdb) c
>> > Continuing.
>> >
>> > Program received signal SIGSEGV, Segmentation fault.
>> > strlen () at ../sysdeps/x86_64/strlen.S:106
>> > 106 ../sysdeps/x86_64/strlen.S: No such file or directory.
>> > (gdb) bt
>> > #0 strlen () at ../sysdeps/x86_64/strlen.S:106
>> > #1 0x00007f92806179a1 in _IO_vfprintf_internal (s=s@entry=0x557f37ad5520, format=<optimized out>, format@entry=0x557f36cd515c "%s:%s() %s err %d", ap=0x7ffc0b7a86d0)
>> > at vfprintf.c:1637
>> > #2 0x00007f92806dffc6 in ___vfprintf_chk (fp=fp@entry=0x557f37ad5520, flag=flag@entry=1, format=format@entry=0x557f36cd515c "%s:%s() %s err %d",
>> > ap=ap@entry=0x7ffc0b7a86d0) at vfprintf_chk.c:33
>> > #3 0x00007f92806c9028 in __GI___vsyslog_chk (pri=<optimized out>, pri@entry=7, flag=flag@entry=1, fmt=fmt@entry=0x557f36cd515c "%s:%s() %s err %d",
>> > ap=ap@entry=0x7ffc0b7a86d0) at ../misc/syslog.c:222
>> > #4 0x0000557f36c6735b in vsyslog (__ap=0x7ffc0b7a86d0, __fmt=0x557f36cd515c "%s:%s() %s err %d", __pri=7) at /usr/include/x86_64-linux-gnu/bits/syslog.h:47
>> > #5 btd_debug (index=index@entry=65535, format=format@entry=0x557f36cd515c "%s:%s() %s err %d") at src/log.c:252
>> > #6 0x0000557f36c94d88 in device_svc_resolved (dev=0x557f36c90e60 <browse_request_exit>, bdaddr_type=0 '\000', err=-111) at src/device.c:2214
>> > #7 0x0000557f36c97adb in search_cb (user_data=<optimized out>, err=-111, recs=<optimized out>) at src/device.c:4516
>> > #8 browse_cb (recs=<optimized out>, err=-111, user_data=<optimized out>) at src/device.c:4549
>> > #9 0x0000557f36c73551 in connect_watch (chan=0x557f37ae0350, cond=<optimized out>, user_data=0x557f37ae0060) at src/sdp-client.c:286
>> > #10 0x00007f928124f6ea in g_main_context_dispatch () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
>> > #11 0x00007f928124faa0 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
>> > #12 0x00007f928124fdc2 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
>> > #13 0x0000557f36c353cc in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:708
>> > (gdb)
>>
>> Ok, so this seem to be SDP causing and error, 111 connection refused.
>>
>> > Syslog:
>> >
>> > bluetoothd: src/device.c:bonding_request_new() Requesting bonding for 68:76:4F:6C:31:E9
>> > bluetoothd: src/agent.c:agent_ref() 0x557f37ae5120: ref=3
>> > bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=2
>> > bluetoothd: src/adapter.c:suspend_discovery()
>> > bluetoothd: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 io_cap 0x01
>> > bluetoothd: src/adapter.c:add_whitelist_complete() 68:76:4F:6C:31:E9 added to kernel whitelist
>> > bluetoothd: src/adapter.c:connected_callback() hci0 device 68:76:4F:6C:31:E9 connected eir_len 12
>> > bluetoothd: src/adapter.c:new_link_key_callback() hci0 new key for 68:76:4F:6C:31:E9 type 4 pin_len 0 store_hint 1
>> > bluetoothd: src/device.c:device_set_bonded()
>> > bluetoothd: src/device.c:device_bonding_complete() bonding 0x557f37acc860 status 0x00
>> > bluetoothd: src/device.c:device_bonding_complete() Proceeding with service discovery
>> > bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=1
>> > bluetoothd: src/adapter.c:resume_discovery()
>> > bluetoothd: src/adapter.c:pair_device_complete() Success (0x00)
>> > bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0x0
>> > bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x00
>> > bluetoothd: src/adapter.c:resume_discovery()
>> > bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
>> > bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
>> > bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
>> > bluetoothd: No cache for 68:76:4F:6C:31:E9
>> > bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
>> > bluetoothd: src/adapter.c:dev_disconnected() Device 68:76:4F:6C:31:E9 disconnected, reason 3
>> > bluetoothd: src/adapter.c:adapter_remove_connection()
>> > bluetoothd: plugins/policy.c:disconnect_cb() reason 3
>> > bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0xe
>> > bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
>> > bluetoothd: src/device.c:device_bonding_failed() status 14
>> > bluetoothd: src/adapter.c:resume_discovery()
>> > bluetoothd: src/device.c:gatt_debug() Primary service discovery failed. ATT ECODE: 0x00
>> > bluetoothd: src/device.c:gatt_debug() Failed to initialize gatt-client
>> > bluetoothd: src/device.c:gatt_client_ready_cb() status: failed, error: 0
>> > bluetoothd: src/device.c:device_svc_resolved() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 err -5
>> > bluetoothd: src/device.c:att_disconnected_cb()
>> > bluetoothd: src/device.c:att_disconnected_cb() Connection reset by peer (104)
>> > bluetoothd: src/gatt-client.c:btd_gatt_client_disconnected() Device disconnected. Cleaning up.
>> > bluetoothd: src/device.c:att_disconnected_cb() Automatic connection disabled
>> > bluetoothd: attrib/gattrib.c:g_attrib_unref() 0x557f37ae4b40: g_attrib_unref=0
>> > bluetoothd: src/device.c:btd_device_set_trusted() trusted 1
>> > bluetoothd: src/device.c:connect_profiles() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 (all), client :1.256
>> > bluetoothd: src/device.c:connect_profiles() Resolving services for /org/bluez/hci0/dev_68_76_4F_6C_31_E9
>> > bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
>> > bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
>> > bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
>> > bluetoothd: No cache for 68:76:4F:6C:31:E9
>> > bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
>> > bluetoothd: 89:48:53:01:00:27: error updating services: Connection refused (111)
>>
>> Interesting, the device is connecting ATT over BR/EDR which is weird
>> if that is a headset, and we can see the 111, though the address
>> printed seems wrong, I wonder if that is why it crashes.
>
> The address thing is something to check further. I have no such device
> in a range whatsoever.
>
>>
>> > There is one interestig thing that I have noticed examining the the
>> > btmon output. The bluez is repeatedly (literally till the end) sending
>> > the Information Request (Extended Feature Mask) and the headset is
>> > answering Not Supported. For the same headset bluez 5.43 sends this
>> > request only once. The bluez 5.44 works fine with a Phillips headset
>> > that answers Success to this knd of Information Response.
>>
>> Well this is the information request is sent by the kernel, so if you
>> haven't change it between versions that should not change between
>> daemon versions, but ATT is not a fixed channel on BR/EDR so I wonder
>> if the information request is actually sent because ATT is being
>> connected.
>
> Could be, good point.
>
>>
>> > Additionaly to Information Request (Ext Feature Mask) bluez 5.44 keeps
>> > repeating ATT Read By Group Type Request, GATT Primary Service
>> > Declaration which in case of Phillips device happens only once. Bluez
>> > 5.43 does not send it whatsoever.
>>
>> I suspect it doesn't even connect over ATT in 5.43, anyway that should
>> only happen once but I can see from the logs that it fails and
>> disconnects and then connects again.
>
> I'll capture some logs with 5.43 and share later this week. This looks
> interesting to follow.
>
> Thanks for your comments,
> K
>
>>
>> > Let me know if I can in any way help debugging this issue further.
>> >
>> > Thanks,
>> > Konrad
>> > --
>> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
>> > the body of a message to majordomo@vger.kernel.org
>> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>>
>> --
>> Luiz Augusto von Dentz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Regression in bluez 5.44, bluetoothd crashes
From: Konrad Zapalowicz @ 2017-04-24 8:25 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZJAs_kSpMk43okA1ZhJow_YZvuTqPPt-Oud2_5yOCD8jA@mail.gmail.com>
On 04/06, Luiz Augusto von Dentz wrote:
> Hi Konrad,
>
> On Thu, Apr 6, 2017 at 3:51 PM, Konrad Zapalowicz
> <konrad.zapalowicz@canonical.com> wrote:
> > Hey,
> >
> > I see a regression in 5.44 when testing Sony SBH52 headset. It fails to
> > connect profiles but the worst thing is that the bluetoothd crashes
> > (logs below).
> >
> > I have git bisect'ed it down to the commit f2483bbfd. It works fine if
> > I remove it.
>
> That is because the very next patch fix it:
>
> commit 4a8c33b1f76edf2dfe33b9956014cc2746ae71d8
> Author: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
> Date: Mon Nov 14 13:30:09 2016 +0200
>
> core/adapter: Fix using wrong address type to listen ATT
>
> bdaddr_type shall only matter for controllers supporting LE otherwise
> it may cause BDADDR_BREDR to be used for things like LE ATT socket
> listen breaking reconnections.
>
Is your suggestion that I might be missing the above patch? I have it
included, I'm using regular 5.44 release.
> > Stacktrace:
> >
> > (gdb) c
> > Continuing.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > strlen () at ../sysdeps/x86_64/strlen.S:106
> > 106 ../sysdeps/x86_64/strlen.S: No such file or directory.
> > (gdb) bt
> > #0 strlen () at ../sysdeps/x86_64/strlen.S:106
> > #1 0x00007f92806179a1 in _IO_vfprintf_internal (s=s@entry=0x557f37ad5520, format=<optimized out>, format@entry=0x557f36cd515c "%s:%s() %s err %d", ap=0x7ffc0b7a86d0)
> > at vfprintf.c:1637
> > #2 0x00007f92806dffc6 in ___vfprintf_chk (fp=fp@entry=0x557f37ad5520, flag=flag@entry=1, format=format@entry=0x557f36cd515c "%s:%s() %s err %d",
> > ap=ap@entry=0x7ffc0b7a86d0) at vfprintf_chk.c:33
> > #3 0x00007f92806c9028 in __GI___vsyslog_chk (pri=<optimized out>, pri@entry=7, flag=flag@entry=1, fmt=fmt@entry=0x557f36cd515c "%s:%s() %s err %d",
> > ap=ap@entry=0x7ffc0b7a86d0) at ../misc/syslog.c:222
> > #4 0x0000557f36c6735b in vsyslog (__ap=0x7ffc0b7a86d0, __fmt=0x557f36cd515c "%s:%s() %s err %d", __pri=7) at /usr/include/x86_64-linux-gnu/bits/syslog.h:47
> > #5 btd_debug (index=index@entry=65535, format=format@entry=0x557f36cd515c "%s:%s() %s err %d") at src/log.c:252
> > #6 0x0000557f36c94d88 in device_svc_resolved (dev=0x557f36c90e60 <browse_request_exit>, bdaddr_type=0 '\000', err=-111) at src/device.c:2214
> > #7 0x0000557f36c97adb in search_cb (user_data=<optimized out>, err=-111, recs=<optimized out>) at src/device.c:4516
> > #8 browse_cb (recs=<optimized out>, err=-111, user_data=<optimized out>) at src/device.c:4549
> > #9 0x0000557f36c73551 in connect_watch (chan=0x557f37ae0350, cond=<optimized out>, user_data=0x557f37ae0060) at src/sdp-client.c:286
> > #10 0x00007f928124f6ea in g_main_context_dispatch () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #11 0x00007f928124faa0 in ?? () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #12 0x00007f928124fdc2 in g_main_loop_run () from target:/lib/x86_64-linux-gnu/libglib-2.0.so.0
> > #13 0x0000557f36c353cc in main (argc=<optimized out>, argv=<optimized out>) at src/main.c:708
> > (gdb)
>
> Ok, so this seem to be SDP causing and error, 111 connection refused.
>
> > Syslog:
> >
> > bluetoothd: src/device.c:bonding_request_new() Requesting bonding for 68:76:4F:6C:31:E9
> > bluetoothd: src/agent.c:agent_ref() 0x557f37ae5120: ref=3
> > bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=2
> > bluetoothd: src/adapter.c:suspend_discovery()
> > bluetoothd: src/adapter.c:adapter_bonding_attempt() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 io_cap 0x01
> > bluetoothd: src/adapter.c:add_whitelist_complete() 68:76:4F:6C:31:E9 added to kernel whitelist
> > bluetoothd: src/adapter.c:connected_callback() hci0 device 68:76:4F:6C:31:E9 connected eir_len 12
> > bluetoothd: src/adapter.c:new_link_key_callback() hci0 new key for 68:76:4F:6C:31:E9 type 4 pin_len 0 store_hint 1
> > bluetoothd: src/device.c:device_set_bonded()
> > bluetoothd: src/device.c:device_bonding_complete() bonding 0x557f37acc860 status 0x00
> > bluetoothd: src/device.c:device_bonding_complete() Proceeding with service discovery
> > bluetoothd: src/agent.c:agent_unref() 0x557f37ae5120: ref=1
> > bluetoothd: src/adapter.c:resume_discovery()
> > bluetoothd: src/adapter.c:pair_device_complete() Success (0x00)
> > bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0x0
> > bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x00
> > bluetoothd: src/adapter.c:resume_discovery()
> > bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
> > bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
> > bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
> > bluetoothd: No cache for 68:76:4F:6C:31:E9
> > bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
> > bluetoothd: src/adapter.c:dev_disconnected() Device 68:76:4F:6C:31:E9 disconnected, reason 3
> > bluetoothd: src/adapter.c:adapter_remove_connection()
> > bluetoothd: plugins/policy.c:disconnect_cb() reason 3
> > bluetoothd: src/adapter.c:bonding_attempt_complete() hci0 bdaddr 68:76:4F:6C:31:E9 type 0 status 0xe
> > bluetoothd: src/device.c:device_bonding_complete() bonding (nil) status 0x0e
> > bluetoothd: src/device.c:device_bonding_failed() status 14
> > bluetoothd: src/adapter.c:resume_discovery()
> > bluetoothd: src/device.c:gatt_debug() Primary service discovery failed. ATT ECODE: 0x00
> > bluetoothd: src/device.c:gatt_debug() Failed to initialize gatt-client
> > bluetoothd: src/device.c:gatt_client_ready_cb() status: failed, error: 0
> > bluetoothd: src/device.c:device_svc_resolved() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 err -5
> > bluetoothd: src/device.c:att_disconnected_cb()
> > bluetoothd: src/device.c:att_disconnected_cb() Connection reset by peer (104)
> > bluetoothd: src/gatt-client.c:btd_gatt_client_disconnected() Device disconnected. Cleaning up.
> > bluetoothd: src/device.c:att_disconnected_cb() Automatic connection disabled
> > bluetoothd: attrib/gattrib.c:g_attrib_unref() 0x557f37ae4b40: g_attrib_unref=0
> > bluetoothd: src/device.c:btd_device_set_trusted() trusted 1
> > bluetoothd: src/device.c:connect_profiles() /org/bluez/hci0/dev_68_76_4F_6C_31_E9 (all), client :1.256
> > bluetoothd: src/device.c:connect_profiles() Resolving services for /org/bluez/hci0/dev_68_76_4F_6C_31_E9
> > bluetoothd: src/gatt-database.c:connect_cb() New incoming BR/EDR ATT connection
> > bluetoothd: attrib/gattrib.c:g_attrib_ref() 0x557f37ae4b40: g_attrib_ref=1
> > bluetoothd: src/device.c:load_gatt_db() Restoring 68:76:4F:6C:31:E9 gatt database from file
> > bluetoothd: No cache for 68:76:4F:6C:31:E9
> > bluetoothd: src/gatt-client.c:btd_gatt_client_connected() Device connected.
> > bluetoothd: 89:48:53:01:00:27: error updating services: Connection refused (111)
>
> Interesting, the device is connecting ATT over BR/EDR which is weird
> if that is a headset, and we can see the 111, though the address
> printed seems wrong, I wonder if that is why it crashes.
The address thing is something to check further. I have no such device
in a range whatsoever.
>
> > There is one interestig thing that I have noticed examining the the
> > btmon output. The bluez is repeatedly (literally till the end) sending
> > the Information Request (Extended Feature Mask) and the headset is
> > answering Not Supported. For the same headset bluez 5.43 sends this
> > request only once. The bluez 5.44 works fine with a Phillips headset
> > that answers Success to this knd of Information Response.
>
> Well this is the information request is sent by the kernel, so if you
> haven't change it between versions that should not change between
> daemon versions, but ATT is not a fixed channel on BR/EDR so I wonder
> if the information request is actually sent because ATT is being
> connected.
Could be, good point.
>
> > Additionaly to Information Request (Ext Feature Mask) bluez 5.44 keeps
> > repeating ATT Read By Group Type Request, GATT Primary Service
> > Declaration which in case of Phillips device happens only once. Bluez
> > 5.43 does not send it whatsoever.
>
> I suspect it doesn't even connect over ATT in 5.43, anyway that should
> only happen once but I can see from the logs that it fails and
> disconnects and then connects again.
I'll capture some logs with 5.43 and share later this week. This looks
interesting to follow.
Thanks for your comments,
K
>
> > Let me know if I can in any way help debugging this issue further.
> >
> > Thanks,
> > Konrad
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
> --
> Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH BlueZ 3/3] client: Always start an agent
From: Luiz Augusto von Dentz @ 2017-04-23 20:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20170423201457.7963-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Always register agent with default capability.
---
client/main.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/client/main.c b/client/main.c
index 8c9d5c3..255cbd5 100644
--- a/client/main.c
+++ b/client/main.c
@@ -2355,10 +2355,10 @@ static gboolean option_version = FALSE;
static gboolean parse_agent(const char *key, const char *value,
gpointer user_data, GError **error)
{
- if (value)
- auto_register_agent = g_strdup(value);
- else
- auto_register_agent = g_strdup("");
+ if (!value)
+ return FALSE;
+
+ auto_register_agent = g_strdup(value);
return TRUE;
}
@@ -2366,8 +2366,7 @@ static gboolean parse_agent(const char *key, const char *value,
static GOptionEntry options[] = {
{ "version", 'v', 0, G_OPTION_ARG_NONE, &option_version,
"Show version information and exit" },
- { "agent", 'a', G_OPTION_FLAG_OPTIONAL_ARG,
- G_OPTION_ARG_CALLBACK, parse_agent,
+ { "agent", 'a', 0, G_OPTION_ARG_CALLBACK, parse_agent,
"Register agent handler", "CAPABILITY" },
{ NULL },
};
@@ -2385,6 +2384,8 @@ int main(int argc, char *argv[])
GDBusClient *client;
guint signal;
+ auto_register_agent = g_strdup("");
+
context = g_option_context_new(NULL);
g_option_context_add_main_entries(context, options, NULL);
--
2.9.3
^ permalink raw reply related
* [PATCH BlueZ 2/3] monitor: Fix not decoding control frames
From: Luiz Augusto von Dentz @ 2017-04-23 20:14 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20170423201457.7963-1-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
In order to enable decoding control frames packet_monitor needs to check
if the index is set to HCI_DEV_NONE since that will call packet_ctrl_open
which setups the ctrl and assign it a cookie.
---
monitor/packet.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/monitor/packet.c b/monitor/packet.c
index 89423d1..2e09dda 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -3866,10 +3866,11 @@ void packet_monitor(struct timeval *tv, struct ucred *cred,
uint16_t manufacturer;
const char *ident;
- if (index_filter && index_number != index)
- return;
-
- index_current = index;
+ if (index != HCI_DEV_NONE) {
+ if (index_filter && index_number != index)
+ return;
+ index_current = index;
+ }
if (tv && time_offset == ((time_t) -1))
time_offset = tv->tv_sec;
--
2.9.3
^ permalink raw reply related
* [PATCH BlueZ 1/3] monitor: Add frame counter support
From: Luiz Augusto von Dentz @ 2017-04-23 20:14 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
This adds frame counter support for io frames:
> HCI Event: Command Complete (0x0e) plen 4 #86 [hci1] 13:00:02.639412
LE Set Scan Parameters (0x08|0x000b) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Scan Enable (0x08|0x000c) plen 2 #87 [hci1] 13:00:02.639663
Scanning: Enabled (0x01)
Filter duplicates: Enabled (0x01)
> HCI Event: Command Complete (0x0e) plen 4 #88 [hci1] 13:00:02.640420
LE Set Scan Enable (0x08|0x000c) ncmd 2
Status: Success (0x00)
---
monitor/packet.c | 45 +++++++++++++++++++++++++++++++++++----------
1 file changed, 35 insertions(+), 10 deletions(-)
diff --git a/monitor/packet.c b/monitor/packet.c
index 3c43356..89423d1 100644
--- a/monitor/packet.c
+++ b/monitor/packet.c
@@ -58,6 +58,7 @@
#include "packet.h"
#define COLOR_CHANNEL_LABEL COLOR_WHITE
+#define COLOR_FRAME_LABEL COLOR_WHITE
#define COLOR_INDEX_LABEL COLOR_WHITE
#define COLOR_TIMESTAMP COLOR_YELLOW
@@ -259,6 +260,17 @@ void packet_select_index(uint16_t index)
#define print_space(x) printf("%*c", (x), ' ');
+#define MAX_INDEX 16
+
+struct index_data {
+ uint8_t type;
+ uint8_t bdaddr[6];
+ uint16_t manufacturer;
+ size_t frame;
+};
+
+static struct index_data index_list[MAX_INDEX];
+
static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
uint16_t index, const char *channel,
const char *color, const char *label,
@@ -267,6 +279,7 @@ static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
int col = num_columns();
char line[256], ts_str[96];
int n, ts_len = 0, ts_pos = 0, len = 0, pos = 0;
+ static size_t last_frame;
if (channel) {
if (use_color()) {
@@ -280,6 +293,20 @@ static void print_packet(struct timeval *tv, struct ucred *cred, char ident,
ts_pos += n;
ts_len += n;
}
+ } else if (index != HCI_DEV_NONE &&
+ index_list[index].frame != last_frame) {
+ if (use_color()) {
+ n = sprintf(ts_str + ts_pos, "%s", COLOR_FRAME_LABEL);
+ if (n > 0)
+ ts_pos += n;
+ }
+
+ n = sprintf(ts_str + ts_pos, " #%zu", index_list[index].frame);
+ if (n > 0) {
+ ts_pos += n;
+ ts_len += n;
+ }
+ last_frame = index_list[index].frame;
}
if ((filter_mask & PACKET_FILTER_SHOW_INDEX) &&
@@ -3828,16 +3855,6 @@ static int addr2str(const uint8_t *addr, char *str)
addr[5], addr[4], addr[3], addr[2], addr[1], addr[0]);
}
-#define MAX_INDEX 16
-
-struct index_data {
- uint8_t type;
- uint8_t bdaddr[6];
- uint16_t manufacturer;
-};
-
-static struct index_data index_list[MAX_INDEX];
-
void packet_monitor(struct timeval *tv, struct ucred *cred,
uint16_t index, uint16_t opcode,
const void *data, uint16_t size)
@@ -9156,6 +9173,8 @@ void packet_hci_command(struct timeval *tv, struct ucred *cred, uint16_t index,
char extra_str[25], vendor_str[150];
int i;
+ index_list[index].frame++;
+
if (size < HCI_COMMAND_HDR_SIZE) {
sprintf(extra_str, "(len %d)", size);
print_packet(tv, cred, '*', index, NULL, COLOR_ERROR,
@@ -9257,6 +9276,8 @@ void packet_hci_event(struct timeval *tv, struct ucred *cred, uint16_t index,
char extra_str[25];
int i;
+ index_list[index].frame++;
+
if (size < HCI_EVENT_HDR_SIZE) {
sprintf(extra_str, "(len %d)", size);
print_packet(tv, cred, '*', index, NULL, COLOR_ERROR,
@@ -9329,6 +9350,8 @@ void packet_hci_acldata(struct timeval *tv, struct ucred *cred, uint16_t index,
uint8_t flags = acl_flags(handle);
char handle_str[16], extra_str[32];
+ index_list[index].frame++;
+
if (size < HCI_ACL_HDR_SIZE) {
if (in)
print_packet(tv, cred, '*', index, NULL, COLOR_ERROR,
@@ -9371,6 +9394,8 @@ void packet_hci_scodata(struct timeval *tv, struct ucred *cred, uint16_t index,
uint8_t flags = acl_flags(handle);
char handle_str[16], extra_str[32];
+ index_list[index].frame++;
+
if (size < HCI_SCO_HDR_SIZE) {
if (in)
print_packet(tv, cred, '*', index, NULL, COLOR_ERROR,
--
2.9.3
^ permalink raw reply related
* MS Designer Keyboard fails to reconnect
From: Andrew - @ 2017-04-23 2:59 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 893 bytes --]
Hello. I`m stuck again, requesting assistance. Using BlueZ 5.44 @
ArchLinux 4.10.11 - clean install, without any legacy stuff that was
the source of my problems back then.
My MS Designer Keyboard is now pairing and connecting correctly. I`m
typing this message with it. But once it disconnects (either after 600
sec idle or by invoking org.bluez.Device1.Disconnect manually),
nothing can make it properly reconnect except deleting it in
bluetoothctl or Blueman and pairing again.
I`ve attached 2 packet dumps: "begin" is what happens on pairing, and
"reconnect" is when I try to continue typing after 10++ minute idle.
No matter which keys I press, nothing like the first two packets of
"reconnect" (a proper key-down / key-up response) gets captured. The
manual disconnect situation is identical to what`s going on in
"reconnect".
Can you please tell me what I need to do to make it work?
[-- Attachment #2: begin.pcapng --]
[-- Type: application/x-pcapng, Size: 2940 bytes --]
[-- Attachment #3: reconnect.pcapng --]
[-- Type: application/x-pcapng, Size: 1096 bytes --]
^ permalink raw reply
* Re: Serial Port connection with DBus API
From: Barry Byford @ 2017-04-22 20:46 UTC (permalink / raw)
To: Bluez mailing list
In-Reply-To: <20170422052644.GA31652@x1c>
On 22 April 2017 at 06:26, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Barry,
>
> On Fri, Apr 21, 2017, Barry Byford wrote:
>> >> > 'Channel': GLib.Variant('i', 1),
> ...
>> However I'm now seeing this error appear in btmon when I try to bind
>> to the RFCOMM socket:
>>
>> = bluetoothd: RFCOMM server failed for SerialPort: rfcomm_bind:
>> Address already in use (98)
>
> I think that means that you already have some other service listening on
> RFCOMM channel 1. Try using some other channel, or identify and stop the
> other service that's using channel 1.
Turns out it was me that was creating the other service. :-(
Depending which order I bind to the socket or RegisterProfile, depends
if I get the error in Bluetoothd or sockets.
I can register the Serial Port profile successfully which allows me to
connect from the (Bluedot) Android app and I can see information being
sent to my Linux board in btmon. However I don't seem to be able to
get at that information in my script.
Looking at this a bit more, maybe the socket connection should be
created from the 'fd' parameter passed to NewConnection. However when
I try to get the socket with this:
def NewConnection(self, path, fd, properties):
self.server_sock = socket.fromfd(fd, socket.AF_BLUETOOTH, socket.SOCK_STREAM,
socket.BTPROTO_RFCOMM)
data = self.server_sock.recv(1024)
It gives the following:
Exception while handling org.bluez.Profile1.NewConnection()
Traceback (most recent call last):
File "/usr/local/lib/python3.5/dist-packages/pydbus/registration.py",
line 81, in call_method
result = method(*parameters, **kwargs)
File "BTclassic.py", line 67, in NewConnection
data = self.server_sock.recv(1024)
OSError: [Errno 88] Socket operation on non-socket
I had been following test/test-hfp as the basic structure but that
doesn't seem to be working for me.
Not sure where to go next with this
^ permalink raw reply
* Segfault when pairing A2DP device
From: Lukas Wagner @ 2017-04-22 13:13 UTC (permalink / raw)
To: linux-bluetooth
Hello,
when I try to pair my Bose QC35 Headset, bluetoothd crashes with the
following stack trace:
#0 0x000000000048d932 ba2str (bluetoothd)
#1 0x00000000004882d1 update_bredr_services (bluetoothd)
#2 0x0000000000488b9e browse_cb (bluetoothd)
#3 0x000000000045e6cc search_completed_cb (bluetoothd)
#4 0x00000000004a03f2 sdp_process (bluetoothd)
#5 0x000000000045e780 search_process_cb (bluetoothd)
#6 0x00007f28aca7545a g_main_context_dispatch (libglib-2.0.so.0)
#7 0x00007f28aca75810 n/a (libglib-2.0.so.0)
#8 0x00007f28aca75b32 g_main_loop_run (libglib-2.0.so.0)
#9 0x000000000044d267 main (bluetoothd)
#10 0x00007f28ac04b511 __libc_start_main (libc.so.6)
#11 0x000000000040ad6a _start (bluetoothd)
Coredump: http://wikisend.com/download/366074/core
Version: bluez 5.44-17-g677a3456a
Steps to reproduce:
- Remove (if already paired) bluetooth headset
- Pair in bluetoothctl
I believe this might be related to the bug reported here:
http://marc.info/?l=linux-bluetooth&m=149121146509800&w=2
Please let me know any more information on this.
I'm also willing to do some debugging myself if anybody can point me
in the right direction.
Cheers
^ permalink raw reply
* pull request: bluetooth-next 2017-04-22
From: Johan Hedberg @ 2017-04-22 13:13 UTC (permalink / raw)
To: davem; +Cc: linux-bluetooth, netdev
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
Hi Dave,
Here are some more Bluetooth patches (and one 802.15.4 patch) in the
bluetooth-next tree targeting the 4.12 kernel. Most of them are pure
fixes.
Please let me know if there are any issues pulling. Thanks.
Johan
---
The following changes since commit fb796707d7a6c9b24fdf80b9b4f24fa5ffcf0ec5:
Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2017-04-21 20:23:53 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git for-upstream
for you to fetch changes up to d160b74da85a4ec072b076db056e27ba7246eba0:
Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY (2017-04-22 10:28:40 +0200)
----------------------------------------------------------------
Arnd Bergmann (2):
Bluetooth: try to improve CONFIG_SERIAL_DEV_BUS dependency
ieee802154: don't select COMMON_CLK
Dean Jenkins (3):
Bluetooth: hci_ldisc: Add missing return in hci_uart_init_work()
Bluetooth: hci_ldisc: Ensure hu->hdev set to NULL before freeing hdev
Bluetooth: hci_ldisc: Add missing clear HCI_UART_PROTO_READY
Sebastian Reichel (1):
Bluetooth: hci_ll: Fix NULL pointer deref on FW upload failure
drivers/bluetooth/Kconfig | 8 +++++++-
drivers/bluetooth/Makefile | 2 +-
drivers/bluetooth/hci_ldisc.c | 7 ++++++-
drivers/bluetooth/hci_ll.c | 3 +--
drivers/net/ieee802154/Kconfig | 2 +-
5 files changed, 16 insertions(+), 6 deletions(-)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ 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