* Re: [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search
From: Szymon Janc @ 2014-02-12 12:17 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org
In-Reply-To: <CAJdJm_P3caDzXXttQUvkoeo3pSaWaiuJ4G0B1gbwfw0uwfDD3A@mail.gmail.com>
Hi Anderson,
On Wednesday 12 of February 2014 07:28:24 Anderson Lizardo wrote:
> Hi Szymon,
>
> On Wed, Feb 12, 2014 at 6:59 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
> >> Applied all except 6/7, I think we should probably return an error if
> >> there is an attempt to register a service out of range, then the
> >> caller can assert so we can have a proper test for it that expect an
> >> error in such case.
> >
> > Well, currently IPC depends on hal-msg.h which defines max allowed service
> > ID and using something bigger is a code bug. We could have make IPC
> > independent of hal-msg.h and just verify registered ID in runtime but
> > that would add extra code for each caller with no profit as IDs are fixed
> > anyway.
>
> Personally, I don't have strong opinions on using assert() versus
> raise(SIGTERM) (which is how runtime error conditions seem to be
> handled). Initially I went with raise(SIGTERM), but then I noticed the
> IDs are statically defined, and there is no way to give a invalid ID
> to ipc_register(), unless due to programming error (for which
> assert() is ideal, due to low overhead and no introduction of dead
> code).
>
> That said, this patch is not critical, but only a check so future
> users of ipc_register() don't reintroduce a similar crash fixed by the
> other commit.
>
> > That test fix is invalid as we actually want to test if IPC handles
> > out-of-
> > bound service ID correctly (when receiving register command).
> > And I'm not sure why this actually was causing any problems since that
> > test is not registering handlers for out-of-bound service ID, just sends
> > ipc message with such ID.
>
> I forgot to clarify this on the commit message: the "out of bound"
> service ID is still passed on the IPC message. What I fixed is the
> service ID field used solely for registering the handlers (i.e. passed
> to ipc_register()). If you check the changed struct, there is another
> field for the IPC headers where there is still the expected (out of
> bound) ID.
>
> In the current format, ipc_register() must not receive an "out of
> bound" ID otherwise memory corruptions occur, which introduces subtle
> bugs (in my case the crash happened in very specific compilation
> parameters and valgrind didn't help because the corrupted structures
> were static).
Yes, I was looking at service ID in wrong line. This seems ok now.
--
BR
Szymon Janc
^ permalink raw reply
* [PATCH 6/6] tools/rfcomm-tester: Add RFCOMM server read test case
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392205301-4204-1-git-send-email-marcin.kraglak@tieto.com>
It will test reading data passed to RFCOMM socket on server side.
---
tools/rfcomm-tester.c | 58 +++++++++++++++++++++++++++++++++++++++++++++++++--
1 file changed, 56 insertions(+), 2 deletions(-)
diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
index b46f95a..1af64f1 100644
--- a/tools/rfcomm-tester.c
+++ b/tools/rfcomm-tester.c
@@ -338,6 +338,14 @@ const struct rfcomm_server_data listen_send_success = {
.send_data = data
};
+const struct rfcomm_server_data listen_read_success = {
+ .server_channel = 0x0c,
+ .client_channel = 0x0c,
+ .expected_status = true,
+ .data_len = sizeof(data),
+ .read_data = data
+};
+
const struct rfcomm_server_data listen_nval = {
.server_channel = 0x0c,
.client_channel = 0x0e,
@@ -544,6 +552,29 @@ static void test_connect(const void *test_data)
tester_print("Connect in progress %d", sk);
}
+static gboolean server_received_data(GIOChannel *io, GIOCondition cond,
+ gpointer user_data)
+{
+ struct test_data *data = tester_get_data();
+ const struct rfcomm_server_data *server_data = data->test_data;
+ char buf[1024];
+ int sk;
+
+ sk = g_io_channel_unix_get_fd(io);
+ if (read(sk, buf, server_data->data_len) != server_data->data_len) {
+ tester_warn("Unable to read %u bytes", server_data->data_len);
+ tester_test_failed();
+ return false;
+ }
+
+ if (memcmp(buf, server_data->read_data, server_data->data_len))
+ tester_test_failed();
+ else
+ tester_test_passed();
+
+ return false;
+}
+
static gboolean rfcomm_listen_cb(GIOChannel *io, GIOCondition cond,
gpointer user_data)
{
@@ -568,6 +599,17 @@ static gboolean rfcomm_listen_cb(GIOChannel *io, GIOCondition cond,
tester_test_failed();
close(new_sk);
return false;
+ } else if (server_data->read_data) {
+ GIOChannel *new_io;
+
+ new_io = g_io_channel_unix_new(new_sk);
+ g_io_channel_set_close_on_unref(new_io, TRUE);
+
+ data->io_id = g_io_add_watch(new_io, G_IO_IN,
+ server_received_data, NULL);
+
+ g_io_channel_unref(new_io);
+ return false;
}
close(new_sk);
@@ -583,8 +625,18 @@ static void connection_cb(uint16_t handle, uint16_t cid, void *user_data,
struct test_data *data = tester_get_data();
const struct rfcomm_server_data *server_data = data->test_data;
- if (server_data->data_len)
+ if (server_data->read_data) {
+ data->conn_handle = handle;
+ data->cid = cid;
+ bthost_send_uih(hciemu_client_get_host(data->hciemu),
+ data->conn_handle, data->cid,
+ server_data->client_channel,
+ server_data->read_data,
+ server_data->data_len);
return;
+ } else if (server_data->data_len) {
+ return;
+ }
if (server_data->expected_status == status)
tester_test_passed();
@@ -681,7 +733,9 @@ int main(int argc, char *argv[])
test_rfcomm("Basic RFCOMM Socket Server - Write Success",
&listen_send_success, setup_powered_server,
test_server);
-
+ test_rfcomm("Basic RFCOMM Socket Server - Read Success",
+ &listen_read_success, setup_powered_server,
+ test_server);
test_rfcomm("Basic RFCOMM Socket Server - Conn Refused", &listen_nval,
setup_powered_server, test_server);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 5/6] tools/rfcomm-tester: Add RFCOMM client read test case
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392205301-4204-1-git-send-email-marcin.kraglak@tieto.com>
This will test reading data passed to RFCOMM socket on client side.
---
tools/rfcomm-tester.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
index 1c2563d..b46f95a 100644
--- a/tools/rfcomm-tester.c
+++ b/tools/rfcomm-tester.c
@@ -51,6 +51,8 @@ struct test_data {
enum hciemu_type hciemu_type;
const void *test_data;
unsigned int io_id;
+ uint16_t conn_handle;
+ uint16_t cid;
};
struct rfcomm_client_data {
@@ -309,6 +311,13 @@ const struct rfcomm_client_data connect_send_success = {
.send_data = data
};
+const struct rfcomm_client_data connect_read_success = {
+ .server_channel = 0x0c,
+ .client_channel = 0x0c,
+ .data_len = sizeof(data),
+ .read_data = data
+};
+
const struct rfcomm_client_data connect_nval = {
.server_channel = 0x0c,
.client_channel = 0x0e,
@@ -389,6 +398,30 @@ static int connect_rfcomm_sock(int sk, const bdaddr_t *bdaddr, uint8_t channel)
return 0;
}
+static gboolean client_received_data(GIOChannel *io, GIOCondition cond,
+ gpointer user_data)
+{
+ struct test_data *data = tester_get_data();
+ const struct rfcomm_client_data *client_data = data->test_data;
+ int sk;
+ char buf[248];
+
+ sk = g_io_channel_unix_get_fd(io);
+
+
+ if (client_data->data_len != read(sk, buf, client_data->data_len)) {
+ tester_test_failed();
+ return false;
+ }
+
+ if (memcmp(client_data->read_data, buf, client_data->data_len))
+ tester_test_failed();
+ else
+ tester_test_passed();
+
+ return false;
+}
+
static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
gpointer user_data)
{
@@ -417,6 +450,15 @@ static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
client_data->data_len))
tester_test_failed();
return false;
+ } else if (client_data->read_data) {
+ g_io_add_watch(io, G_IO_IN, client_received_data,
+ NULL);
+ bthost_send_uih(hciemu_client_get_host(data->hciemu),
+ data->conn_handle, data->cid,
+ client_data->client_channel,
+ client_data->read_data,
+ client_data->data_len);
+ return false;
}
if (err < 0)
@@ -457,10 +499,14 @@ static void rfcomm_connect_cb(uint16_t handle, uint16_t cid,
struct test_data *data = tester_get_data();
const struct rfcomm_client_data *client_data = data->test_data;
- if (client_data->send_data)
+ if (client_data->send_data) {
bthost_add_channel_hook(hciemu_client_get_host(data->hciemu),
handle, client_data->client_channel,
client_hook_func, NULL);
+ } else if (client_data->read_data) {
+ data->conn_handle = handle;
+ data->cid = cid;
+ }
}
static void test_connect(const void *test_data)
@@ -625,6 +671,9 @@ int main(int argc, char *argv[])
test_rfcomm("Basic RFCOMM Socket Client - Write Success",
&connect_send_success, setup_powered_client,
test_connect);
+ test_rfcomm("Basic RFCOMM Socket Client - Read Success",
+ &connect_read_success, setup_powered_client,
+ test_connect);
test_rfcomm("Basic RFCOMM Socket Client - Conn Refused",
&connect_nval, setup_powered_client, test_connect);
test_rfcomm("Basic RFCOMM Socket Server - Success", &listen_success,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 4/6] emulator/bthost: Add function to send RFCOMM UIH frames from bthost
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392205301-4204-1-git-send-email-marcin.kraglak@tieto.com>
This will make RFCOMM UIH frame and fill with data passed by user.
---
emulator/bthost.c | 43 +++++++++++++++++++++++++++++++++++++++++++
emulator/bthost.h | 3 +++
2 files changed, 46 insertions(+)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index 92ae08a..6f3e538 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -2174,6 +2174,49 @@ void bthost_add_channel_hook(struct bthost *bthost, uint16_t handle,
conn->channel_hooks = hook;
}
+void bthost_send_uih(struct bthost *bthost, uint16_t handle, uint16_t cid,
+ uint8_t channel, const void *data, uint16_t len)
+{
+ struct btconn *conn;
+ struct l2conn *l2conn;
+ struct rfcomm_hdr *hdr;
+ uint8_t *uih_frame;
+ uint16_t uih_len;
+
+ conn = bthost_find_conn(bthost, handle);
+ if (!conn)
+ return;
+
+ l2conn = btconn_find_l2cap_conn_by_scid(conn, cid);
+ if (!l2conn || l2conn->psm != 0x0003)
+ return;
+
+ if (len > 127)
+ uih_len = len + sizeof(struct rfcomm_cmd) + sizeof(uint8_t);
+ else
+ uih_len = len + sizeof(struct rfcomm_cmd);
+
+ uih_frame = malloc(uih_len);
+ if (!uih_frame)
+ return;
+
+ hdr = (struct rfcomm_hdr *)uih_frame;
+ hdr->address = RFCOMM_ADDR(1, channel * 2);
+ hdr->control = RFCOMM_CTRL(RFCOMM_UIH, 0);
+ if (len > 127) {
+ hdr->length = RFCOMM_LEN16(cpu_to_le16(sizeof(*hdr) + len));
+ memcpy(uih_frame + sizeof(*hdr) + 1, data, len);
+ } else {
+ hdr->length = RFCOMM_LEN8(sizeof(*hdr) + len);
+ memcpy(uih_frame + sizeof(*hdr), data, len);
+ }
+
+ uih_frame[uih_len - 1] = rfcomm_fcs((void *)hdr);
+ send_acl(bthost, handle, cid, uih_frame, uih_len);
+
+ free(uih_frame);
+}
+
void bthost_stop(struct bthost *bthost)
{
if (bthost->smp_data) {
diff --git a/emulator/bthost.h b/emulator/bthost.h
index 730d004..e278517 100644
--- a/emulator/bthost.h
+++ b/emulator/bthost.h
@@ -107,6 +107,9 @@ void bthost_add_channel_hook(struct bthost *bthost, uint16_t handle,
bthost_channel_hook_func_t func,
void *user_data);
+void bthost_send_uih(struct bthost *bthost, uint16_t handle, uint16_t cid,
+ uint8_t channel, const void *data, uint16_t len);
+
void bthost_start(struct bthost *bthost);
void bthost_stop(struct bthost *bthost);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/6] tools/rfcomm-tester: Add RFCOMM server write test case
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392205301-4204-1-git-send-email-marcin.kraglak@tieto.com>
This will check data write from server to client.
---
tools/rfcomm-tester.c | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
index 80448cb..1c2563d 100644
--- a/tools/rfcomm-tester.c
+++ b/tools/rfcomm-tester.c
@@ -66,6 +66,9 @@ struct rfcomm_server_data {
uint8_t server_channel;
uint8_t client_channel;
bool expected_status;
+ const uint8_t *send_data;
+ const uint8_t *read_data;
+ uint16_t data_len;
};
static void mgmt_debug(const char *str, void *user_data)
@@ -318,6 +321,14 @@ const struct rfcomm_server_data listen_success = {
.expected_status = true
};
+const struct rfcomm_server_data listen_send_success = {
+ .server_channel = 0x0c,
+ .client_channel = 0x0c,
+ .expected_status = true,
+ .data_len = sizeof(data),
+ .send_data = data
+};
+
const struct rfcomm_server_data listen_nval = {
.server_channel = 0x0c,
.client_channel = 0x0e,
@@ -428,6 +439,18 @@ static void client_hook_func(const void *data, uint16_t len,
tester_test_passed();
}
+static void server_hook_func(const void *data, uint16_t len,
+ void *user_data)
+{
+ struct test_data *test_data = tester_get_data();
+ const struct rfcomm_server_data *server_data = test_data->test_data;
+
+ if (memcmp(server_data->send_data, data, len))
+ tester_test_failed();
+ else
+ tester_test_passed();
+}
+
static void rfcomm_connect_cb(uint16_t handle, uint16_t cid,
void *user_data, bool status)
{
@@ -479,6 +502,7 @@ static gboolean rfcomm_listen_cb(GIOChannel *io, GIOCondition cond,
gpointer user_data)
{
struct test_data *data = tester_get_data();
+ const struct rfcomm_server_data *server_data = data->test_data;
int sk, new_sk;
data->io_id = 0;
@@ -491,6 +515,15 @@ static gboolean rfcomm_listen_cb(GIOChannel *io, GIOCondition cond,
return false;
}
+ if (server_data->send_data) {
+ if (server_data->data_len != write(new_sk,
+ server_data->send_data,
+ server_data->data_len))
+ tester_test_failed();
+ close(new_sk);
+ return false;
+ }
+
close(new_sk);
tester_test_passed();
@@ -504,6 +537,9 @@ static void connection_cb(uint16_t handle, uint16_t cid, void *user_data,
struct test_data *data = tester_get_data();
const struct rfcomm_server_data *server_data = data->test_data;
+ if (server_data->data_len)
+ return;
+
if (server_data->expected_status == status)
tester_test_passed();
else
@@ -517,6 +553,9 @@ static void client_new_conn(uint16_t handle, void *user_data)
struct bthost *bthost;
bthost = hciemu_client_get_host(data->hciemu);
+ bthost_add_channel_hook(hciemu_client_get_host(data->hciemu),
+ handle, server_data->client_channel,
+ server_hook_func, NULL);
bthost_connect_rfcomm(bthost, handle, server_data->client_channel,
connection_cb, NULL);
}
@@ -590,6 +629,10 @@ int main(int argc, char *argv[])
&connect_nval, setup_powered_client, test_connect);
test_rfcomm("Basic RFCOMM Socket Server - Success", &listen_success,
setup_powered_server, test_server);
+ test_rfcomm("Basic RFCOMM Socket Server - Write Success",
+ &listen_send_success, setup_powered_server,
+ test_server);
+
test_rfcomm("Basic RFCOMM Socket Server - Conn Refused", &listen_nval,
setup_powered_server, test_server);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/6] tools/rfcomm-tester: Add RFCOMM client write test case
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392205301-4204-1-git-send-email-marcin.kraglak@tieto.com>
This will test sending data through RFCOMM socket from client to server.
---
tools/rfcomm-tester.c | 48 +++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 47 insertions(+), 1 deletion(-)
diff --git a/tools/rfcomm-tester.c b/tools/rfcomm-tester.c
index 44df7e7..80448cb 100644
--- a/tools/rfcomm-tester.c
+++ b/tools/rfcomm-tester.c
@@ -57,6 +57,9 @@ struct rfcomm_client_data {
uint8_t server_channel;
uint8_t client_channel;
int expected_connect_err;
+ const uint8_t *send_data;
+ const uint8_t *read_data;
+ uint16_t data_len;
};
struct rfcomm_server_data {
@@ -294,6 +297,15 @@ const struct rfcomm_client_data connect_success = {
.client_channel = 0x0c
};
+const uint8_t data[] = {0, 1, 2, 3, 4, 5, 6, 7, 8};
+
+const struct rfcomm_client_data connect_send_success = {
+ .server_channel = 0x0c,
+ .client_channel = 0x0c,
+ .data_len = sizeof(data),
+ .send_data = data
+};
+
const struct rfcomm_client_data connect_nval = {
.server_channel = 0x0c,
.client_channel = 0x0e,
@@ -389,6 +401,13 @@ static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
return false;
}
+ if (client_data->send_data) {
+ if (client_data->data_len != write(sk, client_data->send_data,
+ client_data->data_len))
+ tester_test_failed();
+ return false;
+ }
+
if (err < 0)
tester_test_failed();
else
@@ -397,6 +416,30 @@ static gboolean rc_connect_cb(GIOChannel *io, GIOCondition cond,
return false;
}
+static void client_hook_func(const void *data, uint16_t len,
+ void *user_data)
+{
+ struct test_data *test_data = tester_get_data();
+ const struct rfcomm_client_data *client_data = test_data->test_data;
+
+ if (memcmp(client_data->send_data, data, len))
+ tester_test_failed();
+ else
+ tester_test_passed();
+}
+
+static void rfcomm_connect_cb(uint16_t handle, uint16_t cid,
+ void *user_data, bool status)
+{
+ struct test_data *data = tester_get_data();
+ const struct rfcomm_client_data *client_data = data->test_data;
+
+ if (client_data->send_data)
+ bthost_add_channel_hook(hciemu_client_get_host(data->hciemu),
+ handle, client_data->client_channel,
+ client_hook_func, NULL);
+}
+
static void test_connect(const void *test_data)
{
struct test_data *data = tester_get_data();
@@ -408,7 +451,7 @@ static void test_connect(const void *test_data)
bthost_add_l2cap_server(bthost, 0x0003, NULL, NULL);
bthost_add_rfcomm_server(bthost, client_data->server_channel,
- NULL, NULL);
+ rfcomm_connect_cb, NULL);
master_addr = hciemu_get_master_bdaddr(data->hciemu);
client_addr = hciemu_get_client_bdaddr(data->hciemu);
@@ -540,6 +583,9 @@ int main(int argc, char *argv[])
setup_powered_client, test_basic);
test_rfcomm("Basic RFCOMM Socket Client - Success", &connect_success,
setup_powered_client, test_connect);
+ test_rfcomm("Basic RFCOMM Socket Client - Write Success",
+ &connect_send_success, setup_powered_client,
+ test_connect);
test_rfcomm("Basic RFCOMM Socket Client - Conn Refused",
&connect_nval, setup_powered_client, test_connect);
test_rfcomm("Basic RFCOMM Socket Server - Success", &listen_success,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/6] emulator/bthost: Add api to handle RFCOMM data on bthost
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392205301-4204-1-git-send-email-marcin.kraglak@tieto.com>
With this change user can handle data received on RFCOMM connection.
---
emulator/bthost.c | 70 +++++++++++++++++++++++++++++++++++++++++++++++++++----
emulator/bthost.h | 8 +++++++
2 files changed, 74 insertions(+), 4 deletions(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index 8447817..92ae08a 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -126,6 +126,13 @@ struct cid_hook {
struct cid_hook *next;
};
+struct channel_hook {
+ uint8_t channel;
+ bthost_channel_hook_func_t func;
+ void *user_data;
+ struct channel_hook *next;
+};
+
struct btconn {
uint16_t handle;
uint8_t bdaddr[6];
@@ -134,6 +141,7 @@ struct btconn {
uint16_t next_cid;
struct l2conn *l2conns;
struct cid_hook *cid_hooks;
+ struct channel_hook *channel_hooks;
struct btconn *next;
void *smp_data;
};
@@ -232,6 +240,12 @@ static void btconn_free(struct btconn *conn)
conn->cid_hooks = hook->next;
free(hook);
}
+ while (conn->channel_hooks) {
+ struct channel_hook *hook = conn->channel_hooks;
+
+ conn->channel_hooks = hook->next;
+ free(hook);
+ }
free(conn);
}
@@ -1547,6 +1561,19 @@ static struct cid_hook *find_cid_hook(struct btconn *conn, uint16_t cid)
return NULL;
}
+static struct channel_hook *find_channel_hook(struct btconn *conn,
+ uint16_t channel)
+{
+ struct channel_hook *hook;
+
+ for (hook = conn->channel_hooks; hook != NULL; hook = hook->next) {
+ if (hook->channel == channel)
+ return hook;
+ }
+
+ return NULL;
+}
+
static void rfcomm_ua_send(struct bthost *bthost, struct btconn *conn,
struct l2conn *l2conn, uint8_t cr, uint8_t dlci)
{
@@ -1801,9 +1828,6 @@ static void rfcomm_uih_recv(struct bthost *bthost, struct btconn *conn,
if (len < sizeof(*hdr))
return;
- if (RFCOMM_GET_DLCI(hdr->address))
- return;
-
if (RFCOMM_TEST_EA(hdr->length))
hdr_len = sizeof(*hdr);
else
@@ -1814,7 +1838,19 @@ static void rfcomm_uih_recv(struct bthost *bthost, struct btconn *conn,
p = data + hdr_len;
- rfcomm_mcc_recv(bthost, conn, l2conn, p, len - hdr_len);
+ if (RFCOMM_GET_DLCI(hdr->address)) {
+ struct channel_hook *hook;
+
+ hook = find_channel_hook(conn,
+ RFCOMM_GET_CHANNEL(hdr->address));
+ if (!hook)
+ return;
+
+ hook->func(p, len - hdr_len - sizeof(uint8_t),
+ hook->user_data);
+ } else {
+ rfcomm_mcc_recv(bthost, conn, l2conn, p, len - hdr_len);
+ }
}
static void process_rfcomm(struct bthost *bthost, struct btconn *conn,
@@ -2112,6 +2148,32 @@ bool bthost_connect_rfcomm(struct bthost *bthost, uint16_t handle,
&req, sizeof(req), NULL, NULL);
}
+void bthost_add_channel_hook(struct bthost *bthost, uint16_t handle,
+ uint8_t channel,
+ bthost_channel_hook_func_t func,
+ void *user_data)
+{
+ struct channel_hook *hook;
+ struct btconn *conn;
+
+ conn = bthost_find_conn(bthost, handle);
+ if (!conn)
+ return;
+
+ hook = malloc(sizeof(*hook));
+ if (!hook)
+ return;
+
+ memset(hook, 0, sizeof(*hook));
+
+ hook->channel = channel;
+ hook->func = func;
+ hook->user_data = user_data;
+
+ hook->next = conn->channel_hooks;
+ conn->channel_hooks = hook;
+}
+
void bthost_stop(struct bthost *bthost)
{
if (bthost->smp_data) {
diff --git a/emulator/bthost.h b/emulator/bthost.h
index a3c26a1..730d004 100644
--- a/emulator/bthost.h
+++ b/emulator/bthost.h
@@ -99,6 +99,14 @@ bool bthost_connect_rfcomm(struct bthost *bthost, uint16_t handle,
uint8_t channel, bthost_rfcomm_connect_cb func,
void *user_data);
+typedef void (*bthost_channel_hook_func_t) (const void *data, uint16_t len,
+ void *user_data);
+
+void bthost_add_channel_hook(struct bthost *bthost, uint16_t handle,
+ uint8_t channel,
+ bthost_channel_hook_func_t func,
+ void *user_data);
+
void bthost_start(struct bthost *bthost);
void bthost_stop(struct bthost *bthost);
--
1.8.3.1
^ permalink raw reply related
* [PATCH 0/6] RFCOMM data transfer support in bthost
From: Marcin Kraglak @ 2014-02-12 11:41 UTC (permalink / raw)
To: linux-bluetooth
Hi,
Below changes allow to test RFCOMM data transfer and add
simple test to check it. Two new functions are added
to bthost API: bthost_add_channel_hook(), which handles
data received on bthost on specific channel and connection
handle and bthost_send_uih(), which forms RFCOMM UIH frame
and send it.
These changes depends on previous fixes with frame length checks.
Comments are welcome
Regards
Marcin Kraglak (6):
emulator/bthost: Add api to handle RFCOMM data on bthost
tools/rfcomm-tester: Add RFCOMM client write test case
tools/rfcomm-tester: Add RFCOMM server write test case
emulator/bthost: Add function to send RFCOMM UIH frames from bthost
tools/rfcomm-tester: Add RFCOMM client read test case
tools/rfcomm-tester: Add RFCOMM server read test case
emulator/bthost.c | 113 +++++++++++++++++++++++++++--
emulator/bthost.h | 11 +++
tools/rfcomm-tester.c | 194 +++++++++++++++++++++++++++++++++++++++++++++++++-
3 files changed, 313 insertions(+), 5 deletions(-)
--
1.8.3.1
^ permalink raw reply
* Re: [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search
From: Luiz Augusto von Dentz @ 2014-02-12 11:29 UTC (permalink / raw)
To: Szymon Janc; +Cc: Anderson Lizardo, linux-bluetooth@vger.kernel.org
In-Reply-To: <1458044.bhGCHJKobi@leonov>
Hi Szymon,
On Wed, Feb 12, 2014 at 12:59 PM, Szymon Janc <szymon.janc@tieto.com> wrote:
> Hi,
>
> On Wednesday 12 of February 2014 11:58:16 Luiz Augusto von Dentz wrote:
>> Hi Anderson,
>>
>> On Tue, Feb 11, 2014 at 8:32 PM, Anderson Lizardo
>>
>> <anderson.lizardo@openbossa.org> wrote:
>> > These UUIDs are assigned by BT-SIG and therefore there is no need to
>> > use full 128-bit UUIDs. This also avoids unnecessary conversion from
>> > string representation.
>> > ---
>> >
>> > android/handsfree.c | 3 +--
>> > android/hidhost.c | 7 +++----
>> > 2 files changed, 4 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/android/handsfree.c b/android/handsfree.c
>> > index 9482b2e..a869d58 100644
>> > --- a/android/handsfree.c
>> > +++ b/android/handsfree.c
>> > @@ -34,7 +34,6 @@
>> >
>> > #include "lib/bluetooth.h"
>> > #include "lib/sdp.h"
>> > #include "lib/sdp_lib.h"
>> >
>> > -#include "lib/uuid.h"
>> >
>> > #include "src/sdp-client.h"
>> > #include "src/uuid-helper.h"
>> > #include "src/shared/hfp.h"
>> >
>> > @@ -294,7 +293,7 @@ static void handle_connect(const void *buf, uint16_t
>> > len)>
>> > device_init(&bdaddr);
>> >
>> > - bt_string2uuid(&uuid, HFP_HS_UUID);
>> > + sdp_uuid16_create(&uuid, HANDSFREE_SVCLASS_ID);
>> >
>> > if (bt_search_service(&adapter_addr, &device.bdaddr, &uuid,
>> >
>> > sdp_search_cb, NULL, NULL, 0) < 0)
>> > {
>> >
>> > error("handsfree: SDP search failed");
>> >
>> > diff --git a/android/hidhost.c b/android/hidhost.c
>> > index 8bd3455..45fe14f 100644
>> > --- a/android/hidhost.c
>> > +++ b/android/hidhost.c
>> > @@ -37,7 +37,6 @@
>> >
>> > #include "lib/bluetooth.h"
>> > #include "lib/sdp.h"
>> > #include "lib/sdp_lib.h"
>> >
>> > -#include "lib/uuid.h"
>> >
>> > #include "src/shared/mgmt.h"
>> > #include "src/sdp-client.h"
>> > #include "src/uuid-helper.h"
>> >
>> > @@ -751,7 +750,7 @@ static void hid_sdp_did_search_cb(sdp_list_t *recs,
>> > int err, gpointer data)>
>> > dev->version = data->val.uint16;
>> >
>> > }
>> >
>> > - bt_string2uuid(&uuid, HID_UUID);
>> > + sdp_uuid16_create(&uuid, HID_SVCLASS_ID);
>> >
>> > if (bt_search_service(&adapter_addr, &dev->dst, &uuid,
>> >
>> > hid_sdp_search_cb, dev, NULL, 0) < 0) {
>> >
>> > error("failed to search sdp details");
>> >
>> > @@ -792,7 +791,7 @@ static void bt_hid_connect(const void *buf, uint16_t
>> > len)>
>> > ba2str(&dev->dst, addr);
>> > DBG("connecting to %s", addr);
>> >
>> > - bt_string2uuid(&uuid, PNP_UUID);
>> > + sdp_uuid16_create(&uuid, PNP_INFO_SVCLASS_ID);
>> >
>> > if (bt_search_service(&adapter_addr, &dev->dst, &uuid,
>> >
>> > hid_sdp_did_search_cb, dev, NULL,
>> > 0) < 0) {
>> >
>> > error("Failed to search DeviceID SDP details");
>> >
>> > @@ -1293,7 +1292,7 @@ static void connect_cb(GIOChannel *chan, GError
>> > *err, gpointer user_data)>
>> > dev->ctrl_io = g_io_channel_ref(chan);
>> > dev->uhid_fd = -1;
>> >
>> > - bt_string2uuid(&uuid, PNP_UUID);
>> > + sdp_uuid16_create(&uuid, PNP_INFO_SVCLASS_ID);
>> >
>> > if (bt_search_service(&src, &dev->dst, &uuid,
>> >
>> > hid_sdp_did_search_cb, dev, NULL,
>> > 0) < 0) {
>> >
>> > error("failed to search did sdp details");
>> >
>> > --
>> > 1.7.9.5
>>
>> Applied all except 6/7, I think we should probably return an error if
>> there is an attempt to register a service out of range, then the
>> caller can assert so we can have a proper test for it that expect an
>> error in such case.
>
> Well, currently IPC depends on hal-msg.h which defines max allowed service ID
> and using something bigger is a code bug. We could have make IPC independent
> of hal-msg.h and just verify registered ID in runtime but that would add extra
> code for each caller with no profit as IDs are fixed anyway.
Perhaps we should ignore and not register service is initialized with
e.g. -1 just skip ipc_register.
> That test fix is invalid as we actually want to test if IPC handles out-of-
> bound service ID correctly (when receiving register command).
> And I'm not sure why this actually was causing any problems since that test is
> not registering handlers for out-of-bound service ID, just sends ipc message
> with such ID.
Im not sure we have the array of HAL_SERVICE_ID_MAX + 1 I thought that
would be HAL_SERVICE_ID_MAX, nevertheless every test seems to be
calling test_cmd_reg which does call ipc_register which IMO should be
invalid for HAL_SERVICE_ID_MAX + 1.
> (BTW I think we should pass max service id on ipc_init, as currently audio ipc
> is using max service id from bt ipc)
Im did not get the comment above.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search
From: Anderson Lizardo @ 2014-02-12 11:28 UTC (permalink / raw)
To: Szymon Janc; +Cc: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org
In-Reply-To: <1458044.bhGCHJKobi@leonov>
Hi Szymon,
On Wed, Feb 12, 2014 at 6:59 AM, Szymon Janc <szymon.janc@tieto.com> wrote:
>> Applied all except 6/7, I think we should probably return an error if
>> there is an attempt to register a service out of range, then the
>> caller can assert so we can have a proper test for it that expect an
>> error in such case.
>
> Well, currently IPC depends on hal-msg.h which defines max allowed service ID
> and using something bigger is a code bug. We could have make IPC independent
> of hal-msg.h and just verify registered ID in runtime but that would add extra
> code for each caller with no profit as IDs are fixed anyway.
Personally, I don't have strong opinions on using assert() versus
raise(SIGTERM) (which is how runtime error conditions seem to be
handled). Initially I went with raise(SIGTERM), but then I noticed the
IDs are statically defined, and there is no way to give a invalid ID
to ipc_register(), unless due to programming error (for which
assert() is ideal, due to low overhead and no introduction of dead
code).
That said, this patch is not critical, but only a check so future
users of ipc_register() don't reintroduce a similar crash fixed by the
other commit.
>
> That test fix is invalid as we actually want to test if IPC handles out-of-
> bound service ID correctly (when receiving register command).
> And I'm not sure why this actually was causing any problems since that test is
> not registering handlers for out-of-bound service ID, just sends ipc message
> with such ID.
I forgot to clarify this on the commit message: the "out of bound"
service ID is still passed on the IPC message. What I fixed is the
service ID field used solely for registering the handlers (i.e. passed
to ipc_register()). If you check the changed struct, there is another
field for the IPC headers where there is still the expected (out of
bound) ID.
In the current format, ipc_register() must not receive an "out of
bound" ID otherwise memory corruptions occur, which introduces subtle
bugs (in my case the crash happened in very specific compilation
parameters and valgrind didn't help because the corrupted structures
were static).
Best Regards,
--
Anderson Lizardo
http://www.indt.org/?lang=en
INdT - Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Sander Eikelenboom @ 2014-02-12 11:06 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Peter Hurley, Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <3E0F3723-029F-4B12-8D77-9790FDBD3227@holtmann.org>
Monday, February 10, 2014, 11:09:38 PM, you wrote:
> Hi Peter,
>> This patch series addresses a number of previously unknown issues
>> with the RFCOMM tty device implementation, in addition to
>> addressing the locking regression recently reported [1].
>>
>> As Gianluca suggested and I agree, this series first reverts
>> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
> so for 3.14 we should revert 3 patches. And then the other 21 are intended for 3.15 merge window.
> I realize that we still have to deal with some breakage, but we do not want regressions and I clearly not going to take 24 patches for 3.14 at this point in time.
> What I can do is take all 24 patches into bluetooth-next and let them sit for 1 week and have people test them. And then we go ahead with reverting 3 patches from 3.14. Does that make sense?
Reverting those 3 patches works for me.
--
Sander
> Regards
> Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search
From: Szymon Janc @ 2014-02-12 10:59 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Anderson Lizardo, linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZ+V-pg6sGO7yK1gsFnu+6pxDJhBq6QUdW_RyP6+YSMnUg@mail.gmail.com>
Hi,
On Wednesday 12 of February 2014 11:58:16 Luiz Augusto von Dentz wrote:
> Hi Anderson,
>
> On Tue, Feb 11, 2014 at 8:32 PM, Anderson Lizardo
>
> <anderson.lizardo@openbossa.org> wrote:
> > These UUIDs are assigned by BT-SIG and therefore there is no need to
> > use full 128-bit UUIDs. This also avoids unnecessary conversion from
> > string representation.
> > ---
> >
> > android/handsfree.c | 3 +--
> > android/hidhost.c | 7 +++----
> > 2 files changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/android/handsfree.c b/android/handsfree.c
> > index 9482b2e..a869d58 100644
> > --- a/android/handsfree.c
> > +++ b/android/handsfree.c
> > @@ -34,7 +34,6 @@
> >
> > #include "lib/bluetooth.h"
> > #include "lib/sdp.h"
> > #include "lib/sdp_lib.h"
> >
> > -#include "lib/uuid.h"
> >
> > #include "src/sdp-client.h"
> > #include "src/uuid-helper.h"
> > #include "src/shared/hfp.h"
> >
> > @@ -294,7 +293,7 @@ static void handle_connect(const void *buf, uint16_t
> > len)>
> > device_init(&bdaddr);
> >
> > - bt_string2uuid(&uuid, HFP_HS_UUID);
> > + sdp_uuid16_create(&uuid, HANDSFREE_SVCLASS_ID);
> >
> > if (bt_search_service(&adapter_addr, &device.bdaddr, &uuid,
> >
> > sdp_search_cb, NULL, NULL, 0) < 0)
> > {
> >
> > error("handsfree: SDP search failed");
> >
> > diff --git a/android/hidhost.c b/android/hidhost.c
> > index 8bd3455..45fe14f 100644
> > --- a/android/hidhost.c
> > +++ b/android/hidhost.c
> > @@ -37,7 +37,6 @@
> >
> > #include "lib/bluetooth.h"
> > #include "lib/sdp.h"
> > #include "lib/sdp_lib.h"
> >
> > -#include "lib/uuid.h"
> >
> > #include "src/shared/mgmt.h"
> > #include "src/sdp-client.h"
> > #include "src/uuid-helper.h"
> >
> > @@ -751,7 +750,7 @@ static void hid_sdp_did_search_cb(sdp_list_t *recs,
> > int err, gpointer data)>
> > dev->version = data->val.uint16;
> >
> > }
> >
> > - bt_string2uuid(&uuid, HID_UUID);
> > + sdp_uuid16_create(&uuid, HID_SVCLASS_ID);
> >
> > if (bt_search_service(&adapter_addr, &dev->dst, &uuid,
> >
> > hid_sdp_search_cb, dev, NULL, 0) < 0) {
> >
> > error("failed to search sdp details");
> >
> > @@ -792,7 +791,7 @@ static void bt_hid_connect(const void *buf, uint16_t
> > len)>
> > ba2str(&dev->dst, addr);
> > DBG("connecting to %s", addr);
> >
> > - bt_string2uuid(&uuid, PNP_UUID);
> > + sdp_uuid16_create(&uuid, PNP_INFO_SVCLASS_ID);
> >
> > if (bt_search_service(&adapter_addr, &dev->dst, &uuid,
> >
> > hid_sdp_did_search_cb, dev, NULL,
> > 0) < 0) {
> >
> > error("Failed to search DeviceID SDP details");
> >
> > @@ -1293,7 +1292,7 @@ static void connect_cb(GIOChannel *chan, GError
> > *err, gpointer user_data)>
> > dev->ctrl_io = g_io_channel_ref(chan);
> > dev->uhid_fd = -1;
> >
> > - bt_string2uuid(&uuid, PNP_UUID);
> > + sdp_uuid16_create(&uuid, PNP_INFO_SVCLASS_ID);
> >
> > if (bt_search_service(&src, &dev->dst, &uuid,
> >
> > hid_sdp_did_search_cb, dev, NULL,
> > 0) < 0) {
> >
> > error("failed to search did sdp details");
> >
> > --
> > 1.7.9.5
>
> Applied all except 6/7, I think we should probably return an error if
> there is an attempt to register a service out of range, then the
> caller can assert so we can have a proper test for it that expect an
> error in such case.
Well, currently IPC depends on hal-msg.h which defines max allowed service ID
and using something bigger is a code bug. We could have make IPC independent
of hal-msg.h and just verify registered ID in runtime but that would add extra
code for each caller with no profit as IDs are fixed anyway.
That test fix is invalid as we actually want to test if IPC handles out-of-
bound service ID correctly (when receiving register command).
And I'm not sure why this actually was causing any problems since that test is
not registering handlers for out-of-bound service ID, just sends ipc message
with such ID.
(BTW I think we should pass max service id on ipc_init, as currently audio ipc
is using max service id from bt ipc)
--
BR
Szymon Janc
^ permalink raw reply
* AW: Bluetooth high speed supported drivers or patches for kernel 3.11
From: Viswanatham, RaviTeja @ 2014-02-12 10:21 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <20140212100507.GB25950@aemeltch-MOBL1>
-----Ursprüngliche Nachricht-----
Von: Andrei Emeltchenko [mailto:andrei.emeltchenko.news@gmail.com]
Gesendet: Mittwoch, 12. Februar 2014 11:05
An: Viswanatham, RaviTeja
Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
Betreff: Re: Bluetooth high speed supported drivers or patches for kernel 3.11
Hi Raviteja,
On Wed, Feb 12, 2014 at 09:58:19AM +0000, Viswanatham, RaviTeja wrote:
> Hello all,
>
> I bought a USB bluetooth 3.0 HS +Wifi dongle which I want to transfer
> data rate with 24Mbit/s. The dongle contains Realtek 8192cu and CSR
> drivers. I got to know from the bluez mailing list it contains SoftAMP.
I am afraid that the SoftAMP is supported only in Windows drivers.
I tried to send data file through windows from PC to PC it works and could also reach high speed. I want to send data through Linux via bluetooth with high speed. I could send data via bluetooth but I couldn't reach high speed.
I am a bit confused what exactly I need to enable to run bluetooth with high speed ?
Is it problem with wifi driver or with the bluetooth. I am little bit worried here.
Any hints or suggestion would be really appreciated
Thanks
BR
Raviteja
> I want to know is there any possibility to get the drivers or patches
> from the bluez which can enable the mac80211 to reach high speed.
>
> Any hints to get high speed data transfer rate.
^ permalink raw reply
* Re: Bluetooth high speed supported drivers or patches for kernel 3.11
From: Andrei Emeltchenko @ 2014-02-12 10:05 UTC (permalink / raw)
To: Viswanatham, RaviTeja; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <9BC883E0D59F6B4DBD525D460025714B08AE3825@deessmx03.dees.eberspaecher.com>
Hi Raviteja,
On Wed, Feb 12, 2014 at 09:58:19AM +0000, Viswanatham, RaviTeja wrote:
> Hello all,
>
> I bought a USB bluetooth 3.0 HS +Wifi dongle which I want to transfer
> data rate with 24Mbit/s. The dongle contains Realtek 8192cu and CSR
> drivers. I got to know from the bluez mailing list it contains SoftAMP.
I am afraid that the SoftAMP is supported only in Windows drivers.
Best regards
Andrei Emeltchenko
> I want to know is there any possibility to get the drivers or patches
> from the bluez which can enable the mac80211 to reach high speed.
>
> Any hints to get high speed data transfer rate.
^ permalink raw reply
* Bluetooth high speed supported drivers or patches for kernel 3.11
From: Viswanatham, RaviTeja @ 2014-02-12 9:58 UTC (permalink / raw)
To: bluez mailin list (linux-bluetooth@vger.kernel.org)
Hello all,
I bought a USB bluetooth 3.0 HS +Wifi dongle which I want to transfer data rate with 24Mbit/s. The dongle contains Realtek 8192cu and CSR drivers. I got to know from the bluez mailing list it contains SoftAMP. I want to know is there any possibility to get the drivers or patches from the bluez which can enable the mac80211 to reach high speed.
Any hints to get high speed data transfer rate.
Thanks in advance
Raviteja
^ permalink raw reply
* Re: [PATCH BlueZ 1/7] android: Use 16-bit UUID for SDP search
From: Luiz Augusto von Dentz @ 2014-02-12 9:58 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1392143552-11395-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Tue, Feb 11, 2014 at 8:32 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> These UUIDs are assigned by BT-SIG and therefore there is no need to
> use full 128-bit UUIDs. This also avoids unnecessary conversion from
> string representation.
> ---
> android/handsfree.c | 3 +--
> android/hidhost.c | 7 +++----
> 2 files changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/android/handsfree.c b/android/handsfree.c
> index 9482b2e..a869d58 100644
> --- a/android/handsfree.c
> +++ b/android/handsfree.c
> @@ -34,7 +34,6 @@
> #include "lib/bluetooth.h"
> #include "lib/sdp.h"
> #include "lib/sdp_lib.h"
> -#include "lib/uuid.h"
> #include "src/sdp-client.h"
> #include "src/uuid-helper.h"
> #include "src/shared/hfp.h"
> @@ -294,7 +293,7 @@ static void handle_connect(const void *buf, uint16_t len)
>
> device_init(&bdaddr);
>
> - bt_string2uuid(&uuid, HFP_HS_UUID);
> + sdp_uuid16_create(&uuid, HANDSFREE_SVCLASS_ID);
> if (bt_search_service(&adapter_addr, &device.bdaddr, &uuid,
> sdp_search_cb, NULL, NULL, 0) < 0) {
> error("handsfree: SDP search failed");
> diff --git a/android/hidhost.c b/android/hidhost.c
> index 8bd3455..45fe14f 100644
> --- a/android/hidhost.c
> +++ b/android/hidhost.c
> @@ -37,7 +37,6 @@
> #include "lib/bluetooth.h"
> #include "lib/sdp.h"
> #include "lib/sdp_lib.h"
> -#include "lib/uuid.h"
> #include "src/shared/mgmt.h"
> #include "src/sdp-client.h"
> #include "src/uuid-helper.h"
> @@ -751,7 +750,7 @@ static void hid_sdp_did_search_cb(sdp_list_t *recs, int err, gpointer data)
> dev->version = data->val.uint16;
> }
>
> - bt_string2uuid(&uuid, HID_UUID);
> + sdp_uuid16_create(&uuid, HID_SVCLASS_ID);
> if (bt_search_service(&adapter_addr, &dev->dst, &uuid,
> hid_sdp_search_cb, dev, NULL, 0) < 0) {
> error("failed to search sdp details");
> @@ -792,7 +791,7 @@ static void bt_hid_connect(const void *buf, uint16_t len)
> ba2str(&dev->dst, addr);
> DBG("connecting to %s", addr);
>
> - bt_string2uuid(&uuid, PNP_UUID);
> + sdp_uuid16_create(&uuid, PNP_INFO_SVCLASS_ID);
> if (bt_search_service(&adapter_addr, &dev->dst, &uuid,
> hid_sdp_did_search_cb, dev, NULL, 0) < 0) {
> error("Failed to search DeviceID SDP details");
> @@ -1293,7 +1292,7 @@ static void connect_cb(GIOChannel *chan, GError *err, gpointer user_data)
> dev->ctrl_io = g_io_channel_ref(chan);
> dev->uhid_fd = -1;
>
> - bt_string2uuid(&uuid, PNP_UUID);
> + sdp_uuid16_create(&uuid, PNP_INFO_SVCLASS_ID);
> if (bt_search_service(&src, &dev->dst, &uuid,
> hid_sdp_did_search_cb, dev, NULL, 0) < 0) {
> error("failed to search did sdp details");
> --
> 1.7.9.5
Applied all except 6/7, I think we should probably return an error if
there is an attempt to register a service out of range, then the
caller can assert so we can have a proper test for it that expect an
error in such case.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 00/11] Socket HAL updates
From: Andrei Emeltchenko @ 2014-02-12 9:57 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: linux-bluetooth
In-Reply-To: <1392137901-3403-1-git-send-email-andrzej.kaczmarek@tieto.com>
Hi Andrzej,
On Tue, Feb 11, 2014 at 05:58:10PM +0100, Andrzej Kaczmarek wrote:
> Hi,
>
> Current socket HAL implementation is missing major feature which is
> ability to register RFCOMM server from application (so use some UUID
> and assign channel number dynamically). This corresponds to
> BluetoothAdapter::listenUsing(insecure)RfcommWithServiceRecord APIs
> in Android.
Support dynamic RFCOMM sockets looks god though I do not know why renaming
of socket names is really needed.
Best regards
Andrei Emeltchenko
>
> This series of patches adds this feature with other required fixes
> and also some does some minor refactoring.
>
> Andrzej Kaczmarek (11):
> android/bluetooth: Handle 128-bit UUIDs
> android/socket: Refactor socket related symbol names
> android/socket: Improve logging
> android/socket: Simplify SDP records handling
> android/socket: Make servers list as static array
> android/tester: Update test data
> android/socket: Add support for dynamic channel numbers
> android/socket: Register SDP record for application service
> android/socket: Include HF AG in built-in profiles
> android/socket: Update channel numbers
> android/socket: Fix sockets security
>
> android/android-tester.c | 2 +-
> android/bluetooth.c | 61 ++---
> android/hal-msg.h | 3 +
> android/socket.c | 658 +++++++++++++++++++++++------------------------
> 4 files changed, 349 insertions(+), 375 deletions(-)
>
> --
> 1.8.5.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH BlueZ] unit: Fix memory leaks in gobex tests
From: Luiz Augusto von Dentz @ 2014-02-12 9:53 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1392142591-10150-1-git-send-email-anderson.lizardo@openbossa.org>
Hi Anderson,
On Tue, Feb 11, 2014 at 8:16 PM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> ---
> unit/test-gobex-apparam.c | 2 ++
> unit/test-gobex-transfer.c | 2 ++
> 2 files changed, 4 insertions(+)
>
> diff --git a/unit/test-gobex-apparam.c b/unit/test-gobex-apparam.c
> index e6a42cc..976c541 100644
> --- a/unit/test-gobex-apparam.c
> +++ b/unit/test-gobex-apparam.c
> @@ -250,6 +250,8 @@ static void test_apparam_get_multi(void)
> g_assert(string != NULL);
> g_assert_cmpstr(string, ==, "ABC");
>
> + g_free(string);
> +
> g_obex_apparam_free(apparam);
> }
>
> diff --git a/unit/test-gobex-transfer.c b/unit/test-gobex-transfer.c
> index 128a467..7c9fd43 100644
> --- a/unit/test-gobex-transfer.c
> +++ b/unit/test-gobex-transfer.c
> @@ -511,6 +511,7 @@ static void test_stream_put_req_abort(void)
> g_obex_unref(obex);
>
> g_assert_error(d.err, G_OBEX_ERROR, G_OBEX_ERROR_CANCELLED);
> + g_error_free(d.err);
> }
>
> static void test_stream_put_rsp_abort(void)
> @@ -556,6 +557,7 @@ static void test_stream_put_rsp_abort(void)
> g_obex_unref(obex);
>
> g_assert_error(d.err, G_OBEX_ERROR, G_OBEX_ERROR_CANCELLED);
> + g_error_free(d.err);
> }
>
> static void handle_put_seq_wait(GObex *obex, GObexPacket *req,
> --
> 1.7.9.5
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [RFC 0/2] Add hci_smd driver
From: Lukasz Rymanowski @ 2014-02-12 9:11 UTC (permalink / raw)
To: Kumar Gala; +Cc: linux-arm-msm, linux-bluetooth@vger.kernel.org
In-Reply-To: <2AA076F5-9C40-4449-84FB-FC68809197DF@codeaurora.org>
Hi,
On 11 February 2014 21:00, Kumar Gala <galak@codeaurora.org> wrote:
>
> On Feb 11, 2014, at 10:23 AM, Lukasz Rymanowski <lukasz.rymanowski@tieto.com> wrote:
>
>> Hi
>>
>> On 7 February 2014 12:35, Lukasz Rymanowski <lukasz.rymanowski@tieto.com> wrote:
>>> Hello,
>>>
>>> This is a try (long shoot) to upstream hci shared memory driver (hci_smd)
>>> which is used on Qualcomm platforms and BT chips.
>>>
>>> To make it build with upstream tree I had to introduce some simple SMD API.
>>> The idea here is that since SMD channel is represented by platform device
>>> (as it is done in mach-msm),
>>> then platfrom_data contains smd_data which contains API for that channel.
>>>
>>> Writing this SMD API I was inspired with MSM-SMD and since I'm not an expert
>>> in this area I'm asking for comments here.
>>>
>>> Maybe instead of SMD API I made, I should expose functions like smd_open(), smd_write()
>>> etc. something similar how sdio does, and just deliver to upstream dummy device
>>> implementing this SMD API?
>>>
>>> Other options I was considering is to implement module inside mach-msm which
>>> would handle registering SMD BT Channels and when it is done, it would register
>>> new platform device like "smd-bt". Then I could move smd.h to some bluetooth includes
>>> (althought don't now where at the moment) and hci_smd would register driver for "smd-bt"
>>> In this case I would also could rid of one static variable I have now in hci_smd
>>>
>>> Comments on those options are welcome.
>>>
>>> Anyway, Hci_smd is based on one of the older version of this driver found in msm kernel
>>> branch, so there are no wakelocks as in new version and also workqueues are used
>>> instead of takslet.
>>>
>>> Since SMD expose two channels, one for CMD/EVENT and one for ACL Data I decide to
>>> do separate worqueues for this. This is to make sure that ACL data never blocks EVENT
>>> packages
>>>
>>
>> Adding linux-arm-msm group for comments on SMD API.
>>
>> BR
>> Lukasz
>
> What chip/SoC/board are you trying to get bluetooth support on?
>
I'm already running it on Nexus 4 and 7, but for this I have also more
changes in mach-msm (smd_tty.c, smd.c) on top of msm kernel branch
for android.
\Lukasz
> - k
>
> --
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
>
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix channel check when binding RFCOMM sock
From: Andrzej Kaczmarek @ 2014-02-11 22:26 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <52F8F4E9-BCAF-4137-B21C-101F11DE1519@holtmann.org>
Hi Marcel,
On 11 February 2014 16:58, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Andrzej,
>
>> When binding RFCOMM socket we should only check if there is another
>> socket bound or listening on the same channel number. In other case,
>> it won't be possible to bind/listen on a channel in case we have
>> connection made to remote device on the same channel number.
>
> since this has been used for years now, you need to be more specific on when this fails.
It's quite simple: create one socket and connect on channel X, then
create another socket and try to bind on channel X. Event though we
don't have listening socket on channel X yet, it will fail with
EADDRINUSE since rfcomm_sock_bind looks for *any* socket on specified
channel and doesn't care if it's bound/listening on local channel or
just connected to remote channel (in which case it should not fail).
Is it specific enough?
>> Signed-off-by: Andrzej Kaczmarek <andrzej.kaczmarek@tieto.com>
>> ---
>> net/bluetooth/rfcomm/sock.c | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/bluetooth/rfcomm/sock.c b/net/bluetooth/rfcomm/sock.c
>> index 00573fb..9912e23 100644
>> --- a/net/bluetooth/rfcomm/sock.c
>> +++ b/net/bluetooth/rfcomm/sock.c
>> @@ -331,6 +331,7 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
>> {
>> struct sockaddr_rc *sa = (struct sockaddr_rc *) addr;
>> struct sock *sk = sock->sk;
>> + struct sock *sk1;
>> int err = 0;
>>
>> BT_DBG("sk %p %pMR", sk, &sa->rc_bdaddr);
>> @@ -352,7 +353,9 @@ static int rfcomm_sock_bind(struct socket *sock, struct sockaddr *addr, int addr
>>
>> write_lock(&rfcomm_sk_list.lock);
>>
>> - if (sa->rc_channel && __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr)) {
>> + sk1 = __rfcomm_get_sock_by_addr(sa->rc_channel, &sa->rc_bdaddr);
>> + if (sa->rc_channel && sk1 && (sk1->sk_state == BT_BOUND ||
>> + sk1->sk_state == BT_LISTEN)) {
>> err = -EADDRINUSE;
>
> can we find a better name than sk1 here.
Something like 'existing_sk'? Or just 'oldsk'? I have no clue how to
make a meaningful name here.
BR,
Andrzej
^ permalink raw reply
* Re: [RFC 0/2] Add hci_smd driver
From: Kumar Gala @ 2014-02-11 20:00 UTC (permalink / raw)
To: Lukasz Rymanowski; +Cc: linux-arm-msm, linux-bluetooth@vger.kernel.org
In-Reply-To: <CAMudyAsomuEjkpnj_2Dmqikx_t+nYsEcv_Ai0e6xzuFjG7vGbw@mail.gmail.com>
On Feb 11, 2014, at 10:23 AM, Lukasz Rymanowski <lukasz.rymanowski@tieto.com> wrote:
> Hi
>
> On 7 February 2014 12:35, Lukasz Rymanowski <lukasz.rymanowski@tieto.com> wrote:
>> Hello,
>>
>> This is a try (long shoot) to upstream hci shared memory driver (hci_smd)
>> which is used on Qualcomm platforms and BT chips.
>>
>> To make it build with upstream tree I had to introduce some simple SMD API.
>> The idea here is that since SMD channel is represented by platform device
>> (as it is done in mach-msm),
>> then platfrom_data contains smd_data which contains API for that channel.
>>
>> Writing this SMD API I was inspired with MSM-SMD and since I'm not an expert
>> in this area I'm asking for comments here.
>>
>> Maybe instead of SMD API I made, I should expose functions like smd_open(), smd_write()
>> etc. something similar how sdio does, and just deliver to upstream dummy device
>> implementing this SMD API?
>>
>> Other options I was considering is to implement module inside mach-msm which
>> would handle registering SMD BT Channels and when it is done, it would register
>> new platform device like "smd-bt". Then I could move smd.h to some bluetooth includes
>> (althought don't now where at the moment) and hci_smd would register driver for "smd-bt"
>> In this case I would also could rid of one static variable I have now in hci_smd
>>
>> Comments on those options are welcome.
>>
>> Anyway, Hci_smd is based on one of the older version of this driver found in msm kernel
>> branch, so there are no wakelocks as in new version and also workqueues are used
>> instead of takslet.
>>
>> Since SMD expose two channels, one for CMD/EVENT and one for ACL Data I decide to
>> do separate worqueues for this. This is to make sure that ACL data never blocks EVENT
>> packages
>>
>
> Adding linux-arm-msm group for comments on SMD API.
>
> BR
> Lukasz
What chip/SoC/board are you trying to get bluetooth support on?
- k
--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation
^ permalink raw reply
* Re: [PATCH 2/3] avrcp: Fix using incorrect buffer for SetVolume
From: Luiz Augusto von Dentz @ 2014-02-11 18:37 UTC (permalink / raw)
To: Andrei Emeltchenko, linux-bluetooth@vger.kernel.org
In-Reply-To: <20140211111504.GE8980@aemeltch-MOBL1>
Hi Andrei,
On Tue, Feb 11, 2014 at 1:15 PM, Andrei Emeltchenko
<Andrei.Emeltchenko.news@gmail.com> wrote:
> On Tue, Feb 04, 2014 at 04:08:17PM +0200, Andrei Emeltchenko wrote:
>> On Thu, Jan 30, 2014 at 06:12:55PM +0200, Andrei Emeltchenko wrote:
>> > From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>> >
>> > The command requires one parameter.
>>
>> ping
>
> ping
>
>>
>> > ---
>> > profiles/audio/avrcp.c | 2 +-
>> > 1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
>> > index 2e1a940..128f7d3 100644
>> > --- a/profiles/audio/avrcp.c
>> > +++ b/profiles/audio/avrcp.c
>> > @@ -3706,7 +3706,7 @@ int avrcp_set_volume(struct btd_device *dev, uint8_t volume)
>> > {
>> > struct avrcp_server *server;
>> > struct avrcp *session;
>> > - uint8_t buf[AVRCP_HEADER_LENGTH + 2];
>> > + uint8_t buf[AVRCP_HEADER_LENGTH + 1];
>> > struct avrcp_header *pdu = (void *) buf;
>> >
>> > server = find_server(servers, device_get_adapter(dev));
>> > --
>> > 1.8.3.2
Ive applied this one, I leave 1/3 for when we have the code properly
decoupled and patch 3/3 I end up redoing most of it to check for
invalid attributes.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 1/2] unit/avctp: Use pre-defined values instead of magic numbers
From: Luiz Augusto von Dentz @ 2014-02-11 18:34 UTC (permalink / raw)
To: Andrei Emeltchenko, linux-bluetooth@vger.kernel.org
In-Reply-To: <20140211111202.GC8980@aemeltch-MOBL1>
Hi Andrei,
On Tue, Feb 11, 2014 at 1:12 PM, Andrei Emeltchenko
<Andrei.Emeltchenko.news@gmail.com> wrote:
> ping
>
> On Wed, Feb 05, 2014 at 05:28:21PM +0200, Andrei Emeltchenko wrote:
>> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>>
>> ---
>> unit/test-avctp.c | 8 ++++----
>> 1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/unit/test-avctp.c b/unit/test-avctp.c
>> index 581f88c..9d94ae0 100644
>> --- a/unit/test-avctp.c
>> +++ b/unit/test-avctp.c
>> @@ -277,8 +277,8 @@ static void test_client(gconstpointer data)
>> {
>> struct context *context = create_context(0x0100, data);
>>
>> - avctp_send_vendordep_req(context->session, 0, 0, NULL, 0,
>> - handler_response, context);
>> + avctp_send_vendordep_req(context->session, AVC_CTYPE_CONTROL, 0, NULL,
>> + 0, handler_response, context);
>>
>> execute_context(context);
>> }
>> @@ -290,8 +290,8 @@ static void test_server(gconstpointer data)
>> if (g_str_equal(context->data->test_name, "/TP/NFR/BV-03-C")) {
>> int ret;
>>
>> - ret = avctp_register_pdu_handler(context->session, 0x00,
>> - handler, NULL);
>> + ret = avctp_register_pdu_handler(context->session,
>> + AVC_OP_VENDORDEP, handler, NULL);
>> DBG("ret %d", ret);
>> g_assert_cmpint(ret, !=, 0);
>> }
>> --
>> 1.8.3.2
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH BlueZ 7/7] android: Add test-ipc to "make check"
From: Anderson Lizardo @ 2014-02-11 18:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1392143552-11395-1-git-send-email-anderson.lizardo@openbossa.org>
---
Makefile.am | 3 ++-
android/Makefile.am | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 1a44a9f..11f2aa1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -178,6 +178,7 @@ EXTRA_DIST += src/genbuiltin src/bluetooth.conf \
profiles/input/input.conf profiles/proximity/proximity.conf
test_scripts =
+unit_tests =
include Makefile.tools
include Makefile.obexd
@@ -222,7 +223,7 @@ AM_CFLAGS += @DBUS_CFLAGS@ @GLIB_CFLAGS@
AM_CPPFLAGS = -I$(builddir)/lib -I$(srcdir)/gdbus
-unit_tests = unit/test-eir unit/test-uuid unit/test-textfile unit/test-crc
+unit_tests += unit/test-eir unit/test-uuid unit/test-textfile unit/test-crc
unit_test_eir_SOURCES = unit/test-eir.c src/eir.c src/uuid-helper.c
unit_test_eir_LDADD = lib/libbluetooth-internal.la @GLIB_LIBS@
diff --git a/android/Makefile.am b/android/Makefile.am
index 5baa8db..1913b42 100644
--- a/android/Makefile.am
+++ b/android/Makefile.am
@@ -153,7 +153,7 @@ android_audio_a2dp_default_la_SOURCES = android/audio-msg.h \
android/hardware/hardware.h \
android/system/audio.h
-noinst_PROGRAMS += android/test-ipc
+unit_tests += android/test-ipc
android_test_ipc_SOURCES = android/test-ipc.c \
src/shared/util.h src/shared/util.c \
--
1.7.9.5
^ permalink raw reply related
* [PATCH BlueZ 6/7] android: Add assertion for ID parameter in ipc_register/ipc_unregister
From: Anderson Lizardo @ 2014-02-11 18:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1392143552-11395-1-git-send-email-anderson.lizardo@openbossa.org>
It is a programming error to pass a invalid ID for these functions (i.e.
the ID is statically defined on the code). Given that this ID is used
for indexing an array, adding an assertion will ensure that improper API
usage will not cause random crashes due to memory corruption.
---
android/ipc.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/android/ipc.c b/android/ipc.c
index ab0f1a4..373345c 100644
--- a/android/ipc.c
+++ b/android/ipc.c
@@ -336,12 +336,16 @@ void ipc_send_notif(uint8_t service_id, uint8_t opcode, uint16_t len,
void ipc_register(uint8_t service, const struct ipc_handler *handlers,
uint8_t size)
{
+ g_assert(service <= HAL_SERVICE_ID_MAX);
+
services[service].handler = handlers;
services[service].size = size;
}
void ipc_unregister(uint8_t service)
{
+ g_assert(service <= HAL_SERVICE_ID_MAX);
+
services[service].handler = NULL;
services[service].size = 0;
}
--
1.7.9.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox