* Re: [PATCH 3/4] Fix calling watch callbacks after it has been removed
From: Luiz Augusto von Dentz @ 2010-09-06 13:39 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1283768782-4283-3-git-send-email-luiz.dentz@gmail.com>
This one is broken, I will resubmit.
On Mon, Sep 6, 2010 at 1:26 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> From: Luiz Augusto Von Dentz <luiz.dentz-von@nokia.com>
>
> Pending call should be removed if the watch is removed since the
> application no longer expect that to be reached and may already freed the
> data associated with it.
> ---
> gdbus/watch.c | 75 ++++++++++++++++++++++++++++++++++++--------------------
> 1 files changed, 48 insertions(+), 27 deletions(-)
>
> diff --git a/gdbus/watch.c b/gdbus/watch.c
> index 8ad4815..249d927 100644
> --- a/gdbus/watch.c
> +++ b/gdbus/watch.c
> @@ -43,11 +43,21 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
> static guint listener_id = 0;
> static GSList *listeners = NULL;
>
> +struct service_data {
> + DBusConnection *conn;
> + DBusPendingCall *call;
> + char *name;
> + const char *owner;
> + guint id;
> + struct filter_callback *callback;
> +};
> +
> struct filter_callback {
> GDBusWatchFunction conn_func;
> GDBusWatchFunction disc_func;
> GDBusSignalFunction signal_func;
> GDBusDestroyFunction destroy_func;
> + struct service_data *data;
> void *user_data;
> guint id;
> };
> @@ -302,7 +312,7 @@ static struct filter_callback *filter_data_add_callback(
> {
> struct filter_callback *cb = NULL;
>
> - cb = g_new(struct filter_callback, 1);
> + cb = g_new0(struct filter_callback, 1);
>
> cb->conn_func = connect;
> cb->disc_func = disconnect;
> @@ -319,6 +329,24 @@ static struct filter_callback *filter_data_add_callback(
> return cb;
> }
>
> +static void service_data_free(struct service_data *data)
> +{
> + struct filter_callback *callback = data->callback;
> +
> + dbus_connection_unref(data->conn);
> +
> + if (data->call)
> + dbus_pending_call_unref(data->call);
> +
> + if (data->id)
> + g_source_remove(data->id);
> +
> + g_free(data->name);
> + g_free(data);
> +
> + callback->data = NULL;
> +}
> +
> static gboolean filter_data_remove_callback(struct filter_data *data,
> struct filter_callback *cb)
> {
> @@ -327,6 +355,13 @@ static gboolean filter_data_remove_callback(struct filter_data *data,
> data->callbacks = g_slist_remove(data->callbacks, cb);
> data->processed = g_slist_remove(data->processed, cb);
>
> + /* Cancel pending operations */
> + if (cb->data) {
> + if (cb->data->call)
> + dbus_pending_call_cancel(cb->data->call);
> + service_data_free(cb->data);
> + }
> +
> if (cb->destroy_func)
> cb->destroy_func(cb->user_data);
>
> @@ -515,28 +550,14 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
> return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
> }
>
> -struct service_data {
> - DBusConnection *conn;
> - char *name;
> - const char *owner;
> - GDBusWatchFunction conn_func;
> - void *user_data;
> -};
> -
> -static void service_data_free(struct service_data *data)
> -{
> - dbus_connection_unref(data->conn);
> - g_free(data->name);
> - g_free(data);
> -}
> -
> static gboolean update_service(void *user_data)
> {
> struct service_data *data = user_data;
> + struct filter_callback *cb = data->callback;
>
> update_name_cache(data->name, data->owner);
> - if (data->conn_func)
> - data->conn_func(data->conn, data->user_data);
> + if (cb->conn_func)
> + cb->conn_func(data->conn, cb->user_data);
>
> service_data_free(data);
>
> @@ -575,11 +596,11 @@ done:
> dbus_message_unref(reply);
> }
>
> -static void check_service(DBusConnection *connection, const char *name,
> - GDBusWatchFunction connect, void *user_data)
> +static void check_service(DBusConnection *connection,
> + const char *name,
> + struct filter_callback *callback)
> {
> DBusMessage *message;
> - DBusPendingCall *call;
> struct service_data *data;
>
> data = g_try_malloc0(sizeof(*data));
> @@ -590,12 +611,12 @@ static void check_service(DBusConnection *connection, const char *name,
>
> data->conn = dbus_connection_ref(connection);
> data->name = g_strdup(name);
> - data->conn_func = connect;
> - data->user_data = user_data;
> + data->callback = callback;
> + callback->data = data;
>
> data->owner = check_name_cache(name);
> if (data->owner != NULL) {
> - g_idle_add(update_service, data);
> + data->id = g_idle_add(update_service, data);
> return;
> }
>
> @@ -611,13 +632,13 @@ static void check_service(DBusConnection *connection, const char *name,
> DBUS_TYPE_INVALID);
>
> if (dbus_connection_send_with_reply(connection, message,
> - &call, -1) == FALSE) {
> + &data->call, -1) == FALSE) {
> error("Failed to execute method call");
> g_free(data);
> goto done;
> }
>
> - if (call == NULL) {
> + if (data->call == NULL) {
> error("D-Bus connection not available");
> g_free(data);
> goto done;
> @@ -654,7 +675,7 @@ guint g_dbus_add_service_watch(DBusConnection *connection, const char *name,
> return 0;
>
> if (connect)
> - check_service(connection, name, connect, user_data);
> + check_service(connection, name, cb);
>
> return cb->id;
> }
> --
> 1.7.0.4
>
> --
> 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
Computer Engineer
^ permalink raw reply
* [PATCH 3/4] Fix calling watch callbacks after it has been removed
From: Luiz Augusto von Dentz @ 2010-09-06 13:39 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
Pending call should be removed if the watch is removed since the
application no longer expect that to be reached and may already freed the
data associated with it.
---
gdbus/watch.c | 79 +++++++++++++++++++++++++++++++++++---------------------
1 files changed, 49 insertions(+), 30 deletions(-)
diff --git a/gdbus/watch.c b/gdbus/watch.c
index 8ad4815..c0dcc93 100644
--- a/gdbus/watch.c
+++ b/gdbus/watch.c
@@ -43,11 +43,21 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
static guint listener_id = 0;
static GSList *listeners = NULL;
+struct service_data {
+ DBusConnection *conn;
+ DBusPendingCall *call;
+ char *name;
+ const char *owner;
+ guint id;
+ struct filter_callback *callback;
+};
+
struct filter_callback {
GDBusWatchFunction conn_func;
GDBusWatchFunction disc_func;
GDBusSignalFunction signal_func;
GDBusDestroyFunction destroy_func;
+ struct service_data *data;
void *user_data;
guint id;
};
@@ -302,7 +312,7 @@ static struct filter_callback *filter_data_add_callback(
{
struct filter_callback *cb = NULL;
- cb = g_new(struct filter_callback, 1);
+ cb = g_new0(struct filter_callback, 1);
cb->conn_func = connect;
cb->disc_func = disconnect;
@@ -319,6 +329,24 @@ static struct filter_callback *filter_data_add_callback(
return cb;
}
+static void service_data_free(struct service_data *data)
+{
+ struct filter_callback *callback = data->callback;
+
+ dbus_connection_unref(data->conn);
+
+ if (data->call)
+ dbus_pending_call_unref(data->call);
+
+ if (data->id)
+ g_source_remove(data->id);
+
+ g_free(data->name);
+ g_free(data);
+
+ callback->data = NULL;
+}
+
static gboolean filter_data_remove_callback(struct filter_data *data,
struct filter_callback *cb)
{
@@ -327,6 +355,13 @@ static gboolean filter_data_remove_callback(struct filter_data *data,
data->callbacks = g_slist_remove(data->callbacks, cb);
data->processed = g_slist_remove(data->processed, cb);
+ /* Cancel pending operations */
+ if (cb->data) {
+ if (cb->data->call)
+ dbus_pending_call_cancel(cb->data->call);
+ service_data_free(cb->data);
+ }
+
if (cb->destroy_func)
cb->destroy_func(cb->user_data);
@@ -515,28 +550,14 @@ static DBusHandlerResult message_filter(DBusConnection *connection,
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
}
-struct service_data {
- DBusConnection *conn;
- char *name;
- const char *owner;
- GDBusWatchFunction conn_func;
- void *user_data;
-};
-
-static void service_data_free(struct service_data *data)
-{
- dbus_connection_unref(data->conn);
- g_free(data->name);
- g_free(data);
-}
-
static gboolean update_service(void *user_data)
{
struct service_data *data = user_data;
+ struct filter_callback *cb = data->callback;
update_name_cache(data->name, data->owner);
- if (data->conn_func)
- data->conn_func(data->conn, data->user_data);
+ if (cb->conn_func)
+ cb->conn_func(data->conn, cb->user_data);
service_data_free(data);
@@ -575,11 +596,11 @@ done:
dbus_message_unref(reply);
}
-static void check_service(DBusConnection *connection, const char *name,
- GDBusWatchFunction connect, void *user_data)
+static void check_service(DBusConnection *connection,
+ const char *name,
+ struct filter_callback *callback)
{
DBusMessage *message;
- DBusPendingCall *call;
struct service_data *data;
data = g_try_malloc0(sizeof(*data));
@@ -590,12 +611,12 @@ static void check_service(DBusConnection *connection, const char *name,
data->conn = dbus_connection_ref(connection);
data->name = g_strdup(name);
- data->conn_func = connect;
- data->user_data = user_data;
+ data->callback = callback;
+ callback->data = data;
data->owner = check_name_cache(name);
if (data->owner != NULL) {
- g_idle_add(update_service, data);
+ data->id = g_idle_add(update_service, data);
return;
}
@@ -611,21 +632,19 @@ static void check_service(DBusConnection *connection, const char *name,
DBUS_TYPE_INVALID);
if (dbus_connection_send_with_reply(connection, message,
- &call, -1) == FALSE) {
+ &data->call, -1) == FALSE) {
error("Failed to execute method call");
g_free(data);
goto done;
}
- if (call == NULL) {
+ if (data->call == NULL) {
error("D-Bus connection not available");
g_free(data);
goto done;
}
- dbus_pending_call_set_notify(call, service_reply, data, g_free);
-
- dbus_pending_call_unref(call);
+ dbus_pending_call_set_notify(data->call, service_reply, data, NULL);
done:
dbus_message_unref(message);
@@ -654,7 +673,7 @@ guint g_dbus_add_service_watch(DBusConnection *connection, const char *name,
return 0;
if (connect)
- check_service(connection, name, connect, user_data);
+ check_service(connection, name, cb);
return cb->id;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Make the path to oui.txt a compile-time option
From: Bastien Nocera @ 2010-09-06 14:47 UTC (permalink / raw)
To: BlueZ development
[-- Attachment #1: Type: text/plain, Size: 199 bytes --]
Heya,
We've been carrying a similar (but hard-coded) patch in Fedora for a
long while, and it would be nice if we could do this properly upstream
instead.
Patch attached with explanations.
Cheers
[-- Attachment #2: 0001-Make-the-path-to-oui.txt-a-compile-time-option.patch --]
[-- Type: text/x-patch, Size: 1927 bytes --]
>From b96d9394aa850be86ca368aeaeec3bc24c00bce1 Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Mon, 6 Sep 2010 15:43:48 +0100
Subject: [PATCH] Make the path to oui.txt a compile-time option
This avoids bluetoothd trying to load oui.txt from multiple locations
and cause SELinux AVC denials by accessing files it's not supposed
to touch.
---
acinclude.m4 | 8 ++++++++
configure.ac | 1 +
src/oui.c | 14 +++-----------
3 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/acinclude.m4 b/acinclude.m4
index b34f08d..a4e5e2f 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -152,6 +152,14 @@ AC_DEFUN([AC_PATH_SNDFILE], [
AC_SUBST(SNDFILE_LIBS)
])
+AC_DEFUN([AC_PATH_OUI], [
+ AC_ARG_WITH(ouifile,
+ AS_HELP_STRING([--with-ouifile=PATH],[Path to the oui.txt file @<:@auto@:>@]),
+ [ac_with_ouifile=$withval],
+ [ac_with_ouifile="/var/lib/misc/oui.txt"])
+ AC_DEFINE_UNQUOTED(OUIFILE, ["$ac_with_ouifile"], [Define the OUI file path])
+])
+
AC_DEFUN([AC_ARG_BLUEZ], [
debug_enable=no
optimization_enable=yes
diff --git a/configure.ac b/configure.ac
index e8abfe9..74acf31 100644
--- a/configure.ac
+++ b/configure.ac
@@ -41,6 +41,7 @@ AC_PATH_ALSA
AC_PATH_GSTREAMER
AC_PATH_USB
AC_PATH_SNDFILE
+AC_PATH_OUI
AC_ARG_BLUEZ
diff --git a/src/oui.c b/src/oui.c
index 1096d20..80bb3d3 100644
--- a/src/oui.c
+++ b/src/oui.c
@@ -38,23 +38,15 @@
/* http://standards.ieee.org/regauth/oui/oui.txt */
-#define OUIFILE "/var/lib/misc/oui.txt"
-
char *ouitocomp(const char *oui)
{
struct stat st;
char *str, *map, *off, *end;
int fd;
- fd = open("oui.txt", O_RDONLY);
- if (fd < 0) {
- fd = open(OUIFILE, O_RDONLY);
- if (fd < 0) {
- fd = open("/usr/share/misc/oui.txt", O_RDONLY);
- if (fd < 0)
- return NULL;
- }
- }
+ fd = open(OUIFILE, O_RDONLY);
+ if (fd < 0)
+ return NULL;
if (fstat(fd, &st) < 0) {
close(fd);
--
1.7.0.1
^ permalink raw reply related
* Re: [PATCH] Make the path to oui.txt a compile-time option
From: Pacho Ramos @ 2010-09-06 15:12 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1283784432.7529.24.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 381 bytes --]
El lun, 06-09-2010 a las 15:47 +0100, Bastien Nocera escribió:
> Heya,
>
> We've been carrying a similar (but hard-coded) patch in Fedora for a
> long while, and it would be nice if we could do this properly upstream
> instead.
>
> Patch attached with explanations.
>
> Cheers
What is the proper package to ship oui.txt file? Thanks a lot for the
information :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Make the path to oui.txt a compile-time option
From: Bastien Nocera @ 2010-09-06 15:15 UTC (permalink / raw)
To: pacho; +Cc: BlueZ development
In-Reply-To: <1283785976.28657.1.camel@localhost.localdomain>
On Mon, 2010-09-06 at 17:12 +0200, Pacho Ramos wrote:
> El lun, 06-09-2010 a las 15:47 +0100, Bastien Nocera escribió:
> > Heya,
> >
> > We've been carrying a similar (but hard-coded) patch in Fedora for a
> > long while, and it would be nice if we could do this properly upstream
> > instead.
> >
> > Patch attached with explanations.
> >
> > Cheers
>
> What is the proper package to ship oui.txt file? Thanks a lot for the
> information :-)
No idea. In Fedora we ship it in hwdata. No idea where it lives for
Debian-based distributions, or others.
^ permalink raw reply
* Re: [PATCH] Make the path to oui.txt a compile-time option
From: Pacho Ramos @ 2010-09-06 15:16 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1283786114.7529.25.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 857 bytes --]
El lun, 06-09-2010 a las 16:15 +0100, Bastien Nocera escribió:
> On Mon, 2010-09-06 at 17:12 +0200, Pacho Ramos wrote:
> > El lun, 06-09-2010 a las 15:47 +0100, Bastien Nocera escribió:
> > > Heya,
> > >
> > > We've been carrying a similar (but hard-coded) patch in Fedora for a
> > > long while, and it would be nice if we could do this properly upstream
> > > instead.
> > >
> > > Patch attached with explanations.
> > >
> > > Cheers
> >
> > What is the proper package to ship oui.txt file? Thanks a lot for the
> > information :-)
>
> No idea. In Fedora we ship it in hwdata. No idea where it lives for
> Debian-based distributions, or others.
>
OK, thanks, I asked it because under Gentoo no package is currently
providing it and a user suggested to supply it with bluez... but I
haven't made any decision about this yet
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* [PATCH v3] hciconfig: add LE_SET_ADVERTISE_ENABLE cmd
From: Anderson Briglia @ 2010-09-06 15:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Briglia
This patch implements two new hciconfig commands: leadv and noleadv.
These new hciconfig flags are responsible to LE_SET_ADVERTISE_ENABLE
command implementation.
---
tools/hciconfig.c | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/tools/hciconfig.c b/tools/hciconfig.c
index 87dd127..3627b7c 100644
--- a/tools/hciconfig.c
+++ b/tools/hciconfig.c
@@ -149,6 +149,44 @@ static void cmd_scan(int ctl, int hdev, char *opt)
}
}
+static void cmd_le_adv(int ctl, int hdev, char *opt)
+{
+ struct hci_request rq;
+ le_set_advertise_enable_cp advertise_cp;
+ uint8_t status;
+ int dd, ret;
+
+ if (hdev < 0)
+ hdev = hci_get_route(NULL);
+
+ dd = hci_open_dev(hdev);
+ if (dd < 0) {
+ perror("Could not open device");
+ exit(1);
+ }
+
+ memset(&advertise_cp, 0, sizeof(advertise_cp));
+ if (strcmp(opt, "noleadv") == 0)
+ advertise_cp.enable = 0x00;
+ else
+ advertise_cp.enable = 0x01;
+
+ memset(&rq, 0, sizeof(rq));
+ rq.ogf = OGF_LE_CTL;
+ rq.ocf = OCF_LE_SET_ADVERTISE_ENABLE;
+ rq.cparam = &advertise_cp;
+ rq.clen = LE_SET_ADVERTISE_ENABLE_CP_SIZE;
+ rq.rparam = &status;
+ rq.rlen = 1;
+
+ ret = hci_send_req(dd, &rq, 100);
+ if (status || ret < 0)
+ fprintf(stderr, "Can't set advertise mode on hci%d: %s (%d)\n",
+ hdev, strerror(errno), errno);
+
+ hci_close_dev(dd);
+}
+
static void cmd_iac(int ctl, int hdev, char *opt)
{
int s = hci_open_dev(hdev);
@@ -1728,6 +1766,8 @@ static struct {
{ "revision", cmd_revision, 0, "Display revision information" },
{ "block", cmd_block, "<bdaddr>", "Add a device to the blacklist" },
{ "unblock", cmd_unblock, "<bdaddr>", "Remove a device from the blacklist" },
+ { "leadv", cmd_le_adv, 0, "Enable LE advertising" },
+ { "noleadv", cmd_le_adv, 0, "Disable LE advertising" },
{ NULL, NULL, 0 }
};
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Make the path to oui.txt a compile-time option
From: Bastien Nocera @ 2010-09-06 15:22 UTC (permalink / raw)
To: pacho; +Cc: BlueZ development
In-Reply-To: <1283786212.28657.3.camel@localhost.localdomain>
On Mon, 2010-09-06 at 17:16 +0200, Pacho Ramos wrote:
> El lun, 06-09-2010 a las 16:15 +0100, Bastien Nocera escribió:
> > On Mon, 2010-09-06 at 17:12 +0200, Pacho Ramos wrote:
> > > El lun, 06-09-2010 a las 15:47 +0100, Bastien Nocera escribió:
> > > > Heya,
> > > >
> > > > We've been carrying a similar (but hard-coded) patch in Fedora for a
> > > > long while, and it would be nice if we could do this properly upstream
> > > > instead.
> > > >
> > > > Patch attached with explanations.
> > > >
> > > > Cheers
> > >
> > > What is the proper package to ship oui.txt file? Thanks a lot for the
> > > information :-)
> >
> > No idea. In Fedora we ship it in hwdata. No idea where it lives for
> > Debian-based distributions, or others.
> >
>
> OK, thanks, I asked it because under Gentoo no package is currently
> providing it and a user suggested to supply it with bluez... but I
> haven't made any decision about this yet
That's probably a good enough way to ship it. Various distributions seem
to have a different idea on where it should be.
^ permalink raw reply
* Re: [PATCH] Make the path to oui.txt a compile-time option
From: Pacho Ramos @ 2010-09-06 15:38 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1283786557.7529.26.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 462 bytes --]
El lun, 06-09-2010 a las 16:22 +0100, Bastien Nocera escribió:
> > OK, thanks, I asked it because under Gentoo no package is currently
> > providing it and a user suggested to supply it with bluez... but I
> > haven't made any decision about this yet
>
> That's probably a good enough way to ship it. Various distributions seem
> to have a different idea on where it should be.
>
Great, I will probably follow your recommendation, thanks a lot :-)
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Make the path to oui.txt a compile-time option
From: Johan Hedberg @ 2010-09-06 16:10 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1283784432.7529.24.camel@localhost.localdomain>
Hi Bastien,
On Mon, Sep 06, 2010, Bastien Nocera wrote:
> From b96d9394aa850be86ca368aeaeec3bc24c00bce1 Mon Sep 17 00:00:00 2001
> From: Bastien Nocera <hadess@hadess.net>
> Date: Mon, 6 Sep 2010 15:43:48 +0100
> Subject: [PATCH] Make the path to oui.txt a compile-time option
>
> This avoids bluetoothd trying to load oui.txt from multiple locations
> and cause SELinux AVC denials by accessing files it's not supposed
> to touch.
> ---
> acinclude.m4 | 8 ++++++++
> configure.ac | 1 +
> src/oui.c | 14 +++-----------
> 3 files changed, 12 insertions(+), 11 deletions(-)
Seems like a good idea. The patch is now upstream.
Johan
^ permalink raw reply
* Re: [PATCH v3] hciconfig: add LE_SET_ADVERTISE_ENABLE cmd
From: Johan Hedberg @ 2010-09-06 16:11 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <1283786296-16211-1-git-send-email-anderson.briglia@openbossa.org>
Hi Anderson,
On Mon, Sep 06, 2010, Anderson Briglia wrote:
> This patch implements two new hciconfig commands: leadv and noleadv.
> These new hciconfig flags are responsible to LE_SET_ADVERTISE_ENABLE
> command implementation.
> ---
> tools/hciconfig.c | 40 ++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 40 insertions(+), 0 deletions(-)
Thanks. The patch is now upstream.
Johan
^ permalink raw reply
* Re: Running "putkey" for keyboards and mice
From: Bastien Nocera @ 2010-09-06 16:42 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: BlueZ development
In-Reply-To: <1283775595.7529.21.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 691 bytes --]
On Mon, 2010-09-06 at 13:19 +0100, Bastien Nocera wrote:
<snip>
> Johan mentioned that we could implement this using a boolean property
> for whether to store the linkkey on the device or not. When TRUE, should
> we store the linkkey on both the device and on the local filesystem, or
> just on the device?
>
> hci_read_stored_link_key() is not currently used in the code at all, so
> it's possible that a device will be paired, but not marked as such in
> the interface.
I was wrongly reading the code, and it already does that.
Patch attached to add the "KeyOnAdapter" property to devices.
Note that I did not test this thoroughly yet. I'm more looking for
comments right now.
Cheers
[-- Attachment #2: 0001-Add-KeyOnAdapter-property-to-devices.patch --]
[-- Type: text/x-patch, Size: 9698 bytes --]
>From f387bbee64306db9096e28316160fe547388c6c3 Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Mon, 6 Sep 2010 17:21:30 +0100
Subject: [PATCH] Add KeyOnAdapter property to devices
The KeyOnAdapter property will be true if the linkkey comes from
the adapter storage, rather than the local filesystem storage.
This makes it possible for front-ends to add linkkeys to the
adapter itself for keyboard and mice to automatically work
when dual-booting under other OSes.
---
doc/device-api.txt | 16 ++++++++
plugins/hciops.c | 32 ++++++++++++++++
src/adapter.c | 22 +++++++++++
src/adapter.h | 6 +++
src/dbus-hci.c | 1 +
src/device.c | 106 ++++++++++++++++++++++++++++++++++++++++++++++++++++
src/device.h | 1 +
7 files changed, 184 insertions(+), 0 deletions(-)
diff --git a/doc/device-api.txt b/doc/device-api.txt
index b818299..c4f633b 100644
--- a/doc/device-api.txt
+++ b/doc/device-api.txt
@@ -161,6 +161,22 @@ Properties string Address [readonly]
drivers will also be removed and no new ones will
be probed as long as the device is blocked.
+ boolean KeyOnAdapter [readwrite]
+
+ Whether the linkkey for the device is available
+ on the adapter. This will be FALSE if the device
+ is not paired, or the key is not available on
+ the adapter (and just on the filesystem).
+
+ Setting this to TRUE, will write the key to the
+ adapter, returning an error if the adapter
+ does not support this.
+
+ Note that the key is not removed from the local
+ filesystem storage, as, once on the adapter, it
+ will lack linkkey type information, which is
+ required for Bluetooth 2.1 devices.
+
string Alias [readwrite]
The name alias for the remote device. The alias can
diff --git a/plugins/hciops.c b/plugins/hciops.c
index f1e9f69..0a87f3e 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -748,6 +748,36 @@ static int hciops_fast_connectable(int index, gboolean enable)
return err;
}
+static int hciops_put_key (int index, bdaddr_t bdaddr, uint8_t *key)
+{
+ int dd, err;
+
+ dd = hci_open_dev(index);
+ if (dd < 0)
+ return -EIO;
+
+ err = hci_write_stored_link_key(dd, &bdaddr, key, HCI_REQ_TIMEOUT);
+
+ hci_close_dev(dd);
+
+ return -err;
+}
+
+static int hciops_del_key (int index, bdaddr_t bdaddr)
+{
+ int dd, err;
+
+ dd = hci_open_dev(index);
+ if (dd < 0)
+ return -EIO;
+
+ err = hci_delete_stored_link_key(dd, &bdaddr, 0, HCI_REQ_TIMEOUT);
+
+ hci_close_dev(dd);
+
+ return -err;
+}
+
static struct btd_adapter_ops hci_ops = {
.setup = hciops_setup,
.cleanup = hciops_cleanup,
@@ -765,6 +795,8 @@ static struct btd_adapter_ops hci_ops = {
.read_name = hciops_read_name,
.set_class = hciops_set_class,
.set_fast_connectable = hciops_fast_connectable,
+ .put_key = hciops_put_key,
+ .del_key = hciops_del_key,
};
static int hciops_init(void)
diff --git a/src/adapter.c b/src/adapter.c
index fd4cf99..fcd8aae 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3519,3 +3519,25 @@ int btd_adapter_set_fast_connectable(struct btd_adapter *adapter,
return adapter_ops->set_fast_connectable(adapter->dev_id, enable);
}
+
+int btd_adapter_put_key (struct btd_adapter *adapter, bdaddr_t bdaddr, uint8_t *key)
+{
+ if (!adapter_ops)
+ return -EINVAL;
+
+ if (!adapter->up)
+ return -EINVAL;
+
+ return adapter_ops->put_key(adapter->dev_id, bdaddr, key);
+}
+
+int btd_adapter_del_key (struct btd_adapter *adapter, bdaddr_t bdaddr)
+{
+ if (!adapter_ops)
+ return -EINVAL;
+
+ if (!adapter->up)
+ return -EINVAL;
+
+ return adapter_ops->del_key(adapter->dev_id, bdaddr);
+}
diff --git a/src/adapter.h b/src/adapter.h
index fb52b34..86c9eb2 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -187,6 +187,8 @@ struct btd_adapter_ops {
int (*read_name) (int index);
int (*set_class) (int index, uint32_t class);
int (*set_fast_connectable) (int index, gboolean enable);
+ int (*put_key) (int index, bdaddr_t bdaddr, uint8_t *key);
+ int (*del_key) (int index, bdaddr_t bdaddr);
};
int btd_register_adapter_ops(struct btd_adapter_ops *btd_adapter_ops);
@@ -205,3 +207,7 @@ void btd_adapter_unregister_powered_callback(struct btd_adapter *adapter,
* type to default values. Valid for both connectable and discoverable modes. */
int btd_adapter_set_fast_connectable(struct btd_adapter *adapter,
gboolean enable);
+int btd_adapter_put_key (struct btd_adapter *adapter,
+ bdaddr_t bdaddr,
+ uint8_t *key);
+int btd_adapter_del_key (struct btd_adapter *adapter, bdaddr_t bdaddr);
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index 9055ffe..f266409 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -903,6 +903,7 @@ void hcid_dbus_returned_link_key(bdaddr_t *local, bdaddr_t *peer)
return;
device_set_paired(device, TRUE);
+ device_set_key_on_adapter(device, TRUE);
}
int hcid_dbus_get_io_cap(bdaddr_t *local, bdaddr_t *remote,
diff --git a/src/device.c b/src/device.c
index 9055eca..df89656 100644
--- a/src/device.c
+++ b/src/device.c
@@ -139,6 +139,7 @@ struct btd_device {
gboolean paired;
gboolean blocked;
gboolean renewed_key;
+ gboolean key_on_adapter;
gboolean authorizing;
gint ref;
@@ -256,6 +257,11 @@ gboolean device_is_paired(struct btd_device *device)
return device->paired;
}
+gboolean device_linkkey_is_on_adapter(struct btd_device *device)
+{
+ return device->key_on_adapter;
+}
+
gboolean device_is_trusted(struct btd_device *device)
{
return device->trusted;
@@ -329,6 +335,10 @@ static DBusMessage *get_properties(DBusConnection *conn,
boolean = device_is_paired(device);
dict_append_entry(&dict, "Paired", DBUS_TYPE_BOOLEAN, &boolean);
+ /* KeyOnAdapter */
+ boolean = device_linkkey_is_on_adapter(device);
+ dict_append_entry(&dict, "KeyOnAdapter", DBUS_TYPE_BOOLEAN, &boolean);
+
/* Trusted */
boolean = device_is_trusted(device);
dict_append_entry(&dict, "Trusted", DBUS_TYPE_BOOLEAN, &boolean);
@@ -570,6 +580,80 @@ static DBusMessage *set_blocked(DBusConnection *conn, DBusMessage *msg,
}
}
+static int device_put_key_on_adapter(DBusConnection *conn, struct btd_device *device)
+{
+ int err;
+ bdaddr_t src;
+ unsigned char linkkey[16];
+
+ if (device->key_on_adapter)
+ return 0;
+ if (!device->paired)
+ return 0;
+
+ adapter_get_address(device->adapter, &src);
+ if (read_link_key(&src, &device->bdaddr, linkkey, NULL) < 0)
+ return -ENOKEY;
+
+ err = btd_adapter_put_key(device->adapter, device->bdaddr, linkkey);
+ if (err < 0)
+ return -err;
+
+ device->key_on_adapter = TRUE;
+
+ emit_property_changed(conn, device->path, DEVICE_INTERFACE, "KeyOnAdapter",
+ DBUS_TYPE_BOOLEAN, &device->key_on_adapter);
+
+ return 0;
+}
+
+static int device_del_key_on_adapter(DBusConnection *conn, struct btd_device *device)
+{
+ int err;
+
+ if (!device->key_on_adapter)
+ return 0;
+
+ err = btd_adapter_del_key(device->adapter, device->bdaddr);
+ if (err < 0)
+ return err;
+
+ device->key_on_adapter = FALSE;
+
+ emit_property_changed(conn, device->path, DEVICE_INTERFACE, "KeyOnAdapter",
+ DBUS_TYPE_BOOLEAN, &device->key_on_adapter);
+
+ return 0;
+}
+
+static DBusMessage *set_key_on_adapter(DBusConnection *conn, DBusMessage *msg,
+ gboolean value, void *data)
+{
+ struct btd_device *device = data;
+ int err;
+
+ if (value)
+ err = device_put_key_on_adapter(conn, device);
+ else
+ err = device_del_key_on_adapter(conn, device);
+
+ switch (-err) {
+ case 0:
+ return dbus_message_new_method_return(msg);
+ case EINVAL:
+ return g_dbus_create_error(msg,
+ ERROR_INTERFACE ".NotSupported",
+ "Adapter lacks storage support");
+ case ENOKEY:
+ return g_dbus_create_error(msg,
+ ERROR_INTERFACE ".Failed",
+ "Device is paired but link key is not available");
+ default:
+ return g_dbus_create_error(msg, ERROR_INTERFACE ".Failed",
+ "%s", strerror(-err));
+ }
+}
+
static inline DBusMessage *invalid_args(DBusMessage *msg)
{
return g_dbus_create_error(msg, ERROR_INTERFACE ".InvalidArguments",
@@ -620,6 +704,15 @@ static DBusMessage *set_property(DBusConnection *conn,
dbus_message_iter_get_basic(&sub, &value);
return set_blocked(conn, msg, value, data);
+ } else if (g_str_equal("KeyOnAdapter", property)) {
+ dbus_bool_t value;
+
+ if (dbus_message_iter_get_arg_type(&sub) != DBUS_TYPE_BOOLEAN)
+ return invalid_args(msg);
+
+ dbus_message_iter_get_basic(&sub, &value);
+
+ return set_key_on_adapter(conn, msg, value, data);
}
return invalid_args(msg);
@@ -1836,6 +1929,19 @@ void device_set_paired(struct btd_device *device, gboolean value)
DBUS_TYPE_BOOLEAN, &value);
}
+void device_set_key_on_adapter(struct btd_device *device, gboolean value)
+{
+ DBusConnection *conn = get_dbus_connection();
+
+ if (device->key_on_adapter == value)
+ return;
+
+ device->key_on_adapter = value;
+
+ emit_property_changed(conn, device->path, DEVICE_INTERFACE, "KeyOnAdapter",
+ DBUS_TYPE_BOOLEAN, &value);
+}
+
static void device_agent_removed(struct agent *agent, void *user_data)
{
struct btd_device *device = user_data;
diff --git a/src/device.h b/src/device.h
index 21f67d0..6f57b37 100644
--- a/src/device.h
+++ b/src/device.h
@@ -55,6 +55,7 @@ gboolean device_is_temporary(struct btd_device *device);
gboolean device_is_paired(struct btd_device *device);
gboolean device_is_trusted(struct btd_device *device);
void device_set_paired(struct btd_device *device, gboolean paired);
+void device_set_key_on_adapter(struct btd_device *device, gboolean key_on_adapter);
void device_set_temporary(struct btd_device *device, gboolean temporary);
void device_set_cap(struct btd_device *device, uint8_t cap);
uint8_t device_get_cap(struct btd_device *device);
--
1.7.0.1
^ permalink raw reply related
* [RFC] Sim Access Profile API doc
From: Suraj Sumangala @ 2010-09-07 6:02 UTC (permalink / raw)
To: linux-bluetooth
Cc: Jothikumar.Mothilal, joakim.xj.ceder, claudio.takahasi,
Waldemar.Rymarkiewicz, Arkadiusz.Lichwa, Suraj Sumangala
This RFC proposes the interface exposed by
Sim Access Profile Server role.
Please let me know your comments.
---
doc/sap-api.txt | 197 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 197 insertions(+), 0 deletions(-)
create mode 100644 doc/sap-api.txt
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..719cff6
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,197 @@
+BlueZ D-Bus Adapter API description
+***********************************
+
+Copyright (C) 2009-2010 Atheros Communication Ltd
+
+
+Sim Access Server hierarchy
+===========================
+
+Service org.bluez
+Interface org.bluez.SimAccessServer
+Object path [variable prefix]/{hci0,hci1,...}
+
+This interface is available for devices which can function in the
+Server role of the Sim Access profiles.
+It is intended to be used with external stacks / handlers of the Sim Access
+protocol.
+
+
+Methods void RegisterAgent(object agent)
+
+ This registers the Sim Access adapter agent.
+ This also registers the profile with the service
+ Databse and start waiting for an RFCOMM connection
+ on the SAP server channel.
+
+ The object path defines the path the of the agent.
+
+ If an application disconnects from the bus all
+ of its registered agents will be removed.
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.AlreadyExists
+ org.bluez.Error.Failed
+
+ void UnregisterAgent(object agent)
+
+ This unregisters the agent that has been previously
+ registered. The object path parameter must match the
+ same value that has been used on registration.
+
+ Possible errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Response(string command, string result, object response)
+
+ This sends a response to a received SAP command.
+
+ The command parameter specifies the SAP command for
+ which response has to be sent.
+
+ The result parameter specifies the ResultCode for the
+ operation.
+
+ The object response specifies the response packet to
+ be sent if any.
+
+ Below mentioned are the parameters and possible value.
+
+ command result response
+ ----------------------------------------------------
+
+ Connect OkSuccess NA
+ ConnectFailed
+ OkOngoingCall
+
+ APDU OkSuccess array{uint8}
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ APDU7816 OkSuccess array{uint8}
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ ATR OkSuccess array{uint8}
+ NoReason
+ CardPoweredOff
+ CardRemoved
+ DataNotAvailable
+
+ SimPowerOn OkSuccess NA
+ NoReason
+ CardNotAccessible
+ CardRemoved
+ CardPoweredOn
+
+ SimPowerOff OkSuccess NA
+ NoReason
+ CardPoweredOff
+ CardRemoved
+
+ Reset OkSuccess NA
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ CardReaderStatus OkSuccess uint8
+ NoReason
+ DataNotAvailable
+
+ TransportProtocol OkSuccess NA
+ NotSupported
+
+ Disconnect NA NA
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Disconnect(string type)
+
+ This initiates a SAP disconnection from SAP server.
+
+ The type parameter specifies the type of disconnection.
+
+ "Graceful" -> lets the SAP client initiate a
+ garceful disconnection.
+
+ "Immediate" -> disconnects the connection
+ immediately from the server.
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed a read-write are changeable.
+ On success this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+
+ dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+Signals Request(string command, variant value)
+
+ This signal indicates a SAP command received from
+ SAP client.
+
+ The command parameter specifies the SAP command
+ received.
+
+ The value parameter specifies the command parameter
+ packet received from SAP client.
+
+ Below mentioned is the parameters and possible value.
+
+ command value
+ ----------------------------------------------------
+
+ Connect NA
+ APDU Aarray{uint8}
+ APDU7816 Aarray{uint8}
+ ATR NA
+ SimPowerOn NA
+ SimPowerOff NA
+ Reset NA
+ CardReaderStatus NA
+ TransportProtocol uint8
+ Disconnect NA
+
+ PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string SimStatus [readwrite]
+
+ Specifies the availability of the SIM.
+
+ The possible value are
+
+ "UnknownError"
+ "CardReset"
+ "CardNotAccesible"
+ "CardRemoved"
+ "CardInsterted"
+ "CardRecovered"
+
+ uint16 MaxMessageSize [readwrite]
+
+ The maximum possible message size supported by
+ SAP server.
+
+ uint16 MessageSize [readonly]
+
+ The negotiated message size for the current connection.
+ This is valid only when there is an active
+ SAP connection.
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] Sim Access Profile API doc
From: Uwe Kleine-König @ 2010-09-07 7:47 UTC (permalink / raw)
To: Suraj Sumangala
Cc: linux-bluetooth, Jothikumar.Mothilal, joakim.xj.ceder,
claudio.takahasi, Waldemar.Rymarkiewicz, Arkadiusz.Lichwa
In-Reply-To: <1283839375-20033-1-git-send-email-suraj@atheros.com>
Hello Suraj,
I don't know much about sim or bluetooth in general, so only a few minor
comments below.
On Tue, Sep 07, 2010 at 11:32:55AM +0530, Suraj Sumangala wrote:
> This RFC proposes the interface exposed by
> Sim Access Profile Server role.
>
> Please let me know your comments.
>
> ---
> doc/sap-api.txt | 197 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 197 insertions(+), 0 deletions(-)
> create mode 100644 doc/sap-api.txt
>
> diff --git a/doc/sap-api.txt b/doc/sap-api.txt
> new file mode 100644
> index 0000000..719cff6
> --- /dev/null
> +++ b/doc/sap-api.txt
> @@ -0,0 +1,197 @@
> +BlueZ D-Bus Adapter API description
this is a copy&paste leftover?
> +***********************************
> +
> +Copyright (C) 2009-2010 Atheros Communication Ltd
> +
> +
> +Sim Access Server hierarchy
> +===========================
> +
> +Service org.bluez
> +Interface org.bluez.SimAccessServer
> +Object path [variable prefix]/{hci0,hci1,...}
> +
> +This interface is available for devices which can function in the
> +Server role of the Sim Access profiles.
> +It is intended to be used with external stacks / handlers of the Sim Access
> +protocol.
> +
> +
> +Methods void RegisterAgent(object agent)
> +
> + This registers the Sim Access adapter agent.
> + This also registers the profile with the service
> + Databse and start waiting for an RFCOMM connection
s/Databse/database/ (not sure about capitalization)
> + on the SAP server channel.
> +
> + The object path defines the path the of the agent.
> +
> + If an application disconnects from the bus all
> + of its registered agents will be removed.
> +
> + Possible errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.AlreadyExists
> + org.bluez.Error.Failed
> +
> + void UnregisterAgent(object agent)
> +
> + This unregisters the agent that has been previously
> + registered. The object path parameter must match the
> + same value that has been used on registration.
> +
> + Possible errors: org.bluez.Error.DoesNotExist
> + org.bluez.Error.InvalidArguments
> + org.bluez.Error.Failed
> +
> + void Response(string command, string result, object response)
> +
> + This sends a response to a received SAP command.
> +
> + The command parameter specifies the SAP command for
> + which response has to be sent.
> +
> + The result parameter specifies the ResultCode for the
> + operation.
> +
> + The object response specifies the response packet to
> + be sent if any.
> +
> + Below mentioned are the parameters and possible value.
> +
> + command result response
> + ----------------------------------------------------
> +
> + Connect OkSuccess NA
> + ConnectFailed
> + OkOngoingCall
> +
> + APDU OkSuccess array{uint8}
> + NoReason
> + CardNotAccessible
> + CardPoweredOff
> + CardRemoved
> +
> + APDU7816 OkSuccess array{uint8}
> + NoReason
> + CardNotAccessible
> + CardPoweredOff
> + CardRemoved
> +
> + ATR OkSuccess array{uint8}
> + NoReason
> + CardPoweredOff
> + CardRemoved
> + DataNotAvailable
> +
> + SimPowerOn OkSuccess NA
> + NoReason
> + CardNotAccessible
> + CardRemoved
> + CardPoweredOn
> +
> + SimPowerOff OkSuccess NA
> + NoReason
> + CardPoweredOff
> + CardRemoved
> +
> + Reset OkSuccess NA
> + NoReason
> + CardNotAccessible
> + CardPoweredOff
> + CardRemoved
> +
> + CardReaderStatus OkSuccess uint8
> + NoReason
> + DataNotAvailable
> +
> + TransportProtocol OkSuccess NA
> + NotSupported
> +
> + Disconnect NA NA
> +
> + Possible errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.Failed
> +
> + void Disconnect(string type)
> +
> + This initiates a SAP disconnection from SAP server.
> +
> + The type parameter specifies the type of disconnection.
> +
> + "Graceful" -> lets the SAP client initiate a
> + garceful disconnection.
> +
> + "Immediate" -> disconnects the connection
> + immediately from the server.
> +
> + void SetProperty(string name, variant value)
> +
> + Changes the value of the specified property. Only
> + properties that are listed a read-write are changeable.
> + On success this will emit a PropertyChanged signal.
> +
> + Possible Errors: org.bluez.Error.DoesNotExist
> + org.bluez.Error.InvalidArguments
> +
> + dict GetProperties()
> +
> + Returns all properties for the interface. See the
> + properties section for available properties.
> +
> + Possible Errors: org.bluez.Error.InvalidArguments
> +
> +Signals Request(string command, variant value)
> +
> + This signal indicates a SAP command received from
> + SAP client.
> +
> + The command parameter specifies the SAP command
> + received.
> +
> + The value parameter specifies the command parameter
> + packet received from SAP client.
> +
> + Below mentioned is the parameters and possible value.
> +
> + command value
> + ----------------------------------------------------
> +
> + Connect NA
> + APDU Aarray{uint8}
> + APDU7816 Aarray{uint8}
> + ATR NA
> + SimPowerOn NA
> + SimPowerOff NA
> + Reset NA
> + CardReaderStatus NA
> + TransportProtocol uint8
> + Disconnect NA
> +
> + PropertyChanged(string name, variant value)
> +
> + This signal indicates a changed value of the given
> + property.
> +
> +Properties string SimStatus [readwrite]
> +
> + Specifies the availability of the SIM.
> +
> + The possible value are
> +
> + "UnknownError"
> + "CardReset"
> + "CardNotAccesible"
> + "CardRemoved"
> + "CardInsterted"
> + "CardRecovered"
> +
> + uint16 MaxMessageSize [readwrite]
> +
> + The maximum possible message size supported by
> + SAP server.
> +
> + uint16 MessageSize [readonly]
> +
> + The negotiated message size for the current connection.
> + This is valid only when there is an active
> + SAP connection.
and you might want to add your file to EXTRA_DIST in Makefile.am.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* RE: [RFC] Sim Access Profile API doc
From: Waldemar.Rymarkiewicz @ 2010-09-07 8:36 UTC (permalink / raw)
To: suraj, linux-bluetooth
Cc: Jothikumar.Mothilal, joakim.xj.ceder, claudio.takahasi,
Arkadiusz.Lichwa
In-Reply-To: <1283839375-20033-1-git-send-email-suraj@atheros.com>
Hi Suraj,
>From: Suraj Sumangala [mailto:suraj@atheros.com]
>Sent: Tuesday, September 07, 2010 8:03 AM
>+
>+ void Disconnect(string type)
>+
>+ This initiates a SAP disconnection from
>SAP server.
>+
>+ The type parameter specifies the type
>of disconnection.
>+
>+ "Graceful" -> lets the SAP client initiate a
>+ garceful disconnection.
>+
>+ "Immediate" -> disconnects the connection
>+ immediately from the server.
>+
In my view, the disconnection should be initiates by the sap server, not by the agent. In a typical use case the agent will communicate sim state change (card removed or not accessible) to sap server. Based on that, the sap server should make a decision whether disconnect or not. What's more the disconnect procedure is defined in the SAP spec, and would be nice to keep all those procedures in the sap server, not in the agent which will be specific for a sim provider. Therefore, I would remove this method call from the api. I would add the Disconnect signal instead.
Signal:
Disconnect()
This signal will be send when SAP connectionis successfully removed.
In case of graceful disconnection sap server sends signal to the agent REQUEST(disconnect) and wait till SIM free its stuff and send back RESPONSE(disconnect). In case of immediate disconnection sap server will send Disconnect() signal to the agent.
Thanks,
/Waldek
^ permalink raw reply
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-09-07 8:57 UTC (permalink / raw)
To: johan.hedberg, marcel
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <20100902135108.GA30759@jh-x301>
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
Hi Johan,
>-----Original Message-----
>From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
>Sent: Thursday, September 02, 2010 3:51 PM
>> I attached slightly updated patches.
>Thanks. However, the kernel patch and new ioctl will need
>comments at least from Marcel. Once we add an ioctl we're
>stuck with it for quite some time and have to maintain it, no
>matter what kind of newer/better kernel-userspace interfaces
>we come up with. So the choice of accepting a new ioctl isn't so easy.
Then, wait for Marcel's comment.
>One thing that you'd definitely need to fix in your patches is
>to keep at least the same level of support that the current
>BlueZ has with kernels that don't have the new ioctl. Right
>now your patch would make legacy pairing fail in such cases
>which is not acceptable. Only with a major version change
>(5.x) would it be possible to consider requiring a newer
>kernel version in order to have essential functionality in place.
I updated the bluez patch. Now paring will not fail due to not compatible kernel api.
Regards,
/Waldek
[-- Attachment #2: 0001-BT_SECURITY_HIGH-requires-16-digit-pin-code.patch --]
[-- Type: application/octet-stream, Size: 6664 bytes --]
From 2433903023f6e99cc5b1d800f71a7431048a23ee Mon Sep 17 00:00:00 2001
From: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Date: Mon, 21 Jun 2010 18:53:51 +0200
Subject: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
The security level BT_SECURITY_HIGH expects secure connection
and a minimum 16 digit pin code used for bonding. It's required by the
Sim Access Profile.
Patch on behalf of ST-Ericsson SA.
---
lib/hci.h | 8 +++++++-
src/dbus-hci.c | 38 +++++++++++++++++++++++++++++++++-----
src/security.c | 54 ++++++++++++++++++++++++++++++++++++++++++++++--------
3 files changed, 86 insertions(+), 14 deletions(-)
diff --git a/lib/hci.h b/lib/hci.h
index 512dab9..a313929 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -96,7 +96,7 @@ enum {
#define HCISETLINKMODE _IOW('H', 226, int)
#define HCISETACLMTU _IOW('H', 227, int)
#define HCISETSCOMTU _IOW('H', 228, int)
-
+#define HCISETCONNINFO _IOW('H', 229, int)
#define HCIBLOCKADDR _IOW('H', 230, int)
#define HCIUNBLOCKADDR _IOW('H', 231, int)
@@ -2326,9 +2326,15 @@ struct hci_conn_info_req {
struct hci_conn_info conn_info[0];
};
+struct hci_set_conn_info_req {
+ bdaddr_t bdaddr;
+ uint8_t pin_len;
+ uint8_t key_type;
+};
struct hci_auth_info_req {
bdaddr_t bdaddr;
uint8_t type;
+ uint8_t level;
};
struct hci_inquiry_req {
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
index 9055ffe..fe90337 100644
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -165,9 +165,12 @@ static void pincode_cb(struct agent *agent, DBusError *err,
{
struct btd_adapter *adapter = device_get_adapter(device);
pin_code_reply_cp pr;
+ struct hci_auth_info_req ar;
+ struct hci_set_conn_info_req cr;
bdaddr_t sba, dba;
size_t len;
int dev;
+ int ret;
uint16_t dev_id = adapter_get_dev_id(adapter);
dev = hci_open_dev(dev_id);
@@ -180,13 +183,34 @@ static void pincode_cb(struct agent *agent, DBusError *err,
adapter_get_address(adapter, &sba);
device_get_address(device, &dba);
- if (err) {
- hci_send_cmd(dev, OGF_LINK_CTL,
- OCF_PIN_CODE_NEG_REPLY, 6, &dba);
- goto done;
- }
+ if (err)
+ goto reject;
len = strlen(pincode);
+ memset(&ar, 0, sizeof(ar));
+ bacpy(&ar.bdaddr, &dba);
+ ar.level = BT_SECURITY_LOW;
+
+ ret = ioctl(dev, HCIGETAUTHINFO, (unsigned long) &ar);
+ if (ret < 0 && errno != EINVAL) {
+ error("Can't get auth info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
+
+ if (ar.level == BT_SECURITY_HIGH && len < 16) {
+ error("PIN code is not a 16 digit (%d)", len);
+ goto reject;
+ }
+
+ bacpy(&cr.bdaddr, &dba);
+ cr.pin_len = len;
+ cr.key_type = 0xff;
+
+ ret = ioctl(dev, HCISETCONNINFO, (unsigned long) &cr);
+ if (ret < 0 && errno != EINVAL) {
+ error("Can't set conn info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
set_pin_length(&sba, len);
@@ -196,7 +220,11 @@ static void pincode_cb(struct agent *agent, DBusError *err,
pr.pin_len = len;
hci_send_cmd(dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
PIN_CODE_REPLY_CP_SIZE, &pr);
+ goto done;
+reject:
+ hci_send_cmd(dev, OGF_LINK_CTL,
+ OCF_PIN_CODE_NEG_REPLY, 6, &dba);
done:
hci_close_dev(dev);
}
diff --git a/src/security.c b/src/security.c
index 667f1f1..5ede6f6 100644
--- a/src/security.c
+++ b/src/security.c
@@ -309,6 +309,7 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
char sa[18], da[18];
uint8_t type;
int err;
+ int pinlen;
if (!get_adapter_and_device(sba, dba, &adapter, &device, FALSE))
device = NULL;
@@ -318,16 +319,18 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
memset(&req, 0, sizeof(req));
bacpy(&req.bdaddr, dba);
+ req.type = 0x00;
+ /* Set low security in case when kernel does not support 16 digit
+ pin code in the high security level */
+ req.level = BT_SECURITY_LOW;
err = ioctl(dev, HCIGETAUTHINFO, (unsigned long) &req);
- if (err < 0) {
- if (errno != EINVAL)
- DBG("HCIGETAUTHINFO failed %s (%d)",
+ if (err < 0 && errno != EINVAL)
+ DBG("HCIGETAUTHINFO failed %s (%d)",
strerror(errno), errno);
- req.type = 0x00;
- }
- DBG("kernel auth requirements = 0x%02x", req.type);
+ DBG("kernel auth requirements = 0x%02x and security level = 0x%02x", \
+ req.type, req.level);
if (main_opts.debug_keys && device && device_get_debug_key(device, key))
type = 0x03;
@@ -341,17 +344,37 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
DBG("link key type = 0x%02x", type);
+ pinlen = read_pin_length(sba, dba);
+ DBG("stored link key type = 0x%02x pin_len = %d", type, pinlen);
+
/* Don't use unauthenticated combination keys if MITM is
- * required */
- if (type == 0x04 && req.type != 0xff && (req.type & 0x01))
+ * required and also don't use combination link keys authenticated
+ * with the PIN code len < 16 if security level BT_SECURITY_HIGH
+ * is required */
+ if ((type == 0x04 && req.type != 0xff && (req.type & 0x01)) ||
+ (type == 0x00 && req.level == BT_SECURITY_HIGH && pinlen < 16))
hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY,
6, dba);
else {
link_key_reply_cp lr;
+ struct hci_set_conn_info_req cr;
memcpy(lr.link_key, key, 16);
bacpy(&lr.bdaddr, dba);
+ bacpy(&cr.bdaddr, dba);
+ cr.pin_len = pinlen;
+ cr.key_type = type;
+
+ err = ioctl(dev, HCISETCONNINFO, (unsigned long) &cr);
+ if (err < 0 && errno != EINVAL) {
+ error("Can't set conn info: %s (%d)", strerror(errno),
+ errno);
+ hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY,
+ 6, dba);
+ return;
+ }
+
hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_REPLY,
LINK_KEY_REPLY_CP_SIZE, &lr);
}
@@ -523,8 +546,10 @@ static void pin_code_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
pin_code_reply_cp pr;
struct hci_conn_info_req *cr;
struct hci_conn_info *ci;
+ struct hci_auth_info_req ar;
char sa[18], da[18], pin[17];
int pinlen;
+ int err;
memset(&pr, 0, sizeof(pr));
bacpy(&pr.bdaddr, dba);
@@ -542,10 +567,23 @@ static void pin_code_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
}
ci = cr->conn_info;
+ memset(&ar, 0, sizeof(ar));
+ bacpy(&ar.bdaddr, dba);
+ ar.level = BT_SECURITY_LOW;
+
+ err = ioctl(dev, HCIGETAUTHINFO, (unsigned long) &ar);
+ if (err < 0 && errno != EINVAL) {
+ error("Can't get auth info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
memset(pin, 0, sizeof(pin));
pinlen = read_pin_code(sba, dba, pin);
if (pinlen > 0) {
+ if (ar.level == BT_SECURITY_HIGH && pinlen < 16) {
+ error("Not 16 digit pin code.");
+ goto reject;
+ }
set_pin_length(sba, pinlen);
memcpy(pr.pin_code, pin, pinlen);
pr.pin_len = pinlen;
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 0/3] Bluetooth: L2CAP robustness fixes
From: Emeltchenko Andrei @ 2010-09-07 8:57 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Fixes increase L2CAP robustness to DOS attacks to BT stack.
Andrei Emeltchenko (3):
Bluetooth: fix MTU L2CAP configuration parameter
Bluetooth: check for l2cap header in start fragment
Bluetooth: check L2CAP length in first ACL fragment
net/bluetooth/l2cap.c | 25 +++++++++++++++++++++----
1 files changed, 21 insertions(+), 4 deletions(-)
^ permalink raw reply
* [PATCHv2 1/3] Bluetooth: fix MTU L2CAP configuration parameter
From: Emeltchenko Andrei @ 2010-09-07 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1283849867-916-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
When receiving L2CAP negative configuration response with respect
to MTU parameter we modify wrong field. MTU here means proposed
value of MTU that the remote device intends to transmit. So for local
L2CAP socket it is pi->imtu.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index c784703..9fad312 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2771,10 +2771,10 @@ static int l2cap_parse_conf_rsp(struct sock *sk, void *rsp, int len, void *data,
case L2CAP_CONF_MTU:
if (val < L2CAP_DEFAULT_MIN_MTU) {
*result = L2CAP_CONF_UNACCEPT;
- pi->omtu = L2CAP_DEFAULT_MIN_MTU;
+ pi->imtu = L2CAP_DEFAULT_MIN_MTU;
} else
- pi->omtu = val;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->omtu);
+ pi->imtu = val;
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
break;
case L2CAP_CONF_FLUSH_TO:
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 2/3] Bluetooth: check for l2cap header in start fragment
From: Emeltchenko Andrei @ 2010-09-07 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1283849867-916-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] page 36 mentioned
"Note: Start Fragments always begin with the Basic L2CAP header
of a PDU."
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9fad312..774e134 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4664,7 +4664,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
l2cap_conn_unreliable(conn, ECOMM);
}
- if (skb->len < 2) {
+ if (skb->len < L2CAP_HDR_SIZE) {
BT_ERR("Frame is too short (len %d)", skb->len);
l2cap_conn_unreliable(conn, ECOMM);
goto drop;
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 3/3] Bluetooth: check L2CAP length in first ACL fragment
From: Emeltchenko Andrei @ 2010-09-07 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1283849867-916-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Current Bluetooth code assembles fragments of big L2CAP packets
in l2cap_recv_acldata and then checks allowed L2CAP size in
assemled L2CAP packet (pi->imtu < skb->len).
The patch moves allowed L2CAP size check to the early stage when
we receive the first fragment of L2CAP packet. We do not need to
reserve and keep L2CAP fragments for bad packets.
Trace below is received when using stress tools sending big
fragmented L2CAP packets.
...
[ 1712.798492] swapper: page allocation failure. order:4, mode:0x4020
[ 1712.804809] [<c0031870>] (unwind_backtrace+0x0/0xdc) from [<c00a1f70>]
(__alloc_pages_nodemask+0x4)
[ 1712.814666] [<c00a1f70>] (__alloc_pages_nodemask+0x47c/0x4d4) from
[<c00a1fd8>] (__get_free_pages+)
[ 1712.824645] [<c00a1fd8>] (__get_free_pages+0x10/0x3c) from [<c026eb5c>]
(__alloc_skb+0x4c/0xfc)
[ 1712.833465] [<c026eb5c>] (__alloc_skb+0x4c/0xfc) from [<bf28c738>]
(l2cap_recv_acldata+0xf0/0x1f8 )
[ 1712.843322] [<bf28c738>] (l2cap_recv_acldata+0xf0/0x1f8 [l2cap]) from
[<bf0094ac>] (hci_rx_task+0x)
...
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 774e134..5adbaf8 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4654,6 +4654,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
if (flags & ACL_START) {
struct l2cap_hdr *hdr;
+ struct sock *sk;
+ u16 cid;
int len;
if (conn->rx_len) {
@@ -4672,6 +4674,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
hdr = (struct l2cap_hdr *) skb->data;
len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
+ cid = __le16_to_cpu(hdr->cid);
if (len == skb->len) {
/* Complete frame received */
@@ -4688,6 +4691,20 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
goto drop;
}
+ sk = l2cap_get_chan_by_scid(&conn->chan_list, cid);
+ if (!sk)
+ goto drop;
+
+ if (l2cap_pi(sk)->imtu < len) {
+ BT_ERR("Frame exceeding recv MTU (len %d, MTU %d)",
+ len, l2cap_pi(sk)->imtu);
+ conn->rx_len = 0; /* needed? */
+ bh_unlock_sock(sk);
+ goto drop;
+ }
+
+ bh_unlock_sock(sk);
+
/* Allocate skb for the complete frame (with header) */
conn->rx_skb = bt_skb_alloc(len, GFP_ATOMIC);
if (!conn->rx_skb)
--
1.7.0.4
^ permalink raw reply related
* RE: [PATCH] Fix clean-local target
From: Waldemar.Rymarkiewicz @ 2010-09-07 9:09 UTC (permalink / raw)
To: u.kleine-koenig, johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100903191937.GA29821@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1371 bytes --]
Uwe,
There is no intention behind that. Have updated the patch.
@Johan: Will you consider to push it to upstream ?
/Waldek
>-----Original Message-----
>From: Uwe Kleine-König [mailto:u.kleine-koenig@pengutronix.de]
>Sent: Friday, September 03, 2010 9:20 PM
>To: Rymarkiewicz Waldemar
>Cc: linux-bluetooth@vger.kernel.org
>Subject: Re: [PATCH] Fix clean-local target
>
>Hello Waldemar,
>
>On Fri, Sep 03, 2010 at 01:33:33PM +0200, Waldemar Rymarkiewicz wrote:
>> The fix avoids failure of the second consequent call of 'make clean'.
>>
>> Signed-off-by: Waldemar Rymarkiewicz
><waldemar.rymarkiewicz@tieto.com>
>> ---
>> Makefile.am | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Makefile.am b/Makefile.am index 5684e99..2fa03e1 100644
>> --- a/Makefile.am
>> +++ b/Makefile.am
>> @@ -385,5 +385,5 @@ lib/bluetooth/%.h: lib/%.h
>> $(AM_V_at)$(MKDIR_P) lib/bluetooth
>> $(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
>>
>> -clean-local: lib/bluetooth
>> - @$(RM) -r $<
>> +clean-local:
>> + $(RM) -r lib/bluetooth
>> \ No newline at end of file
>Is the missing newline at eof on purpose?
>
>Best regards
>Uwe
>
>--
>Pengutronix e.K. | Uwe Kleine-König
> |
>Industrial Linux Solutions |
>http://www.pengutronix.de/ |
>
[-- Attachment #2: 0001-Fix-clean-local-target.patch --]
[-- Type: application/octet-stream, Size: 695 bytes --]
From 56b93956070d45e3f70ba0579a44d757a3ba994b Mon Sep 17 00:00:00 2001
From: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
Date: Fri, 3 Sep 2010 13:20:08 +0200
Subject: [PATCH] Fix clean-local target
The fix avoids failure of the second consequent call of 'make clean'.
---
Makefile.am | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 9a78780..49815af 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -403,5 +403,6 @@ lib/bluetooth/%.h: lib/%.h
$(AM_V_at)$(MKDIR_P) lib/bluetooth
$(AM_V_GEN)$(LN_S) $(abs_top_srcdir)/$< $@
-clean-local: lib/bluetooth
- @$(RM) -r $<
+clean-local:
+ $(RM) -r lib/bluetooth
+
--
1.7.0.4
^ permalink raw reply related
* [PATCHv2 2/3] Bluetooth: check for l2cap header in start fragment
From: Emeltchenko Andrei @ 2010-09-07 9:12 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] page 36 mentioned
"Note: Start Fragments always begin with the Basic L2CAP header
of a PDU."
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9fad312..774e134 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4664,7 +4664,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
l2cap_conn_unreliable(conn, ECOMM);
}
- if (skb->len < 2) {
+ if (skb->len < L2CAP_HDR_SIZE) {
BT_ERR("Frame is too short (len %d)", skb->len);
l2cap_conn_unreliable(conn, ECOMM);
goto drop;
--
1.7.0.4
^ permalink raw reply related
* Re: [RFC] Sim Access Profile API doc
From: Suraj Sumangala @ 2010-09-07 9:28 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz@tieto.com
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal, joakim.xj.ceder@stericsson.com,
claudio.takahasi@gmail.com, Arkadiusz.Lichwa@tieto.com
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480979581239@EXMB04.eu.tieto.com>
Hi Waldek,
On 9/7/2010 2:06 PM, Waldemar.Rymarkiewicz@tieto.com wrote:
> Hi Suraj,
>
>> From: Suraj Sumangala [mailto:suraj@atheros.com]
>> Sent: Tuesday, September 07, 2010 8:03 AM
>
>> +
>> + void Disconnect(string type)
>> +
>> + This initiates a SAP disconnection from
>> SAP server.
>> +
>> + The type parameter specifies the type
>> of disconnection.
>> +
>> + "Graceful" -> lets the SAP client initiate a
>> + garceful disconnection.
>> +
>> + "Immediate" -> disconnects the connection
>> + immediately from the server.
>> +
>
> In my view, the disconnection should be initiates by the sap server, not by the agent. In a typical use case the agent will communicate sim state change (card removed or not accessible) to sap server. Based on that, the sap server should make a decision whether disconnect or not. What's more the disconnect procedure is defined in the SAP spec, and would be nice to keep all those procedures in the sap server, not in the agent which will be specific for a sim provider. Therefore, I would remove this method call from the api. I would add the Disconnect signal instead.
>
> Signal:
> Disconnect()
> This signal will be send when SAP connectionis successfully removed.
>
> In case of graceful disconnection sap server sends signal to the agent REQUEST(disconnect) and wait till SIM free its stuff and send back RESPONSE(disconnect). In case of immediate disconnection sap server will send Disconnect() signal to the agent.
Ok, In which all situations should the SAP server decide that the SAP
connection has to be disconnected (you have mentioned Sim Status change
as one candidate)?
Also, based on what should the server decide to initiate a "Graceful" or
"Immediate" disconnection?
>
> Thanks,
> /Waldek
Regards
Suraj
^ permalink raw reply
* Re: [RFC] Sim Access Profile API doc
From: Johan Hedberg @ 2010-09-07 9:29 UTC (permalink / raw)
To: Suraj Sumangala
Cc: linux-bluetooth, Jothikumar.Mothilal, joakim.xj.ceder,
claudio.takahasi, Waldemar.Rymarkiewicz, Arkadiusz.Lichwa
In-Reply-To: <1283839375-20033-1-git-send-email-suraj@atheros.com>
Hi Suraj,
On Tue, Sep 07, 2010, Suraj Sumangala wrote:
> +Methods void RegisterAgent(object agent)
> +
> + This registers the Sim Access adapter agent.
> + This also registers the profile with the service
> + Databse and start waiting for an RFCOMM connection
> + on the SAP server channel.
> +
> + The object path defines the path the of the agent.
> +
> + If an application disconnects from the bus all
> + of its registered agents will be removed.
> +
> + Possible errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.AlreadyExists
> + org.bluez.Error.Failed
> +
> + void UnregisterAgent(object agent)
> +
> + This unregisters the agent that has been previously
> + registered. The object path parameter must match the
> + same value that has been used on registration.
> +
> + Possible errors: org.bluez.Error.DoesNotExist
> + org.bluez.Error.InvalidArguments
> + org.bluez.Error.Failed
So you have these nice agent registration methods, however where's the
definition of the agent interface? And if you're going to use an agent
for this (which seems like a good idea) the SAP commands should map to
D-Bus method calls to the agent and the D-Bus method replies from the
agent should map to the SAP replies. I.e. please get rid of the D-Bus
signals and methods you currently have for this.
Btw, I'm not 100% convinced that this is the most sensible architecture
for implementing SAP, but assuming that it is the above comments apply
:)
Johan
^ permalink raw reply
* Re: [PATCH] Fix clean-local target
From: Johan Hedberg @ 2010-09-07 9:47 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: u.kleine-koenig, linux-bluetooth
In-Reply-To: <99B09243E1A5DA4898CDD8B700111448097958128E@EXMB04.eu.tieto.com>
Hi Waldek,
On Tue, Sep 07, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> @Johan: Will you consider to push it to upstream ?
Yes, it's now upstream. I was waiting for a comment from Marcel since he
quite often has something to say about autotools file changes, but since
the patch seems quite trivial I went ahead and pushed it.
Johan
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox