* 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
* Re: [PATCH -next v2] Bluetooth: fix return value check
From: Marcel Holtmann @ 2013-12-14 14:50 UTC (permalink / raw)
To: Wei Yongjun
Cc: Gustavo F. Padovan, Johan Hedberg, yongjun_wei,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAPgLHd-RYQ14ZoEKZGm0iO5JVkPmr5s1k+H6nh4OR=Wr=r8EfQ@mail.gmail.com>
Hi Wei,
> In case of error, the function bt_skb_alloc() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should
> be replaced with NULL test.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> net/bluetooth/6lowpan.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH -next v2] Bluetooth: fix return value check
From: Wei Yongjun @ 2013-12-14 13:55 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
In case of error, the function bt_skb_alloc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should
be replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
net/bluetooth/6lowpan.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 37239db..fb38c78 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -337,8 +337,8 @@ static inline int skbuff_copy(void *msg, int len, int count, int mtu,
count = min_t(unsigned int, mtu, len);
tmp = bt_skb_alloc(count, GFP_ATOMIC);
- if (IS_ERR(tmp))
- return PTR_ERR(tmp);
+ if (!tmp)
+ return -ENOMEM;
*frag = tmp;
@@ -384,8 +384,8 @@ static struct sk_buff *create_pdu(struct l2cap_conn *conn, void *msg,
BT_DBG("conn %p len %zu mtu %d count %d", conn, len, conn->mtu, count);
skb = bt_skb_alloc(count + L2CAP_HDR_SIZE, GFP_ATOMIC);
- if (IS_ERR(skb))
- return skb;
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
skb->priority = priority;
^ permalink raw reply related
* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Johan Hedberg @ 2013-12-14 13:36 UTC (permalink / raw)
To: Alexander Holler; +Cc: linux-bluetooth
In-Reply-To: <52AC4425.7080109@ahsoftware.de>
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.
Johan
^ permalink raw reply
* Re: Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 11:55 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <52AC4425.7080109@ahsoftware.de>
Am 14.12.2013 12:42, schrieb Alexander Holler:
> Hello,
>
> I've experienced a small problem which makes me wonder how userspace is
> expected to handle that.
>
> To explain the problem, I use simple-agent and rfcomm on the local side
> (Linux with bluez) and a remote device with a fixed pin (without user
> interaction, it refuses or allows connections based on the pin), but I
> think the underlying problem is independent of that configuration.
>
> Furthermore, I did a small patch to the local simple-agent:
> -----------------
> diff --git a/test/simple-agent b/test/simple-agent
> index 854e1af..63b705b 100755
> --- a/test/simple-agent
> +++ b/test/simple-agent
> @@ -64,8 +64,9 @@ class Agent(dbus.service.Object):
> in_signature="o",
> out_signature="s")
> def RequestPinCode(self, device):
> print("RequestPinCode (%s)" % (device))
> - set_trusted(device)
> - return ask("Enter PIN Code: ")
> + #set_trusted(device)
> + #return ask("Enter PIN Code: ")
> + return "666"
>
> @dbus.service.method(AGENT_INTERFACE,
> in_signature="o",
> out_signature="u")
> -----------------
>
> That means it now always returns 666 as pin without asking the user.
> This pin doesn't match the pin of the remote device.
>
> If I now call
>
> for i in $(seq 1 100); do rfcomm connect rfcomm666 aa:bb:cc:dd:ee:ff ; done
>
> in a shell, only one Pin request (the first) ends up at simple-agent but
> all connection attempts are refused.
>
> 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.
>
> The problem I see here is, that userspace has no control about what
> happens during a connection attempt. And userspace doesn't know if any
> other process just did a connection attempt too. How should userspace
> behave to make sure every connection attempt ends up in a pin-request
> for the user?
>
> Shouldn't those connection/pairing/authorization attempts to the same
> remote device be serialized by bluez?
>
Sorry, I forget to mention the local system: Linux 3.12.5 and bluez 5.12.
Regards,
Alexander Holler
^ permalink raw reply
* Shouldn't bluez serialize connection/authorization attempts?
From: Alexander Holler @ 2013-12-14 11:42 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I've experienced a small problem which makes me wonder how userspace is
expected to handle that.
To explain the problem, I use simple-agent and rfcomm on the local side
(Linux with bluez) and a remote device with a fixed pin (without user
interaction, it refuses or allows connections based on the pin), but I
think the underlying problem is independent of that configuration.
Furthermore, I did a small patch to the local simple-agent:
-----------------
diff --git a/test/simple-agent b/test/simple-agent
index 854e1af..63b705b 100755
--- a/test/simple-agent
+++ b/test/simple-agent
@@ -64,8 +64,9 @@ class Agent(dbus.service.Object):
in_signature="o",
out_signature="s")
def RequestPinCode(self, device):
print("RequestPinCode (%s)" % (device))
- set_trusted(device)
- return ask("Enter PIN Code: ")
+ #set_trusted(device)
+ #return ask("Enter PIN Code: ")
+ return "666"
@dbus.service.method(AGENT_INTERFACE,
in_signature="o",
out_signature="u")
-----------------
That means it now always returns 666 as pin without asking the user.
This pin doesn't match the pin of the remote device.
If I now call
for i in $(seq 1 100); do rfcomm connect rfcomm666 aa:bb:cc:dd:ee:ff ; done
in a shell, only one Pin request (the first) ends up at simple-agent but
all connection attempts are refused.
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.
The problem I see here is, that userspace has no control about what
happens during a connection attempt. And userspace doesn't know if any
other process just did a connection attempt too. How should userspace
behave to make sure every connection attempt ends up in a pin-request
for the user?
Shouldn't those connection/pairing/authorization attempts to the same
remote device be serialized by bluez?
Regards,
Alexander Holler
^ permalink raw reply related
* Re: [PATCH -next] Bluetooth: fix return value check
From: Marcel Holtmann @ 2013-12-14 9:49 UTC (permalink / raw)
To: Wei Yongjun
Cc: Gustavo F. Padovan, Johan Hedberg, yongjun_wei,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAPgLHd_1w0SJy3oc7NYgRRzsCZEEZc7SR+RBSz8zjaZsYAPFWg@mail.gmail.com>
Hi Wei,
> In case of error, the function bt_skb_alloc() returns NULL pointer
> not ERR_PTR(). The IS_ERR() test in the return value check should
> be replaced with NULL test.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> net/bluetooth/6lowpan.c | 8 ++++----
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
> index 37239db..fb38c78 100644
> --- a/net/bluetooth/6lowpan.c
> +++ b/net/bluetooth/6lowpan.c
> @@ -337,8 +337,8 @@ static inline int skbuff_copy(void *msg, int len, int count, int mtu,
> count = min_t(unsigned int, mtu, len);
>
> tmp = bt_skb_alloc(count, GFP_ATOMIC);
> - if (IS_ERR(tmp))
> - return PTR_ERR(tmp);
> + if (!tmp)
> + return PTR_ERR(-ENOMEM);
>
> *frag = tmp;
net/bluetooth/6lowpan.c: In function ‘skbuff_copy’:
net/bluetooth/6lowpan.c:340:4: warning: passing argument 1 of ‘PTR_ERR’ makes pointer from integer without a cast [enabled by default]
return PTR_ERR(-ENOMEM);
^
In file included from /data/kernel/bluetooth-next/arch/x86/include/asm/processor.h:31:0,
from /data/kernel/bluetooth-next/arch/x86/include/asm/thread_info.h:22,
from include/linux/thread_info.h:54,
from /data/kernel/bluetooth-next/arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:18,
from include/linux/spinlock.h:50,
from include/linux/mm_types.h:8,
from include/linux/kmemcheck.h:4,
from include/linux/skbuff.h:18,
from include/linux/if_arp.h:26,
from net/bluetooth/6lowpan.c:14:
include/linux/err.h:27:127: note: expected ‘const void *’ but argument is of type ‘int’
static inline long __must_check PTR_ERR(__force const void *ptr)
Have you actually compiled your code?
>
> @@ -384,8 +384,8 @@ static struct sk_buff *create_pdu(struct l2cap_conn *conn, void *msg,
> BT_DBG("conn %p len %zu mtu %d count %d", conn, len, conn->mtu, count);
>
> skb = bt_skb_alloc(count + L2CAP_HDR_SIZE, GFP_ATOMIC);
> - if (IS_ERR(skb))
> - return skb;
> + if (!skb)
> + return ERR_PTR(-ENOMEM);
>
> skb->priority = priority;
Regards
Marcel
^ permalink raw reply
* Re: [PATCH -next] Bluetooth: remove unused including <linux/version.h>
From: Marcel Holtmann @ 2013-12-14 9:42 UTC (permalink / raw)
To: Wei Yongjun
Cc: Gustavo F. Padovan, Johan Hedberg, yongjun_wei,
linux-bluetooth@vger.kernel.org development
In-Reply-To: <CAPgLHd9zXw3039hXeoRPMt-0k7E1MRbrhS1tsKoWDvLU1ooV5w@mail.gmail.com>
Hi Wei,
> From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
>
> Remove including <linux/version.h> that don't need it.
>
> Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
> ---
> net/bluetooth/6lowpan.c | 1 -
> 1 file changed, 1 deletion(-)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* [PATCH -next] Bluetooth: fix return value check
From: Wei Yongjun @ 2013-12-14 4:43 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
In case of error, the function bt_skb_alloc() returns NULL pointer
not ERR_PTR(). The IS_ERR() test in the return value check should
be replaced with NULL test.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
net/bluetooth/6lowpan.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index 37239db..fb38c78 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -337,8 +337,8 @@ static inline int skbuff_copy(void *msg, int len, int count, int mtu,
count = min_t(unsigned int, mtu, len);
tmp = bt_skb_alloc(count, GFP_ATOMIC);
- if (IS_ERR(tmp))
- return PTR_ERR(tmp);
+ if (!tmp)
+ return PTR_ERR(-ENOMEM);
*frag = tmp;
@@ -384,8 +384,8 @@ static struct sk_buff *create_pdu(struct l2cap_conn *conn, void *msg,
BT_DBG("conn %p len %zu mtu %d count %d", conn, len, conn->mtu, count);
skb = bt_skb_alloc(count + L2CAP_HDR_SIZE, GFP_ATOMIC);
- if (IS_ERR(skb))
- return skb;
+ if (!skb)
+ return ERR_PTR(-ENOMEM);
skb->priority = priority;
^ permalink raw reply related
* [PATCH -next] Bluetooth: remove unused including <linux/version.h>
From: Wei Yongjun @ 2013-12-14 4:43 UTC (permalink / raw)
To: marcel, gustavo, johan.hedberg; +Cc: yongjun_wei, linux-bluetooth
From: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Remove including <linux/version.h> that don't need it.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
---
net/bluetooth/6lowpan.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/bluetooth/6lowpan.c b/net/bluetooth/6lowpan.c
index ba840fe..18c48e1 100644
--- a/net/bluetooth/6lowpan.c
+++ b/net/bluetooth/6lowpan.c
@@ -11,7 +11,6 @@
GNU General Public License for more details.
*/
-#include <linux/version.h>
#include <linux/if_arp.h>
#include <linux/netdevice.h>
#include <linux/etherdevice.h>
^ permalink raw reply related
* Re: Failed to connect: org.bluez.Error.NotReady
From: Brian J. Murrell @ 2013-12-13 17:36 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: Szymon Janc, Bastien Nocera, BlueZ development
In-Reply-To: <CAJdJm_NMUP3gd1oABgXL9iYJPSwez=1DGCF2b8uKwVNosRS0ZQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1192 bytes --]
On Fri, 2013-12-13 at 15:09 -0200, Anderson Lizardo wrote:
> Hi Brian,
Hi Anderson,
> Since BlueZ 5, the adapter power state (on/off) is not saved anymore
> by bluetoothd (on BlueZ 4, there were InitiallyPowered/RememberPowered
> options in main.conf that took care of powering up adapters; these
> options are gone in BlueZ 5). There should be an external component
> that takes care of powering up the adapter after it is attached.
Interesting. I wonder if F20 itself is supposed to be doing this or if
it's expecting the desktop (i.e. via applet or whatever) to do it.
> As Bastien mentioned, it is built-in for GNOME.
Ahh.
> I don't use GNOME,
Me either. I use MATE. GNOME[3] is incapable of handling my video
configuration. GNOME2 and thus MATE handles it just fine, FWIW.
> but
> in theory, once you enable Bluetooth on its settings, the adapter will
> be powered on once it is attached.
So, it seems that F20 *is* expecting the desktop model to handle that.
I wonder what the model is supposed to be for the likes of MATE. I'm
not at all convinced that the MATE that's in F20 has been
bluetooth-enabled to handle this.
Cheers,
b.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Failed to connect: org.bluez.Error.NotReady
From: Anderson Lizardo @ 2013-12-13 17:09 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: Szymon Janc, Bastien Nocera, BlueZ development
In-Reply-To: <1386951737.23365.19.camel@pc.interlinx.bc.ca>
Hi Brian,
On Fri, Dec 13, 2013 at 2:22 PM, Brian J. Murrell <brian@interlinx.bc.ca> wrote:
> [bluetooth]# power on
> [CHG] Controller 00:02:72:1E:E0:12 Class: 0x0c0104
> Changing power on succeeded
> [CHG] Controller 00:02:72:1E:E0:12 Powered: yes
> [CHG] Device 7C:1E:52:6E:59:D2 Connected: yes
>
> And now the mouse works. I wonder what happened in the first place to
> make it stop running. Certainly the unplugging/plugging in of the
> dongle might have been enough to need it powering on so it's not clear
> that it just spontaneously lost power or anything like that.
Since BlueZ 5, the adapter power state (on/off) is not saved anymore
by bluetoothd (on BlueZ 4, there were InitiallyPowered/RememberPowered
options in main.conf that took care of powering up adapters; these
options are gone in BlueZ 5). There should be an external component
that takes care of powering up the adapter after it is attached.
>
>> (assuming there is no UI applet running that should take care of
>> powering it up automatically.)
>
> Which is an interesting point. What is the UI applet for all of this
> supposed to be now in F20?
As Bastien mentioned, it is built-in for GNOME. I don't use GNOME, but
in theory, once you enable Bluetooth on its settings, the adapter will
be powered on once it is attached.
Best Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Failed to connect: org.bluez.Error.NotReady
From: Bastien Nocera @ 2013-12-13 16:24 UTC (permalink / raw)
To: Brian J. Murrell; +Cc: Anderson Lizardo, Szymon Janc, BlueZ development
In-Reply-To: <1386951737.23365.19.camel@pc.interlinx.bc.ca>
On Fri, 2013-12-13 at 11:22 -0500, Brian J. Murrell wrote:
<snip>
> > (assuming there is no UI applet running that should take care of
> > powering it up automatically.)
>
> Which is an interesting point. What is the UI applet for all of this
> supposed to be now in F20?
There's no "applet" in GNOME 3.10. Launch the Settings -> Bluetooth and
turn Bluetooth on there, in the titlebar.
^ 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