* Re: [PATCH 1/3] android/tester: Add Socket test read channel number after listen
From: Johan Hedberg @ 2013-12-16 9:14 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1387183137-19439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Mon, Dec 16, 2013, Andrei Emeltchenko wrote:
> After listen() call Bluedroid sends channel number as (int) through file
> descriptor.
> ---
> android/android-tester.c | 27 +++++++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
All three patches have been applied. Thanks.
Johan
^ permalink raw reply
* [PATCH 5/5] hciemu: Print error in case hci_vhci is not loaded
From: Andrei Emeltchenko @ 2013-12-16 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1387184262-21439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Error message should indicate that module is not loaded:
Opening /dev/vhci failed: No such file or directory
---
src/shared/hciemu.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/shared/hciemu.c b/src/shared/hciemu.c
index c2b4748..9f4bfaf 100644
--- a/src/shared/hciemu.c
+++ b/src/shared/hciemu.c
@@ -31,6 +31,7 @@
#include <stdlib.h>
#include <string.h>
#include <stdbool.h>
+#include <errno.h>
#include <sys/socket.h>
#include <glib.h>
@@ -216,6 +217,7 @@ static bool create_vhci(struct hciemu *hciemu)
fd = open("/dev/vhci", O_RDWR | O_NONBLOCK | O_CLOEXEC);
if (fd < 0) {
+ perror("Opening /dev/vhci failed");
btdev_destroy(btdev);
return false;
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 4/5] l2cap-tester: Remove unneeded variable
From: Andrei Emeltchenko @ 2013-12-16 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1387184262-21439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
err is only used to assign -errno before return.
---
tools/l2cap-tester.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/tools/l2cap-tester.c b/tools/l2cap-tester.c
index e4dade2..4b1e5e2 100644
--- a/tools/l2cap-tester.c
+++ b/tools/l2cap-tester.c
@@ -489,15 +489,14 @@ static int create_l2cap_sock(struct test_data *data, uint16_t psm)
{
const uint8_t *master_bdaddr;
struct sockaddr_l2 addr;
- int sk, err;
+ int sk;
sk = socket(PF_BLUETOOTH, SOCK_SEQPACKET | SOCK_NONBLOCK,
BTPROTO_L2CAP);
if (sk < 0) {
- err = -errno;
tester_warn("Can't create socket: %s (%d)", strerror(errno),
errno);
- return err;
+ return -errno;
}
master_bdaddr = hciemu_get_master_bdaddr(data->hciemu);
@@ -517,11 +516,10 @@ static int create_l2cap_sock(struct test_data *data, uint16_t psm)
addr.l2_bdaddr_type = BDADDR_BREDR;
if (bind(sk, (struct sockaddr *) &addr, sizeof(addr)) < 0) {
- err = -errno;
tester_warn("Can't bind socket: %s (%d)", strerror(errno),
errno);
close(sk);
- return err;
+ return -errno;
}
return sk;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/5] hciemu: Make code consistent
From: Andrei Emeltchenko @ 2013-12-16 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1387184262-21439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
It is enough to check for zero in __sync_sub_and_fetch(). This makes
code consistent like shown below:
./src/shared/mgmt.c: if (__sync_sub_and_fetch(&mgmt->ref_count, 1))
./src/shared/pcap.c: if (__sync_sub_and_fetch(&pcap->ref_count, 1))
./src/shared/btsnoop.c: if (__sync_sub_and_fetch(&btsnoop->ref_count, 1))
./src/shared/hciemu.c: if (__sync_sub_and_fetch(&hciemu->ref_count, 1))
---
src/shared/hciemu.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/shared/hciemu.c b/src/shared/hciemu.c
index 0ea191f..c2b4748 100644
--- a/src/shared/hciemu.c
+++ b/src/shared/hciemu.c
@@ -341,7 +341,7 @@ void hciemu_unref(struct hciemu *hciemu)
if (!hciemu)
return;
- if (__sync_sub_and_fetch(&hciemu->ref_count, 1) > 0)
+ if (__sync_sub_and_fetch(&hciemu->ref_count, 1))
return;
g_list_foreach(hciemu->post_command_hooks, destroy_command_hook, NULL);
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/5] avdtp: Remove unneeded local variable
From: Andrei Emeltchenko @ 2013-12-16 8:57 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1387184262-21439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
profiles/audio/avdtp.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/profiles/audio/avdtp.c b/profiles/audio/avdtp.c
index f866b39..e12ad9d 100644
--- a/profiles/audio/avdtp.c
+++ b/profiles/audio/avdtp.c
@@ -773,10 +773,9 @@ static int get_send_buffer_size(int sk)
socklen_t optlen = sizeof(size);
if (getsockopt(sk, SOL_SOCKET, SO_SNDBUF, &size, &optlen) < 0) {
- int err = -errno;
- error("getsockopt(SO_SNDBUF) failed: %s (%d)", strerror(-err),
- -err);
- return err;
+ error("getsockopt(SO_SNDBUF) failed: %s (%d)", strerror(errno),
+ errno);
+ return -errno;
}
/*
@@ -792,10 +791,9 @@ static int set_send_buffer_size(int sk, int size)
socklen_t optlen = sizeof(size);
if (setsockopt(sk, SOL_SOCKET, SO_SNDBUF, &size, optlen) < 0) {
- int err = -errno;
- error("setsockopt(SO_SNDBUF) failed: %s (%d)", strerror(-err),
- -err);
- return err;
+ error("setsockopt(SO_SNDBUF) failed: %s (%d)", strerror(errno),
+ errno);
+ return -errno;
}
return 0;
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/5] btmgmt: Remove unneeded code
From: Andrei Emeltchenko @ 2013-12-16 8:57 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
tools/btmgmt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/tools/btmgmt.c b/tools/btmgmt.c
index 1d71d74..f31d8b1 100644
--- a/tools/btmgmt.c
+++ b/tools/btmgmt.c
@@ -555,7 +555,6 @@ static void user_confirm(uint16_t index, uint16_t len, const void *param,
rsp_len = strlen(rsp);
if (rsp[rsp_len - 1] == '\n') {
rsp[rsp_len - 1] = '\0';
- rsp_len--;
}
if (rsp[0] == 'y' || rsp[0] == 'Y')
--
1.8.3.2
^ permalink raw reply related
* [PATCH 3/3] android/tester: Add Socket test invalid bdaddr
From: Andrei Emeltchenko @ 2013-12-16 8:38 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1387183137-19439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Test for zero bluetooth address in connect().
---
android/android-tester.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/android/android-tester.c b/android/android-tester.c
index 9acc79d..eb938d0 100644
--- a/android/android-tester.c
+++ b/android/android-tester.c
@@ -832,6 +832,16 @@ static const struct socket_data btsock_success_check_chan = {
.test_channel = true,
};
+static const struct socket_data btsock_inv_param_bdaddr = {
+ .bdaddr = NULL,
+ .sock_type = BTSOCK_RFCOMM,
+ .channel = 1,
+ .service_uuid = NULL,
+ .service_name = "Test service",
+ .flags = 0,
+ .expected_status = BT_STATUS_PARM_INVALID,
+};
+
static void setup_socket_interface(const void *test_data)
{
struct test_data *data = tester_get_data();
@@ -1075,5 +1085,9 @@ int main(int argc, char *argv[])
&btsock_inv_params_chan_uuid,
setup_socket_interface, test_generic_connect, teardown);
+ test_bredrle("Socket Connect - Invalid: bdaddr",
+ &btsock_inv_param_bdaddr,
+ setup_socket_interface, test_generic_connect, teardown);
+
return tester_run();
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 2/3] android/tester: Add Socket test invalid chan and uuid
From: Andrei Emeltchenko @ 2013-12-16 8:38 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1387183137-19439-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
At least one of parameters: channel or uuid shouldn't be zero.
---
android/android-tester.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/android/android-tester.c b/android/android-tester.c
index 9b56616..9acc79d 100644
--- a/android/android-tester.c
+++ b/android/android-tester.c
@@ -804,6 +804,7 @@ static const struct socket_data btsock_inv_param_socktype_l2cap = {
/* Test invalid: channel & uuid are both zeroes */
static const struct socket_data btsock_inv_params_chan_uuid = {
+ .bdaddr = &bdaddr_dummy,
.sock_type = BTSOCK_RFCOMM,
.channel = 0,
.service_uuid = NULL,
@@ -1070,5 +1071,9 @@ int main(int argc, char *argv[])
&btsock_inv_param_socktype_l2cap,
setup_socket_interface, test_generic_connect, teardown);
+ test_bredrle("Socket Connect - Invalid: chan, uuid",
+ &btsock_inv_params_chan_uuid,
+ setup_socket_interface, test_generic_connect, teardown);
+
return tester_run();
}
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/3] android/tester: Add Socket test read channel number after listen
From: Andrei Emeltchenko @ 2013-12-16 8:38 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
After listen() call Bluedroid sends channel number as (int) through file
descriptor.
---
android/android-tester.c | 27 +++++++++++++++++++++++++++
1 file changed, 27 insertions(+)
diff --git a/android/android-tester.c b/android/android-tester.c
index a58104d..9b56616 100644
--- a/android/android-tester.c
+++ b/android/android-tester.c
@@ -82,6 +82,7 @@ struct socket_data {
int channel;
int flags;
bt_status_t expected_status;
+ bool test_channel;
};
#define WAIT_FOR_SIGNAL_TIME 2 /* in seconds */
@@ -820,6 +821,16 @@ static const struct socket_data btsock_success = {
.expected_status = BT_STATUS_SUCCESS,
};
+static const struct socket_data btsock_success_check_chan = {
+ .sock_type = BTSOCK_RFCOMM,
+ .channel = 1,
+ .service_uuid = NULL,
+ .service_name = "Test service",
+ .flags = 0,
+ .expected_status = BT_STATUS_SUCCESS,
+ .test_channel = true,
+};
+
static void setup_socket_interface(const void *test_data)
{
struct test_data *data = tester_get_data();
@@ -857,6 +868,18 @@ static void test_generic_listen(const void *test_data)
return;
}
+ if (status == BT_STATUS_SUCCESS && test->test_channel) {
+ int channel, len;
+
+ len = read(sock_fd, &channel, sizeof(channel));
+ if (len != sizeof(channel) || channel != test->channel) {
+ tester_test_failed();
+ goto clean;
+ }
+
+ tester_print("read correct channel: %d", channel);
+ }
+
tester_test_passed();
clean:
@@ -1035,6 +1058,10 @@ int main(int argc, char *argv[])
&btsock_success,
setup_socket_interface, test_generic_listen, teardown);
+ test_bredrle("Socket Listen - Check returned channel",
+ &btsock_success_check_chan,
+ setup_socket_interface, test_generic_listen, teardown);
+
test_bredrle("Socket Connect - Invalid: sock_type 0",
&btsock_inv_param_socktype, setup_socket_interface,
test_generic_connect, teardown);
--
1.8.3.2
^ permalink raw reply related
* Re: [PATCH] Add PICS, PIXITs and PTS test results for L2CAP
From: Johan Hedberg @ 2013-12-16 8:17 UTC (permalink / raw)
To: Sebastian Chlad; +Cc: linux-bluetooth, Sebastian Chlad
In-Reply-To: <1387147192-19246-1-git-send-email-sebastianx.chlad@intel.com>
Hi Sebastian,
On Sun, Dec 15, 2013, Sebastian Chlad wrote:
> +* - different than PTS defaults
> +# - not yet implemented/supported
> +
> +M - mandatory
> +O - optional
> +
> + Roles
> +-------------------------------------------------------------------------------
> +Parameter Name Selected Description
> +-------------------------------------------------------------------------------
> +TSPC_L2CAP_1_1 True Data Channel Initiator (C.1)
> +TSPC_L2CAP_1_2 True Data Channel Acceptor (C.1)
> +TSPC_L2CAP_1_3 False (#) LE Master (C.2)
> +TSPC_L2CAP_1_4 False (#) LE Slave (C.2)
I thought the idea of the '#' notation was that we could mark entries as
True if they eventually will be supported but are not yet implemented.
Wouldn't these last two entries fall under this category.
> +-------------------------------------------------------------------------------
> +Test Name Result Notes
> +-------------------------------------------------------------------------------
> +TC_COS_CED_BV_01_C INC IUT should introduce testing tools
> +TC_COS_CED_BV_03_C INC IUT should introduce testing tools
What does the note here mean. l2test? If so wouldn't it be more helpful
to list the exact l2test command that's needs to be run?
Johan
^ permalink raw reply
* Re: [PATCH] android/tester: Fix syntax of test cases
From: Johan Hedberg @ 2013-12-16 8:11 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1387181005-12044-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Mon, Dec 16, 2013, Andrei Emeltchenko wrote:
> Remove "Test" from every test message print and correct typo.
> ---
> android/android-tester.c | 36 ++++++++++++++++++------------------
> 1 file changed, 18 insertions(+), 18 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] emulator/bthost: Fix use after free in bthost_destroy
From: Johan Hedberg @ 2013-12-16 8:07 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1387137348-5377-1-git-send-email-szymon.janc@gmail.com>
Hi Szymon,
On Sun, Dec 15, 2013, Szymon Janc wrote:
> cmd was dereferenced after free. Use temp pointer for freeing.
> ---
> emulator/bthost.c | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Adding missing test scripts to Makefile.tools
From: Johan Hedberg @ 2013-12-16 8:06 UTC (permalink / raw)
To: Sebastian Chlad; +Cc: linux-bluetooth, Sebastian Chlad
In-Reply-To: <1387108069-9616-1-git-send-email-sebastianx.chlad@intel.com>
Hi Sebastian,
On Sun, Dec 15, 2013, Sebastian Chlad wrote:
> ---
> Makefile.tools | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
Applied (after fixing up the commit message prefix). Thanks.
Johan
^ permalink raw reply
* [PATCH] android/tester: Fix syntax of test cases
From: Andrei Emeltchenko @ 2013-12-16 8:03 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Remove "Test" from every test message print and correct typo.
---
android/android-tester.c | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/android/android-tester.c b/android/android-tester.c
index f388d94..a58104d 100644
--- a/android/android-tester.c
+++ b/android/android-tester.c
@@ -811,7 +811,7 @@ static const struct socket_data btsock_inv_params_chan_uuid = {
.expected_status = BT_STATUS_PARM_INVALID,
};
-static const struct socket_data btsock_sucess = {
+static const struct socket_data btsock_success = {
.sock_type = BTSOCK_RFCOMM,
.channel = 1,
.service_uuid = NULL,
@@ -980,66 +980,66 @@ int main(int argc, char *argv[])
tester_init(&argc, &argv);
- test_bredrle("Test Init", NULL, setup_base, test_dummy, teardown);
+ test_bredrle("Init", NULL, setup_base, test_dummy, teardown);
- test_bredrle("Test Enable - Success", &bluetooth_enable_success_test,
+ test_bredrle("Enable - Success", &bluetooth_enable_success_test,
setup_base, test_enable, teardown);
- test_bredrle("Test Enable - Done", &bluetooth_enable_done_test,
+ test_bredrle("Enable - Done", &bluetooth_enable_done_test,
setup_enabled_adapter, test_enable_done, teardown);
- test_bredrle("Test Disable - Success", &bluetooth_disable_success_test,
+ test_bredrle("Disable - Success", &bluetooth_disable_success_test,
setup_enabled_adapter, test_disable, teardown);
- test_bredrle("Test Set BDNAME - Success",
+ test_bredrle("Set BDNAME - Success",
&bluetooth_setprop_bdname_success_test,
setup_enabled_adapter,
test_setprop_bdname_success, teardown);
- test_bredrle("Test Set SCAN_MODE - Success",
+ test_bredrle("Set SCAN_MODE - Success",
&bluetooth_setprop_scanmode_success_test,
setup_enabled_adapter,
test_setprop_scanmode_succes, teardown);
- test_bredrle("Test Set DISCOVERY_TIMEOUT - Success",
+ test_bredrle("Set DISCOVERY_TIMEOUT - Success",
&bluetooth_setprop_disctimeout_success_test,
setup_enabled_adapter,
test_setprop_disctimeout_succes, teardown);
- test_bredrle("Test Get BDADDR - Success",
+ test_bredrle("Get BDADDR - Success",
&bluetooth_getprop_bdaddr_success_test,
setup_enabled_adapter,
test_getprop_bdaddr_success, teardown);
- test_bredrle("Test Get BDNAME - Success",
+ test_bredrle("Get BDNAME - Success",
&bluetooth_getprop_bdname_success_test,
setup_enabled_adapter,
test_getprop_bdname_success, teardown);
- test_bredrle("Test Socket Init", NULL, setup_socket_interface,
+ test_bredrle("Socket Init", NULL, setup_socket_interface,
test_dummy, teardown);
- test_bredrle("Test Socket Listen - Invalid: sock_type 0",
+ test_bredrle("Socket Listen - Invalid: sock_type 0",
&btsock_inv_param_socktype, setup_socket_interface,
test_generic_listen, teardown);
- test_bredrle("Test Socket Listen - Invalid: sock_type L2CAP",
+ test_bredrle("Socket Listen - Invalid: sock_type L2CAP",
&btsock_inv_param_socktype_l2cap,
setup_socket_interface, test_generic_listen, teardown);
- test_bredrle("Test Socket Listen - Invalid: chan, uuid",
+ test_bredrle("Socket Listen - Invalid: chan, uuid",
&btsock_inv_params_chan_uuid,
setup_socket_interface, test_generic_listen, teardown);
- test_bredrle("Test Socket Listen - Check returned fd valid",
- &btsock_sucess,
+ test_bredrle("Socket Listen - Check returned fd valid",
+ &btsock_success,
setup_socket_interface, test_generic_listen, teardown);
- test_bredrle("Test Socket Connect - Invalid: sock_type 0",
+ test_bredrle("Socket Connect - Invalid: sock_type 0",
&btsock_inv_param_socktype, setup_socket_interface,
test_generic_connect, teardown);
- test_bredrle("Test Socket Connect - Invalid: sock_type L2CAP",
+ test_bredrle("Socket Connect - Invalid: sock_type L2CAP",
&btsock_inv_param_socktype_l2cap,
setup_socket_interface, test_generic_connect, teardown);
--
1.8.3.2
^ permalink raw reply related
* [PATCH] Add PICS, PIXITs and PTS test results for L2CAP
From: Sebastian Chlad @ 2013-12-15 22:39 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Sebastian Chlad
This allows better tracking of the current state of implementation
---
android/pics-l2cap.txt | 157 ++++++++++++++++++++++++++
android/pixit-l2cap.txt | 39 +++++++
android/pts-l2cap.txt | 293 ++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 489 insertions(+)
create mode 100644 android/pics-l2cap.txt
create mode 100644 android/pixit-l2cap.txt
create mode 100644 android/pts-l2cap.txt
diff --git a/android/pics-l2cap.txt b/android/pics-l2cap.txt
new file mode 100644
index 0000000..72ec932
--- /dev/null
+++ b/android/pics-l2cap.txt
@@ -0,0 +1,157 @@
+L2CAP PICS for the PTS tool.
+
+* - different than PTS defaults
+# - not yet implemented/supported
+
+M - mandatory
+O - optional
+
+ Roles
+-------------------------------------------------------------------------------
+Parameter Name Selected Description
+-------------------------------------------------------------------------------
+TSPC_L2CAP_1_1 True Data Channel Initiator (C.1)
+TSPC_L2CAP_1_2 True Data Channel Acceptor (C.1)
+TSPC_L2CAP_1_3 False (#) LE Master (C.2)
+TSPC_L2CAP_1_4 False (#) LE Slave (C.2)
+-------------------------------------------------------------------------------
+C.1: Mandatory IF BR/EDR or BR/EDR/LE is claimed, ELSE Excluded.
+C.2: Mandatory to support (at least one of TSPC_L2CAP_1_3 or TSPC_L2CAP_1_4)
+ IF LE or BR/EDR/LE claimed, ELSE Excluded.
+-------------------------------------------------------------------------------
+
+
+ General Operation
+-------------------------------------------------------------------------------
+Parameter Name Selected Description
+-------------------------------------------------------------------------------
+TSPC_L2CAP_2_1 True Support of L2CAP signaling channel (C.20)
+TSPC_L2CAP_2_2 True Support of configuration process (C.20)
+TSPC_L2CAP_2_4 True Support of command echo request (C.21)
+TSPC_L2CAP_2_3 True Support of connection oriented data
+ channel (C.20)
+TSPC_L2CAP_2_5 True Support of command echo response (C.20)
+TSPC_L2CAP_2_6 True (*) Support of command information request (C.21)
+TSPC_L2CAP_2_7 True Support of command information response (C.20)
+TSPC_L2CAP_2_8 False Support of a channel group (C.21)
+TSPC_L2CAP_2_9 False Support of packet for connectionless
+ channel (C.21)
+TSPC_L2CAP_2_10 False Support retransmission mode (C.21)
+TSPC_L2CAP_2_11 False Support flow control mode(C.21)
+TSPC_L2CAP_2_12 True (*) Enhanced Retransmission Mode (C.1, C.13)
+TSPC_L2CAP_2_13 True (*) Streaming Mode (C.1, C.14)
+TSPC_L2CAP_2_14 True (*) FCS Option (C.2)
+TSPC_L2CAP_2_15 True (*) Generate Local Busy Condition (C.3)
+TSPC_L2CAP_2_16 True (*) Send Reject (C.3)
+TSPC_L2CAP_2_17 True (*) Send Selective Reject (C.3)
+TSPC_L2CAP_2_18 True (*) Mandatory use of ERTM (C.4)
+TSPC_L2CAP_2_19 True (*) Mandatory use of Streaming Mode (C.5)
+TSPC_L2CAP_2_20 True (*) Optional use of ERTM (C.4)
+TSPC_L2CAP_2_21 True (*) Optional use of Streaming Mode (C.5)
+TSPC_L2CAP_2_22 True (*) Send data using SAR in ERTM (C.6)
+TSPC_L2CAP_2_23 True (*) Send data using SAR in Streaming Mode (C.7)
+TSPC_L2CAP_2_24 True (*) Actively request Basic Mode for a PSM that
+ supports the use of ERTM or Streaming
+ Mode (C.8)
+TSPC_L2CAP_2_25 True (*) Supports performing L2CAP channel mode
+ configuration fallback from SM
+ to ERTM (C.9)
+TSPC_L2CAP_2_26 True (*) Supports sending more than one unacknowledged
+ I-Frame when operating in ERTM (C.10)
+TSPC_L2CAP_2_27 True (*) Supports sending more than three unacknowledged
+ I-Frame when operating in ERTM (C.10)
+TSPC_L2CAP_2_28 True (*) Supports configuring the peer TxWindow
+ greater than 1 (C.11)
+TSPC_L2CAP_2_29 False AMP Support (C.12)
+TSPC_L2CAP_2_30 True (*) Fixed Channel Support (C.12)
+TSPC_L2CAP_2_31 False AMP Manager Support (C.12)
+TSPC_L2CAP_2_32 False ERTM over AMP (C.12)
+TSPC_L2CAP_2_33 False Streaming Mode Source over AMP Support (C.15)
+TSPC_L2CAP_2_34 False Streaming Mode Sink over AMP Support (C.15)
+TSPC_L2CAP_2_35 False Unicast Connectionless Data, Reception (C.1, C.16)
+TSPC_L2CAP_2_36 False Ability to transmit an unencrypted packet over
+ a Unicast connectionless L2CAP
+ channel (C.16)
+TSPC_L2CAP_2_37 False Ability to transmit an encrypted packet over
+ a Unicast connectionless L2CAP
+ channel (C.16)
+TSPC_L2CAP_2_38 False Extended Flow Specification for BR/EDR (C.8)
+TSPC_L2CAP_2_39 False Extended Window Size (C.8)
+TSPC_L2CAP_2_40 False Support of Low Energy signaling channel (C.17)
+TSPC_L2CAP_2_41 False Support of command reject (C.17)
+TSPC_L2CAP_2_42 False Send Connection Parameter Update Request (C.18)
+TSPC_L2CAP_2_43 False Send Connection Parameter Update Response (C.19)
+TSPC_L2CAP_2_44 False Extended Flow Specification for AMP (C.22)
+TSPC_L2CAP_2_45 False Send disconnect request command (O)
+-------------------------------------------------------------------------------
+C.1: Mandatory to support at least one of TSPC_L2CAP_2_12 OR TSPC_L2CAP_2_13 OR
+ TSPC_L2CAP_2_35 IF BR/EDR BR/EDR/LE AND SUM_ICS 31/7 (CSA1) OR
+ SUM_ICS 31/8 (3.0) OR SUM_ICS 31/9 (3.0+HS) OR SUM_ICS 31/10 (4.0))
+ is supported, ELSE Excluded
+C.2: Optional IF TSPC_L2CAP_2_12 OR TSPC_L2CAP_2_13 is claimed, ELSE Excluded.
+C.3: Optional IF TSPC_L2CAP_2_12 AND TSPC_L2CAP_2_28 is claimed, ELSE Excluded.
+C.4: IF TSPC_L2CAP_2_12 is claimed THEN either TSPC_L2CAP_2_18
+ OR TSPC_L2CAP_2_20 are Mandatory, ELSE Excluded.
+C.5: IF TSPC_L2CAP_2_13 is claimed THEN either TSPC_L2CAP_2_19
+ OR TSPC_L2CAP_2_21 are Mandatory, ELSE Excluded.
+C.6: Optional IF TSPC_L2CAP_2_12 is claimed, ELSE Excluded.
+C.7: Optional IF TSPC_L2CAP_2_13 is claimed, ELSE Excluded.
+C.8: Optional IF TSPC_L2CAP_2_12 OR TSPC_L2CAP_2_13 is claimed, ELSE Excluded.
+C.9: Mandatory IF TSPC_L2CAP_2_12 AND TSPC_L2CAP_2_13 AND TSPC_L2CAP_2_21
+ is claimed, ELSE Excluded.
+C.10: Optional IF TSPC_L2CAP_2_12 is claimed, ELSE Excluded.
+C.11: Optional IF TSPC_L2CAP_2_12 is claimed, ELSE Excluded.
+C.12: Mandatory IF SUM_ICS 31/9 (3.0 + HS) is claimed, ELSE Optional.
+C.13: Mandatory IF SUM_ICS 31/9 (3.0 + HS) is claimed, ELSE Optional.
+C.14: Optional IF SUM_ICS 31/8 OR 31/9 OR 31/10 OR 31/11 is claimed, ELSE Excluded.
+C.15: Optional IF TSPC_L2CAP_2_29 is claimed, ELSE Excluded.
+C.16: Optional IF (SUM_ICS 31/8 OR SUM_ICS 31/9 OR 31/10 OR 31/11) is claimed,
+ ELSE Excluded.
+C.17: Mandatory IF LE OR BR/EDR/LE is claimed, ELSE Excluded.
+C.18: Optional IF (SUM_ICS 31/10 AND 1/4) is claimed, ELSE Excluded.
+C.19: Mandatory IF (SUM_ICS 31/10 AND 1/3) is claimed, ELSE Excluded.
+C.20: Mandatory IF LE OR BR/EDR/LE, is claimed, ELSE Excluded
+C.21: Optional IF LE OR BR/EDR/LE, is claimed, ELSE Excluded
+C.22: Mandatory IF TSPC_L2CAP_2_29 is claimed, ELSE Excluded.
+-------------------------------------------------------------------------------
+
+
+ Configurable Parameters
+-------------------------------------------------------------------------------
+Parameter Name Selected Description
+-------------------------------------------------------------------------------
+TSPC_L2CAP_3_1 True Support of RTX timer (M)
+TSPC_L2CAP_3_2 True Support of ERTX timer (C.4)
+TSPC_L2CAP_3_3 True Support minimum MTU size 48 octets (C.4)
+TSPC_L2CAP_3_4 True (*) Support MTU size larger than 48 octets (C.5)
+TSPC_L2CAP_3_5 True Support of flush timeout value for reliable
+ channel (C.4)
+TSPC_L2CAP_3_6 False Support of flush timeout value for unreliable
+ channel (C.5)
+TSPC_L2CAP_3_7 False Support of bi-directional quality of service
+ (QoS) option field (C.1)
+TSPC_L2CAP_3_8 False Negotiate QoS service type (C.5)
+TSPC_L2CAP_3_9 False Negotiate and support service type ‘No
+ traffic’ (C.2)
+TSPC_L2CAP_3_10 False Negotiate and support service type ‘Best
+ effort’ (C.3)
+TSPC_L2CAP_3_11 False Negotiate and support service type
+ ‘Guaranteed’ (C.2)
+TSPC_L2CAP_3_12 True (*) Support minimum MTU size 23 octets (C.6)
+TSPC_L2CAP_3_13 False Negotiate and support service type ‘No traffic’
+ for Extended Flow Specification (C.7)
+TSPC_L2CAP_3_14 False Negotiate and support service type ‘Best Effort'
+ for Extended Flow Specification (C.8)
+TSPC_L2CAP_3_15 False Negotiate and support service type ‘Guaranteed’
+ for Extended Flow Specification (C.9)
+-------------------------------------------------------------------------------
+C.1: Mandatory if TSPC_L2CAP_3_8 is supported, ELSE Optional.
+C.2: Optional if TSPC_L2CAP_3_8 is supported, ELSE Excluded.
+C.3: Mandatory if TSPC_L2CAP_3_8 is supported, ELSE Excluded.
+C.4: Mandatory IF BR/EDR OR BR/EDR/LE is claimed, ELSE Excluded.
+C.5: Optional IF BR/EDR OR BR/EDR/LE is claimed, ELSE Excluded.
+C.6: Mandatory IF LE OR BR/EDR/LE is claimed, ELSE Excluded.
+C.7: Optional if TSPC_L2CAP_2_44 OR TSPC_L2CAP_2_38 is supported, ELSE Excluded.
+C.8: Mandatory if TSPC_L2CAP_2_44 OR TSPC_L2CAP_2_38 is supported, ELSE Excluded.
+C.9: Optional if TSPC_L2CAP_2_44 OR TSPC_L2CAP_2_38 is supported, ELSE Excluded.
+-------------------------------------------------------------------------------
diff --git a/android/pixit-l2cap.txt b/android/pixit-l2cap.txt
new file mode 100644
index 0000000..6f2beae
--- /dev/null
+++ b/android/pixit-l2cap.txt
@@ -0,0 +1,39 @@
+L2CAP PIXIT for the PTS tool.
+
+* - different than PTS defaults
+& - should be set to IUT Bluetooth address
+
+ Required PIXIT settings
+-------------------------------------------------------------------------------
+Parameter Name Value
+-------------------------------------------------------------------------------
+TSPX_bd_addr_iut 112233445566 (*&)
+TSPX_client_class_of_device 100104
+TSPX_server_class_of_device 100104
+TSPX_security_enabled False
+TSPX_delete_link_key False
+TSPX_pin_code 0000
+TSPX_flushto FFFF
+TSPX_inmtu 02A0
+TSPX_no_fail_verditcs FALSE
+TSPX_oumtu 02A0
+TSPX_iut_role_initiator FALSE
+TSPX_psm 0001
+TSPX_time_guard 180000
+TSPX_timer_ertx 120000
+TSPX_timer_ertx_max 300000
+TSPX_timer_ertx_min 60000
+TSPX_timer_rtx 10000
+TSPX_timer_rtx_max 60000
+TSPX_timer_rtx_min 1000
+TSPX_rfc_mode_tx_window_size 08
+TSPX_rfc_mode_max_transmit 03
+TSPX_rfc_mode_retransmission_timeout 07D0
+TSPX_rfc_mode_monitor_timeout 2EE0
+TSPX_rfc_mode_maximum_pdu_size 02A0
+TSPX_extended_window_size 0012
+TSPX_use_implicit_send TRUE
+TSPX_use_dynamic_pin FALSE
+TSPX_iut_SDU_size_in_bytes 144
+TSPX_secure_simple_pairing_pass_key_confirmation FALSE
+-------------------------------------------------------------------------------
diff --git a/android/pts-l2cap.txt b/android/pts-l2cap.txt
new file mode 100644
index 0000000..a599515
--- /dev/null
+++ b/android/pts-l2cap.txt
@@ -0,0 +1,293 @@
+PTS test results for L2CAP
+
+PTS version: 5.0
+Tested: 10-11.12.2013
+
+Results:
+PASS test passed
+FAIL test failed
+INC test is inconclusive
+N/A test is disabled due to PICS setup
+
+-------------------------------------------------------------------------------
+Test Name Result Notes
+-------------------------------------------------------------------------------
+TC_COS_CED_BV_01_C INC IUT should introduce testing tools
+TC_COS_CED_BV_03_C INC IUT should introduce testing tools
+TC_COS_CED_BV_04_C N/A
+TC_COS_CED_BV_05_C PASS IUT must be connectable and discoverable
+TC_COS_CED_BV_07_C PASS IUT must be connectable and discoverable
+TC_COS_CED_BV_08_C PASS IUT must be connectable and discoverable
+TC_COS_CED_BV_09_C PASS IUT should introduce testing tools
+TC_COS_CED_BV_10_C N/A
+TC_COS_CED_BV_11_C PASS IUT must be connectable and discoverable
+TC_COS_CED_BI_01_C PASS IUT must be connectable and discoverable
+TC_COS_CFD_BV_01_C PASS IUT must be connectable
+TC_COS_CFD_BV_02_C PASS IUT must be connectable
+TC_COS_CFD_BV_03_C PASS IUT must be connectable
+TC_COS_CED_BV_08_C INC IUT should introduce testing tools
+TC_COS_CED_BV_09_C INC IUT should introduce testing tools
+TC_COS_CED_BV_10_C N/A
+TC_COS_CED_BI_11_C PASS IUT must be connectable
+TC_COS_CFD_BV_12_C PASS IUT must be connectable
+TC_COS_CFD_BV_13_C N/A
+TC_COS_IEX_BV_01_C PASS IUT must be connectable
+TC_COS_IEX_BV_02_C PASS IUT must be connectable
+TC_COS_ECH_BV_01_C PASS IUT must be connectable
+TC_COS_ECH_BV_02_C INC IUT should introduce testing tools
+TC_CLS_CLR_BV_01_C N/A
+TC_CLS_UCD_BV_01_C N/A
+TC_CLS_UCD_BV_02_C N/A
+TC_CLS_UCD_BV_03_C N/A
+TC_EXF_BV_01_C PASS IUT must be connectable
+TC_EXF_BV_02_C PASS IUT must be connectable
+TC_EXF_BV_03_C PASS IUT must be connectable
+TC_EXF_BV_04_C N/A
+TC_EXF_BV_05_C PASS IUT must be connectable
+TC_EXF_BV_06_C N/A
+TC_CMC_BV_01_C INC IUT should introduce testing tools
+TC_CMC_BV_02_C INC IUT should introduce testing tools
+TC_CMC_BV_03_C INC IUT should introduce testing tools
+TC_CMC_BV_04_C INC IUT should introduce testing tools
+TC_CMC_BV_05_C INC IUT should introduce testing tools
+TC_CMC_BV_06_C INC IUT should introduce testing tools
+TC_CMC_BV_07_C INC IUT should introduce testing tools
+TC_CMC_BV_08_C INC IUT should introduce testing tools
+TC_CMC_BV_09_C INC IUT should introduce testing tools
+TC_CMC_BV_10_C INC IUT should introduce testing tools
+TC_CMC_BV_11_C INC IUT should introduce testing tools
+TC_CMC_BV_12_C INC IUT should introduce testing tools
+TC_CMC_BV_13_C INC IUT should introduce testing tools
+TC_CMC_BV_14_C INC IUT should introduce testing tools
+TC_CMC_BV_15_C INC IUT should introduce testing tools
+TC_CMC_BI_01_C INC IUT should introduce testing tools
+TC_CMC_BI_02_C INC IUT should introduce testing tools
+TC_CMC_BI_03_C INC IUT should introduce testing tools
+TC_CMC_BI_04_C INC IUT should introduce testing tools
+TC_CMC_BI_05_C INC IUT should introduce testing tools
+TC_CMC_BI_06_C INC IUT should introduce testing tools
+TC_FOC_BV_01_C INC IUT should introduce testing tools
+TC_FOC_BV_02_C INC IUT should introduce testing tools
+TC_FOC_BV_03_C INC IUT should introduce testing tools
+TC_FOC_BV_04_C INC IUT should introduce testing tools
+TC_OFS_BV_01_C INC IUT should introduce testing tools
+TC_OFS_BV_02_C INC IUT should introduce testing tools
+TC_OFS_BV_03_C INC IUT should introduce testing tools
+TC_OFS_BV_04_C INC IUT should introduce testing tools
+TC_OFS_BV_05_C INC IUT should introduce testing tools
+TC_OFS_BV_06_C INC IUT should introduce testing tools
+TC_OFS_BV_07_C INC IUT should introduce testing tools
+TC_OFS_BV_08_C INC IUT should introduce testing tools
+TC_ERM_BV_01_C INC IUT should introduce testing tools
+TC_ERM_BV_02_C INC IUT should introduce testing tools
+TC_ERM_BV_03_C INC IUT should introduce testing tools
+TC_ERM_BV_04_C INC IUT should introduce testing tools
+TC_ERM_BV_05_C INC IUT should introduce testing tools
+TC_ERM_BV_06_C INC IUT should introduce testing tools
+TC_ERM_BV_07_C INC IUT should introduce testing tools
+TC_ERM_BV_08_C INC IUT should introduce testing tools
+TC_ERM_BV_09_C INC IUT should introduce testing tools
+TC_ERM_BV_10_C INC IUT should introduce testing tools
+TC_ERM_BV_11_C INC IUT should introduce testing tools
+TC_ERM_BV_12_C INC IUT should introduce testing tools
+TC_ERM_BV_13_C INC IUT should introduce testing tools
+TC_ERM_BV_14_C INC IUT should introduce testing tools
+TC_ERM_BV_15_C INC IUT should introduce testing tools
+TC_ERM_BV_16_C INC IUT should introduce testing tools
+TC_ERM_BV_17_C INC IUT should introduce testing tools
+TC_ERM_BV_18_C INC IUT should introduce testing tools
+TC_ERM_BV_19_C INC IUT should introduce testing tools
+TC_ERM_BV_20_C INC IUT should introduce testing tools
+TC_ERM_BV_21_C INC IUT should introduce testing tools
+TC_ERM_BV_22_C INC IUT should introduce testing tools
+TC_ERM_BV_23_C INC IUT should introduce testing tools
+TC_ERM_BI_01_C INC IUT should introduce testing tools
+TC_ERM_BI_02_C INC IUT should introduce testing tools
+TC_ERM_BI_03_C INC IUT should introduce testing tools
+TC_ERM_BI_04_C INC IUT should introduce testing tools
+TC_ERM_BI_05_C INC IUT should introduce testing tools
+TC_STM_BV_01_C INC IUT should introduce testing tools
+TC_STM_BV_02_C INC IUT should introduce testing tools
+TC_STM_BV_03_C INC IUT should introduce testing tools
+TC_STM_BV_11_C N/A
+TC_STM_BV_12_C N/A
+TC_STM_BV_13_C N/A
+TC_FIX_BV_01_C PASS IUT must be connectable
+TC_FIX_BV_02_C N/A
+TC_EWC_BV_01_C N/A
+TC_EWC_BV_02_C N/A
+TC_EWC_BV_03_C N/A
+TC_LSC_BV_01_C N/A
+TC_LSC_BV_02_C N/A
+TC_LSC_BV_03_C N/A
+TC_LSC_BI_04_C N/A
+TC_LSC_BI_05_C N/A
+TC_LSC_BV_06_C N/A
+TC_LSC_BV_07_C N/A
+TC_LSC_BV_08_C N/A
+TC_LSC_BV_09_C N/A
+TC_LSC_BI_10_C N/A
+TC_LSC_BI_11_C N/A
+TC_LSC_BV_12_C N/A
+TC_CCH_BV_01_C N/A
+TC_CCH_BV_02_C N/A
+TC_CCH_BV_03_C N/A
+TC_CCH_BV_04_C N/A
+TC_ECF_BV_01_C N/A
+TC_ECF_BV_02_C N/A
+TC_ECF_BV_03_C N/A
+TC_ECF_BV_04_C N/A
+TC_ECF_BV_05_C N/A
+TC_ECF_BV_06_C N/A
+TC_ECF_BV_07_C N/A
+TC_ECF_BV_08_C N/A
+TC_LE_CPU_BV_01_C N/A
+TC_LE_CPU_BV_02_C N/A
+TC_LE_CPU_BI_01_C N/A
+TC_LE_CPU_BI_02_C N/A
+TC_LE_REJ_BV_01_C N/A
+
+-------------------------------------------------------------------------------
+ HELPER SECTION
+-------------------------------------------------------------------------------
+Test Name Result Notes
+-------------------------------------------------------------------------------
+TC_HELPER_COS_CED_BV_01_C PASS IUT must be connectable
+TC_HELPER_COS_CED_BV_03_C INC IUT should introduce testing tools
+TC_HELPER_COS_CED_BV_04_C N/A
+TC_HELPER_COS_CED_BV_05_C INC IUT should introduce testing tools
+TC_HELPER_COS_CED_BV_07_C N/A
+TC_HELPER_COS_CED_BV_08_C INC
+TC_HELPER_COS_CED_BV_09_C INC
+TC_HELPER_COS_CED_BV_11_C INC IUT should introduce testing tools
+TC_HELPER_COS_CED_BI_01_C PASS IUT must be connectable
+TC_HELPER_COS_CFD_BV_01_C INC
+TC_HELPER_COS_CFD_BV_02_C INC IUT should introduce testing tools
+TC_HELPER_COS_CFD_BV_03_C INC IUT should introduce testing tools
+TC_HELPER_COS_CFD_BV_08_C PASS IUT must be connectable
+TC_HELPER_COS_CFD_BV_09_C PASS IUT must be connectable
+TC_HELPER_COS_CFD_BV_10_C INC
+TC_HELPER_COS_CFD_BV_11_C INC IUT should introduce testing tools
+TC_HELPER_COS_CFD_BV_12_C PASS IUT must be connectable
+TC_HELPER_COS_CFD_BV_13_C INC
+TC_HELPER_CLS_CLR_BV_01_C PASS IUT must be connectable
+TC_HELPER_CLS_UCD_BV_01_C N/A
+TC_HELPER_CLS_UCD_BV_02_C N/A
+TC_HELPER_CLS_UCD_BV_03_C N/A
+TC_HELPER_EXF_BV_01_C PASS IUT must be connectable
+TC_HELPER_EXF_BV_02_C PASS IUT must be connectable
+TC_HELPER_EXF_BV_03_C PASS IUT must be connectable
+TC_HELPER_EXF_BV_04_C PASS IUT must be connectable
+TC_HELPER_EXF_BV_05_C PASS IUT must be connectable
+TC_HELPER_EXF_BV_06_C PASS IUT must be connectable
+TC_HELPER_CMC_BV_01_C INC
+TC_HELPER_CMC_BV_02_C INC
+TC_HELPER_CMC_BV_03_C INC
+TC_HELPER_CMC_BV_405_C INC
+TC_HELPER_CMC_BV_06_C INC
+TC_HELPER_CMC_BV_07_C INC
+TC_HELPER_CMC_BV_08_C INC
+TC_HELPER_CMC_BV_09_C INC
+TC_HELPER_CMC_BV_10_C INC
+TC_HELPER_CMC_BV_11_C INC
+TC_HELPER_CMC_BV_12_C INC
+TC_HELPER_CMC_BV_13_C INC
+TC_HELPER_CMC_BV_14_C INC
+TC_HELPER_CMC_BV_15_C INC
+TC_HELPER_CMC_BI_01_C INC
+TC_HELPER_CMC_BI_02_C INC
+TC_HELPER_CMC_BI_03_C INC
+TC_HELPER_CMC_BI_04_C INC
+TC_HELPER_CMC_BI_05_C INC
+TC_HELPER_CMC_BI_06_C INC
+TC_HELPER_FOC_BV_01_ALT_1_C INC
+TC_HELPER_FOC_BV_01_ALT_2_C INC
+TC_HELPER_FOC_BV_02_ALT_1_C INC
+TC_HELPER_FOC_BV_02_ALT_2_C INC
+TC_HELPER_FOC_BV_03_ALT_1_C INC
+TC_HELPER_FOC_BV_03_ALT_2_C INC
+TC_HELPER_FOC_BV_04_ALT_1_C INC
+TC_HELPER_FOC_BV_04_ALT_2_C INC
+TC_HELPER_OFS_BV_01_C INC
+TC_HELPER_OFS_BV_02_C INC
+TC_HELPER_OFS_BV_03_C INC
+TC_HELPER_OFS_BV_04_C INC
+TC_HELPER_OFS_BV_05_C INC
+TC_HELPER_OFS_BV_06_C INC
+TC_HELPER_OFS_BV_07_C INC
+TC_HELPER_OFS_BV_08_C INC
+TC_HELPER_ERM_BV_01_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_02_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_02_C__no_Sframe_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_03_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_05_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_06_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_07_C_ALT_1_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_07_C_ALT_2_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_08_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_09_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_10_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_11_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_12_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_13_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_14_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_15_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_16_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_17_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_18_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_19_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_20_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_21_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_21_TxWin1_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_21_ALT_1_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_21_ALT_2_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_22_ALT_1_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_22_ALT_2_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BV_23_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_1_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_2_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_3_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_4_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_5_ALT_1_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_5_ALT_2_C INC IUT should introduce testing tools
+TC_HELPER_ERM_BI_5_ALT_3_C INC IUT should introduce testing tools
+TC_HELPER_STM_BV_01_C INC
+TC_HELPER_STM_BV_02_C INC
+TC_HELPER_STM_BV_03_C INC
+TC_HELPER_STM_BV_11_C N/A
+TC_HELPER_STM_BV_12_C N/A
+TC_HELPER_STM_BV_13_C N/A
+TC_HELPER_FIX_BV_01_C N/A
+TC_HELPER_FIX_BV_02_C PASS IUT must be connectable
+TC_HELPER_EWC_BV_01_C INC
+TC_HELPER_EWC_BV_02_C INC
+TC_HELPER_EWC_BV_03_C INC
+TC_HELPER_LSC_BV_01_C N/A
+TC_HELPER_LSC_BV_02_C N/A
+TC_HELPER_LSC_BV_03_C N/A
+TC_HELPER_LSC_BI_04_C N/A
+TC_HELPER_LSC_BI_05_C N/A
+TC_HELPER_LSC_BV_06_C N/A
+TC_HELPER_LSC_BV_07_C N/A
+TC_HELPER_LSC_BV_08_C N/A
+TC_HELPER_LSC_BV_09_C N/A
+TC_HELPER_LSC_BI_10_C N/A
+TC_HELPER_LSC_BI_11_C N/A
+TC_HELPER_LSC_BV_12_C N/A
+TC_HELPER_CCH_BV_01_C N/A
+TC_HELPER_CCH_BV_02_C N/A
+TC_HELPER_CCH_BV_03_C N/A
+TC_HELPER_CCH_BV_04_C N/A
+TC_HELPER_ECF_BV_01_C N/A
+TC_HELPER_ECF_BV_02_C N/A
+TC_HELPER_ECF_BV_03_C N/A
+TC_HELPER_ECF_BV_04_C N/A
+TC_HELPER_ECF_BV_05_C N/A
+TC_HELPER_ECF_BV_06_C N/A
+TC_HELPER_ECF_BV_07_C N/A
+TC_HELPER_ECF_BV_08_C N/A
+TC_HELPER_LE_CPU_BV_01_C N/A
+TC_HELPER_LE_CPU_BV_02_C N/A
+TC_HELPER_LE_CPU_BI_01_C N/A
+TC_HELPER_LE_CPU_BI_02_C N/A
+TC_HELPER_LE_REJ_BI_01_C N/A
--
1.8.1.2
^ permalink raw reply related
* [PATCH] emulator/bthost: Fix use after free in bthost_destroy
From: Szymon Janc @ 2013-12-15 19:55 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
cmd was dereferenced after free. Use temp pointer for freeing.
---
emulator/bthost.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index 10e7a05..b05072a 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -186,13 +186,15 @@ static struct l2conn *btconn_find_l2cap_conn_by_scid(struct btconn *conn,
void bthost_destroy(struct bthost *bthost)
{
- struct cmd *cmd;
-
if (!bthost)
return;
- for (cmd = bthost->cmd_q.tail; cmd != NULL; cmd = cmd->next)
+ while (bthost->cmd_q.tail) {
+ struct cmd *cmd = bthost->cmd_q.tail;
+
+ bthost->cmd_q.tail = cmd->next;
free(cmd);
+ }
while (bthost->conns) {
struct btconn *conn = bthost->conns;
--
1.8.5.1
^ permalink raw reply related
* Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b
From: Alexander Holler @ 2013-12-15 17:54 UTC (permalink / raw)
To: Gianluca Anzolin, Peter Hurley
Cc: marcel, Gustavo Padovan, linux-bluetooth, gregkh, jslaby,
linux-kernel
In-Reply-To: <20131215150847.GA10288@sottospazio.it>
Am 15.12.2013 16:08, schrieb Gianluca Anzolin:
> The attached patch fixes the regression by releasing the tty_port in the
> shutdown method(). This way we can avoid strange games in the dlc callback
> where we are constrained by the dlc lock.
Yes, it fixes the problem here too.
> If this kind of approach is acceptable I will submit the patch for inclusion in
> a separate email.
If you do so, please add a Cc: stable@vger.kernel.org so that at least
3.12 will have a working rfcomm. You might also add a Reported-by:
and/or Tested-by: <holler@ahsoftware.de> if that makes someone happy ;)
I've missed this patch previously, because it came late and I was happy
with the series of patches you've already had done.
Thanks a lot (for the previous series too).
Regards,
Alexander Holler
^ permalink raw reply
* Re: [PATCH] linux-firmware: Update Intel Bluetooth devices firmware patch files
From: Ben Hutchings @ 2013-12-15 17:53 UTC (permalink / raw)
To: Tedd Ho-Jeong An; +Cc: dwmw2, don.try, linux-bluetooth
In-Reply-To: <20131113172123.5702c78d@han1-desk-dev>
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]
On Wed, 2013-11-13 at 17:21 -0800, Tedd Ho-Jeong An wrote:
> From: Tedd Ho-Jeong An <tedd.an@intel.com>
>
> This patch updates firmware patch files for following Intel Bluetooth devices:
> - Intel Wireless Bluetooth 7260
> - Intel Wireless Bluetooth 3160
>
> This patch fixes
> - sometimes device doesn't response to HCI_reset after multiple reboot
> - issue with HCI stress testing
> - issue with some multi profile cases
>
> Signed-off-by: Tedd Ho-Jeong An <tedd.an@intel.com>
> ---
> WHENCE | 4 ++--
> intel/ibt-hw-37.7.10-fw-1.0.2.3.d.bseq | Bin 16761 -> 18145 bytes
> intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq | Bin 16516 -> 17917 bytes
> 3 files changed, 2 insertions(+), 2 deletions(-)
[...]
Applied, thanks. Sorry for the delay.
Ben.
--
Ben Hutchings
Q. Which is the greater problem in the world today, ignorance or apathy?
A. I don't know and I couldn't care less.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: linux-firmware: pull-request Marvell mwifiex-firmware 2013-11-06
From: Ben Hutchings @ 2013-12-15 17:47 UTC (permalink / raw)
To: Bing Zhao; +Cc: linux-wireless, linux-bluetooth, Frank Huang
In-Reply-To: <1383765913-19716-1-git-send-email-bzhao@marvell.com>
[-- Attachment #1: Type: text/plain, Size: 2139 bytes --]
On Wed, 2013-11-06 at 11:25 -0800, Bing Zhao wrote:
> The following changes since commit 7d0c7a8cfd78388d90cc784a185b19dcbdbce824:
>
> Merge branch 'wilink4' of git://git.kernel.org/pub/scm/linux/kernel/git/balbi/linux-firmware (2013-10-13 21:11:46 +0100)
>
> are available in the git repository at:
>
>
> git://git.marvell.com/mwifiex-firmware.git master
>
> for you to fetch changes up to b7c848634538ff87317acd802fb4645cfd2f9fb5:
>
> linux-firmware: add Marvell SD8897-B0 firmware combo image (2013-11-04 16:03:34 -0800)
Sorry for the delay. Done.
Ben.
> ----------------------------------------------------------------
> Bing Zhao (2):
> linux-firmware: update Marvell PCIe/USB 8897-B0 firmware combo image
> linux-firmware: add Marvell SD8897-B0 firmware combo image
>
> WHENCE | 5 ++++-
> mrvl/pcie8897_uapsta.bin | Bin 350244 -> 656896 bytes
> mrvl/sd8897_uapsta.bin | Bin 0 -> 639012 bytes
> 3 files changed, 4 insertions(+), 1 deletion(-)
> create mode 100644 mrvl/sd8897_uapsta.bin
>
> diff --git a/WHENCE b/WHENCE
> index 2d52804..3875e77 100644
> --- a/WHENCE
> +++ b/WHENCE
> @@ -727,11 +727,14 @@ Version: 14.66.9.p96
> File: mrvl/sd8797_uapsta.bin
> Version: 14.66.11.p151
>
> +File: mrvl/sd8897_uapsta.bin
> +Version: 15.69.2.p11
> +
> File: mrvl/usb8797_uapsta.bin
> Version: 14.69.11.p179
>
> File: mrvl/pcie8897_uapsta.bin
> -Version: 15.69.201.p52
> +Version: 15.69.2.p11
>
> Licence: Redistributable. See LICENCE.Marvell for details. Originates from
> http://git.marvell.com/?p=mwifiex-firmware.git
> diff --git a/mrvl/pcie8897_uapsta.bin b/mrvl/pcie8897_uapsta.bin
> index b067689..858c100 100644
> Binary files a/mrvl/pcie8897_uapsta.bin and b/mrvl/pcie8897_uapsta.bin differ
> diff --git a/mrvl/sd8897_uapsta.bin b/mrvl/sd8897_uapsta.bin
> new file mode 100644
> index 0000000..70732a6
> Binary files /dev/null and b/mrvl/sd8897_uapsta.bin differ
--
Ben Hutchings
Q. Which is the greater problem in the world today, ignorance or apathy?
A. I don't know and I couldn't care less.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b
From: Gianluca Anzolin @ 2013-12-15 15:08 UTC (permalink / raw)
To: Peter Hurley
Cc: Alexander Holler, marcel, Gustavo Padovan, linux-bluetooth,
gregkh, jslaby, linux-kernel
In-Reply-To: <52ADB6B7.5010503@hurleysoftware.com>
[-- Attachment #1: Type: text/plain, Size: 2470 bytes --]
On Sun, Dec 15, 2013 at 09:03:35AM -0500, Peter Hurley wrote:
> On 12/15/2013 06:24 AM, Gianluca Anzolin wrote:
> >On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
> >>Am 12.12.2013 21:36, schrieb Peter Hurley:
> >>
> >>>>What currently happens is that when one kills rfcomm (and any other
> >>>>terminal which might use that tty), the entry in /dev doesn't
> >>>>disappear. That means the same call to refcomm with the same device
> >>>>(e.g. [/dev/]rfcomm1 doesn't work.
> >>>
> >>>Thanks for the report, Alexander.
> >>>
> >>>Point 4 above details a different situation; something else is
> >>>happening.
> >>>
> >>>Would you please detail the necessary steps to reproduce this regression?
> >>>(How do you 'kill' rfcomm? etc. Shell command lines would be best.)
> >>
> >>Just call
> >>
> >>rfcomm connect rfcomm9 01:23:45:67:89:ab
> >>
> >>wait until the connection happened (a message will appear) and then
> >>press ctrl-c. This still terminates the bluetooth connection, but the
> >>device in /dev is now left.
> >
> >Yes I'm able to reproduce the regression which is indeed caused by that
> >commit.
> >
> >However I'm puzzled. Surely there is a fifth case I didn't cover because
> >when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
> >not, and therefore I cannot get a reference to it and send the HUP.
>
> There is a fifth case, but it's crazy.
>
> The tty has been properly shutdown and destroyed because the tty file handle
> was closed, not hungup. The rfcomm device reference was properly put
> when the tty was released.
>
> But when the remote hangs up (and sends disc), then rfcomm_dev_state_change()
> is called -- to kill the port reference (thus the rfcomm device) that was
> instantiated locally! Ridiculous. Doubly ridiculous because it's the local
> port shutdown that closes the dlc locally that sends the disconnect (and sets
> the local dlc state) that triggers the received rfcomm_dev_state_change()!
>
> If this behavior is desirable (or necessary because it's been exposed to
> userspace), then why was the design ever reference-counted to begin with?
>
> Regards,
> Peter Hurley
The attached patch fixes the regression by releasing the tty_port in the
shutdown method(). This way we can avoid strange games in the dlc callback
where we are constrained by the dlc lock.
If this kind of approach is acceptable I will submit the patch for inclusion in
a separate email.
Thanks,
Gianluca
[-- Attachment #2: rfc.patch --]
[-- Type: text/x-diff, Size: 578 bytes --]
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index 84fcf9f..917b441 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
@@ -129,6 +129,11 @@ static void rfcomm_dev_shutdown(struct tty_port *port)
/* close the dlc */
rfcomm_dlc_close(dev->dlc, 0);
+
+ /* release the port if it was created with the flag RELEASE_ONHUP */
+ if (test_bit(RFCOMM_RELEASE_ONHUP, &dev->flags) &&
+ !test_and_set_bit(RFCOMM_TTY_RELEASED, &dev->flags))
+ tty_port_put(&dev->port);
}
static const struct tty_port_operations rfcomm_port_ops = {
^ permalink raw reply related
* Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b
From: Peter Hurley @ 2013-12-15 14:03 UTC (permalink / raw)
To: Gianluca Anzolin, Alexander Holler, marcel
Cc: Gustavo Padovan, linux-bluetooth, gregkh, jslaby, linux-kernel
In-Reply-To: <20131215112413.GA8980@sottospazio.it>
On 12/15/2013 06:24 AM, Gianluca Anzolin wrote:
> On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
>> Am 12.12.2013 21:36, schrieb Peter Hurley:
>>
>>>> What currently happens is that when one kills rfcomm (and any other
>>>> terminal which might use that tty), the entry in /dev doesn't
>>>> disappear. That means the same call to refcomm with the same device
>>>> (e.g. [/dev/]rfcomm1 doesn't work.
>>>
>>> Thanks for the report, Alexander.
>>>
>>> Point 4 above details a different situation; something else is
>>> happening.
>>>
>>> Would you please detail the necessary steps to reproduce this regression?
>>> (How do you 'kill' rfcomm? etc. Shell command lines would be best.)
>>
>> Just call
>>
>> rfcomm connect rfcomm9 01:23:45:67:89:ab
>>
>> wait until the connection happened (a message will appear) and then
>> press ctrl-c. This still terminates the bluetooth connection, but the
>> device in /dev is now left.
>
> Yes I'm able to reproduce the regression which is indeed caused by that
> commit.
>
> However I'm puzzled. Surely there is a fifth case I didn't cover because
> when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
> not, and therefore I cannot get a reference to it and send the HUP.
There is a fifth case, but it's crazy.
The tty has been properly shutdown and destroyed because the tty file handle
was closed, not hungup. The rfcomm device reference was properly put
when the tty was released.
But when the remote hangs up (and sends disc), then rfcomm_dev_state_change()
is called -- to kill the port reference (thus the rfcomm device) that was
instantiated locally! Ridiculous. Doubly ridiculous because it's the local
port shutdown that closes the dlc locally that sends the disconnect (and sets
the local dlc state) that triggers the received rfcomm_dev_state_change()!
If this behavior is desirable (or necessary because it's been exposed to
userspace), then why was the design ever reference-counted to begin with?
Regards,
Peter Hurley
^ permalink raw reply
* [PATCH] Adding missing test scripts to Makefile.tools
From: Sebastian Chlad @ 2013-12-15 11:47 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth, Sebastian Chlad
In-Reply-To: <1386880421-19461-2-git-send-email-sebastianx.chlad@intel.com>
---
Makefile.tools | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Makefile.tools b/Makefile.tools
index 78034f5..78bdf80 100644
--- a/Makefile.tools
+++ b/Makefile.tools
@@ -291,4 +291,5 @@ test_scripts += test/sap_client.py test/bluezutils.py \
test/service-did.xml test/service-spp.xml test/service-opp.xml \
test/service-ftp.xml test/simple-player test/test-nap \
test/test-heartrate test/test-alert test/test-hfp \
- test/test-cyclingspeed
+ test/test-cyclingspeed test/opp-client test/ftp-client \
+ test/pbap-client test/map-client
--
1.8.1.2
^ permalink raw reply related
* Re: [REGRESSION] rfcomm (userland) broken by commit 29cd718b
From: Gianluca Anzolin @ 2013-12-15 11:24 UTC (permalink / raw)
To: Alexander Holler
Cc: Peter Hurley, Gustavo Padovan, marcel, linux-bluetooth, gregkh,
jslaby, linux-kernel
In-Reply-To: <52AA483E.4080706@ahsoftware.de>
On Fri, Dec 13, 2013 at 12:35:26AM +0100, Alexander Holler wrote:
> Am 12.12.2013 21:36, schrieb Peter Hurley:
>
> >> What currently happens is that when one kills rfcomm (and any other
> >> terminal which might use that tty), the entry in /dev doesn't
> >> disappear. That means the same call to refcomm with the same device
> >> (e.g. [/dev/]rfcomm1 doesn't work.
> >
> > Thanks for the report, Alexander.
> >
> > Point 4 above details a different situation; something else is
> > happening.
> >
> > Would you please detail the necessary steps to reproduce this regression?
> > (How do you 'kill' rfcomm? etc. Shell command lines would be best.)
>
> Just call
>
> rfcomm connect rfcomm9 01:23:45:67:89:ab
>
> wait until the connection happened (a message will appear) and then
> press ctrl-c. This still terminates the bluetooth connection, but the
> device in /dev is now left.
Yes I'm able to reproduce the regression which is indeed caused by that
commit.
However I'm puzzled. Surely there is a fifth case I didn't cover because
when rfcomm_dev_state_change() is called, the tty_port is there but the tty is
not, and therefore I cannot get a reference to it and send the HUP.
I'll let you know when I have something working.
>
> Regards,
>
> Alexander Holler
^ permalink raw reply
* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 15:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <52AC7237.10306@ahsoftware.de>
Am 14.12.2013 15:59, schrieb Alexander Holler:
> Am 14.12.2013 14:36, schrieb Johan Hedberg:
>> Hi Alexander,
>>
>> On Sat, Dec 14, 2013, Alexander Holler wrote:
>>> So besides the first connection attempt, all others do die somewhere
>>> where userspace has no control over.
>>>
>>> What happens is likely that connection attempts are refused by the
>>> remote side, because an ongoing connection or authorization attempt
>>> isn't finished while a new one arrives.
>>
>> From the HCI logs you showed on IRC it was quite clear that the (remote
>> side) authorization phase for each connect attempt was finished before
>> the next connect attempt started, i.e. there was an L2CAP Connect
>> Response with an error status before the next L2CAP Connect Request. So
>> from this perspective there didn't seem to be any lack of serialization.
>
> That wasn't so clear for me as I've seen different responses from the
> remote device, but still nothing ended up at the local agent afer the
> first connection attempt failed (regardless how many retries).
>
> So there is no solution to this problem and one local user can easily
> DOS all local bluetooth communicaton?
Ok, that might be the wrong question. But I see two problems here:
First, an application can't be sure why a connection attempt failed.
Second, how should an application behave if a connection attempt failed
because of unknown reasons? Just retrying doesn't seem work.
Regards,
Alexander Holler
^ permalink raw reply
* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 14:59 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <20131214133625.GA27187@x220.p-661hnu-f1>
Am 14.12.2013 14:36, schrieb Johan Hedberg:
> Hi Alexander,
>
> On Sat, Dec 14, 2013, Alexander Holler wrote:
>> So besides the first connection attempt, all others do die somewhere
>> where userspace has no control over.
>>
>> What happens is likely that connection attempts are refused by the
>> remote side, because an ongoing connection or authorization attempt
>> isn't finished while a new one arrives.
>
> From the HCI logs you showed on IRC it was quite clear that the (remote
> side) authorization phase for each connect attempt was finished before
> the next connect attempt started, i.e. there was an L2CAP Connect
> Response with an error status before the next L2CAP Connect Request. So
> from this perspective there didn't seem to be any lack of serialization.
That wasn't so clear for me as I've seen different responses from the
remote device, but still nothing ended up at the local agent afer the
first connection attempt failed (regardless how many retries).
So there is no solution to this problem and one local user can easily
DOS all local bluetooth communicaton?
Regards,
Alexander Holler
^ 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