* [PATCH BlueZ 4/9] android/hal-ipc-api: Add Get Player Attributes Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 12 +++++++++++-
android/hal-msg.h | 11 +++++++++++
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 2e4ecbe..27060d5 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1224,7 +1224,17 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
In case of an error, the error response will be returned.
- Opcode 0x04 - Get Player Application Values command/response
+ Opcode 0x04 - Get Player Values Response command/response
+
+ Command parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ Value # (1 octet)
+ ...
+
+ In case of an error, the error response will be returned.
+
+ Valid attributes: Same as in List Player Attributes
+
Opcode 0x05 - Get Player Application Attributes Text command/response
Opcode 0x06 - Get Player Application Values Text command/response
Opcode 0x07 - Get Element Attributes Text command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 2dcdafc..753f5a3 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -816,3 +816,14 @@ struct hal_cmd_avrcp_list_player_values {
uint8_t number;
uint8_t values[0];
} __attribute__((packed));
+
+struct hal_avrcp_player_attr_value {
+ uint8_t attr;
+ uint8_t value;
+} __attribute__((packed));
+
+#define HAL_OP_AVRCP_GET_PLAYER_ATTRS 0x04
+struct hal_cmd_avrcp_get_player_attrs {
+ uint8_t number;
+ struct hal_avrcp_player_attr_value attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 3/9] android/hal-ipc-api: Add List Player Values Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 9 ++++++++-
android/hal-msg.h | 6 ++++++
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index ae58fda..2e4ecbe 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1216,7 +1216,14 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
0x03 = Shuffle
0x04 = Scan
- Opcode 0x03 - List Player Application Values command/response
+ Opcode 0x03 - List Player Values Response command/response
+
+ Command parameters: Number of values (1 octet)
+ Value # (1 octet)
+ ...
+
+ In case of an error, the error response will be returned.
+
Opcode 0x04 - Get Player Application Values command/response
Opcode 0x05 - Get Player Application Attributes Text command/response
Opcode 0x06 - Get Player Application Values Text command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 4a438d1..2dcdafc 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -810,3 +810,9 @@ struct hal_cmd_avrcp_list_player_attrs {
uint8_t number;
uint8_t attrs[0];
} __attribute__((packed));
+
+#define HAL_OP_AVRCP_LIST_PLAYER_VALUES 0x03
+struct hal_cmd_avrcp_list_player_values {
+ uint8_t number;
+ uint8_t values[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 2/9] android/hal-ipc-api: Add List Player Attributes Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392216494-30885-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 14 +++++++++++++-
android/hal-msg.h | 11 +++++++++++
2 files changed, 24 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index 01c2e81..ae58fda 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1203,7 +1203,19 @@ Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
0x04 = Rev seek
0xff = Error
- Opcode 0x02 - List Player Application Attributes command/response
+ Opcode 0x02 - List Player Attributes Response command/response
+
+ Command parameters: Number of attributes (1 octet)
+ Attribute # (1 octet)
+ ...
+
+ In case of an error, the error response will be returned.
+
+ Valid attributes: 0x01 = Equalizer
+ 0x02 = Repead
+ 0x03 = Shuffle
+ 0x04 = Scan
+
Opcode 0x03 - List Player Application Values command/response
Opcode 0x04 - Get Player Application Values command/response
Opcode 0x05 - Get Player Application Attributes Text command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 82cd3f5..4a438d1 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -799,3 +799,14 @@ struct hal_cmd_avrcp_get_play_status {
uint32_t duration;
uint32_t position;
} __attribute__((packed));
+
+#define HAL_AVRCP_PLAYER_ATTR_EQUALIZER 0x01
+#define HAL_AVRCP_PLAYER_ATTR_REPEAT 0x02
+#define HAL_AVRCP_PLAYER_ATTR_SHUFFLE 0x03
+#define HAL_AVRCP_PLAYER_ATTR_SCAN 0x04
+
+#define HAL_OP_AVRCP_LIST_PLAYER_ATTRS 0x02
+struct hal_cmd_avrcp_list_player_attrs {
+ uint8_t number;
+ uint8_t attrs[0];
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* [PATCH BlueZ 1/9] android/hal-ipc-api: Add Get Play Status Response
From: Luiz Augusto von Dentz @ 2014-02-12 14:48 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
---
android/hal-ipc-api.txt | 30 +++++++++++++++++++++++++++++-
android/hal-msg.h | 16 ++++++++++++++++
2 files changed, 45 insertions(+), 1 deletion(-)
diff --git a/android/hal-ipc-api.txt b/android/hal-ipc-api.txt
index ad5d192..01c2e81 100644
--- a/android/hal-ipc-api.txt
+++ b/android/hal-ipc-api.txt
@@ -1174,7 +1174,35 @@ Bluetooth Remote Control HAL (ID 8)
Android HAL name: "avrcp" (BT_PROFILE_AV_RC_ID)
Opcode 0x00 - Error response
- Opcode 0x01 - Get Play Status command/response
+
+ Response parameters: Status (1 octet)
+
+ Valid status values: 0x01 = Fail
+ 0x02 = Not ready
+ 0x03 = No memory
+ 0x04 = Busy
+ 0x05 = Done (already completed)
+ 0x06 = Unsupported
+ 0x07 = Parameter invalid
+ 0x08 = Unhandled
+ 0x09 = Authentication failure
+ 0x0a = Remote device down
+
+ Opcode 0x01 - Get Play Status Response command/response
+
+ Command parameters: Status (1 octet)
+ Duration (4 octets)
+ Position (4 octets)
+
+ In case of an error, the error response will be returned.
+
+ Valid status values: 0x00 = Stopped
+ 0x01 = Playing
+ 0x02 = Paused
+ 0x03 = Fwd seek
+ 0x04 = Rev seek
+ 0xff = Error
+
Opcode 0x02 - List Player Application Attributes command/response
Opcode 0x03 - List Player Application Values command/response
Opcode 0x04 - Get Player Application Values command/response
diff --git a/android/hal-msg.h b/android/hal-msg.h
index 6ef00f9..82cd3f5 100644
--- a/android/hal-msg.h
+++ b/android/hal-msg.h
@@ -783,3 +783,19 @@ struct hal_ev_handsfree_unknown_at {
} __attribute__((packed));
#define HAL_EV_HANDSFREE_HSP_KEY_PRESS 0x90
+
+/* AVRCP HAL API */
+
+#define HAL_AVRCP_PLAY_STATUS_STOPPED 0x00
+#define HAL_AVRCP_PLAY_STATUS_PLAYING 0x01
+#define HAL_AVRCP_PLAY_STATUS_PAUSED 0x02
+#define HAL_AVRCP_PLAY_STATUS_FWD_SEEK 0x03
+#define HAL_AVRCP_PLAY_STATUS_REV_SEEK 0x04
+#define HAL_AVRCP_PLAY_STATUS_ERROR 0xff
+
+#define HAL_OP_AVRCP_GET_PLAY_STATUS 0x01
+struct hal_cmd_avrcp_get_play_status {
+ uint8_t status;
+ uint32_t duration;
+ uint32_t position;
+} __attribute__((packed));
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH] android/socket: Fix wrong memory access
From: Szymon Janc @ 2014-02-12 14:24 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1392214396-2576-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Wednesday 12 of February 2014 16:13:16 Andrei Emeltchenko wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> This fixes accessing proto[2] in the code.
> ---
> android/socket.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/android/socket.c b/android/socket.c
> index c62ca61..1551e9b 100644
> --- a/android/socket.c
> +++ b/android/socket.c
> @@ -190,7 +190,7 @@ static sdp_record_t *create_rfcomm_record(uint8_t chan,
> uuid_t *uuid, {
> sdp_list_t *svclass_id;
> sdp_list_t *seq, *proto_seq, *pbg_seq;
> - sdp_list_t *proto[2];
> + sdp_list_t *proto[3];
> uuid_t l2cap_uuid, rfcomm_uuid, obex_uuid, pbg_uuid;
> sdp_data_t *channel;
> sdp_record_t *record;
Pushed, thanks.
--
BR
Szymon Janc
^ permalink raw reply
* [PATCH] android: Fix memory leak: uuid free
From: Andrei Emeltchenko @ 2014-02-12 14:22 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Free uuid before exiting.
---
android/bluetooth.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/android/bluetooth.c b/android/bluetooth.c
index 5de3401..b818e88 100644
--- a/android/bluetooth.c
+++ b/android/bluetooth.c
@@ -1557,6 +1557,8 @@ int bt_adapter_add_record(sdp_record_t *rec, uint8_t svc_hint)
sdp_uuid2strn(uuid, uuid_str, sizeof(uuid_str));
DBG("UUID %s already added", uuid_str);
+
+ bt_free(uuid);
return -EALREADY;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH] android/socket: Fix wrong memory access
From: Andrei Emeltchenko @ 2014-02-12 14:13 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
This fixes accessing proto[2] in the code.
---
android/socket.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/android/socket.c b/android/socket.c
index c62ca61..1551e9b 100644
--- a/android/socket.c
+++ b/android/socket.c
@@ -190,7 +190,7 @@ static sdp_record_t *create_rfcomm_record(uint8_t chan, uuid_t *uuid,
{
sdp_list_t *svclass_id;
sdp_list_t *seq, *proto_seq, *pbg_seq;
- sdp_list_t *proto[2];
+ sdp_list_t *proto[3];
uuid_t l2cap_uuid, rfcomm_uuid, obex_uuid, pbg_uuid;
sdp_data_t *channel;
sdp_record_t *record;
--
1.8.3.2
^ permalink raw reply related
* [RFCV2] android/avrcp: Decouple AVRCP logic from btio
From: Andrei Emeltchenko @ 2014-02-12 13:13 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <5637916.N4zjDhQ0cI@leonov>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
The patch makes AVRCP to be channel-agnostic so that it might be used in
unit tests. The idea is that all AVRCP logic would come to avrcp-lib and
channel stuff got to avrcp.
---
android/Android.mk | 1 +
android/Makefile.am | 1 +
android/avrcp-lib.c | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++
android/avrcp-lib.h | 29 +++++++++++++++++++++++++
android/avrcp.c | 28 ++++++++++++++++--------
5 files changed, 112 insertions(+), 9 deletions(-)
create mode 100644 android/avrcp-lib.c
create mode 100644 android/avrcp-lib.h
diff --git a/android/Android.mk b/android/Android.mk
index 71d678b..fa9a86e 100644
--- a/android/Android.mk
+++ b/android/Android.mk
@@ -39,6 +39,7 @@ LOCAL_SRC_FILES := \
bluez/android/avdtp.c \
bluez/android/a2dp.c \
bluez/android/avctp.c \
+ bluez/android/avrcp-lib.c \
bluez/android/avrcp.c \
bluez/android/pan.c \
bluez/android/handsfree.c \
diff --git a/android/Makefile.am b/android/Makefile.am
index 1913b42..07cc851 100644
--- a/android/Makefile.am
+++ b/android/Makefile.am
@@ -36,6 +36,7 @@ android_bluetoothd_SOURCES = android/main.c \
android/avdtp.h android/avdtp.c \
android/a2dp.h android/a2dp.c \
android/avctp.h android/avctp.c \
+ android/avrcp-lib.h android/avrcp-lib.c \
android/avrcp.h android/avrcp.c \
android/socket.h android/socket.c \
android/pan.h android/pan.c \
diff --git a/android/avrcp-lib.c b/android/avrcp-lib.c
new file mode 100644
index 0000000..080e37a
--- /dev/null
+++ b/android/avrcp-lib.c
@@ -0,0 +1,62 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#include <stdbool.h>
+#include <glib.h>
+
+#include "lib/bluetooth.h"
+
+#include "src/log.h"
+
+#include "avctp.h"
+#include "avrcp-lib.h"
+
+void avrcp_free(void *data)
+{
+ struct avrcp *session = data;
+
+ if (session->session)
+ avctp_shutdown(session->session);
+
+ g_free(session);
+}
+
+struct avrcp *avrcp_new(int fd, size_t imtu, size_t omtu,
+ uint16_t version)
+{
+ struct avrcp *session;
+
+ session = g_new0(struct avrcp, 1);
+
+ session->session = avctp_new(fd, imtu, omtu, version);
+ if (!session->session) {
+ g_free(session);
+ return NULL;
+ }
+
+ return session;
+}
diff --git a/android/avrcp-lib.h b/android/avrcp-lib.h
new file mode 100644
index 0000000..f1dbf0d
--- /dev/null
+++ b/android/avrcp-lib.h
@@ -0,0 +1,29 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2014 Intel Corporation. All rights reserved.
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+struct avrcp {
+ struct avctp *session;
+};
+
+struct avrcp *avrcp_new(int fd, size_t imtu, size_t omtu, uint16_t version);
+void avrcp_free(void *data);
diff --git a/android/avrcp.c b/android/avrcp.c
index b8304f5..3d3e323 100644
--- a/android/avrcp.c
+++ b/android/avrcp.c
@@ -38,6 +38,7 @@
#include "hal-msg.h"
#include "ipc.h"
#include "avctp.h"
+#include "avrcp-lib.h"
#define L2CAP_PSM_AVCTP 0x17
@@ -53,7 +54,7 @@ static GIOChannel *server = NULL;
struct avrcp_device {
bdaddr_t dst;
- struct avctp *session;
+ struct avrcp *session;
GIOChannel *io;
};
@@ -133,7 +134,7 @@ static void avrcp_device_free(void *data)
struct avrcp_device *dev = data;
if (dev->session)
- avctp_shutdown(dev->session);
+ avrcp_free(dev->session);
if (dev->io) {
g_io_channel_shutdown(dev->io, FALSE, NULL);
@@ -168,6 +169,17 @@ static int device_cmp(gconstpointer s, gconstpointer user_data)
return bacmp(&dev->dst, dst);
}
+static struct avrcp_device *avrcp_find(const bdaddr_t *dst)
+{
+ GSList *l;
+
+ l = g_slist_find_custom(devices, dst, device_cmp);
+ if (!l)
+ return NULL;
+
+ return l->data;
+}
+
static void disconnect_cb(void *data)
{
struct avrcp_device *dev = data;
@@ -222,17 +234,17 @@ static void connect_cb(GIOChannel *chan, GError *err, gpointer user_data)
}
fd = g_io_channel_unix_get_fd(chan);
- dev->session = avctp_new(fd, imtu, omtu, 0x0100);
+ dev->session = avrcp_new(fd, imtu, omtu, 0x0100);
if (!dev->session) {
avrcp_device_free(dev);
return;
}
- avctp_set_destroy_cb(dev->session, disconnect_cb, dev);
+ avctp_set_destroy_cb(dev->session->session, disconnect_cb, dev);
/* FIXME: get the real name of the device */
- avctp_init_uinput(dev->session, "bluetooth", address);
+ avctp_init_uinput(dev->session->session, "bluetooth", address);
g_io_channel_set_close_on_unref(chan, FALSE);
@@ -331,12 +343,10 @@ void bt_avrcp_connect(const bdaddr_t *dst)
{
struct avrcp_device *dev;
char addr[18];
- GSList *l;
DBG("");
- l = g_slist_find_custom(devices, dst, device_cmp);
- if (l)
+ if (avrcp_find(dst))
return;
dev = avrcp_device_new(dst);
@@ -363,7 +373,7 @@ void bt_avrcp_disconnect(const bdaddr_t *dst)
dev = l->data;
if (dev->session) {
- avctp_shutdown(dev->session);
+ avrcp_free(dev->session);
return;
}
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH v2] android/README: Update with implementation status summary
From: Szymon Janc @ 2014-02-12 13:00 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392115207-14297-1-git-send-email-szymon.janc@tieto.com>
Hi,
On Tuesday 11 of February 2014 11:40:07 Szymon Janc wrote:
> This will give a better overview of implemented features.
> ---
> android/README | 38 +++++++++++++++++++++++++++++++++-----
> 1 file changed, 33 insertions(+), 5 deletions(-)
>
> diff --git a/android/README b/android/README
> index e3c314f..b987dc9 100644
> --- a/android/README
> +++ b/android/README
> @@ -132,15 +132,43 @@ automatically on HAL library initialization. To
> deinitialize HAL library and stop daemon type 'bluetooth cleanup'. Type
> 'help' for more information. Tab completion is also supported.
>
> +=====================
> +Implementation status
> +=====================
> +
> +Summary of HALs implementation status.
> +
> +complete - implementation is feature complete and Android Framework is
> able + to use it normally
> +partial - implementation is in progress and not all required features
> are + present, Android Framework is able to use some of
> features +initial - only initial implementations is present, Android
> Framework is + able to initialize but most likely not able to
> use it +not started - no implementation, Android Framework is not able to
> initialize it +
> +Profile ID HAL header Status
> +---------------------------------------
> +core bluetooth.h complete
> +a2dp bt_av.h complete
> +gatt bt_gatt.h not started
> + bt_gatt_client.h not started
> + bt_gatt_server.h not started
> +handsfree bt_hf.h initial
> +hidhost bt_hh.h complete
> +health bt_hl.h not started
> +pan bt_pan.h complete
> +avrcp bt_rc.h partial
> +socket bt_sock.h partial
> +
> ===========================
> Implementation shortcomings
> ===========================
>
> -It is possible that some of HAL functionality is missing implementation due
> to -reasons like feature feasibility or necessity for latest Android
> Framework. -This sections provides list of such deficiencies. Note that HAL
> library is -always expected to fully implement HAL API so missing
> implementation might -happen only in daemon.
> +It is possible that some of HAL functionality (although being marked as
> +complete) is missing implementation due to reasons like feature feasibility
> or +necessity for latest Android Framework. This sections provides list of
> such +deficiencies. Note that HAL library is always expected to fully
> implement HAL +API so missing implementation might happen only in daemon.
>
> HAL Bluetooth
> =============
Pushed.
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 00/11] Socket HAL updates
From: Szymon Janc @ 2014-02-12 12:55 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: Andrzej Kaczmarek, linux-bluetooth
In-Reply-To: <20140212095739.GA25950@aemeltch-MOBL1>
Hi Andrei,
On Wednesday 12 of February 2014 11:57:41 Andrei Emeltchenko wrote:
> 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.
I find new names a bit easier to understand and this is now applied.
--
BR
Szymon Janc
^ permalink raw reply
* Re: [PATCH 00/11] Socket HAL updates
From: Szymon Janc @ 2014-02-12 12:54 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 Tuesday 11 of February 2014 17:58:10 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.
>
> 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(-)
All patches in this set are now upstream, thanks a lot.
--
BR
Szymon Janc
^ permalink raw reply
* 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
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