* [PATCH BlueZ 6/6] tools: Emit Seeked signal if Position changes
From: Luiz Augusto von Dentz @ 2013-01-21 15:21 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1358781718-386-1-git-send-email-luiz.dentz@gmail.com>
From: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
MPRIS spec says PropertiesChanged is not emitted for Position, which is
probably to make clear that progress is done using the rate, so instead
Seeked should be emitted.
---
tools/mpris-player.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
diff --git a/tools/mpris-player.c b/tools/mpris-player.c
index 448050d..b8de9a1 100644
--- a/tools/mpris-player.c
+++ b/tools/mpris-player.c
@@ -1646,6 +1646,8 @@ static void player_property_changed(GDBusProxy *proxy, const char *name,
{
struct player *player;
const char *property;
+ uint32_t position;
+ uint64_t value;
player = find_player(proxy);
if (player == NULL)
@@ -1658,6 +1660,18 @@ static void player_property_changed(GDBusProxy *proxy, const char *name,
g_dbus_emit_property_changed(player->conn, MPRIS_PLAYER_PATH,
MPRIS_PLAYER_INTERFACE,
property);
+
+ if (strcasecmp(name, "Position") != 0)
+ return;
+
+ dbus_message_iter_get_basic(iter, &position);
+
+ value = position * 1000;
+
+ g_dbus_emit_signal(player->conn, MPRIS_PLAYER_PATH,
+ MPRIS_PLAYER_INTERFACE, "Seeked",
+ DBUS_TYPE_INT64, &value,
+ DBUS_TYPE_INVALID);
}
static void transport_property_changed(GDBusProxy *proxy, const char *name,
--
1.8.0.2
^ permalink raw reply related
* Re: [PATCH] Check uuid in disconnect profile.
From: Luiz Augusto von Dentz @ 2013-01-21 16:07 UTC (permalink / raw)
To: Alexandros Antonopoulos; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358775868-9963-1-git-send-email-alexandros.antonopoulos@oss.bmw-carit.de>
Hi Alexandros,
On Mon, Jan 21, 2013 at 3:44 PM, Alexandros Antonopoulos
<alexandros.antonopoulos@oss.bmw-carit.de> wrote:
> If the user calls Device1.DisconnectProfile with an invalid profile
> uuid disconnect_profile still tries to parse the uuid resulting in
> a SIGSEGV
>
> ---
> src/device.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/device.c b/src/device.c
> index 3675616..1771c0f 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -1270,6 +1270,9 @@ static DBusMessage *disconnect_profile(DBusConnection *conn, DBusMessage *msg,
>
> uuid = bt_name2string(pattern);
>
> + if (uuid == NULL)
> + return btd_error_invalid_args(msg);
> +
> p = find_connectable_profile(dev, uuid);
> g_free(uuid);
>
> --
> 1.8.1
All four patches are now upstream, Ive changed the commit message for
this one to include the prefix and also please next time state it is a
fix and provide the backtrace so we know the severity of the problem.
btw, thanks for the patches.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [RFC] Bluetooth: Fix missing MITM protection when being responding LM
From: mail @ 2013-01-21 17:35 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Timo Mueller
From: Timo Mueller <timo.mueller@bmw-carit.de>
A MITM protected SSP associaton model can be used for pairing if both
local and remote IO capabilities are set to something other than
NoInputNoOutput.
With these IO capabilities a MITM protected SSP association model is
used if we are initiating the pairing process (initiating LM).
When responding to a pairing request - remote device is the initiating
LM - the pairing should also be proteced against MITM attacks.
Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
---
When we were testing the iPhone 5 we noticed that the association
model changes depending on which side initiates the pairing. For
example if we paired from the phone "Just Works" was used while if the
phone was the responding LM a "Numeric Comparison" was used instead.
We'd like to enforce MITM protection in our cars whenever possible.
That is why we want to set the MITM protection even when being the
responding LM. The patch proposes this policy as the default approach.
Expected SSP accociation model:
|-------------------------------------------|
| Device | SSP assocation model |
|===========================================|
| KeyboardDisplay | Numeric Comparison |
| ------------------------------------------|
| NoInputNoOutput | Just Works |
| ------------------------------------------|
| KeyboardOnly | Passkey Entry |
|-------------------------------------------|
Tested Devices:
KeyboardDisplay:
iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
BlueZ 5 - Simple Agent
NoInputNoOutput:
BlueZ 5 - Simple Agent
KeyboardOnly:
Logitech Keyboard Case, BlueZ 5 - Simple Agent
I've also tested this patch with the following kernels:
3.8-rc4
3.4
Best regards,
Timo
net/bluetooth/hci_conn.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 25bfce0..806583b 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->type = type;
conn->mode = HCI_CM_ACTIVE;
conn->state = BT_OPEN;
- conn->auth_type = HCI_AT_GENERAL_BONDING;
conn->io_capability = hdev->io_capability;
conn->remote_auth = 0xff;
conn->key_type = 0xff;
+ if (hdev->io_capability == 0x03)
+ conn->auth_type = HCI_AT_GENERAL_BONDING;
+ else
+ conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
+
set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
--
1.7.11.7
^ permalink raw reply related
* Re: [PATCH] monitor: Fix possible crash on unknown command
From: Marcel Holtmann @ 2013-01-21 19:39 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1358781467-32172-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
> If uknown command is received monitor would crash due to dereference
> of NULL opcode_data pointer.
> ---
> monitor/packet.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
good catch. Patch has been applied.
Regards
Marcel
^ permalink raw reply
* [PATCH] tools: Fix glib assert in mgmt-tester if hci_vhci module is not loaded
From: Szymon Janc @ 2013-01-21 20:25 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
Print descriptive warning on HCI emulation setup failure and fail test
gracefully. This is better comparing to glib assertion when not fully
initialized HCI emulation is being unreferenced.
---
src/shared/hciemu.c | 31 ++++++++++++++++++++++---------
tools/mgmt-tester.c | 4 ++++
2 files changed, 26 insertions(+), 9 deletions(-)
diff --git a/src/shared/hciemu.c b/src/shared/hciemu.c
index d523743..a15102d 100644
--- a/src/shared/hciemu.c
+++ b/src/shared/hciemu.c
@@ -188,7 +188,7 @@ static guint create_source_btdev(int fd, struct btdev *btdev)
return source;
}
-static void create_vhci(struct hciemu *hciemu)
+static bool create_vhci(struct hciemu *hciemu)
{
struct btdev *btdev;
uint8_t bdaddr[6];
@@ -197,7 +197,7 @@ static void create_vhci(struct hciemu *hciemu)
btdev = btdev_create(BTDEV_TYPE_BREDR, 0x00);
if (!btdev)
- return;
+ return false;
str = hciemu_get_address(hciemu);
@@ -210,15 +210,17 @@ static void create_vhci(struct hciemu *hciemu)
fd = open("/dev/vhci", O_RDWR | O_NONBLOCK | O_CLOEXEC);
if (fd < 0) {
btdev_destroy(btdev);
- return;
+ return false;
}
hciemu->master_dev = btdev;
hciemu->master_source = create_source_btdev(fd, btdev);
+
+ return true;
}
-static void create_stack(struct hciemu *hciemu)
+static bool create_stack(struct hciemu *hciemu)
{
struct btdev *btdev;
struct bthost *bthost;
@@ -226,12 +228,12 @@ static void create_stack(struct hciemu *hciemu)
btdev = btdev_create(BTDEV_TYPE_BREDR, 0x00);
if (!btdev)
- return;
+ return false;
bthost = bthost_create();
if (!bthost) {
btdev_destroy(btdev);
- return;
+ return false;
}
btdev_set_command_handler(btdev, client_command_callback, hciemu);
@@ -240,7 +242,7 @@ static void create_stack(struct hciemu *hciemu)
0, sv) < 0) {
bthost_destroy(bthost);
btdev_destroy(btdev);
- return;
+ return false;
}
hciemu->client_dev = btdev;
@@ -248,6 +250,8 @@ static void create_stack(struct hciemu *hciemu)
hciemu->client_source = create_source_btdev(sv[0], btdev);
hciemu->host_source = create_source_bthost(sv[1], bthost);
+
+ return true;
}
static gboolean start_stack(gpointer user_data)
@@ -267,8 +271,17 @@ struct hciemu *hciemu_new(void)
if (!hciemu)
return NULL;
- create_vhci(hciemu);
- create_stack(hciemu);
+ if (!create_vhci(hciemu)) {
+ g_free(hciemu);
+ return NULL;
+ }
+
+ if (!create_stack(hciemu)) {
+ g_source_remove(hciemu->master_source);
+ btdev_destroy(hciemu->master_dev);
+ g_free(hciemu);
+ return NULL;
+ }
g_idle_add(start_stack, hciemu);
diff --git a/tools/mgmt-tester.c b/tools/mgmt-tester.c
index bf61f9d..63e7714 100644
--- a/tools/mgmt-tester.c
+++ b/tools/mgmt-tester.c
@@ -217,6 +217,10 @@ static void read_index_list_callback(uint8_t status, uint16_t length,
index_removed_callback, NULL, NULL);
data->hciemu = hciemu_new();
+ if (!data->hciemu) {
+ tester_warn("Failed to setup HCI emulation");
+ tester_pre_setup_failed();
+ }
}
static void test_pre_setup(const void *test_data)
--
1.8.1
^ permalink raw reply related
* Simultaneous data transfer on ACL and BLE links
From: Ajay @ 2013-01-21 21:04 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
Hi ,
Kernel has set some restrictions in simultaneous L2cap data
transfer on BLE and ACL links on a common device .
My test scenario is as follows
Device A has both LE and ACL link with device B and C
respectively . when i start sending l2cap data on ACL link (A to B),
it work fine . But when i starts sending BLE data along with ACL data
(A to C ) , it fails with error "send failed : interrupt system call"
. when i count the LE packets that had reached upto hci layer , it
shows some 367 packets.
Later i noticed that LE data is getting queued at hci
layer and it is not scheduled properly . following piece of code
tells us the order of scheduling.. (hci_core.c)
static void hci_tx_task(unsigned long arg)
{
struct hci_dev *hdev = (struct hci_dev *) arg;
struct sk_buff *skb;
read_lock(&hci_task_lock);
BT_DBG("%s acl %d sco %d le %d", hdev->name, hdev->acl_cnt,
hdev->sco_cnt, hdev->le_cnt);
/* Schedule queues and send stuff to HCI driver */
hci_sched_acl(hdev);
hci_sched_sco(hdev);
hci_sched_esco(hdev);
hci_sched_le(hdev);
......
Here both acl and le scheduling are using same count as
reference (hdev->acl_cnt) and they have never make use of hdev->le_cnt.
please kindly go through this issue.
--
Thanks & Regards
AJAY KV
GlobalEdge software Ltd
8892753703
[-- Attachment #2: ajay_kv.vcf --]
[-- Type: text/x-vcard, Size: 74 bytes --]
begin:vcard
fn:AJAY KV
n:;AJAY
tel;cell:8892753703
version:2.1
end:vcard
^ permalink raw reply
* Re: [RFC] Bluetooth: Fix missing MITM protection when being responding LM
From: Johan Hedberg @ 2013-01-22 8:13 UTC (permalink / raw)
To: mail; +Cc: linux-bluetooth, Timo Mueller
In-Reply-To: <1358789748-318-1-git-send-email-mail@timomueller.eu>
Hi Timo,
On Mon, Jan 21, 2013, mail@timomueller.eu wrote:
> A MITM protected SSP associaton model can be used for pairing if both
> local and remote IO capabilities are set to something other than
> NoInputNoOutput.
>
> With these IO capabilities a MITM protected SSP association model is
> used if we are initiating the pairing process (initiating LM).
>
> When responding to a pairing request - remote device is the initiating
> LM - the pairing should also be proteced against MITM attacks.
>
> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
> ---
> When we were testing the iPhone 5 we noticed that the association
> model changes depending on which side initiates the pairing. For
> example if we paired from the phone "Just Works" was used while if the
> phone was the responding LM a "Numeric Comparison" was used instead.
>
> We'd like to enforce MITM protection in our cars whenever possible.
> That is why we want to set the MITM protection even when being the
> responding LM. The patch proposes this policy as the default approach.
>
> Expected SSP accociation model:
> |-------------------------------------------|
> | Device | SSP assocation model |
> |===========================================|
> | KeyboardDisplay | Numeric Comparison |
> | ------------------------------------------|
> | NoInputNoOutput | Just Works |
> | ------------------------------------------|
> | KeyboardOnly | Passkey Entry |
> |-------------------------------------------|
>
> Tested Devices:
> KeyboardDisplay:
> iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
> Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
> BlueZ 5 - Simple Agent
>
> NoInputNoOutput:
> BlueZ 5 - Simple Agent
>
> KeyboardOnly:
> Logitech Keyboard Case, BlueZ 5 - Simple Agent
>
> I've also tested this patch with the following kernels:
> 3.8-rc4
> 3.4
>
> Best regards,
> Timo
>
> net/bluetooth/hci_conn.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> index 25bfce0..806583b 100644
> --- a/net/bluetooth/hci_conn.c
> +++ b/net/bluetooth/hci_conn.c
> @@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
> conn->type = type;
> conn->mode = HCI_CM_ACTIVE;
> conn->state = BT_OPEN;
> - conn->auth_type = HCI_AT_GENERAL_BONDING;
> conn->io_capability = hdev->io_capability;
> conn->remote_auth = 0xff;
> conn->key_type = 0xff;
>
> + if (hdev->io_capability == 0x03)
> + conn->auth_type = HCI_AT_GENERAL_BONDING;
> + else
> + conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
> +
> set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
> conn->disc_timeout = HCI_DISCONN_TIMEOUT;
The question that could equally be asked is why does iOS *not* set the
MITM flag when initiating pairing to a remote device. If it did this
issue would not exist.
Since the over all sequence of the IO capability negotiation with iOS devices
when we're on the acceptor side might be a bit unclear to people by just
reading your commit message and patch I'll provide here a HCI trace of it:
> HCI Event: IO Capability Response (0x32) plen 9
Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
IO capability: DisplayYesNo (0x01)
OOB data: Authentication data not present (0x00)
Authentication: General Bonding - MITM not required (0x04)
> HCI Event: IO Capability Request (0x31) plen 6
Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
< HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
IO capability: DisplayYesNo (0x01)
OOB data: Authentication data not present (0x00)
Authentication: General Bonding - MITM not required (0x04)
Basically the BlueZ side has so far given the remote initiator the
choice whether to do just-works or not. However, I do agree that it's
good to strive for a best-possible security in the pairing (within the
limits of the available IO capabilities) so setting the MITM flag on our
side should be fine.
The one thing that I'd still consider improving is to make the setting
of the MITM flag also dependent on the remote IO capability and not just
the local one, since we do know the remote one before we need to give
our own value when we are on the acceptor side of the pairing. Thoughts?
Johan
^ permalink raw reply
* RE: [RFC] Bluetooth: Fix missing MITM protection when being responding LM
From: Oleksandr.Domin @ 2013-01-22 8:53 UTC (permalink / raw)
To: johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <20130122081320.GA27138@x220>
Hi Johan,
>Hi Timo,
>
>On Mon, Jan 21, 2013, mail@timomueller.eu wrote:
>> A MITM protected SSP associaton model can be used for pairing if both
>> local and remote IO capabilities are set to something other than
>> NoInputNoOutput.
>>
>> With these IO capabilities a MITM protected SSP association model is
>> used if we are initiating the pairing process (initiating LM).
>>
>> When responding to a pairing request - remote device is the initiating
>> LM - the pairing should also be proteced against MITM attacks.
>>
>> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
>> ---
>> When we were testing the iPhone 5 we noticed that the association
>> model changes depending on which side initiates the pairing. For
>> example if we paired from the phone "Just Works" was used while if the
>> phone was the responding LM a "Numeric Comparison" was used instead.
>>
>> We'd like to enforce MITM protection in our cars whenever possible.
>> That is why we want to set the MITM protection even when being the
>> responding LM. The patch proposes this policy as the default approach.
>>
>> Expected SSP accociation model:
>> |-------------------------------------------|
>> | Device | SSP assocation model |
>> |===========================================|
>> | KeyboardDisplay | Numeric Comparison |
>> | ------------------------------------------|
>> | NoInputNoOutput | Just Works |
>> | ------------------------------------------|
>> | KeyboardOnly | Passkey Entry |
>> |-------------------------------------------|
>>
>> Tested Devices:
>> KeyboardDisplay:
>> iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
>> Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
>> BlueZ 5 - Simple Agent
>>
>> NoInputNoOutput:
>> BlueZ 5 - Simple Agent
>>
>> KeyboardOnly:
>> Logitech Keyboard Case, BlueZ 5 - Simple Agent
>>
>> I've also tested this patch with the following kernels:
>> 3.8-rc4
>> 3.4
>>
>> Best regards,
>> Timo
>>
>> net/bluetooth/hci_conn.c | 6 +++++-
>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>> index 25bfce0..806583b 100644
>> --- a/net/bluetooth/hci_conn.c
>> +++ b/net/bluetooth/hci_conn.c
>> @@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev,
>int type, bdaddr_t *dst)
>> conn->type = type;
>> conn->mode = HCI_CM_ACTIVE;
>> conn->state = BT_OPEN;
>> - conn->auth_type = HCI_AT_GENERAL_BONDING;
>> conn->io_capability = hdev->io_capability;
>> conn->remote_auth = 0xff;
>> conn->key_type = 0xff;
>>
>> + if (hdev->io_capability == 0x03)
>> + conn->auth_type = HCI_AT_GENERAL_BONDING;
>> + else
>> + conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
>> +
>> set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
>> conn->disc_timeout = HCI_DISCONN_TIMEOUT;
>
>The question that could equally be asked is why does iOS *not* set the
>MITM flag when initiating pairing to a remote device. If it did this
>issue would not exist.
Welcome in the IOP WORLD :-D
>
>Since the over all sequence of the IO capability negotiation with iOS
>devices
>when we're on the acceptor side might be a bit unclear to people by just
>reading your commit message and patch I'll provide here a HCI trace of it:
>
> > HCI Event: IO Capability Response (0x32) plen 9
> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
> IO capability: DisplayYesNo (0x01)
> OOB data: Authentication data not present (0x00)
> Authentication: General Bonding - MITM not required (0x04)
> > HCI Event: IO Capability Request (0x31) plen 6
> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
> IO capability: DisplayYesNo (0x01)
> OOB data: Authentication data not present (0x00)
> Authentication: General Bonding - MITM not required (0x04)
>
>Basically the BlueZ side has so far given the remote initiator the
>choice whether to do just-works or not. However, I do agree that it's
>good to strive for a best-possible security in the pairing (within the
>limits of the available IO capabilities) so setting the MITM flag on our
>side should be fine.
>
>The one thing that I'd still consider improving is to make the setting
>of the MITM flag also dependent on the remote IO capability and not just
>the local one, since we do know the remote one before we need to give
>our own value when we are on the acceptor side of the pairing. Thoughts?
>
>Johan
>--
>To unsubscribe from this list: send the line "unsubscribe linux-bluetooth"
>in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] avctp: Add functionality for CT browsing commands
From: Alexandros Antonopoulos @ 2013-01-22 10:32 UTC (permalink / raw)
To: linux-bluetooth
Add the missing functionality for full support of browsing channel
on the CT side. This is required for AVRCP >= 1.4
The patch is based on the control channel functionality
---
profiles/audio/avctp.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++
profiles/audio/avctp.h | 6 +++
2 files changed, 146 insertions(+)
diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
index e65594d..02bee2b 100644
--- a/profiles/audio/avctp.c
+++ b/profiles/audio/avctp.c
@@ -136,6 +136,14 @@ struct avctp_control_req {
void *user_data;
};
+struct avctp_browsing_req {
+ struct avctp_pending_req *p;
+ uint8_t *operands;
+ uint16_t operand_count;
+ avctp_browsing_rsp_cb func;
+ void *user_data;
+};
+
typedef int (*avctp_process_cb) (void *data);
struct avctp_pending_req {
@@ -527,6 +535,44 @@ static int avctp_send(struct avctp_channel *control, uint8_t transaction,
return err;
}
+static int avctp_browsing_send(struct avctp_channel *browsing,
+ uint8_t transaction, uint8_t cr,
+ uint8_t *operands, size_t operand_count)
+{
+ struct avctp_header *avctp;
+ struct msghdr msg;
+ struct iovec iov[2];
+ int sk, err = 0;
+
+ iov[0].iov_base = browsing->buffer;
+ iov[0].iov_len = sizeof(*avctp);
+ iov[1].iov_base = operands;
+ iov[1].iov_len = operand_count;
+
+ if (browsing->omtu < (iov[0].iov_len + iov[1].iov_len))
+ return -EOVERFLOW;
+
+ sk = g_io_channel_unix_get_fd(browsing->io);
+
+ memset(browsing->buffer, 0, iov[0].iov_len);
+
+ avctp = (void *) browsing->buffer;
+
+ avctp->transaction = transaction;
+ avctp->packet_type = AVCTP_PACKET_SINGLE;
+ avctp->cr = cr;
+ avctp->pid = htons(AV_REMOTE_SVCLASS_ID);
+
+ memset(&msg, 0, sizeof(msg));
+ msg.msg_iov = iov;
+ msg.msg_iovlen = 2;
+
+ if (sendmsg(sk, &msg, 0) < 0)
+ err = -errno;
+
+ return err;
+}
+
static void control_req_destroy(void *data)
{
struct avctp_control_req *req = data;
@@ -535,6 +581,14 @@ static void control_req_destroy(void *data)
g_free(req);
}
+static void browsing_req_destroy(void *data)
+{
+ struct avctp_browsing_req *req = data;
+
+ g_free(req->operands);
+ g_free(req);
+}
+
static gboolean req_timeout(gpointer user_data)
{
struct avctp_channel *chan = user_data;
@@ -563,6 +617,15 @@ static int process_control(void *data)
req->operands, req->operand_count);
}
+static int process_browsing(void *data)
+{
+ struct avctp_browsing_req *req = data;
+ struct avctp_pending_req *p = req->p;
+
+ return avctp_browsing_send(p->chan, p->transaction, AVCTP_COMMAND,
+ req->operands, req->operand_count);
+}
+
static gboolean process_queue(void *user_data)
{
struct avctp_channel *chan = user_data;
@@ -636,6 +699,48 @@ static void control_response(struct avctp_channel *control,
}
}
+static void browsing_response(struct avctp_channel *browsing,
+ struct avctp_header *avctp,
+ uint8_t *operands,
+ size_t operand_count)
+{
+ struct avctp_pending_req *p = browsing->p;
+ struct avctp_browsing_req *req;
+ GSList *l;
+
+ if (p && p->transaction == avctp->transaction) {
+ browsing->processed = g_slist_prepend(browsing->processed, p);
+
+ if (p->timeout > 0) {
+ g_source_remove(p->timeout);
+ p->timeout = 0;
+ }
+
+ browsing->p = NULL;
+
+ if (browsing->process_id == 0)
+ browsing->process_id = g_idle_add(process_queue,
+ browsing);
+ }
+
+ for (l = browsing->processed; l; l = l->next) {
+ p = l->data;
+ req = p->data;
+
+ if (p->transaction != avctp->transaction)
+ continue;
+
+ if (req->func && req->func(browsing->session,
+ operands, operand_count,
+ req->user_data))
+ return;
+
+ browsing->processed = g_slist_remove(browsing->processed, p);
+
+ return;
+ }
+}
+
static gboolean session_browsing_cb(GIOChannel *chan, GIOCondition cond,
gpointer data)
{
@@ -665,6 +770,11 @@ static gboolean session_browsing_cb(GIOChannel *chan, GIOCondition cond,
ret -= AVCTP_HEADER_LENGTH;
operand_count = ret;
+ if (avctp->cr == AVCTP_RESPONSE) {
+ browsing_response(browsing, avctp, operands, operand_count);
+ return TRUE;
+ }
+
packet_size = AVCTP_HEADER_LENGTH;
avctp->cr = AVCTP_RESPONSE;
@@ -1294,6 +1404,36 @@ static int avctp_send_req(struct avctp *session, uint8_t code,
return 0;
}
+int avctp_send_browsing_req(struct avctp *session,
+ uint8_t *operands, size_t operand_count,
+ avctp_browsing_rsp_cb func, void *user_data)
+{
+ struct avctp_channel *browsing = session->browsing;
+ struct avctp_pending_req *p;
+ struct avctp_browsing_req *req;
+
+ if (browsing == NULL)
+ return -ENOTCONN;
+
+ req = g_new0(struct avctp_browsing_req, 1);
+ req->func = func;
+ req->operands = g_memdup(operands, operand_count);
+ req->operand_count = operand_count;
+ req->user_data = user_data;
+
+ p = pending_create(browsing, process_browsing, req,
+ browsing_req_destroy);
+
+ req->p = p;
+
+ g_queue_push_tail(browsing->queue, p);
+
+ if (browsing->process_id == 0)
+ browsing->process_id = g_idle_add(process_queue, browsing);
+
+ return 0;
+}
+
static char *op2str(uint8_t op)
{
switch (op & 0x7f) {
diff --git a/profiles/audio/avctp.h b/profiles/audio/avctp.h
index c25a3b3..b9107bd 100644
--- a/profiles/audio/avctp.h
+++ b/profiles/audio/avctp.h
@@ -82,6 +82,9 @@ typedef size_t (*avctp_control_pdu_cb) (struct avctp *session,
typedef gboolean (*avctp_rsp_cb) (struct avctp *session, uint8_t code,
uint8_t subunit, uint8_t *operands,
size_t operand_count, void *user_data);
+typedef gboolean (*avctp_browsing_rsp_cb) (struct avctp *session,
+ uint8_t *operands, size_t operand_count,
+ void *user_data);
typedef size_t (*avctp_browsing_pdu_cb) (struct avctp *session,
uint8_t transaction,
uint8_t *operands, size_t operand_count,
@@ -116,3 +119,6 @@ int avctp_send_vendordep_req(struct avctp *session, uint8_t code,
uint8_t subunit, uint8_t *operands,
size_t operand_count,
avctp_rsp_cb func, void *user_data);
+int avctp_send_browsing_req(struct avctp *session,
+ uint8_t *operands, size_t operand_count,
+ avctp_browsing_rsp_cb func, void *user_data);
--
1.8.1
^ permalink raw reply related
* [RFC 0/1] avctp: Set browsing channel connection for ct
From: Alexandros Antonopoulos @ 2013-01-22 10:34 UTC (permalink / raw)
To: linux-bluetooth
A few comments:
Handling channel creation for AVRCP:
For AVRCP >= 1.4 the browsing channel can be connected after the
control channel is connected successfully.
It's not clear for me what bluez should do in case the browsing
channel connection fails. There is nothing stopping bluez for still
providing avrcp 1.3 functionality over the control channel.
If the choice is to allow the use of the control channel even if the
browsing one fails then bluez needs the logic in
avrcp.c:state_changed(). If not then both channels must be destroyed
and the session must not be initialized.
State AVCTP_STATE_CONNECTED in state_changed has also to differentiate
between AVRCP <= 1.3 and AVRCP >= 1.4. In AVRCP <= 1.3 after the
control channel is created the avrcp session can be initialized.
In AVRCP >= 1.4 we need first to try and connect the browsing channel.
The session can be created if:
- The state is AVCTP_STATE_BROWSING_CONNECTED (if the browsing channel
was connected successfully),
- The state is AVCTP_STATE_CONNECTED and old_state is
AVCTP_STATE_BROWSING_CONNECTING (if the browsing channel connection
failed),
- The state is AVCTP_STATE_CONNECTED but avctp_connect_browsing fails.
Handling the feature mask:
Since bluez will support AVRCP 1.5 is the AVRCP_FEATURE_BROWSING
actually required? It was checked on the target side during the session
init.
Alexandros Antonopoulos (1):
avctp: Set browsing channel connection for ct
profiles/audio/avctp.c | 11 +++++++++++
profiles/audio/avctp.h | 4 +++-
profiles/audio/avrcp.c | 28 +++++++++++++++++++++++-----
profiles/audio/device.c | 4 ++++
4 files changed, 41 insertions(+), 6 deletions(-)
--
1.8.1
^ permalink raw reply
* [RFC 1/1] avctp: Set browsing channel connection for ct
From: Alexandros Antonopoulos @ 2013-01-22 10:34 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1358850844-19752-1-git-send-email-alexandros.antonopoulos@oss.bmw-carit.de>
Add two extra states for the browsing channel and handle the connection
sequence in avrcp.c
---
profiles/audio/avctp.c | 11 +++++++++++
profiles/audio/avctp.h | 4 +++-
profiles/audio/avrcp.c | 28 +++++++++++++++++++++++-----
profiles/audio/device.c | 4 ++++
4 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
index e65594d..753f8fe 100644
--- a/profiles/audio/avctp.c
+++ b/profiles/audio/avctp.c
@@ -476,6 +476,12 @@ static void avctp_set_state(struct avctp *session, avctp_state_t new_state)
case AVCTP_STATE_CONNECTED:
DBG("AVCTP Connected");
break;
+ case AVCTP_STATE_BROWSING_CONNECTING:
+ DBG("AVCTP Browsing Connecting");
+ break;
+ case AVCTP_STATE_BROWSING_CONNECTED:
+ DBG("AVCTP Browsing Connected");
+ break;
default:
error("Invalid AVCTP state %d", new_state);
return;
@@ -913,9 +919,12 @@ static void avctp_connect_browsing_cb(GIOChannel *chan, GError *err,
G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
(GIOFunc) session_browsing_cb, session);
+ avctp_set_state(session, AVCTP_STATE_BROWSING_CONNECTED);
return;
fail:
+ avctp_set_state(session, AVCTP_STATE_CONNECTED);
+
if (session->browsing) {
avctp_channel_destroy(session->browsing);
session->browsing = NULL;
@@ -1648,6 +1657,8 @@ int avctp_connect_browsing(struct avctp *session)
if (session->browsing != NULL)
return 0;
+ avctp_set_state(session, AVCTP_STATE_BROWSING_CONNECTING);
+
io = bt_io_connect(avctp_connect_browsing_cb, session, NULL, &err,
BT_IO_OPT_SOURCE_BDADDR,
adapter_get_address(session->server->adapter),
diff --git a/profiles/audio/avctp.h b/profiles/audio/avctp.h
index c25a3b3..d1fe693 100644
--- a/profiles/audio/avctp.h
+++ b/profiles/audio/avctp.h
@@ -67,7 +67,9 @@ struct avctp;
typedef enum {
AVCTP_STATE_DISCONNECTED = 0,
AVCTP_STATE_CONNECTING,
- AVCTP_STATE_CONNECTED
+ AVCTP_STATE_CONNECTED,
+ AVCTP_STATE_BROWSING_CONNECTING,
+ AVCTP_STATE_BROWSING_CONNECTED
} avctp_state_t;
typedef void (*avctp_state_cb) (struct audio_device *dev,
diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
index 636d3e4..6cab45f 100644
--- a/profiles/audio/avrcp.c
+++ b/profiles/audio/avrcp.c
@@ -2182,12 +2182,9 @@ static void session_tg_init(struct avrcp *session)
(1 << AVRCP_EVENT_TRACK_REACHED_END) |
(1 << AVRCP_EVENT_SETTINGS_CHANGED);
- if (session->version >= 0x0104) {
+ if (session->version >= 0x0104)
avrcp_register_notification(session,
AVRCP_EVENT_VOLUME_CHANGED);
- if (session->features & AVRCP_FEATURE_BROWSING)
- avctp_connect_browsing(session->conn);
- }
session->control_id = avctp_register_pdu_handler(session->conn,
AVC_OP_VENDORDEP,
@@ -2341,6 +2338,7 @@ static void state_changed(struct audio_device *dev, avctp_state_t old_state,
{
struct avrcp_server *server;
struct avrcp *session;
+ uint8_t browsing_failed = false;
server = find_server(servers, device_get_adapter(dev->btd_dev));
if (!server)
@@ -2367,8 +2365,28 @@ static void state_changed(struct audio_device *dev, avctp_state_t old_state,
if (session == NULL)
break;
- session->init(session);
+ if (session->version <= 0x0103) {
+ session->init(session);
+ break;
+ }
+
+ /*AVCRP >= 1.4*/
+ if (old_state == AVCTP_STATE_CONNECTING) {
+ if (avctp_connect_browsing(session->conn) != 0)
+ browsing_failed = true;
+ } else if (old_state == AVCTP_STATE_BROWSING_CONNECTING) {
+ browsing_failed = true;
+ }
+ if (browsing_failed)
+ session->init(session);
+ break;
+ case AVCTP_STATE_BROWSING_CONNECTED:
+ if (session == NULL)
+ break;
+
+ session->init(session);
+ break;
default:
return;
}
diff --git a/profiles/audio/device.c b/profiles/audio/device.c
index d4ba6d2..2aa22bb 100644
--- a/profiles/audio/device.c
+++ b/profiles/audio/device.c
@@ -289,6 +289,10 @@ static void device_avctp_cb(struct audio_device *dev,
break;
case AVCTP_STATE_CONNECTED:
break;
+ case AVCTP_STATE_BROWSING_CONNECTING:
+ break;
+ case AVCTP_STATE_BROWSING_CONNECTED:
+ break;
}
}
--
1.8.1
^ permalink raw reply related
* Re: [RFC] Bluetooth: Fix missing MITM protection when being responding LM
From: Marcel Holtmann @ 2013-01-22 10:36 UTC (permalink / raw)
To: Johan Hedberg; +Cc: mail, linux-bluetooth, Timo Mueller
In-Reply-To: <20130122081320.GA27138@x220>
Hi Johan,
> > A MITM protected SSP associaton model can be used for pairing if both
> > local and remote IO capabilities are set to something other than
> > NoInputNoOutput.
> >
> > With these IO capabilities a MITM protected SSP association model is
> > used if we are initiating the pairing process (initiating LM).
> >
> > When responding to a pairing request - remote device is the initiating
> > LM - the pairing should also be proteced against MITM attacks.
> >
> > Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
> > ---
> > When we were testing the iPhone 5 we noticed that the association
> > model changes depending on which side initiates the pairing. For
> > example if we paired from the phone "Just Works" was used while if the
> > phone was the responding LM a "Numeric Comparison" was used instead.
> >
> > We'd like to enforce MITM protection in our cars whenever possible.
> > That is why we want to set the MITM protection even when being the
> > responding LM. The patch proposes this policy as the default approach.
> >
> > Expected SSP accociation model:
> > |-------------------------------------------|
> > | Device | SSP assocation model |
> > |===========================================|
> > | KeyboardDisplay | Numeric Comparison |
> > | ------------------------------------------|
> > | NoInputNoOutput | Just Works |
> > | ------------------------------------------|
> > | KeyboardOnly | Passkey Entry |
> > |-------------------------------------------|
> >
> > Tested Devices:
> > KeyboardDisplay:
> > iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
> > Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
> > BlueZ 5 - Simple Agent
> >
> > NoInputNoOutput:
> > BlueZ 5 - Simple Agent
> >
> > KeyboardOnly:
> > Logitech Keyboard Case, BlueZ 5 - Simple Agent
> >
> > I've also tested this patch with the following kernels:
> > 3.8-rc4
> > 3.4
> >
> > Best regards,
> > Timo
> >
> > net/bluetooth/hci_conn.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
> > index 25bfce0..806583b 100644
> > --- a/net/bluetooth/hci_conn.c
> > +++ b/net/bluetooth/hci_conn.c
> > @@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
> > conn->type = type;
> > conn->mode = HCI_CM_ACTIVE;
> > conn->state = BT_OPEN;
> > - conn->auth_type = HCI_AT_GENERAL_BONDING;
> > conn->io_capability = hdev->io_capability;
> > conn->remote_auth = 0xff;
> > conn->key_type = 0xff;
> >
> > + if (hdev->io_capability == 0x03)
> > + conn->auth_type = HCI_AT_GENERAL_BONDING;
> > + else
> > + conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
> > +
> > set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
> > conn->disc_timeout = HCI_DISCONN_TIMEOUT;
>
> The question that could equally be asked is why does iOS *not* set the
> MITM flag when initiating pairing to a remote device. If it did this
> issue would not exist.
because iOS does not support SIM Access Profile. Outside of SIM Access,
there is really no need to support high security.
The difference between medium security and high security is really only
the man-in-the-middle protection. From an encryption and link key
strength point of view they are identical. Both link keys are P-192
derived and the encryption cipher is still E0.
> Since the over all sequence of the IO capability negotiation with iOS devices
> when we're on the acceptor side might be a bit unclear to people by just
> reading your commit message and patch I'll provide here a HCI trace of it:
>
> > HCI Event: IO Capability Response (0x32) plen 9
> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
> IO capability: DisplayYesNo (0x01)
> OOB data: Authentication data not present (0x00)
> Authentication: General Bonding - MITM not required (0x04)
> > HCI Event: IO Capability Request (0x31) plen 6
> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
> IO capability: DisplayYesNo (0x01)
> OOB data: Authentication data not present (0x00)
> Authentication: General Bonding - MITM not required (0x04)
>
> Basically the BlueZ side has so far given the remote initiator the
> choice whether to do just-works or not. However, I do agree that it's
> good to strive for a best-possible security in the pairing (within the
> limits of the available IO capabilities) so setting the MITM flag on our
> side should be fine.
This is still something we need to think about carefully. I am not sure
we should just always be doing this. This might actually be better
solved with a sysfs option or a mgmt command to pick different behavior.
Since this is General Bonding and not Dedicated Bonding, I am not
convinced that this is a good idea.
> The one thing that I'd still consider improving is to make the setting
> of the MITM flag also dependent on the remote IO capability and not just
> the local one, since we do know the remote one before we need to give
> our own value when we are on the acceptor side of the pairing. Thoughts?
This is a minimum requirement that we check the remote IO capabilities
here. Since there is no point in trying MITM protection if the other
side has no capabilities to ever create such a key.
I would be also curious if we still can qualify our own behavior and not
end up with cases where we can't because we have no way to trigger it.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 00/10 v2] Bluetooth: Fix more mgmt parameter checks
From: Marcel Holtmann @ 2013-01-22 10:45 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358684842-4441-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> Here's an updated patch set based on feedback from Marcel for the first
> one.
>
> This one still needs my patch (acked by Marcel)
>
> "Bluetooth: Fix Class of Device indication when powering off"
>
> and Szymons patch (acked by me)
>
> "Bluetooth: Fix pair device command reply if adapter is powered off"
>
> to be applied first to bluetooth-next.git. At least I've got those two
> in my local tree before this set, so no guarantees that there wont be
> conflicts if they are not applied first.
they all look good to me.
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* [PATCH 1/3] Bluetooth: Add LE Local Features reading support
From: Johan Hedberg @ 2013-01-22 12:01 UTC (permalink / raw)
To: linux-bluetooth
From: Johan Hedberg <johan.hedberg@intel.com>
To be able to make the appropriate decisions for some LE procedures we
need to know the LE features that the local controller supports.
Therefore, it's important to have the LE Read Local Supported Features
HCI comand as part of the HCI init sequence.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci.h | 6 ++++++
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
3 files changed, 27 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 45eee08..521eefa 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -943,6 +943,12 @@ struct hci_rp_le_read_buffer_size {
__u8 le_max_pkt;
} __packed;
+#define HCI_OP_LE_READ_LOCAL_FEATURES 0x2003
+struct hci_rp_le_read_local_features {
+ __u8 status;
+ __u8 features[8];
+} __packed;
+
#define HCI_OP_LE_READ_ADV_TX_POWER 0x2007
struct hci_rp_le_read_adv_tx_power {
__u8 status;
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 769a740..3f607c9 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -152,6 +152,7 @@ struct hci_dev {
__u8 minor_class;
__u8 features[8];
__u8 host_features[8];
+ __u8 le_features[8];
__u8 commands[64];
__u8 hci_ver;
__u16 hci_rev;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 705078a..07c8c79 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -609,6 +609,9 @@ static void le_setup(struct hci_dev *hdev)
/* Read LE Buffer Size */
hci_send_cmd(hdev, HCI_OP_LE_READ_BUFFER_SIZE, 0, NULL);
+ /* Read LE Local Supported Features */
+ hci_send_cmd(hdev, HCI_OP_LE_READ_LOCAL_FEATURES, 0, NULL);
+
/* Read LE Advertising Channel TX Power */
hci_send_cmd(hdev, HCI_OP_LE_READ_ADV_TX_POWER, 0, NULL);
}
@@ -1090,6 +1093,19 @@ static void hci_cc_le_read_buffer_size(struct hci_dev *hdev,
hci_req_complete(hdev, HCI_OP_LE_READ_BUFFER_SIZE, rp->status);
}
+static void hci_cc_le_read_local_features(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_local_features *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, rp->status);
+
+ if (!rp->status)
+ memcpy(hdev->le_features, rp->features, 8);
+
+ hci_req_complete(hdev, HCI_OP_LE_READ_LOCAL_FEATURES, rp->status);
+}
+
static void hci_cc_le_read_adv_tx_power(struct hci_dev *hdev,
struct sk_buff *skb)
{
@@ -2628,6 +2644,10 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_le_read_buffer_size(hdev, skb);
break;
+ case HCI_OP_LE_READ_LOCAL_FEATURES:
+ hci_cc_le_read_local_features(hdev, skb);
+ break;
+
case HCI_OP_LE_READ_ADV_TX_POWER:
hci_cc_le_read_adv_tx_power(hdev, skb);
break;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 2/3] Bluetooth: Add support for reading LE White List Size
From: Johan Hedberg @ 2013-01-22 12:02 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1358856121-1928-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
The LE White List Size is necessary to be known before attempting to
feed the controller with any addresses intended for the white list. This
patch adds the necessary HCI command sending to the HCI init sequence.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci.h | 6 ++++++
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
3 files changed, 27 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 521eefa..f1766a6 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1001,6 +1001,12 @@ struct hci_cp_le_create_conn {
#define HCI_OP_LE_CREATE_CONN_CANCEL 0x200e
+#define HCI_OP_LE_READ_WHITE_LIST_SIZE 0x200f
+struct hci_rp_le_read_white_list_size {
+ __u8 status;
+ __u8 size;
+} __packed;
+
#define HCI_OP_LE_CONN_UPDATE 0x2013
struct hci_cp_le_conn_update {
__le16 handle;
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 3f607c9..d6ed4ac 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -153,6 +153,7 @@ struct hci_dev {
__u8 features[8];
__u8 host_features[8];
__u8 le_features[8];
+ __u8 le_white_list_size;
__u8 commands[64];
__u8 hci_ver;
__u16 hci_rev;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 07c8c79..d2fee64 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -614,6 +614,9 @@ static void le_setup(struct hci_dev *hdev)
/* Read LE Advertising Channel TX Power */
hci_send_cmd(hdev, HCI_OP_LE_READ_ADV_TX_POWER, 0, NULL);
+
+ /* Read LE White List Size */
+ hci_send_cmd(hdev, HCI_OP_LE_READ_WHITE_LIST_SIZE, 0, NULL);
}
static void hci_setup(struct hci_dev *hdev)
@@ -1306,6 +1309,19 @@ static void hci_cc_le_set_scan_enable(struct hci_dev *hdev,
}
}
+static void hci_cc_le_read_white_list_size(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_white_list_size *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%2.2x size %u", hdev->name, rp->status, rp->size);
+
+ if (!rp->status)
+ hdev->le_white_list_size = rp->size;
+
+ hci_req_complete(hdev, HCI_OP_LE_READ_WHITE_LIST_SIZE, rp->status);
+}
+
static void hci_cc_le_ltk_reply(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_rp_le_ltk_reply *rp = (void *) skb->data;
@@ -2684,6 +2700,10 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_le_set_scan_enable(hdev, skb);
break;
+ case HCI_OP_LE_READ_WHITE_LIST_SIZE:
+ hci_cc_le_read_white_list_size(hdev, skb);
+ break;
+
case HCI_OP_LE_LTK_REPLY:
hci_cc_le_ltk_reply(hdev, skb);
break;
--
1.7.10.4
^ permalink raw reply related
* [PATCH 3/3] Bluetooth: Add support for reading LE supported states
From: Johan Hedberg @ 2013-01-22 12:02 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1358856121-1928-1-git-send-email-johan.hedberg@gmail.com>
From: Johan Hedberg <johan.hedberg@intel.com>
The LE supported states indicate the states and state combinations that
the link layer supports. This is important information for knowing what
operations are possible when dealing with multiple connected devices.
This patch adds reading of the supported states to the HCI init
sequence.
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
---
include/net/bluetooth/hci.h | 6 ++++++
include/net/bluetooth/hci_core.h | 1 +
net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
3 files changed, 27 insertions(+)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index f1766a6..7f12c25f 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -1045,6 +1045,12 @@ struct hci_rp_le_ltk_neg_reply {
__le16 handle;
} __packed;
+#define HCI_OP_LE_READ_SUPPORTED_STATES 0x201c
+struct hci_rp_le_read_supported_states {
+ __u8 status;
+ __u8 le_states[8];
+} __packed;
+
/* ---- HCI Events ---- */
#define HCI_EV_INQUIRY_COMPLETE 0x01
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index d6ed4ac..bcf8ffe 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -154,6 +154,7 @@ struct hci_dev {
__u8 host_features[8];
__u8 le_features[8];
__u8 le_white_list_size;
+ __u8 le_states[8];
__u8 commands[64];
__u8 hci_ver;
__u16 hci_rev;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index d2fee64..d4fcba6 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -617,6 +617,9 @@ static void le_setup(struct hci_dev *hdev)
/* Read LE White List Size */
hci_send_cmd(hdev, HCI_OP_LE_READ_WHITE_LIST_SIZE, 0, NULL);
+
+ /* Read LE Supported States */
+ hci_send_cmd(hdev, HCI_OP_LE_READ_SUPPORTED_STATES, 0, NULL);
}
static void hci_setup(struct hci_dev *hdev)
@@ -1346,6 +1349,19 @@ static void hci_cc_le_ltk_neg_reply(struct hci_dev *hdev, struct sk_buff *skb)
hci_req_complete(hdev, HCI_OP_LE_LTK_NEG_REPLY, rp->status);
}
+static void hci_cc_le_read_supported_states(struct hci_dev *hdev,
+ struct sk_buff *skb)
+{
+ struct hci_rp_le_read_supported_states *rp = (void *) skb->data;
+
+ BT_DBG("%s status 0x%2.2x", hdev->name, rp->status);
+
+ if (!rp->status)
+ memcpy(hdev->le_states, rp->le_states, 8);
+
+ hci_req_complete(hdev, HCI_OP_LE_READ_SUPPORTED_STATES, rp->status);
+}
+
static void hci_cc_write_le_host_supported(struct hci_dev *hdev,
struct sk_buff *skb)
{
@@ -2712,6 +2728,10 @@ static void hci_cmd_complete_evt(struct hci_dev *hdev, struct sk_buff *skb)
hci_cc_le_ltk_neg_reply(hdev, skb);
break;
+ case HCI_OP_LE_READ_SUPPORTED_STATES:
+ hci_cc_le_read_supported_states(hdev, skb);
+ break;
+
case HCI_OP_WRITE_LE_HOST_SUPPORTED:
hci_cc_write_le_host_supported(hdev, skb);
break;
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 1/3] health: Fix possible use after free
From: Luiz Augusto von Dentz @ 2013-01-22 12:04 UTC (permalink / raw)
To: Syam Sidhardhan; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358775211-31005-1-git-send-email-s.syam@samsung.com>
Hi Syam,
On Mon, Jan 21, 2013 at 3:33 PM, Syam Sidhardhan <s.syam@samsung.com> wrote:
> A pointer to freed memory is dereferenced if we call function
> hdp_get_dcpsm_cb() with out any earlier reference.
> ---
> profiles/health/hdp.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/profiles/health/hdp.c b/profiles/health/hdp.c
> index c15f06a..a42ca48 100644
> --- a/profiles/health/hdp.c
> +++ b/profiles/health/hdp.c
> @@ -542,9 +542,9 @@ static void hdp_get_dcpsm_cb(uint16_t dcpsm, gpointer user_data, GError *err)
> hdp_tmp_dc_data_destroy, &gerr))
> return;
>
> - hdp_tmp_dc_data_unref(hdp_conn);
> hdp_conn->cb(hdp_chann->mdl, err, hdp_conn);
> g_error_free(gerr);
> + hdp_tmp_dc_data_unref(hdp_conn);
> }
>
> static void device_reconnect_mdl_cb(struct mcap_mdl *mdl, GError *err,
> --
> 1.7.9.5
All 3 patches are now upstream, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH 1/3] Bluetooth: Add LE Local Features reading support
From: Marcel Holtmann @ 2013-01-22 12:04 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-1-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> To be able to make the appropriate decisions for some LE procedures we
> need to know the LE features that the local controller supports.
> Therefore, it's important to have the LE Read Local Supported Features
> HCI comand as part of the HCI init sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 2/3] Bluetooth: Add support for reading LE White List Size
From: Marcel Holtmann @ 2013-01-22 12:05 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-2-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The LE White List Size is necessary to be known before attempting to
> feed the controller with any addresses intended for the white list. This
> patch adds the necessary HCI command sending to the HCI init sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 3/3] Bluetooth: Add support for reading LE supported states
From: Marcel Holtmann @ 2013-01-22 12:05 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <1358856121-1928-3-git-send-email-johan.hedberg@gmail.com>
Hi Johan,
> The LE supported states indicate the states and state combinations that
> the link layer supports. This is important information for knowing what
> operations are possible when dealing with multiple connected devices.
> This patch adds reading of the supported states to the HCI init
> sequence.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
> ---
> include/net/bluetooth/hci.h | 6 ++++++
> include/net/bluetooth/hci_core.h | 1 +
> net/bluetooth/hci_event.c | 20 ++++++++++++++++++++
> 3 files changed, 27 insertions(+)
Acked-by: Marcel Holtmann <marcel@holtmann.org>
Regards
Marcel
^ permalink raw reply
* Re: [RFC 1/1] avctp: Set browsing channel connection for ct
From: Luiz Augusto von Dentz @ 2013-01-22 16:01 UTC (permalink / raw)
To: Alexandros Antonopoulos; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358850844-19752-2-git-send-email-alexandros.antonopoulos@oss.bmw-carit.de>
Hi Alexandros,
On Tue, Jan 22, 2013 at 12:34 PM, Alexandros Antonopoulos
<alexandros.antonopoulos@oss.bmw-carit.de> wrote:
> Add two extra states for the browsing channel and handle the connection
> sequence in avrcp.c
>
> ---
> profiles/audio/avctp.c | 11 +++++++++++
> profiles/audio/avctp.h | 4 +++-
> profiles/audio/avrcp.c | 28 +++++++++++++++++++++++-----
> profiles/audio/device.c | 4 ++++
> 4 files changed, 41 insertions(+), 6 deletions(-)
>
> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
> index e65594d..753f8fe 100644
> --- a/profiles/audio/avctp.c
> +++ b/profiles/audio/avctp.c
> @@ -476,6 +476,12 @@ static void avctp_set_state(struct avctp *session, avctp_state_t new_state)
> case AVCTP_STATE_CONNECTED:
> DBG("AVCTP Connected");
> break;
> + case AVCTP_STATE_BROWSING_CONNECTING:
> + DBG("AVCTP Browsing Connecting");
> + break;
> + case AVCTP_STATE_BROWSING_CONNECTED:
> + DBG("AVCTP Browsing Connected");
> + break;
> default:
> error("Invalid AVCTP state %d", new_state);
> return;
> @@ -913,9 +919,12 @@ static void avctp_connect_browsing_cb(GIOChannel *chan, GError *err,
> G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
> (GIOFunc) session_browsing_cb, session);
>
> + avctp_set_state(session, AVCTP_STATE_BROWSING_CONNECTED);
> return;
>
> fail:
> + avctp_set_state(session, AVCTP_STATE_CONNECTED);
> +
> if (session->browsing) {
> avctp_channel_destroy(session->browsing);
> session->browsing = NULL;
> @@ -1648,6 +1657,8 @@ int avctp_connect_browsing(struct avctp *session)
> if (session->browsing != NULL)
> return 0;
>
> + avctp_set_state(session, AVCTP_STATE_BROWSING_CONNECTING);
> +
> io = bt_io_connect(avctp_connect_browsing_cb, session, NULL, &err,
> BT_IO_OPT_SOURCE_BDADDR,
> adapter_get_address(session->server->adapter),
> diff --git a/profiles/audio/avctp.h b/profiles/audio/avctp.h
> index c25a3b3..d1fe693 100644
> --- a/profiles/audio/avctp.h
> +++ b/profiles/audio/avctp.h
> @@ -67,7 +67,9 @@ struct avctp;
> typedef enum {
> AVCTP_STATE_DISCONNECTED = 0,
> AVCTP_STATE_CONNECTING,
> - AVCTP_STATE_CONNECTED
> + AVCTP_STATE_CONNECTED,
> + AVCTP_STATE_BROWSING_CONNECTING,
> + AVCTP_STATE_BROWSING_CONNECTED
> } avctp_state_t;
>
> typedef void (*avctp_state_cb) (struct audio_device *dev,
> diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
> index 636d3e4..6cab45f 100644
> --- a/profiles/audio/avrcp.c
> +++ b/profiles/audio/avrcp.c
> @@ -2182,12 +2182,9 @@ static void session_tg_init(struct avrcp *session)
> (1 << AVRCP_EVENT_TRACK_REACHED_END) |
> (1 << AVRCP_EVENT_SETTINGS_CHANGED);
>
> - if (session->version >= 0x0104) {
> + if (session->version >= 0x0104)
> avrcp_register_notification(session,
> AVRCP_EVENT_VOLUME_CHANGED);
> - if (session->features & AVRCP_FEATURE_BROWSING)
> - avctp_connect_browsing(session->conn);
> - }
>
> session->control_id = avctp_register_pdu_handler(session->conn,
> AVC_OP_VENDORDEP,
> @@ -2341,6 +2338,7 @@ static void state_changed(struct audio_device *dev, avctp_state_t old_state,
> {
> struct avrcp_server *server;
> struct avrcp *session;
> + uint8_t browsing_failed = false;
>
> server = find_server(servers, device_get_adapter(dev->btd_dev));
> if (!server)
> @@ -2367,8 +2365,28 @@ static void state_changed(struct audio_device *dev, avctp_state_t old_state,
> if (session == NULL)
> break;
>
> - session->init(session);
> + if (session->version <= 0x0103) {
> + session->init(session);
> + break;
> + }
> +
> + /*AVCRP >= 1.4*/
> + if (old_state == AVCTP_STATE_CONNECTING) {
> + if (avctp_connect_browsing(session->conn) != 0)
> + browsing_failed = true;
> + } else if (old_state == AVCTP_STATE_BROWSING_CONNECTING) {
> + browsing_failed = true;
> + }
>
> + if (browsing_failed)
> + session->init(session);
> + break;
> + case AVCTP_STATE_BROWSING_CONNECTED:
> + if (session == NULL)
> + break;
> +
> + session->init(session);
> + break;
> default:
> return;
> }
> diff --git a/profiles/audio/device.c b/profiles/audio/device.c
> index d4ba6d2..2aa22bb 100644
> --- a/profiles/audio/device.c
> +++ b/profiles/audio/device.c
> @@ -289,6 +289,10 @@ static void device_avctp_cb(struct audio_device *dev,
> break;
> case AVCTP_STATE_CONNECTED:
> break;
> + case AVCTP_STATE_BROWSING_CONNECTING:
> + break;
> + case AVCTP_STATE_BROWSING_CONNECTED:
> + break;
> }
> }
>
> --
> 1.8.1
>
This patch has been applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH] avctp: Add functionality for CT browsing commands
From: Luiz Augusto von Dentz @ 2013-01-22 16:02 UTC (permalink / raw)
To: Alexandros Antonopoulos; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358850763-19532-1-git-send-email-alexandros.antonopoulos@oss.bmw-carit.de>
Hi Alexandros,
On Tue, Jan 22, 2013 at 12:32 PM, Alexandros Antonopoulos
<alexandros.antonopoulos@oss.bmw-carit.de> wrote:
> Add the missing functionality for full support of browsing channel
> on the CT side. This is required for AVRCP >= 1.4
> The patch is based on the control channel functionality
>
> ---
> profiles/audio/avctp.c | 140 +++++++++++++++++++++++++++++++++++++++++++++++++
> profiles/audio/avctp.h | 6 +++
> 2 files changed, 146 insertions(+)
>
> diff --git a/profiles/audio/avctp.c b/profiles/audio/avctp.c
> index e65594d..02bee2b 100644
> --- a/profiles/audio/avctp.c
> +++ b/profiles/audio/avctp.c
> @@ -136,6 +136,14 @@ struct avctp_control_req {
> void *user_data;
> };
>
> +struct avctp_browsing_req {
> + struct avctp_pending_req *p;
> + uint8_t *operands;
> + uint16_t operand_count;
> + avctp_browsing_rsp_cb func;
> + void *user_data;
> +};
> +
> typedef int (*avctp_process_cb) (void *data);
>
> struct avctp_pending_req {
> @@ -527,6 +535,44 @@ static int avctp_send(struct avctp_channel *control, uint8_t transaction,
> return err;
> }
>
> +static int avctp_browsing_send(struct avctp_channel *browsing,
> + uint8_t transaction, uint8_t cr,
> + uint8_t *operands, size_t operand_count)
> +{
> + struct avctp_header *avctp;
> + struct msghdr msg;
> + struct iovec iov[2];
> + int sk, err = 0;
> +
> + iov[0].iov_base = browsing->buffer;
> + iov[0].iov_len = sizeof(*avctp);
> + iov[1].iov_base = operands;
> + iov[1].iov_len = operand_count;
> +
> + if (browsing->omtu < (iov[0].iov_len + iov[1].iov_len))
> + return -EOVERFLOW;
> +
> + sk = g_io_channel_unix_get_fd(browsing->io);
> +
> + memset(browsing->buffer, 0, iov[0].iov_len);
> +
> + avctp = (void *) browsing->buffer;
> +
> + avctp->transaction = transaction;
> + avctp->packet_type = AVCTP_PACKET_SINGLE;
> + avctp->cr = cr;
> + avctp->pid = htons(AV_REMOTE_SVCLASS_ID);
> +
> + memset(&msg, 0, sizeof(msg));
> + msg.msg_iov = iov;
> + msg.msg_iovlen = 2;
> +
> + if (sendmsg(sk, &msg, 0) < 0)
> + err = -errno;
> +
> + return err;
> +}
> +
> static void control_req_destroy(void *data)
> {
> struct avctp_control_req *req = data;
> @@ -535,6 +581,14 @@ static void control_req_destroy(void *data)
> g_free(req);
> }
>
> +static void browsing_req_destroy(void *data)
> +{
> + struct avctp_browsing_req *req = data;
> +
> + g_free(req->operands);
> + g_free(req);
> +}
> +
> static gboolean req_timeout(gpointer user_data)
> {
> struct avctp_channel *chan = user_data;
> @@ -563,6 +617,15 @@ static int process_control(void *data)
> req->operands, req->operand_count);
> }
>
> +static int process_browsing(void *data)
> +{
> + struct avctp_browsing_req *req = data;
> + struct avctp_pending_req *p = req->p;
> +
> + return avctp_browsing_send(p->chan, p->transaction, AVCTP_COMMAND,
> + req->operands, req->operand_count);
> +}
> +
> static gboolean process_queue(void *user_data)
> {
> struct avctp_channel *chan = user_data;
> @@ -636,6 +699,48 @@ static void control_response(struct avctp_channel *control,
> }
> }
>
> +static void browsing_response(struct avctp_channel *browsing,
> + struct avctp_header *avctp,
> + uint8_t *operands,
> + size_t operand_count)
> +{
> + struct avctp_pending_req *p = browsing->p;
> + struct avctp_browsing_req *req;
> + GSList *l;
> +
> + if (p && p->transaction == avctp->transaction) {
> + browsing->processed = g_slist_prepend(browsing->processed, p);
> +
> + if (p->timeout > 0) {
> + g_source_remove(p->timeout);
> + p->timeout = 0;
> + }
> +
> + browsing->p = NULL;
> +
> + if (browsing->process_id == 0)
> + browsing->process_id = g_idle_add(process_queue,
> + browsing);
> + }
> +
> + for (l = browsing->processed; l; l = l->next) {
> + p = l->data;
> + req = p->data;
> +
> + if (p->transaction != avctp->transaction)
> + continue;
> +
> + if (req->func && req->func(browsing->session,
> + operands, operand_count,
> + req->user_data))
> + return;
> +
> + browsing->processed = g_slist_remove(browsing->processed, p);
> +
> + return;
> + }
> +}
> +
> static gboolean session_browsing_cb(GIOChannel *chan, GIOCondition cond,
> gpointer data)
> {
> @@ -665,6 +770,11 @@ static gboolean session_browsing_cb(GIOChannel *chan, GIOCondition cond,
> ret -= AVCTP_HEADER_LENGTH;
> operand_count = ret;
>
> + if (avctp->cr == AVCTP_RESPONSE) {
> + browsing_response(browsing, avctp, operands, operand_count);
> + return TRUE;
> + }
> +
> packet_size = AVCTP_HEADER_LENGTH;
> avctp->cr = AVCTP_RESPONSE;
>
> @@ -1294,6 +1404,36 @@ static int avctp_send_req(struct avctp *session, uint8_t code,
> return 0;
> }
>
> +int avctp_send_browsing_req(struct avctp *session,
> + uint8_t *operands, size_t operand_count,
> + avctp_browsing_rsp_cb func, void *user_data)
> +{
> + struct avctp_channel *browsing = session->browsing;
> + struct avctp_pending_req *p;
> + struct avctp_browsing_req *req;
> +
> + if (browsing == NULL)
> + return -ENOTCONN;
> +
> + req = g_new0(struct avctp_browsing_req, 1);
> + req->func = func;
> + req->operands = g_memdup(operands, operand_count);
> + req->operand_count = operand_count;
> + req->user_data = user_data;
> +
> + p = pending_create(browsing, process_browsing, req,
> + browsing_req_destroy);
> +
> + req->p = p;
> +
> + g_queue_push_tail(browsing->queue, p);
> +
> + if (browsing->process_id == 0)
> + browsing->process_id = g_idle_add(process_queue, browsing);
> +
> + return 0;
> +}
> +
> static char *op2str(uint8_t op)
> {
> switch (op & 0x7f) {
> diff --git a/profiles/audio/avctp.h b/profiles/audio/avctp.h
> index c25a3b3..b9107bd 100644
> --- a/profiles/audio/avctp.h
> +++ b/profiles/audio/avctp.h
> @@ -82,6 +82,9 @@ typedef size_t (*avctp_control_pdu_cb) (struct avctp *session,
> typedef gboolean (*avctp_rsp_cb) (struct avctp *session, uint8_t code,
> uint8_t subunit, uint8_t *operands,
> size_t operand_count, void *user_data);
> +typedef gboolean (*avctp_browsing_rsp_cb) (struct avctp *session,
> + uint8_t *operands, size_t operand_count,
> + void *user_data);
> typedef size_t (*avctp_browsing_pdu_cb) (struct avctp *session,
> uint8_t transaction,
> uint8_t *operands, size_t operand_count,
> @@ -116,3 +119,6 @@ int avctp_send_vendordep_req(struct avctp *session, uint8_t code,
> uint8_t subunit, uint8_t *operands,
> size_t operand_count,
> avctp_rsp_cb func, void *user_data);
> +int avctp_send_browsing_req(struct avctp *session,
> + uint8_t *operands, size_t operand_count,
> + avctp_browsing_rsp_cb func, void *user_data);
> --
> 1.8.1
Patch applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ] avrcp: Ignore MSB of Absolute Volume parameter
From: Luiz Augusto von Dentz @ 2013-01-22 16:03 UTC (permalink / raw)
To: João Paulo Rechi Vita; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1358537120-7955-1-git-send-email-jprvita@openbossa.org>
Hi Joao,
On Fri, Jan 18, 2013 at 9:25 PM, João Paulo Rechi Vita
<jprvita@openbossa.org> wrote:
> According to the Section 6.13.1 of the AVRCP 1.5 specification document,
> the most significant bit of the Absolute Volume parameter is reserved
> for future additions, so it should be ignored when parsing parameters of
> the SetAbsoluteVolume command. This is also necessary to pass PTS test
> TC_TG_VLH_BI_02_C.
> ---
> profiles/audio/avrcp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/profiles/audio/avrcp.c b/profiles/audio/avrcp.c
> index 636d3e4..237f176 100644
> --- a/profiles/audio/avrcp.c
> +++ b/profiles/audio/avrcp.c
> @@ -1398,11 +1398,13 @@ static uint8_t avrcp_handle_set_absolute_volume(struct avrcp *session,
> {
> struct avrcp_player *player = session->player;
> uint16_t len = ntohs(pdu->params_len);
> + uint8_t volume;
>
> if (len != 1)
> goto err;
>
> - if (pdu->params[0] > 127)
> + volume = pdu->params[0] & 0x7F;
> + if (volume > 127)
> goto err;
>
> if (!player)
> --
> 1.7.11.7
Patch applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [RFC] Bluetooth: Fix missing MITM protection when being responding LM
From: Timo Müller @ 2013-01-22 17:36 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, linux-bluetooth, Timo Mueller
In-Reply-To: <1358851002.7365.11.camel@aeonflux>
Hi Johan, Hi Marcel,
Marcel Holtmann wrote, On 22.01.2013 11:36:
> Hi Johan,
>
>>> A MITM protected SSP associaton model can be used for pairing if both
>>> local and remote IO capabilities are set to something other than
>>> NoInputNoOutput.
>>>
>>> With these IO capabilities a MITM protected SSP association model is
>>> used if we are initiating the pairing process (initiating LM).
>>>
>>> When responding to a pairing request - remote device is the initiating
>>> LM - the pairing should also be proteced against MITM attacks.
>>>
>>> Signed-off-by: Timo Mueller <timo.mueller@bmw-carit.de>
>>> ---
>>> When we were testing the iPhone 5 we noticed that the association
>>> model changes depending on which side initiates the pairing. For
>>> example if we paired from the phone "Just Works" was used while if the
>>> phone was the responding LM a "Numeric Comparison" was used instead.
>>>
>>> We'd like to enforce MITM protection in our cars whenever possible.
>>> That is why we want to set the MITM protection even when being the
>>> responding LM. The patch proposes this policy as the default approach.
>>>
>>> Expected SSP accociation model:
>>> |-------------------------------------------|
>>> | Device | SSP assocation model |
>>> |===========================================|
>>> | KeyboardDisplay | Numeric Comparison |
>>> | ------------------------------------------|
>>> | NoInputNoOutput | Just Works |
>>> | ------------------------------------------|
>>> | KeyboardOnly | Passkey Entry |
>>> |-------------------------------------------|
>>>
>>> Tested Devices:
>>> KeyboardDisplay:
>>> iPhone 4 (iOS4), iPhone 5 (iOS6), Nokia N9, HTC One S,
>>> Samsung Galaxy (CM 10.1), Nexus 4, Nokia 6313 Classic,
>>> BlueZ 5 - Simple Agent
>>>
>>> NoInputNoOutput:
>>> BlueZ 5 - Simple Agent
>>>
>>> KeyboardOnly:
>>> Logitech Keyboard Case, BlueZ 5 - Simple Agent
>>>
>>> I've also tested this patch with the following kernels:
>>> 3.8-rc4
>>> 3.4
>>>
>>> Best regards,
>>> Timo
>>>
>>> net/bluetooth/hci_conn.c | 6 +++++-
>>> 1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
>>> index 25bfce0..806583b 100644
>>> --- a/net/bluetooth/hci_conn.c
>>> +++ b/net/bluetooth/hci_conn.c
>>> @@ -357,11 +357,15 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
>>> conn->type = type;
>>> conn->mode = HCI_CM_ACTIVE;
>>> conn->state = BT_OPEN;
>>> - conn->auth_type = HCI_AT_GENERAL_BONDING;
>>> conn->io_capability = hdev->io_capability;
>>> conn->remote_auth = 0xff;
>>> conn->key_type = 0xff;
>>>
>>> + if (hdev->io_capability == 0x03)
>>> + conn->auth_type = HCI_AT_GENERAL_BONDING;
>>> + else
>>> + conn->auth_type = HCI_AT_GENERAL_BONDING_MITM;
>>> +
>>> set_bit(HCI_CONN_POWER_SAVE, &conn->flags);
>>> conn->disc_timeout = HCI_DISCONN_TIMEOUT;
>>
>> The question that could equally be asked is why does iOS *not* set the
>> MITM flag when initiating pairing to a remote device. If it did this
>> issue would not exist.
>
> because iOS does not support SIM Access Profile. Outside of SIM Access,
> there is really no need to support high security.
>
> The difference between medium security and high security is really only
> the man-in-the-middle protection. From an encryption and link key
> strength point of view they are identical. Both link keys are P-192
> derived and the encryption cipher is still E0.
>
>> Since the over all sequence of the IO capability negotiation with iOS devices
>> when we're on the acceptor side might be a bit unclear to people by just
>> reading your commit message and patch I'll provide here a HCI trace of it:
>>
>> > HCI Event: IO Capability Response (0x32) plen 9
>> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
>> IO capability: DisplayYesNo (0x01)
>> OOB data: Authentication data not present (0x00)
>> Authentication: General Bonding - MITM not required (0x04)
>> > HCI Event: IO Capability Request (0x31) plen 6
>> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
>> < HCI Command: IO Capability Request Reply (0x01|0x002b) plen 9
>> Address: 04:F7:E4:xx:xx:xx (OUI 04-F7-E4)
>> IO capability: DisplayYesNo (0x01)
>> OOB data: Authentication data not present (0x00)
>> Authentication: General Bonding - MITM not required (0x04)
>>
>> Basically the BlueZ side has so far given the remote initiator the
>> choice whether to do just-works or not. However, I do agree that it's
>> good to strive for a best-possible security in the pairing (within the
>> limits of the available IO capabilities) so setting the MITM flag on our
>> side should be fine.
>
> This is still something we need to think about carefully. I am not sure
> we should just always be doing this. This might actually be better
> solved with a sysfs option or a mgmt command to pick different behavior.
>
> Since this is General Bonding and not Dedicated Bonding, I am not
> convinced that this is a good idea.
>
The BT spec says for both bonding types "parameter *should* (meaning
it's recommended to) be set to MITM Protection Not Required" if
initiator and responder support SSP. For dedicated bonding BlueZ is
already requiring MITM anyway (if possible). I think it would be good to
follow this approach also with general bonding.
Influencing the behaviour for general bonding with a mgmt command could
be an alternative. I will try to add this and send the proposal to the
mailing list.
>> The one thing that I'd still consider improving is to make the setting
>> of the MITM flag also dependent on the remote IO capability and not just
>> the local one, since we do know the remote one before we need to give
>> our own value when we are on the acceptor side of the pairing. Thoughts?
>
> This is a minimum requirement that we check the remote IO capabilities
> here. Since there is no point in trying MITM protection if the other
> side has no capabilities to ever create such a key.
So instead of setting the default association model according to the
local IO capabilities, the hci_get_auth_req method could be modified.
For general bonding the method would figure out the MITM requirement
analogous to the if-block for dedicated bonding. (With the mgmt command,
this would only be done when MITM is required.)
>
> I would be also curious if we still can qualify our own behavior and not
> end up with cases where we can't because we have no way to trigger it.
>
> Regards
>
> Marcel
Best regards,
Timo
^ permalink raw reply
* [PATCH BlueZ 0/2] AVRCP: Add support for Vol Up/Down operations on TG
From: João Paulo Rechi Vita @ 2013-01-22 18:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: luiz.dentz, João Paulo Rechi Vita
This series creates a new quirk called QUIRK_IGNORE to be able to accept and
ignore certain keys. Then it uses this infrastructure to accept and ignore
Volume Up/Down operations, instead of replying with "Not Implemented".
Suport for Volume Up/Down is mandatory on TG side if we claim to support
Category 2 (Monitor / Amplifier). It's also tested by PTS on test
TC_TG_PTT_BV_02_I.
João Paulo Rechi Vita (2):
avctp: Create ignore quirk
avctp: Receive and silent ignore Vol Up/Down operations
profiles/audio/avctp.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)
--
1.7.11.7
^ 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