* Re: [PATCH 0/4] Bluetooth: Associate connectable setting with adv type
From: Marcel Holtmann @ 2013-10-14 18:24 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1381774527-13746-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> Here's a rewritten patch set to allow associating the connectable
> setting with the advertising type. Unlike the first attempt this one
> doesn't introduce a new parameter to enable_advertising() but instead
> does a pending mgmt command lookup to help determine the right
> advertising type.
>
> There's also a fourth patch to do similar refactoring for
> set_discoverable as we did for set_connectable wrt. splitting raw HCI
> sockets from mgmt control, but I didn't quite get around to tying that
> to the advertising data yet (the general discoverable flag).
>
> Johan
>
> ----------------------------------------------------------------
> Johan Hedberg (4):
> Bluetooth: Make Set Connectable also update the LE advertising type
> Bluetooth: Move set_bredr_scan() to avoid forward declaration
> Bluetooth: Fix updating scan mode in set_bredr()
> Bluetooth: Convert Set Discoverable to use an asynchronous request
>
> net/bluetooth/mgmt.c | 144 ++++++++++++++++++++++++++++++++++++++-------------
> 1 file changed, 109 insertions(+), 35 deletions(-)
all four patches have been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] Bluetooth: Reject invalid bdaddr types for sockets
From: Marcel Holtmann @ 2013-10-14 18:27 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1381774673-14150-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> We need to verify that the bdaddr type passed to connect() and bind() is
> within the set of valid values. If it is not we need to cleanly fail
> with EINVAL.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_sock.c | 6 ++++++
> 1 file changed, 6 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/2] Bluetooth: Check that bind() bdaddr type matches connect()
From: Marcel Holtmann @ 2013-10-14 18:27 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1381774673-14150-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> If a socket was bound to an address type other than BR/EDR (such as LE)
> we should reject trying to connect it to a BR/EDR address. The same
> applies for binding to BR/EDR and trying to connect to non-BR/EDR.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> net/bluetooth/l2cap_sock.c | 6 ++++++
> 1 file changed, 6 insertions(+)
patch has been applied to bluetooth-next tree.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Check that scan window is smaller or equal than scan interval
From: Johan Hedberg @ 2013-10-14 18:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381769732-19707-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Mon, Oct 14, 2013, Marcel Holtmann wrote:
> The scan window parameter for connection establishment and passive
> scanning needs to be smaller or equal than the scan interval.
>
> Instead of waiting for a controller to reject these values later on,
> just reject them right away.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/mgmt.c | 4 ++++
> 1 file changed, 4 insertions(+)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* [RFC BlueZ v0] doc: Add GATT API
From: Claudio Takahasi @ 2013-10-14 19:09 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
This patch proposes an unified GATT API for local and remote services.
---
Partial implementation of the proposed API:
git://git.infradead.org/users/cktakahasi/bluez.git gatt-api-devel
doc/gatt-api.txt | 158 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 158 insertions(+)
create mode 100644 doc/gatt-api.txt
diff --git a/doc/gatt-api.txt b/doc/gatt-api.txt
new file mode 100644
index 0000000..af4d68d
--- /dev/null
+++ b/doc/gatt-api.txt
@@ -0,0 +1,158 @@
+BlueZ D-Bus GATT API description
+********************************
+
+GATT local and remote services share the same high-level D-Bus API. Local
+refers to local GATT based service exported by a BlueZ plugin or an external
+application. Remote refers to GATT services exported by the peer.
+
+BlueZ acts as a proxy, translating ATT operations to D-Bus method calls and
+Properties (or the opposite). Support for D-Bus Object Manager is mandatory for
+external services to allow seamless GATT declarations (Service, Characteristic
+and Descriptors) discovery.
+
+Service hierarchy
+=================
+
+GATT remote and local service representation. Object path for local services
+is freely definable.
+
+External local services should register the services using ServiceManager1
+registration method and must implement ServiceAgent1 interface.
+
+Service org.bluez
+Interface org.bluez.Service1 [Experimental]
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serviceXX
+
+Properties string UUID [read-only]
+
+ 128-bit UUID of the GATT based service. It represents
+ the UUID of a local external service or remote GATT
+ service.
+
+ array{object} Includes [read-only]: Not implemented
+
+ Array of object paths representing the included
+ services of this service.
+
+
+Characteristic hierarchy
+========================
+
+For local GATT defined services, the object paths need to follow the service
+path hierarchy and are freely definable.
+
+Service org.bluez
+Interface org.bluez.Characteristic1 [Experimental]
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serviceXX/charYYYY
+
+Properties string UUID [read-only]
+
+ 128-bit characteristic UUID. It represents the UUID of
+ a local external characteristic or remote GATT
+ characteristic.
+
+ object Service [read-only]
+
+ Object path of the GATT service the characteristc
+ belongs to.
+
+ array{byte} Value [read-write]
+
+ Cached Value of the characteristic. If present, the
+ value will be cached by bluetoothd and updated when the
+ PropertiesChanged signal is emitted.
+
+ External services must emit this signal when the
+ characteristic supports notification/indication, so
+ that clients can be notified of the new value.
+
+ array{string} Flags [read-only, optional]
+
+ Defines how the characteristic value can be used. See
+ Core spec page 1898, "Table 3.5: Characteristic
+ Properties bit field" and page 1900, "Table 3.8:
+ Characteristic Extended Properties bit field". Allowed
+ values: "broadcast", "read", "write-without-response",
+ "write", "notify", "indicate",
+ "authenticated-signed-writes", "reliable-write", and
+ "writable-auxiliaries".
+
+
+Characteristic Descriptors hierarchy
+====================================
+
+Local or remote GATT characteristic descriptors hierarchy.
+
+Service org.bluez
+Interface org.bluez.Descriptor1 [Experimental]
+Object path [variable prefix]/{hci0,hci1,...}/dev_XX_XX_XX_XX_XX_XX/serviceXX/charYYYY/descriptorZZZ
+
+Properties string UUID [read-only]
+
+ 128-bit descriptor UUID. It represents the UUID of a
+ local external descriptor or remote descriptor.
+
+ object Characteristic [read-only]
+
+ Object path of the GATT characteristc the descriptor
+ belongs to.
+
+ array{byte} Value [read-write]
+
+ Raw characteristic descriptor value. For external GATT
+ services, value changes should be reported through
+ PropertiesChanged signal.
+
+ string Permissions [read-only]: To be defined
+
+ Defines read/write authentication and authorization
+ requirements.
+
+Service Manager hierarchy
+=========================
+
+ServiceManager allows external applications to register GATT based services.
+Services should follow the API for Service and Characteristic described above.
+
+For GATT local services, services and characteristics definitions are
+discovered automatically using D-Bus Object Manager.
+
+Service org.bluez
+Interface org.bluez.ServiceManager1 [Experimental]
+Object path /org/bluez
+
+Methods RegisterApplication(object application, dict options)
+
+ Registers remote application services exported under
+ the interface Service1. Characteristic objects must
+ be hierarchical to their service and must use the
+ interface Characteristic1. D-Bus Object Manager is
+ used to fetch the exported objects.
+
+ "application" object path together with the D-Bus system
+ bus connection ID define the identification of the
+ application registering a GATT based service.
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.AlreadyExists
+
+ UnregisterApplication(object application)
+
+ This unregisters the application that has been
+ previously registered. The object path parameter
+ must match the same value that has been used
+ on registration.
+
+ Possible errors: org.bluez.Error.DoesNotExist
+
+Service Agent hierarchy
+=======================
+
+Service org.bluez
+Interface org.bluez.ServiceAgent1 [Experimental]
+Object path freely definable
+
+Methods void Release()
+
+ Release this agent. At this point, it will not be used
+ by BlueZ anymore and can be destroyed by the owner.
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Read number of supported IAC on controller setup
From: Marcel Holtmann @ 2013-10-14 20:56 UTC (permalink / raw)
To: linux-bluetooth
When initializing a controller make sure to read out the number of
supported IAC and store its result. This value is needed to determine
if limited discoverable for BR/EDR can be configured or not.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci.h | 6 ++++++
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_core.c | 6 +++++-
net/bluetooth/hci_event.c | 19 +++++++++++++++++++
4 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index c8a91cb..8567f44 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -815,6 +815,12 @@ struct hci_cp_host_buffer_size {
__le16 sco_max_pkt;
} __packed;
+#define HCI_OP_READ_NUM_SUPPORTED_IAC 0x0c38
+struct hci_rp_read_num_supported_iac {
+ __u8 status;
+ __u8 num_iac;
+} __packed;
+
#define HCI_OP_WRITE_INQUIRY_MODE 0x0c45
#define HCI_MAX_EIR_LENGTH 240
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 0326b16..4e20842 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -159,6 +159,7 @@ struct hci_dev {
__u16 manufacturer;
__u16 lmp_subver;
__u16 voice_setting;
+ __u8 num_iac;
__u8 io_capability;
__s8 inq_tx_power;
__u16 page_scan_interval;
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 0e05ede..b5ef05e 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -370,6 +370,9 @@ static void bredr_setup(struct hci_request *req)
/* Read Voice Setting */
hci_req_add(req, HCI_OP_READ_VOICE_SETTING, 0, NULL);
+ /* Read Number of Supported IAC */
+ hci_req_add(req, HCI_OP_READ_NUM_SUPPORTED_IAC, 0, NULL);
+
/* Clear Event Filters */
flt_type = HCI_FLT_CLEAR_ALL;
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
@@ -2271,7 +2274,8 @@ struct hci_dev *hci_alloc_dev(void)
hdev->pkt_type = (HCI_DM1 | HCI_DH1 | HCI_HV1);
hdev->esco_type = (ESCO_HV1);
hdev->link_mode = (HCI_LM_ACCEPT);
- hdev->io_capability = 0x03; /* No Input No Output */
+ hdev->num_iac = 0x01; /* One IAC support is mandatory */
+ hdev->io_capability = 0x03; /* No Input No Output */
hdev->inq_tx_power = HCI_TX_POWER_INVALID;
hdev->adv_tx_power = HCI_TX_POWER_INVALID;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index da2bc3d..5391469 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -418,6 +418,21 @@ static void hci_cc_write_voice_setting(struct hci_dev *hdev,
hdev->notify(hdev, HCI_NOTIFY_VOICE_SETTING);
}
+static void hci_cc_read_num_supported_iac(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_read_num_supported_iac *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, rp->status);
+
+ if (rp->status)
+ return;
+
+ hdev->num_iac = rp->num_iac;
+
+ BT_DBG("%s num iac %d", hdev->name, hdev->num_iac);
+}
+
static void hci_cc_write_ssp_mode(struct hci_dev *hdev, struct sk_buff *skb)
{
__u8 status = *((__u8 *) skb->data);
@@ -2135,6 +2150,10 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_write_voice_setting(hdev, skb);
break;
+ case HCI_OP_READ_NUM_SUPPORTED_IAC:
+ hci_cc_read_num_supported_iac(hdev, skb);
+ break;
+
case HCI_OP_WRITE_SSP_MODE:
hci_cc_write_ssp_mode(hdev, skb);
break;
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Read current IAC LAP on controller setup
From: Marcel Holtmann @ 2013-10-14 21:06 UTC (permalink / raw)
To: linux-bluetooth
Read the current IAC LAP values when initializing the controller. The
values are not used, but it is good to have them in the trace files
for debugging purposes.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci.h | 2 ++
net/bluetooth/hci_core.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 8567f44..b096f5f 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -821,6 +821,8 @@ struct hci_rp_read_num_supported_iac {
__u8 num_iac;
} __packed;
+#define HCI_OP_READ_CURRENT_IAC_LAP 0x0c39
+
#define HCI_OP_WRITE_INQUIRY_MODE 0x0c45
#define HCI_MAX_EIR_LENGTH 240
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index b5ef05e..7add9c9 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -373,6 +373,9 @@ static void bredr_setup(struct hci_request *req)
/* Read Number of Supported IAC */
hci_req_add(req, HCI_OP_READ_NUM_SUPPORTED_IAC, 0, NULL);
+ /* Read Current IAC LAP */
+ hci_req_add(req, HCI_OP_READ_CURRENT_IAC_LAP, 0, NULL);
+
/* Clear Event Filters */
flt_type = HCI_FLT_CLEAR_ALL;
hci_req_add(req, HCI_OP_SET_EVENT_FLT, 1, &flt_type);
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH] Bluetooth: Read current IAC LAP on controller setup
From: Gustavo Padovan @ 2013-10-14 22:32 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381784796-52321-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
2013-10-14 Marcel Holtmann <marcel@holtmann.org>:
> Read the current IAC LAP values when initializing the controller. The
> values are not used, but it is good to have them in the trace files
> for debugging purposes.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> include/net/bluetooth/hci.h | 2 ++
> net/bluetooth/hci_core.c | 3 +++
> 2 files changed, 5 insertions(+)
Both patches have been pushed to bluetooth-next. Thanks.
Gustavo
^ permalink raw reply
* [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Marcel Holtmann @ 2013-10-14 23:08 UTC (permalink / raw)
To: linux-bluetooth
The limited discoverable mode should be used when a device is only
discoverable for a certain amount of time and after that it returns
back into being non-discoverable.
The management interface allows to specify a timeout parameter when
makeing a device discoverable. If such a timeout is specified or
changed, enter limited discoverable mode. Otherwise enter general
discoverable mode.
Devices in limited discoverable mode can still be found by the
general discovery procedure. It is mandatory that a device sets
both GIAC and LIAC when entering limited discoverable mode.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
include/net/bluetooth/hci.h | 6 ++++++
net/bluetooth/mgmt.c | 41 +++++++++++++++++++++++++++++++++++++----
2 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index b096f5f..ab96f3b 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -823,6 +823,12 @@ struct hci_rp_read_num_supported_iac {
#define HCI_OP_READ_CURRENT_IAC_LAP 0x0c39
+#define HCI_OP_WRITE_CURRENT_IAC_LAP 0x0c3a
+struct hci_cp_write_current_iac_lap {
+ __u8 num_iac;
+ __u8 iac_lap[6];
+} __packed;
+
#define HCI_OP_WRITE_INQUIRY_MODE 0x0c45
#define HCI_MAX_EIR_LENGTH 240
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 861e389..cba15da 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1041,6 +1041,8 @@ static int set_discoverable(struct sock *sk, struct hci_dev *hdev, void *data,
}
if (!!cp->val == test_bit(HCI_DISCOVERABLE, &hdev->dev_flags)) {
+ u16 current_timeout = hdev->discov_timeout;
+
if (hdev->discov_timeout > 0) {
cancel_delayed_work(&hdev->discov_off);
hdev->discov_timeout = 0;
@@ -1052,8 +1054,16 @@ static int set_discoverable(struct sock *sk, struct hci_dev *hdev, void *data,
msecs_to_jiffies(hdev->discov_timeout * 1000));
}
- err = send_settings_rsp(sk, MGMT_OP_SET_DISCOVERABLE, hdev);
- goto failed;
+ /* A change in timeout means that the device is switching
+ * from one discoverable mode to another. In that case
+ * the IAC LAP needs to be changed.
+ */
+ if ((current_timeout > 0 && timeout > 0) ||
+ (current_timeout == 0 && timeout == 0)) {
+ err = send_settings_rsp(sk, MGMT_OP_SET_DISCOVERABLE,
+ hdev);
+ goto failed;
+ }
}
cmd = mgmt_pending_add(sk, MGMT_OP_SET_DISCOVERABLE, hdev, data, len);
@@ -1066,10 +1076,33 @@ static int set_discoverable(struct sock *sk, struct hci_dev *hdev, void *data,
scan = SCAN_PAGE;
- if (cp->val)
+ if (cp->val) {
+ struct hci_cp_write_current_iac_lap cp;
+
+ if (timeout > 0) {
+ /* Limited discoverable mode */
+ cp.num_iac = 2;
+ cp.iac_lap[0] = 0x00; /* LIAC */
+ cp.iac_lap[1] = 0x8b;
+ cp.iac_lap[2] = 0x9e;
+ cp.iac_lap[3] = 0x33; /* GIAC */
+ cp.iac_lap[4] = 0x8b;
+ cp.iac_lap[5] = 0x9e;
+ } else {
+ /* General discoverable mode */
+ cp.num_iac = 1;
+ cp.iac_lap[0] = 0x33; /* GIAC */
+ cp.iac_lap[1] = 0x8b;
+ cp.iac_lap[2] = 0x9e;
+ }
+
+ hci_req_add(&req, HCI_OP_WRITE_CURRENT_IAC_LAP,
+ (cp.num_iac * 3) + 1, &cp);
+
scan |= SCAN_INQUIRY;
- else
+ } else {
cancel_delayed_work(&hdev->discov_off);
+ }
hci_req_add(&req, HCI_OP_WRITE_SCAN_ENABLE, 1, &scan);
--
1.8.3.1
^ permalink raw reply related
* [PATCH] Bluetooth: Fix minor coding style issue in set_connectable()
From: Marcel Holtmann @ 2013-10-14 23:38 UTC (permalink / raw)
To: linux-bluetooth
There is a minor coding style violation and so just fix it. No actual
logic has changed.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
---
net/bluetooth/mgmt.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index cba15da..9048653 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -1297,14 +1297,13 @@ static int set_connectable(struct sock *sk, struct hci_dev *hdev, void *data,
if (test_bit(HCI_BREDR_ENABLED, &hdev->dev_flags) &&
cp->val != test_bit(HCI_PSCAN, &hdev->flags)) {
-
if (cp->val) {
scan = SCAN_PAGE;
} else {
scan = 0;
if (test_bit(HCI_ISCAN, &hdev->flags) &&
- hdev->discov_timeout > 0)
+ hdev->discov_timeout > 0)
cancel_delayed_work(&hdev->discov_off);
}
--
1.8.3.1
^ permalink raw reply related
* pull request: bluetooth-next 2013-10-14
From: Gustavo Padovan @ 2013-10-14 23:52 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, linux-bluetooth, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 12473 bytes --]
Hi John,
More patches for 3.12, busy times for Bluetooth. More than a 100 commits since
the last pull. The bulk of work comes from Johan and Marcel, they are doing
fixes and improvements all over the Bluetooth subsystem, as the diffstat can
show.
Please pull or let me know of any problems! Thanks.
Gustavo
--
The following changes since commit 4f3e219d95a3c31b916dcd5e2631c4e440736f79:
Bluetooth: Only one command per L2CAP LE signalling is supported (2013-10-03 16:09:59 +0300)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next for-upstream
for you to fetch changes up to 4b836f393bd8ed111857a6ee1865e44627266ec6:
Bluetooth: Read current IAC LAP on controller setup (2013-10-14 19:31:18 -0300)
----------------------------------------------------------------
Andre Guedes (4):
Bluetooth: Rename hci_conn variable in hci_connect_le()
Bluetooth: Initialize hci_conn fields in hci_connect_le
Bluetooth: Use HCI request for LE connection
Bluetooth: Refactor hci_connect_le
Johan Hedberg (17):
Bluetooth: Rename HCI_LE_PERIPHERAL to HCI_ADVERTISING
Bluetooth: Add public mgmt function to send New Settings event
Bluetooth: Fix re-enabling advertising after a connection
Bluetooth: Fix changing advertising setting while LE is connected
Bluetooth: Fix potential double-frees of L2CAP skbs
Bluetooth: Fix checking for HCI_SETUP flag when receiving mgmt commands
Bluetooth: Reorganize set_connectable HCI command sending
Bluetooth: Move more logic into set_connectable complete callback
Bluetooth: Add missing error handling for Set Connectable
Bluetooth: Move static advertising functions to avoid forward declarations
Bluetooth: Fix updating advertising data needlessly
Bluetooth: Make Set Connectable also update the LE advertising type
Bluetooth: Move set_bredr_scan() to avoid forward declaration
Bluetooth: Fix updating scan mode in set_bredr()
Bluetooth: Convert Set Discoverable to use an asynchronous request
Bluetooth: Reject invalid bdaddr types for sockets
Bluetooth: Check that bind() bdaddr type matches connect()
Johannes Berg (1):
Bluetooth: Fix variable shadow warnings
Marcel Holtmann (117):
Bluetooth: Fix controller list for AMP discover response
Bluetooth: Remove useless external function to count controllers
Bluetooth: Add constants for AMP controller type
Bluetooth: Separate AMP controller type from HCI device type
Bluetooth: Use explicit AMP controller id value for BR/EDR
Bluetooth: Rename AMP status constants and use them
Bluetooth: Remove pointless inline function
Bluetooth: Remove check for number of AMP controller
Bluetooth: Move hci_amp_capable() function into L2CAP core
Bluetooth: Simplify check if L2CAP connection is AMP capable
Bluetooth: Check for non BR/EDR controller in AMP discover response
Bluetooth: Reject enabling controllers without valid addresses
Bluetooth: Use explicit check for BR/EDR device type
Bluetooth: Simplify device type check for AMP discover response
Bluetooth: Use random address if public address is not available
Bluetooth: Add HCI structure for LE advertising parameters command
Bluetooth: Make it clear that disabling LE disables advertising
Bluetooth: Use helper functions for enabling/disabling advertising
Bluetooth: Add constants for LE advertising types
Bluetooth: Set LE advertising parameters before enabling it
Bluetooth: Use helper function for re-enabling advertising
Bluetooth: Remove no longer needed mgmt_new_settings() function
Bluetooth: Remove mgmt_valid_hdev() helper function
Bluetooth: Send new settings only when pairable changes
Bluetooth: Make mgmt_index_added() and mgmt_index_removed() return void
Bluetooth: Make mgmt_set_powered_failed() return void
Bluetooth: Make mgmt_disconnect_failed() return void
Bluetooth: Make mgmt_connect_failed() return void
Bluetooth: Make mgmt_device_connected() return void
Bluetooth: Make mgmt_device_disconnected() return void
Bluetooth: Make mgmt_device_found() return void
Bluetooth: Make mgmt_remote_name() return void
Bluetooth: Make mgmt_discovering() return void
Bluetooth: Power off AMP controllers after setup phase
Bluetooth: Make mgmt power down notification for BR/EDR explicit
Bluetooth: List powered down AMP controllers correctly
Bluetooth: Read supported features and commands on AMP controllers
Bluetooth: Read location data on AMP controller init
Bluetooth: Read flow control mode on AMP controller init
Bluetooth: Remove unneeded val variable when setting SSP
Bluetooth: Restrict high speed support to SSP enabled controllers
Bluetooth: Fix too long line with set_advertising() function
Bluetooth: Use hci_conn_num() for checking number of LE connections
Bluetooth: Use hci_conn_num() instead of direct connection hash access
Bluetooth: AMP contollers do not support the legacy ioctls
Bluetooth: Remove unused bfusb_ioctl() callback
Bluetooth: Remove unused bluecard_hci_ioctl() callback
Bluetooth: Remove unused bt3c_hci_ioctl() callback
Bluetooth: Remove unused btuart_hci_ioctl() callback
Bluetooth: Remove unused dtl1_hci_ioctl() callback
Bluetooth: Remove unused btmrvl_ioctl() callback
Bluetooth: Remove hdev->ioctl driver callback
Bluetooth: Move amp.h header file into net/bluetooth/
Bluetooth: Move a2mp.h header file into net/bluetooth/
Bluetooth: Move smp.h header file into net/bluetooth/
Bluetooth: Move skb->dev assignment for hdev->send into central place
Bluetooth: Remove pointless check of hci_send_frame parameter
Bluetooth: Remove return value from hci_send_frame() function
Bluetooth: Remove unused h4_check_data_len() function
Bluetooth: Provide hdev parameter to hci_recv_frame() driver callback
Bluetooth: Add hdev parameter to hdev->send driver callback
Bluetooth: Remove pointless parameter check in bfusb_send_frame()
Bluetooth: Remove pointless parameter check in bluecard_hci_send_frame()
Bluetooth: Remove pointless parameter check in bt3c_hci_send_frame()
Bluetooth: Remove pointless parameter check in btmrvl_send_frame()
Bluetooth: Remove pointless parameter check in btuart_hci_send_frame()
Bluetooth: Remove pointless parameter check in dtl1_hci_send_frame()
Bluetooth: Remove pointless parameter check in hci_uart_send_frame()
Bluetooth: Remove pointless parameter check in vhci_send_frame()
Bluetooth: Declare btusb_table[] and blacklist_table[] as const
Bluetooth: Declare bfusb_table[] as const
Bluetooth: Declare bpa10x_table[] as const
Bluetooth: Declare ath3k_table[] and ath3k_blist_tbl[] as const
Bluetooth: Make LE scan interval and window a controller option
Bluetooth: Add management command for setting LE scan parameters
Bluetooth: Fix endless loop with HCI_QUIRK_RESET_ON_CLOSE
Bluetooth: Don't advertise high speed support without SSP
Bluetooth: Add MGMT_OP_SET_SCAN_PARAMS to supported commands list
Bluetooth: Fix HCI init for 1st generation BlueFRITZ! devices
Bluetooth: Fix PSM value for L2CAP connectionless data packets
Bluetooth: Limit security mode 4 level 0 to connection oriented channels
Bluetooth: Allow 3D profile to use security mode 4 level 0
Bluetooth: The L2CAP fixed channel connectionless data is supported
Bluetooth: Unicast connectionless data reception is supported
Bluetooth: Remove l2cap_conn->dst usage from AMP manager
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from SMP
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst usage from L2CAP
Bluetooth: Remove l2cap_conn->src and l2cap_conn->dst pointers
Bluetooth: Remove pointless bdaddr_to_le() helper function
Bluetooth: Store the source address type of LE connections
Bluetooth: Store source address of HCI connections
Bluetooth: Update source address and type for incoming LE connections
Bluetooth: Use hci_conn->src address for SMP functions
Bluetooth: Use hci_conn->src address for L2CAP functions
Bluetooth: Fix input address type for SMP C1 function
Bluetooth: Fix coding style violations in SMP handling
Bluetooth: Update L2CAP socket source address from HCI connection
Bluetooth: Store address information in L2CAP channel structure
Bluetooth: Return the correct address type for L2CAP sockets
Bluetooth: Access RFCOMM session addresses through L2CAP channel
Bluetooth: Access CMTP session addresses through L2CAP channel
Bluetooth: Access HIDP session addresses through L2CAP channel
Bluetooth: Access BNEP session addresses through L2CAP channel
Bluetooth: Use SCO addresses from HCI connection directly
Bluetooth: Store SCO address information in its own socket structure
Bluetooth: Store RFCOMM address information in its own socket structure
Bluetooth: Remove src and dst fields from bt_sock structure
Bluetooth: Use l2cap_pi(sk) directly where possible
Bluetooth: Add support for per socket msg_name callback
Bluetooth: Provide msg_name callback for L2CAP connectionless channels
Bluetooth: Increase minor version of core module
Bluetooth: Adjust header for proc socket information
Bluetooth: Introduce L2CAP channel flag for defer setup
Bluetooth: Introduce L2CAP channel callback for resuming
Bluetooth: Check that scan window is smaller or equal than scan interval
Bluetooth: Read number of supported IAC on controller setup
Bluetooth: Read current IAC LAP on controller setup
drivers/bluetooth/ath3k.c | 4 +-
drivers/bluetooth/bfusb.c | 31 +--
drivers/bluetooth/bluecard_cs.c | 30 +--
drivers/bluetooth/bpa10x.c | 11 +-
drivers/bluetooth/bt3c_cs.c | 30 +--
drivers/bluetooth/btmrvl_main.c | 26 +-
drivers/bluetooth/btmrvl_sdio.c | 8 +-
drivers/bluetooth/btsdio.c | 6 +-
drivers/bluetooth/btuart_cs.c | 30 +--
drivers/bluetooth/btusb.c | 21 +-
drivers/bluetooth/btwilink.c | 9 +-
drivers/bluetooth/dtl1_cs.c | 30 +--
drivers/bluetooth/hci_bcsp.c | 5 +-
drivers/bluetooth/hci_h4.c | 24 --
drivers/bluetooth/hci_h5.c | 2 +-
drivers/bluetooth/hci_ldisc.c | 12 +-
drivers/bluetooth/hci_ll.c | 14 +-
drivers/bluetooth/hci_vhci.c | 15 +-
include/net/bluetooth/bluetooth.h | 5 +-
include/net/bluetooth/hci.h | 49 +++-
include/net/bluetooth/hci_core.h | 79 ++-----
include/net/bluetooth/l2cap.h | 14 +-
include/net/bluetooth/mgmt.h | 7 +
include/net/bluetooth/rfcomm.h | 2 +
include/net/bluetooth/sco.h | 5 +-
net/bluetooth/a2mp.c | 63 ++---
{include/net => net}/bluetooth/a2mp.h | 0
net/bluetooth/af_bluetooth.c | 23 +-
net/bluetooth/amp.c | 10 +-
{include/net => net}/bluetooth/amp.h | 0
net/bluetooth/bnep/core.c | 18 +-
net/bluetooth/cmtp/core.c | 6 +-
net/bluetooth/hci_conn.c | 156 ++++++++----
net/bluetooth/hci_core.c | 156 +++++++-----
net/bluetooth/hci_event.c | 103 ++++----
net/bluetooth/hci_sock.c | 10 +-
net/bluetooth/hidp/core.c | 18 +-
net/bluetooth/l2cap_core.c | 221 ++++++++++-------
net/bluetooth/l2cap_sock.c | 86 +++++--
net/bluetooth/mgmt.c | 550 ++++++++++++++++++++++++++++++-------------
net/bluetooth/rfcomm/core.c | 19 +-
net/bluetooth/rfcomm/sock.c | 28 ++-
net/bluetooth/sco.c | 44 ++--
net/bluetooth/smp.c | 81 ++++---
{include/net => net}/bluetooth/smp.h | 0
45 files changed, 1192 insertions(+), 869 deletions(-)
rename {include/net => net}/bluetooth/a2mp.h (100%)
rename {include/net => net}/bluetooth/amp.h (100%)
rename {include/net => net}/bluetooth/smp.h (100%)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] audio/AVDTP: Fix crash after disconnecting
From: Johan Hedberg @ 2013-10-15 6:57 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1381745687-5677-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Oct 14, 2013, Luiz Augusto von Dentz wrote:
> If the session is disconnected while process_discover is pending the
> source id is not removed causing the following crash:
> at 0x414C08: finalize_discovery (avdtp.c:1050)
> by 0x414C5A: process_discover (avdtp.c:3346)
> by 0x3D46047E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x3D46048157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x3D46048559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x40A3B6: main (main.c:595)
> Address 0x5e25de8 is 1,144 bytes inside a block of size 1,176 free'd
> at 0x4A074C4: free (in
> /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
> by 0x3D4604D9AE: g_free (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x4152F2: connection_lost (avdtp.c:1206)
> by 0x4162C4: cancel_request (avdtp.c:2662)
> by 0x4164BD: request_timeout (avdtp.c:2672)
> by 0x3D46048962: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x3D46047E05: g_main_context_dispatch (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x3D46048157: ??? (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x3D46048559: g_main_loop_run (in /usr/lib64/libglib-2.0.so.0.3600.3)
> by 0x40A3B6: main (main.c:595)
> ---
> profiles/audio/avdtp.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
All three patches have been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH BlueZ] audio/AVCTP: Fix sending requests with same transaction id
From: Johan Hedberg @ 2013-10-15 6:58 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1381754763-27278-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Oct 14, 2013, Luiz Augusto von Dentz wrote:
> If a request is outstanding in the processed list its transaction shall
> not be reused as it can cause the wrong callback to be called.
>
> This can be reproduced in very rare occasions where e.g. a notification
> using the same transaction of the current request arrives before the
> response itself.
> ---
> profiles/audio/avctp.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
Applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Johan Hedberg @ 2013-10-15 7:31 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381792099-8732-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Mon, Oct 14, 2013, Marcel Holtmann wrote:
> + if (cp->val) {
> + struct hci_cp_write_current_iac_lap cp;
> +
> + if (timeout > 0) {
> + /* Limited discoverable mode */
Wouldn't we want to follow the recommendation from the Core spec here,
volume 3, part C, section 4.1.2.1:
"A Bluetooth device should not be in limited discoverable mode for more than
TGAP(104)"
TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Johan Hedberg @ 2013-10-15 7:40 UTC (permalink / raw)
To: Marcel Holtmann, linux-bluetooth
In-Reply-To: <20131015073157.GA24495@x220.p-661hnu-f1>
Hi,
On Tue, Oct 15, 2013, Johan Hedberg wrote:
> On Mon, Oct 14, 2013, Marcel Holtmann wrote:
> > + if (cp->val) {
> > + struct hci_cp_write_current_iac_lap cp;
> > +
> > + if (timeout > 0) {
> > + /* Limited discoverable mode */
>
> Wouldn't we want to follow the recommendation from the Core spec here,
> volume 3, part C, section 4.1.2.1:
>
> "A Bluetooth device should not be in limited discoverable mode for more than
> TGAP(104)"
>
> TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
We might even want to limit this to 30 seconds so the same can be used
for LE once this is hooked up to advertising:
TGAP(lim_adv_timeout) 30.72s Maximum time to remain Required value
advertising when in the
limited discoverable mode
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Fix minor coding style issue in set_connectable()
From: Johan Hedberg @ 2013-10-15 8:28 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <1381793925-14134-1-git-send-email-marcel@holtmann.org>
Hi Marcel,
On Mon, Oct 14, 2013, Marcel Holtmann wrote:
> There is a minor coding style violation and so just fix it. No actual
> logic has changed.
>
> Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
> ---
> net/bluetooth/mgmt.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
Applied to bluetooth-next. Thanks.
Johan
^ permalink raw reply
* Re: [RFC BlueZ v0] doc: Add GATT API
From: Johan Hedberg @ 2013-10-15 8:35 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1381777790-28891-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Mon, Oct 14, 2013, Claudio Takahasi wrote:
> +Service Manager hierarchy
> +=========================
> +
> +ServiceManager allows external applications to register GATT based services.
> +Services should follow the API for Service and Characteristic described above.
> +
> +For GATT local services, services and characteristics definitions are
> +discovered automatically using D-Bus Object Manager.
> +
> +Service org.bluez
> +Interface org.bluez.ServiceManager1 [Experimental]
> +Object path /org/bluez
> +
> +Methods RegisterApplication(object application, dict options)
> +
> + Registers remote application services exported under
> + the interface Service1. Characteristic objects must
> + be hierarchical to their service and must use the
> + interface Characteristic1. D-Bus Object Manager is
> + used to fetch the exported objects.
> +
> + "application" object path together with the D-Bus system
> + bus connection ID define the identification of the
> + application registering a GATT based service.
> +
> + Possible errors: org.bluez.Error.InvalidArguments
> + org.bluez.Error.AlreadyExists
> +
> + UnregisterApplication(object application)
> +
> + This unregisters the application that has been
> + previously registered. The object path parameter
> + must match the same value that has been used
> + on registration.
> +
> + Possible errors: org.bluez.Error.DoesNotExist
> +
> +Service Agent hierarchy
> +=======================
> +
> +Service org.bluez
I suppose this should not be "org.bluez" since it's the agent that's
providing it.
> +Interface org.bluez.ServiceAgent1 [Experimental]
> +Object path freely definable
If this is the object registered by ServiceManager1.RegisterApplication
I think we need some renaming. Either this interface should be called
org.bluez.ServiceApplication1 or the registration method shoud be
renamed to RegisterAgent.
Or is the idea that an "application" is a set of objects and interfaces
(services, characteristics, etc.) and as a minimum there must be this
ServiceAgent1 interface at the root object? In that case the naming
might make sense.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Marcel Holtmann @ 2013-10-15 8:52 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20131015073157.GA24495@x220.p-661hnu-f1>
Hi Johan,
>> + if (cp->val) {
>> + struct hci_cp_write_current_iac_lap cp;
>> +
>> + if (timeout > 0) {
>> + /* Limited discoverable mode */
>
> Wouldn't we want to follow the recommendation from the Core spec here,
> volume 3, part C, section 4.1.2.1:
>
> "A Bluetooth device should not be in limited discoverable mode for more than
> TGAP(104)"
>
> TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
I was not going to be this strict. So yes, userspace can violate the GAP part here, but it might be a good idea to ensure that when a too large value is entered we stick with general discoverable mode. However is this really worth it.
Another option is to just reject too large timeout values as invalid parameters and force userspace to implement large timeouts with general discoverable mode in userspace.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Johan Hedberg @ 2013-10-15 9:16 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <66F13BAB-8341-44B5-9D84-A55DFDD6C324@holtmann.org>
Hi Marcel,
On Tue, Oct 15, 2013, Marcel Holtmann wrote:
> >> + if (cp->val) {
> >> + struct hci_cp_write_current_iac_lap cp;
> >> +
> >> + if (timeout > 0) {
> >> + /* Limited discoverable mode */
> >
> > Wouldn't we want to follow the recommendation from the Core spec here,
> > volume 3, part C, section 4.1.2.1:
> >
> > "A Bluetooth device should not be in limited discoverable mode for more than
> > TGAP(104)"
> >
> > TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
>
> I was not going to be this strict. So yes, userspace can violate the
> GAP part here, but it might be a good idea to ensure that when a too
> large value is entered we stick with general discoverable mode.
> However is this really worth it.
For Advertising the max value is actually not just a recommendation but
a requirement (check my other mail), so at least there we should
probably enforce it. And if we have to enforce it for LE we might as
well do it for BR/EDR too. It's anyway a rather simple change to the
if-statement.
> Another option is to just reject too large timeout values as invalid
> parameters and force userspace to implement large timeouts with
> general discoverable mode in userspace.
I don't think it's a good idea to force this kind of special handling to
user space (not just the requirement to know where the limits go but
also the need to implement a separate timer).
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Marcel Holtmann @ 2013-10-15 9:30 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20131015091658.GA4930@x220.p-661hnu-f1>
Hi Johan,
>>>> + if (cp->val) {
>>>> + struct hci_cp_write_current_iac_lap cp;
>>>> +
>>>> + if (timeout > 0) {
>>>> + /* Limited discoverable mode */
>>>
>>> Wouldn't we want to follow the recommendation from the Core spec here,
>>> volume 3, part C, section 4.1.2.1:
>>>
>>> "A Bluetooth device should not be in limited discoverable mode for more than
>>> TGAP(104)"
>>>
>>> TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
>>
>> I was not going to be this strict. So yes, userspace can violate the
>> GAP part here, but it might be a good idea to ensure that when a too
>> large value is entered we stick with general discoverable mode.
>> However is this really worth it.
>
> For Advertising the max value is actually not just a recommendation but
> a requirement (check my other mail), so at least there we should
> probably enforce it. And if we have to enforce it for LE we might as
> well do it for BR/EDR too. It's anyway a rather simple change to the
> if-statement.
>
>> Another option is to just reject too large timeout values as invalid
>> parameters and force userspace to implement large timeouts with
>> general discoverable mode in userspace.
>
> I don't think it's a good idea to force this kind of special handling to
> user space (not just the requirement to know where the limits go but
> also the need to implement a separate timer).
This sounds also a bit like black magic. Userspace needs to know that a small value enters limited discoverable mode and a large one sticks with general discoverable mode. We might should have added a flag to the command in the first place. However I think our general intention was that with a timeout we do limited discoverable mode and without a timeout we do general discoverable mode.
I was complaining on why we bothered with a timeout for this parameter when building src/share/mgmt.[ch] and cleaning up some of the core adapter handling. Mainly because for PairableTimeout D-Bus property we have to run our own timer and for DiscoverableTimeout property we rely on the kernel. And in the end just running your own timeout was a lot simpler, then integrating with the kernel.
So I would be actually fine just saying with timeout that is limited discoverable mode. If you want general discoverable mode with a timeout, then you have to run this by yourself.
Then again, nothing stops us from introducing mode 0x02 for limited discoverable if you feel that we should keep the general discoverable mode with a timeout.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Johan Hedberg @ 2013-10-15 9:49 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth
In-Reply-To: <F77D26AD-3835-4A7B-BD9F-CF5F5ACA7F4A@holtmann.org>
Hi Marcel,
On Tue, Oct 15, 2013, Marcel Holtmann wrote:
> >>>> + if (cp->val) {
> >>>> + struct hci_cp_write_current_iac_lap cp;
> >>>> +
> >>>> + if (timeout > 0) {
> >>>> + /* Limited discoverable mode */
> >>>
> >>> Wouldn't we want to follow the recommendation from the Core spec
> >>> here, volume 3, part C, section 4.1.2.1:
> >>>
> >>> "A Bluetooth device should not be in limited discoverable mode for
> >>> more than TGAP(104)"
> >>>
> >>> TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
> >>
> >> I was not going to be this strict. So yes, userspace can violate
> >> the GAP part here, but it might be a good idea to ensure that when
> >> a too large value is entered we stick with general discoverable
> >> mode. However is this really worth it.
> >
> > For Advertising the max value is actually not just a recommendation
> > but a requirement (check my other mail), so at least there we should
> > probably enforce it. And if we have to enforce it for LE we might as
> > well do it for BR/EDR too. It's anyway a rather simple change to the
> > if-statement.
> >
> >> Another option is to just reject too large timeout values as
> >> invalid parameters and force userspace to implement large timeouts
> >> with general discoverable mode in userspace.
> >
> > I don't think it's a good idea to force this kind of special
> > handling to user space (not just the requirement to know where the
> > limits go but also the need to implement a separate timer).
>
> This sounds also a bit like black magic. Userspace needs to know that
> a small value enters limited discoverable mode and a large one sticks
> with general discoverable mode. We might should have added a flag to
> the command in the first place. However I think our general intention
> was that with a timeout we do limited discoverable mode and without a
> timeout we do general discoverable mode.
>
> I was complaining on why we bothered with a timeout for this parameter
> when building src/share/mgmt.[ch] and cleaning up some of the core
> adapter handling. Mainly because for PairableTimeout D-Bus property we
> have to run our own timer and for DiscoverableTimeout property we rely
> on the kernel. And in the end just running your own timeout was a lot
> simpler, then integrating with the kernel.
>
> So I would be actually fine just saying with timeout that is limited
> discoverable mode. If you want general discoverable mode with a
> timeout, then you have to run this by yourself.
Fair enough, and I really don't want to complicate this more by adding a
new 0x02 value either. The patch has now been pushed to bluetooth-next.
Johan
^ permalink raw reply
* Re: [PATCH] Bluetooth: Add support for entering limited discoverable mode
From: Marcel Holtmann @ 2013-10-15 10:02 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20131015094905.GA5788@x220.p-661hnu-f1>
Hi Johan,
>>>>>> + if (cp->val) {
>>>>>> + struct hci_cp_write_current_iac_lap cp;
>>>>>> +
>>>>>> + if (timeout > 0) {
>>>>>> + /* Limited discoverable mode */
>>>>>
>>>>> Wouldn't we want to follow the recommendation from the Core spec
>>>>> here, volume 3, part C, section 4.1.2.1:
>>>>>
>>>>> "A Bluetooth device should not be in limited discoverable mode for
>>>>> more than TGAP(104)"
>>>>>
>>>>> TGAP(104) in turn is defined as 1 minute (vol 3, part C, Appendix A).
>>>>
>>>> I was not going to be this strict. So yes, userspace can violate
>>>> the GAP part here, but it might be a good idea to ensure that when
>>>> a too large value is entered we stick with general discoverable
>>>> mode. However is this really worth it.
>>>
>>> For Advertising the max value is actually not just a recommendation
>>> but a requirement (check my other mail), so at least there we should
>>> probably enforce it. And if we have to enforce it for LE we might as
>>> well do it for BR/EDR too. It's anyway a rather simple change to the
>>> if-statement.
>>>
>>>> Another option is to just reject too large timeout values as
>>>> invalid parameters and force userspace to implement large timeouts
>>>> with general discoverable mode in userspace.
>>>
>>> I don't think it's a good idea to force this kind of special
>>> handling to user space (not just the requirement to know where the
>>> limits go but also the need to implement a separate timer).
>>
>> This sounds also a bit like black magic. Userspace needs to know that
>> a small value enters limited discoverable mode and a large one sticks
>> with general discoverable mode. We might should have added a flag to
>> the command in the first place. However I think our general intention
>> was that with a timeout we do limited discoverable mode and without a
>> timeout we do general discoverable mode.
>>
>> I was complaining on why we bothered with a timeout for this parameter
>> when building src/share/mgmt.[ch] and cleaning up some of the core
>> adapter handling. Mainly because for PairableTimeout D-Bus property we
>> have to run our own timer and for DiscoverableTimeout property we rely
>> on the kernel. And in the end just running your own timeout was a lot
>> simpler, then integrating with the kernel.
>>
>> So I would be actually fine just saying with timeout that is limited
>> discoverable mode. If you want general discoverable mode with a
>> timeout, then you have to run this by yourself.
>
> Fair enough, and I really don't want to complicate this more by adding a
> new 0x02 value either. The patch has now been pushed to bluetooth-next.
and I was tending towards reworking the patch to add a new 0x02 mode. In that mode we enforce the correct timeout values ahead of time.
I am no longer convinced that we are doing the right thing here. I was 100% sure yesterday and today, I would start exploring other options.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ 1/3] audio/media: Add support for tracking Seeked signal
From: Luiz Augusto von Dentz @ 2013-10-15 10:11 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
In-Reply-To: <1381492404-25765-1-git-send-email-luiz.dentz@gmail.com>
Hi,
On Fri, Oct 11, 2013 at 2:53 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
>
> This tracks Seeked signal and update the position in case it happens.
> ---
> profiles/audio/media.c | 21 +++++++++++++++++++++
> 1 file changed, 21 insertions(+)
>
> diff --git a/profiles/audio/media.c b/profiles/audio/media.c
> index 9c72b8d..646c76a 100644
> --- a/profiles/audio/media.c
> +++ b/profiles/audio/media.c
> @@ -96,6 +96,7 @@ struct media_player {
> guint watch;
> guint properties_watch;
> guint track_watch;
> + guint seek_watch;
> char *status;
> uint32_t position;
> uint32_t duration;
> @@ -949,6 +950,7 @@ static void media_player_free(gpointer data)
> g_dbus_remove_watch(conn, mp->watch);
> g_dbus_remove_watch(conn, mp->properties_watch);
> g_dbus_remove_watch(conn, mp->track_watch);
> + g_dbus_remove_watch(conn, mp->seek_watch);
>
> if (mp->track)
> g_hash_table_unref(mp->track);
> @@ -1681,6 +1683,21 @@ static gboolean properties_changed(DBusConnection *connection, DBusMessage *msg,
> return TRUE;
> }
>
> +static gboolean position_changed(DBusConnection *connection, DBusMessage *msg,
> + void *user_data)
> +{
> + struct media_player *mp = user_data;
> + DBusMessageIter iter;
> +
> + DBG("sender=%s path=%s", mp->sender, mp->path);
> +
> + dbus_message_iter_init(msg, &iter);
> +
> + set_position(mp, &iter);
> +
> + return TRUE;
> +}
> +
> static struct media_player *media_player_create(struct media_adapter *adapter,
> const char *sender,
> const char *path,
> @@ -1702,6 +1719,10 @@ static struct media_player *media_player_create(struct media_adapter *adapter,
> path, MEDIA_PLAYER_INTERFACE,
> properties_changed,
> mp, NULL);
> + mp->seek_watch = g_dbus_add_signal_watch(conn, sender,
> + path, MEDIA_PLAYER_INTERFACE,
> + "Seeked", position_changed,
> + mp, NULL);
> mp->player = avrcp_register_player(adapter->btd_adapter, &player_cb,
> mp, media_player_free);
> if (!mp->player) {
> --
> 1.8.3.1
Pushed.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCHv1 0/5] Initial Android BlueZ patches
From: Andrei Emeltchenko @ 2013-10-15 10:36 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
This is second chunk from my initial big patch set. Fixed style issues commented
by Marcel.
Note that due to Marcel comment this cannot be built unless you include my patch
for Android bionic library:
http://code.google.com/p/android-bluez/source/detail?r=77a07e7703b63e280d9880baad30b3375e7df079&repo=bionic#
Andrei Emeltchenko (5):
android: Create HAL API header skeleton
android: Add basic mgmt initialization sequence
android: Add adapter and device struct for BlueZ daemon
android: sdp: Reuse BlueZ SDP server in Android
android: Add cap to bind to port < 1024
Makefile.android | 8 +-
android/Android.mk | 13 +++
android/adapter.c | 63 ++++++++++++++
android/adapter.h | 36 ++++++++
android/device.c | 29 +++++++
android/device.h | 24 +++++
android/hal_msg.h | 246 ++++++++++++++++++++++++++++++++++++++++++++++++++++
android/main.c | 244 +++++++++++++++++++++++++++++++++++++++++++++++++++
configure.ac | 4 +
9 files changed, 665 insertions(+), 2 deletions(-)
create mode 100644 android/adapter.c
create mode 100644 android/adapter.h
create mode 100644 android/device.c
create mode 100644 android/device.h
create mode 100644 android/hal_msg.h
--
1.7.10.4
^ permalink raw reply
* [PATCHv1 1/5] android: Create HAL API header skeleton
From: Andrei Emeltchenko @ 2013-10-15 10:36 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1381833423-862-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Header describes the protocol between Android HAL threads and BlueZ
daemon.
Change-Id: Idfba8c6ebe6234340d1b0258756ee2bedfc315d7
---
android/hal_msg.h | 246 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 246 insertions(+)
create mode 100644 android/hal_msg.h
diff --git a/android/hal_msg.h b/android/hal_msg.h
new file mode 100644
index 0000000..4c5ca69
--- /dev/null
+++ b/android/hal_msg.h
@@ -0,0 +1,246 @@
+/*
+ *
+ * BlueZ - Bluetooth protocol stack for Linux
+ *
+ * Copyright (C) 2013 Intel Corporation. All rights reserved.
+ *
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * This library is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
+ *
+ */
+
+struct hal_msg_hdr {
+ uint8_t service_id;
+ uint8_t opcode;
+ uint16_t len;
+} __attribute__((packed));
+
+#define HAL_SERVICE_ID_CORE 0
+#define HAL_SERVICE_ID_BLUETOOTH 1
+#define HAL_SERVICE_ID_SOCK 2
+#define HAL_SERVICE_ID_HIDHOST 3
+#define HAL_SERVICE_ID_PAN 4
+#define HAL_SERVICE_ID_HANDSFREE 5
+#define HAL_SERVICE_ID_AD2P 6
+#define HAL_SERVICE_ID_HEALTH 7
+#define HAL_SERVICE_ID_AVRCP 8
+#define HAL_SERVICE_ID_GATT 9
+
+/* Core Service */
+
+#define HAL_MSG_OP_ERROR 0x00
+struct hal_msg_rsp_error {
+ uint8_t status;
+} __attribute__((packed));
+
+#define HAL_MSG_OP_REGISTER_MODULE 0x01
+struct hal_msg_cmd_register_module {
+ uint8_t service_id;
+} __attribute__((packed));
+struct hal_msg_rsp_register_module {
+ uint8_t service_id;
+} __attribute__((packed));
+
+#define HAL_MSG_OP_UNREGISTER_MODULE 0x02
+struct hal_msg_cmd_unregister_module {
+ uint8_t service_id;
+} __attribute__((packed));
+
+/* Bluetooth Core HAL API */
+
+#define HAL_MSG_OP_BT_ENABLE 0x01
+
+#define HAL_MSG_OP_BT_DISABLE 0x02
+
+#define HAL_MSG_OP_BT_GET_ADAPTER_PROPS 0x03
+
+#define HAL_MSG_OP_BT_GET_ADAPTER_PROP 0x04
+struct hal_msg_cmd_bt_get_adapter_prop {
+ uint8_t type;
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_SET_ADAPTER_PROP 0x05
+struct hal_msg_cmd_bt_set_adapter_prop {
+ uint8_t type;
+ uint16_t len;
+ uint8_t val[0];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_GET_REMOTE_DEVICE_PROPS 0x06
+struct hal_msg_cmd_bt_get_remote_device_props {
+ uint8_t bdaddr[6];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_GET_REMOTE_DEVICE_PROP 0x07
+struct hal_msg_cmd_bt_get_remote_device_prop {
+ uint8_t bdaddr[6];
+ uint8_t type;
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_SET_REMOTE_DEVICE_PROP 0x08
+struct hal_msg_cmd_bt_set_remote_device_prop {
+ uint8_t bdaddr[6];
+ uint8_t type;
+ uint16_t len;
+ uint8_t val[0];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_GET_REMOTE_SERVICE_REC 0x09
+struct hal_msg_cmd_bt_get_remote_service_rec {
+ uint8_t bdaddr[6];
+ uint8_t uuid[16];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_GET_REMOTE_SERVICE 0x0a
+struct hal_msg_cmd_bt_get_remote_service {
+ uint8_t bdaddr[6];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_START_DISCOVERY 0x0b
+
+#define HAL_MSG_OP_BT_CANCEL_DISCOVERY 0x0c
+
+#define HAL_MSG_OP_BT_CREATE_BOND 0x0d
+struct hal_msg_cmd_bt_create_bond {
+ uint8_t bdaddr[6];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_REMOVE_BOND 0x0d
+struct hal_msg_cmd_bt_remove_bond {
+ uint8_t bdaddr[6];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_CANCEL_BOND 0x0f
+struct hal_msg_cmd_bt_cancel_bond {
+ uint8_t bdaddr[6];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_PIN_REPLY 0x10
+struct hal_msg_cmd_bt_pin_reply {
+ uint8_t bdaddr[6];
+ uint8_t accept;
+ uint8_t pin_len;
+ uint8_t pin_code[16];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_SSP_REPLY 0x11
+struct hal_msg_cmd_bt_ssp_reply {
+ uint8_t bdaddr[6];
+ uint8_t ssp_variant;
+ uint8_t accept;
+ uint32_t passkey;
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_DUT_MODE_CONF 0x12
+struct hal_msg_cmd_bt_dut_mode_conf {
+ uint8_t enable;
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_DUT_MODE_SEND 0x13
+struct hal_msg_cmd_bt_dut_mode_send {
+ uint16_t opcode;
+ uint8_t len;
+ uint8_t data[0];
+} __attribute__((packed));
+
+#define HAL_MSG_OP_BT_LE_TEST_MODE 0x14
+struct hal_msg_cmd_bt_le_test_mode {
+ uint16_t opcode;
+ uint8_t len;
+ uint8_t data[0];
+} __attribute__((packed));
+
+/* Notifications and confirmations */
+
+#define HAL_MSG_EV_BT_ERROR 0x80
+
+#define HAL_MSG_EV_BT_ADAPTER_STATE_CHANGED 0x81
+struct hal_msg_ev_bt_adapter_state_changed {
+ uint8_t state;
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_ADAPTER_PROPS_CHANGED 0x82
+struct hal_property {
+ uint8_t type;
+ uint16_t len;
+ uint8_t val[0];
+} __attribute__((packed));
+struct hal_msg_ev_bt_adapter_props_changed {
+ uint8_t status;
+ uint8_t num_props;
+ struct hal_property props[0];
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_REMOTE_DEVICE_PROPS 0x83
+struct hal_msg_ev_bt_remote_device_props {
+ uint8_t status;
+ uint8_t bdaddr[6];
+ uint8_t num_props;
+ struct hal_property props[0];
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_DEVICE_FOUND 0x84
+struct hal_msg_ev_bt_device_found {
+ uint8_t num_props;
+ struct hal_property props[0];
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_DISCOVERY_STATE_CHANGED 0x85
+struct hal_msg_ev_bt_discovery_state_changed {
+ uint8_t state;
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_PIN_REQUEST 0x86
+struct hal_msg_ev_bt_pin_request {
+ uint8_t bdaddr[6];
+ uint8_t name[249 - 1];
+ uint8_t class_of_dev[3];
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_SSP_REQUEST 0x87
+struct hal_msg_ev_bt_ssp_request {
+ uint8_t bdaddr[6];
+ uint8_t name[249 - 1];
+ uint8_t class_of_dev[3];
+ uint8_t pairing_variant;
+ uint32_t passkey;
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_BOND_STATE_CHANGED 0x88
+struct hal_msg_ev_bt_bond_state_changed {
+ uint8_t status;
+ uint8_t bdaddr[6];
+ uint8_t state;
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_ACL_STATE_CHANGED 0x89
+struct hal_msg_ev_bt_acl_state_changed {
+ uint8_t status;
+ uint8_t bdaddr[6];
+ uint8_t state;
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_DUT_MODE_RECEIVE 0x8a
+struct hal_msg_ev_bt_dut_mode_receive {
+ uint16_t opcode;
+ uint8_t len;
+ uint8_t data[0];
+} __attribute__((packed));
+
+#define HAL_MSG_EV_BT_LE_TEST_MODE 0x8b
+struct hal_msg_ev_bt_le_test_mode {
+ uint8_t status;
+ uint16_t num_packets;
+} __attribute__((packed));
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox