* [PATCH 2/3] Add support for passing the CID to btiotest
From: Vinicius Costa Gomes @ 2011-04-15 0:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
In-Reply-To: <1302826003-5511-1-git-send-email-vinicius.gomes@openbossa.org>
---
test/btiotest.c | 11 ++++++++---
1 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/test/btiotest.c b/test/btiotest.c
index c02a25a..c4d8f4f 100644
--- a/test/btiotest.c
+++ b/test/btiotest.c
@@ -225,7 +225,7 @@ static void confirm_cb(GIOChannel *io, gpointer user_data)
}
static void l2cap_connect(const char *src, const char *dst, uint16_t psm,
- gint disconn, gint sec)
+ uint16_t cid, gint disconn, gint sec)
{
struct io_data *data;
GError *err = NULL;
@@ -241,6 +241,7 @@ static void l2cap_connect(const char *src, const char *dst, uint16_t psm,
BT_IO_OPT_SOURCE, src,
BT_IO_OPT_DEST, dst,
BT_IO_OPT_PSM, psm,
+ BT_IO_OPT_CID, cid,
BT_IO_OPT_SEC_LEVEL, sec,
BT_IO_OPT_INVALID);
else
@@ -249,6 +250,7 @@ static void l2cap_connect(const char *src, const char *dst, uint16_t psm,
&err,
BT_IO_OPT_DEST, dst,
BT_IO_OPT_PSM, psm,
+ BT_IO_OPT_CID, cid,
BT_IO_OPT_SEC_LEVEL, sec,
BT_IO_OPT_INVALID);
@@ -466,6 +468,7 @@ static gint opt_disconn = -1;
static gint opt_accept = DEFAULT_ACCEPT_TIMEOUT;
static gint opt_sec = 0;
static gboolean opt_master = FALSE;
+static gint opt_cid = 0;
static GMainLoop *main_loop;
@@ -474,6 +477,8 @@ static GOptionEntry options[] = {
"RFCOMM channel" },
{ "psm", 'p', 0, G_OPTION_ARG_INT, &opt_psm,
"L2CAP PSM" },
+ { "cid", 'j', 0, G_OPTION_ARG_INT, &opt_cid,
+ "L2CAP CID" },
{ "sco", 's', 0, G_OPTION_ARG_NONE, &opt_sco,
"Use SCO" },
{ "defer", 'd', 0, G_OPTION_ARG_NONE, &opt_defer,
@@ -513,9 +518,9 @@ int main(int argc, char *argv[])
printf("accept=%d, reject=%d, discon=%d, defer=%d, sec=%d\n",
opt_accept, opt_reject, opt_disconn, opt_defer, opt_sec);
- if (opt_psm) {
+ if (opt_psm || opt_cid) {
if (argc > 1)
- l2cap_connect(opt_dev, argv[1], opt_psm,
+ l2cap_connect(opt_dev, argv[1], opt_psm, opt_cid,
opt_disconn, opt_sec);
else
l2cap_listen(opt_dev, opt_psm, opt_defer, opt_reject,
--
1.7.4.3
^ permalink raw reply related
* [PATCH 1/3] Add support for getting the Encryption Key Size via btio
From: Vinicius Costa Gomes @ 2011-04-15 0:06 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Vinicius Costa Gomes
Some profiles specify some restriction depending on the length
of the key used to encrypt the link, this adds an way to retrieve
that value from the kernel.
Current kernels don't provide this information so the size is
always zero.
---
btio/btio.c | 21 +++++++++++++++++++++
btio/btio.h | 1 +
lib/bluetooth.h | 1 +
3 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/btio/btio.c b/btio/btio.c
index 3f5b69a..aed9e0a 100644
--- a/btio/btio.c
+++ b/btio/btio.c
@@ -485,6 +485,22 @@ static gboolean get_sec_level(int sock, BtIOType type, int *level,
return TRUE;
}
+static gboolean get_key_size(int sock, BtIOType type, int *size,
+ GError **err)
+{
+ struct bt_security sec;
+ socklen_t len;
+
+ memset(&sec, 0, sizeof(sec));
+ len = sizeof(sec);
+ if (getsockopt(sock, SOL_BLUETOOTH, BT_SECURITY, &sec, &len) == 0) {
+ *size = sec.key_size;
+ return TRUE;
+ }
+
+ return FALSE;
+}
+
static gboolean l2cap_set(int sock, int sec_level, uint16_t imtu, uint16_t omtu,
uint8_t mode, int master, GError **err)
{
@@ -800,6 +816,11 @@ static gboolean l2cap_get(int sock, GError **err, BtIOOption opt1,
va_arg(args, int *), err))
return FALSE;
break;
+ case BT_IO_OPT_KEY_SIZE:
+ if (!get_key_size(sock, BT_IO_L2CAP,
+ va_arg(args, int *), err))
+ return FALSE;
+ break;
case BT_IO_OPT_PSM:
*(va_arg(args, uint16_t *)) = src.l2_psm ?
src.l2_psm : dst.l2_psm;
diff --git a/btio/btio.h b/btio/btio.h
index 53e8eaa..637710f 100644
--- a/btio/btio.h
+++ b/btio/btio.h
@@ -52,6 +52,7 @@ typedef enum {
BT_IO_OPT_DEST_BDADDR,
BT_IO_OPT_DEFER_TIMEOUT,
BT_IO_OPT_SEC_LEVEL,
+ BT_IO_OPT_KEY_SIZE,
BT_IO_OPT_CHANNEL,
BT_IO_OPT_SOURCE_CHANNEL,
BT_IO_OPT_DEST_CHANNEL,
diff --git a/lib/bluetooth.h b/lib/bluetooth.h
index 738e07a..1492139 100644
--- a/lib/bluetooth.h
+++ b/lib/bluetooth.h
@@ -63,6 +63,7 @@ extern "C" {
#define BT_SECURITY 4
struct bt_security {
uint8_t level;
+ uint8_t key_size;
};
#define BT_SECURITY_SDP 0
#define BT_SECURITY_LOW 1
--
1.7.4.3
^ permalink raw reply related
* [RFC 2/2] Bluetooth: Add support for returning the encryption key size
From: Vinicius Costa Gomes @ 2011-04-15 0:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, Vinicius Costa Gomes
In-Reply-To: <1302825888-5359-1-git-send-email-vinicius.gomes@openbossa.org>
This will be useful when userspace wants to restrict some kinds of
operations based on the length of the key size used to encrypt the
link.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
include/net/bluetooth/bluetooth.h | 1 +
net/bluetooth/l2cap_sock.c | 4 ++++
2 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/bluetooth.h b/include/net/bluetooth/bluetooth.h
index acf186d..28ae91a 100644
--- a/include/net/bluetooth/bluetooth.h
+++ b/include/net/bluetooth/bluetooth.h
@@ -56,6 +56,7 @@
#define BT_SECURITY 4
struct bt_security {
__u8 level;
+ __u8 key_size;
};
#define BT_SECURITY_SDP 0
#define BT_SECURITY_LOW 1
diff --git a/net/bluetooth/l2cap_sock.c b/net/bluetooth/l2cap_sock.c
index b5796fd..7d143f4 100644
--- a/net/bluetooth/l2cap_sock.c
+++ b/net/bluetooth/l2cap_sock.c
@@ -492,8 +492,12 @@ static int l2cap_sock_getsockopt(struct socket *sock, int level, int optname, ch
break;
}
+ memset(&sec, 0, sizeof(sec));
sec.level = l2cap_pi(sk)->sec_level;
+ if (sk->sk_state == BT_CONNECTED)
+ sec.key_size = l2cap_pi(sk)->conn->hcon->enc_key_size;
+
len = min_t(unsigned int, len, sizeof(sec));
if (copy_to_user(optval, (char *) &sec, len))
err = -EFAULT;
--
1.7.4.3
^ permalink raw reply related
* [RFC 1/2] Bluetooth: Add support for storing the key size
From: Vinicius Costa Gomes @ 2011-04-15 0:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, Vinicius Costa Gomes
In-Reply-To: <1302825888-5359-1-git-send-email-vinicius.gomes@openbossa.org>
In some cases it will be useful having the key size used for
encrypting the link. For example, some profiles may restrict
some operations depending on the key length.
The key size is stored in the key that is passed to userspace
using the pin_length field in the key structure.
For now this field is only valid for LE controllers. 3.0+HS
controllers define the Read Encryption Key Size command, this
field is intended for storing the value returned by that
command.
Signed-off-by: Vinicius Costa Gomes <vinicius.gomes@openbossa.org>
---
include/net/bluetooth/hci_core.h | 3 ++-
net/bluetooth/hci_core.c | 3 ++-
net/bluetooth/hci_event.c | 1 +
net/bluetooth/mgmt.c | 4 ++--
net/bluetooth/smp.c | 16 ++++++++++------
5 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 9bb3c42..3345d96 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -263,6 +263,7 @@ struct hci_conn {
__u8 sec_level;
__u8 pending_sec_level;
__u8 pin_length;
+ __u8 enc_key_size;
__u8 io_capability;
__u8 power_save;
__u16 disc_timeout;
@@ -552,7 +553,7 @@ struct link_key *hci_find_ltk(struct hci_dev *hdev, __le16 ediv, u8 rand[8]);
struct link_key *hci_find_link_key_type(struct hci_dev *hdev,
bdaddr_t *bdaddr, u8 type);
int hci_add_ltk(struct hci_dev *hdev, int new_key, bdaddr_t *bdaddr,
- __le16 ediv, u8 rand[8], u8 ltk[16]);
+ u8 key_size, __le16 ediv, u8 rand[8], u8 ltk[16]);
int hci_remove_link_key(struct hci_dev *hdev, bdaddr_t *bdaddr);
int hci_remote_oob_data_clear(struct hci_dev *hdev);
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index c380665..dc7ff39 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1103,7 +1103,7 @@ int hci_add_link_key(struct hci_dev *hdev, int new_key, bdaddr_t *bdaddr,
}
int hci_add_ltk(struct hci_dev *hdev, int new_key, bdaddr_t *bdaddr,
- __le16 ediv, u8 rand[8], u8 ltk[16])
+ u8 key_size, __le16 ediv, u8 rand[8], u8 ltk[16])
{
struct link_key *key, *old_key;
struct key_master_id *id;
@@ -1128,6 +1128,7 @@ int hci_add_ltk(struct hci_dev *hdev, int new_key, bdaddr_t *bdaddr,
bacpy(&key->bdaddr, bdaddr);
memcpy(key->val, ltk, sizeof(key->val));
key->type = KEY_TYPE_LTK;
+ key->pin_len = key_size;
id = (void *) &key->data;
id->ediv = ediv;
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 882a2be..5c8a51f 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2654,6 +2654,7 @@ static inline void hci_le_ltk_request_evt(struct hci_dev *hdev,
memcpy(cp.ltk, ltk->val, sizeof(ltk->val));
cp.handle = cpu_to_le16(conn->handle);
+ conn->pin_length = ltk->pin_len;
hci_send_cmd(hdev, HCI_OP_LE_LTK_REPLY, sizeof(cp), &cp);
diff --git a/net/bluetooth/mgmt.c b/net/bluetooth/mgmt.c
index 9c25513..ffbcd6e 100644
--- a/net/bluetooth/mgmt.c
+++ b/net/bluetooth/mgmt.c
@@ -956,8 +956,8 @@ static int load_keys(struct sock *sk, u16 index, unsigned char *data, u16 len)
if (key->dlen != sizeof(struct key_master_id))
continue;
- hci_add_ltk(hdev, 0, &key->bdaddr, id->ediv,
- id->rand, key->val);
+ hci_add_ltk(hdev, 0, &key->bdaddr, key->pin_len,
+ id->ediv, id->rand, key->val);
continue;
}
diff --git a/net/bluetooth/smp.c b/net/bluetooth/smp.c
index a93ac78..2dd5748 100644
--- a/net/bluetooth/smp.c
+++ b/net/bluetooth/smp.c
@@ -399,6 +399,7 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
SMP_MAX_ENC_KEY_SIZE - conn->smp_key_size);
hci_le_start_enc(hcon, ediv, rand, stk);
+ hcon->enc_key_size = conn->smp_key_size;
hex_dump_to_buffer(key, sizeof(key), 16, 1, buf,
sizeof(buf), 0);
@@ -419,7 +420,8 @@ static u8 smp_cmd_pairing_random(struct l2cap_conn *conn, struct sk_buff *skb)
memset(stk + conn->smp_key_size, 0,
SMP_MAX_ENC_KEY_SIZE - conn->smp_key_size);
- hci_add_ltk(conn->hcon->hdev, 0, conn->dst, ediv, rand, stk);
+ hci_add_ltk(conn->hcon->hdev, 0, conn->dst, conn->smp_key_size,
+ ediv, rand, stk);
hex_dump_to_buffer(key, sizeof(key), 16, 1, buf,
sizeof(buf), 0);
@@ -489,6 +491,8 @@ int smp_conn_security(struct l2cap_conn *conn, __u8 sec_level)
hci_le_start_enc(hcon, master->ediv, master->rand,
key->val);
+ hcon->enc_key_size = key->pin_len;
+
goto done;
}
}
@@ -529,7 +533,7 @@ static int smp_cmd_encrypt_info(struct l2cap_conn *conn, struct sk_buff *skb)
memset(rand, 0, sizeof(rand));
- err = hci_add_ltk(conn->hcon->hdev, 0, conn->dst, 0, rand, rp->ltk);
+ err = hci_add_ltk(conn->hcon->hdev, 0, conn->dst, 0, 0, rand, rp->ltk);
if (err)
return SMP_UNSPECIFIED;
@@ -556,8 +560,8 @@ static int smp_cmd_master_ident(struct l2cap_conn *conn, struct sk_buff *skb)
id->ediv = rp->ediv;
memcpy(id->rand, rp->rand, sizeof(rp->rand));
- hci_add_ltk(conn->hcon->hdev, 1, conn->src, rp->ediv,
- rp->rand, key->val);
+ hci_add_ltk(conn->hcon->hdev, 1, conn->src, conn->smp_key_size,
+ rp->ediv, rp->rand, key->val);
smp_distribute_keys(conn, 1);
@@ -676,8 +680,8 @@ int smp_distribute_keys(struct l2cap_conn *conn, __u8 force)
smp_send_cmd(conn, SMP_CMD_ENCRYPT_INFO, sizeof(enc), &enc);
- hci_add_ltk(conn->hcon->hdev, 1, conn->dst, ediv,
- ident.rand, enc.ltk);
+ hci_add_ltk(conn->hcon->hdev, 1, conn->dst, conn->smp_key_size,
+ ediv, ident.rand, enc.ltk);
ident.ediv = cpu_to_le16(ediv);
--
1.7.4.3
^ permalink raw reply related
* [RFC 0/2] Returning Encryption Key Size
From: Vinicius Costa Gomes @ 2011-04-15 0:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, johan.hedberg, Vinicius Costa Gomes
Disclaimer: the code this is based on is still on review, so this is
is subject to change.
Having Encryption Key Size exported to userspace is needed because
some profiles might have some restrictions depending on the key size
used to encrypt the link.
This patch series implement exporting to userspace adding one more
field to the bt_security structure.
For now, this only is valid for LE links, for 3.0+HS controllers
the Read Encryption Key Size command is defined. The plan is to
use that command for reading the key size as soon as the link
is encrypted, and storing the value read in the field that was
added to hci_conn.
The related userspace patches should follow this series.
--
Cheers,
Vinicius Costa Gomes (2):
Bluetooth: Add support for storing the key size
Bluetooth: Add support for returning the encryption key size
include/net/bluetooth/bluetooth.h | 1 +
include/net/bluetooth/hci_core.h | 3 ++-
net/bluetooth/hci_core.c | 3 ++-
net/bluetooth/hci_event.c | 1 +
net/bluetooth/l2cap_sock.c | 4 ++++
net/bluetooth/mgmt.c | 4 ++--
net/bluetooth/smp.c | 16 ++++++++++------
7 files changed, 22 insertions(+), 10 deletions(-)
--
1.7.4.3
^ permalink raw reply
* Re: [PATCH] hcidump: use correct size to copy 'direction' value
From: Johan Hedberg @ 2011-04-14 17:15 UTC (permalink / raw)
To: Iain Hibbert; +Cc: linux-bluetooth
In-Reply-To: <20110414091124.D0AB826008F@galant.ukfsn.org>
Hi Iain,
On Thu, Apr 14, 2011, Iain Hibbert wrote:
> frm.in is stored as an uint8_t, so we cannot copy an int there
> directly. use an intermediate variable so that it also works
> on big-endian systems.
> ---
> src/hcidump.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix unregistering a2dp sep while it is locked
From: Johan Hedberg @ 2011-04-14 17:13 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1302686450-5961-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Wed, Apr 13, 2011, Luiz Augusto von Dentz wrote:
> If sep is locked it should not be unregistered until properly unlocked.
> ---
> audio/a2dp.c | 16 ++++++++++++++++
> 1 files changed, 16 insertions(+), 0 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2 1/9] Register primary services exported over basic rate
From: Johan Hedberg @ 2011-04-14 17:13 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1302546243-24005-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Mon, Apr 11, 2011, Claudio Takahasi wrote:
> This patch registers the object paths for primary services exported
> through SDP. PSM, start and end handle information are available in
> the Protocol Descriptor List.
> ---
> attrib/gatt.c | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> attrib/gatt.h | 6 ++++
> src/device.c | 56 ++++++++++++++++++++++++++++++++++++++++-
> 3 files changed, 139 insertions(+), 1 deletions(-)
All patches in this set have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix race condition on gatttool
From: Johan Hedberg @ 2011-04-14 17:07 UTC (permalink / raw)
To: Sheldon Demario; +Cc: linux-bluetooth
In-Reply-To: <1302544624-5216-1-git-send-email-sheldon.demario@openbossa.org>
Hi Sheldon,
On Mon, Apr 11, 2011, Sheldon Demario wrote:
> When the connect_cb() takes too long to be called the event_loop goes to idle
> state and executes the callback too early
> ---
> attrib/gatttool.c | 128 +++++++++++++++++++++++++---------------------------
> 1 files changed, 62 insertions(+), 66 deletions(-)
Thanks, the patch has been pushed upstream. Could you please fix your
editor settings so that it doesn't produce lines longer than 74
characters for git commit messages? I had to manually edit it this time.
Johan
^ permalink raw reply
* Re: [PATCH] Remove unnecessary code from pin handler
From: Johan Hedberg @ 2011-04-14 17:04 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth
In-Reply-To: <1302450491-26550-1-git-send-email-dh.herrmann@googlemail.com>
Hi David,
On Sun, Apr 10, 2011, David Herrmann wrote:
> The source address is not used inside the pin handler and, thus,
> can be skipped.
> ---
> src/event.c | 4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
The patch has been applied. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2] Add test/test-oob for testing Out Of Band pairing
From: Johan Hedberg @ 2011-04-14 17:04 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, henrik.possung
In-Reply-To: <1302255474-15128-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On Fri, Apr 08, 2011, Szymon Janc wrote:
> This test utilizes D-Bus Out Of Band API so bluetoothd must be
> compiled with dbusoob plugin.
> ---
> Makefile.tools | 4 +-
> test/test-oob | 80 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 2 files changed, 82 insertions(+), 2 deletions(-)
> create mode 100755 test/test-oob
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: bugfix patches for hcidump
From: Iain Hibbert @ 2011-04-14 9:10 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20110414072937.GA28187@jh-x301>
On Thu, 14 Apr 2011, Johan Hedberg wrote:
> Your patch email is still marked as "new" in my linux-bluetooth folder,
> so in that sense it's not lost. I've just forgotten to check back on
> older unapplied patches for a while.
Hence why a bugtracker would be good.. I previously unsubscribed from this
list because it turns into a patch dumping ground, and I guess that you
guys must feel pain trying to keep up..
> The reason why it didn't immediately go upstream was a coding style
> issue (missing space after a typecast) and the reuse of an iterator
> variable for something else than iteration. I don't remember what I was
> doing at the time when I glanced at your patch but it seems I must have
> been in quite a hurry since I didn't respond with these comments back
> then. Sorry about that.
Ok thanks (though you should be aware that I don't see space after cast
mentioned in the CodingStyle document :), will repost in a moment..
iain
^ permalink raw reply
* [PATCH] hcidump: use correct size to copy 'direction' value
From: Iain Hibbert @ 2011-04-14 9:08 UTC (permalink / raw)
To: linux-bluetooth
frm.in is stored as an uint8_t, so we cannot copy an int there
directly. use an intermediate variable so that it also works
on big-endian systems.
---
src/hcidump.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/src/hcidump.c b/src/hcidump.c
index 2023130..f865ad6 100644
--- a/src/hcidump.c
+++ b/src/hcidump.c
@@ -281,9 +281,11 @@ static int process_frames(int dev, int sock, int fd, unsigned long flags)
cmsg = CMSG_FIRSTHDR(&msg);
while (cmsg) {
+ int dir;
switch (cmsg->cmsg_type) {
case HCI_CMSG_DIR:
- memcpy(&frm.in, CMSG_DATA(cmsg), sizeof(int));
+ memcpy(&dir, CMSG_DATA(cmsg), sizeof(int));
+ frm.in = (uint8_t) dir;
break;
case HCI_CMSG_TSTAMP:
memcpy(&frm.ts, CMSG_DATA(cmsg),
--
1.7.4.1
^ permalink raw reply related
* Re: bugfix patches for hcidump
From: Johan Hedberg @ 2011-04-14 7:29 UTC (permalink / raw)
To: Iain Hibbert; +Cc: linux-bluetooth
In-Reply-To: <alpine.NEB.2.00.1104140748380.12891@galant.ukfsn.org>
Hi Iain,
On Thu, Apr 14, 2011, Iain Hibbert wrote:
> Is this still the correct place to post patches for hcidump?
Yes.
> I ask because I have posted a bugfix twice and so far been ignored, in my
> opinion BlueZ *really* needs a bug tracker so things don't get lost..
Your patch email is still marked as "new" in my linux-bluetooth folder,
so in that sense it's not lost. I've just forgotten to check back on
older unapplied patches for a while. The reason why it didn't
immediately go upstream was a coding style issue (missing space after a
typecast) and the reuse of an iterator variable for something else than
iteration. I don't remember what I was doing at the time when I glanced
at your patch but it seems I must have been in quite a hurry since I
didn't respond with these comments back then. Sorry about that.
Johan
^ permalink raw reply
* bugfix patches for hcidump
From: Iain Hibbert @ 2011-04-14 6:52 UTC (permalink / raw)
To: linux-bluetooth
Hi
Is this still the correct place to post patches for hcidump?
I ask because I have posted a bugfix twice and so far been ignored, in my
opinion BlueZ *really* needs a bug tracker so things don't get lost..
iain
http://article.gmane.org/gmane.linux.bluez.kernel/12276/match=
^ permalink raw reply
* Re: [PATCH] Bluetooth: MTU configuration for LE links
From: Marcel Holtmann @ 2011-04-13 23:20 UTC (permalink / raw)
To: Anderson Lizardo
Cc: Anderson Briglia, linux-bluetooth, ville.tervo, johan.hedberg,
Vinicius Costa Gomes
In-Reply-To: <BANLkTinOJGPTfQwjTi7mXEWHWKAd0aX6Zw@mail.gmail.com>
Hi Anderson,
> >> One thing to consider is that there are a couple of MTU checks along
> >> the L2CAP code. The issue which originated this patch is code such as:
> >>
> >> /* Check outgoing MTU */
> >> if (len > pi->omtu) {
> >> err = -EMSGSIZE;
> >> goto done;
> >> }
> >>
> >> We understood that just letting omtu/imtu values on kernel reflect the
> >> current connection MTU settings was the cleanest solution. What do you
> >> propose? Bypassing these checks for LE?
> >
> > this does not look clean to me. And we might have an internal MTU
> > variable as part of L2CAP, but the way how it gets set and thus its
> > semantic differs clearly between BR/EDR and LE. So shoehorning an
> > existing socket option this is clearly a bad idea.
>
> Sure. What to do then if:
>
> 1) LE links have MTU (omtu specifically) hard-coded to 23 on kernel.
> 2) the kernel rejects sending data longer than omtu.
>
> (this is the current situation)
>
> This clearly needs some fix on kernel side, otherwise we can't send
> PDUs longer than the LE default MTU (23), *even* if the peer device
> supports a bigger MTU.
I agree with that. Userspace needs to be able to change the kernel MTU
if a different one gets negotiated. That is not the problem. The problem
is trying to shoehorn this into an existing (and already declared
legacy) socket option.
> Suggestions are welcome regarding how to best approach this, without
> affecting current BR/EDR MTU semantics.
We need to have a socket option that allows us the dynamically change
the MTU of a L2CAP link. And right now this option will only be valid if
the link is actually an LE link.
Regards
Marcel
^ permalink raw reply
* RE: About the BT_SECURITY_HIGH support in Bluez stack
From: Waldemar.Rymarkiewicz @ 2011-04-13 16:13 UTC (permalink / raw)
To: braghave; +Cc: linux-bluetooth
In-Reply-To: <aa10f49e01a426ffd88f4cd8cf1e2f17.squirrel@www.codeaurora.org>
Hi,
>Is there any plan to add this feature to Bluez in near future?
>at least for bluez 5.x time frame?
Yes, I plan to fix it.
Waldek
^ permalink raw reply
* RE: About the BT_SECURITY_HIGH support in Bluez stack
From: braghave @ 2011-04-13 13:38 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: braghave, johan.hedberg, linux-bluetooth
In-Reply-To: <99B09243E1A5DA4898CDD8B70011144810861C42D7@EXMB04.eu.tieto.com>
Hi,
Thanks for the response.
Is there any plan to add this feature to Bluez in near future? at least
for bluez 5.x time frame?
Thanks,
--
Bhaktha
Qualcomm India, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
> Hi,
>
>>> I was looking at the archived conversations below,
>>>
>>> http://marc.info/?t=128290950000001&r=1&w=2
>>>
>>> I see, there is some effort in adding this BT_SECURITY_HIGH suuport
>>> in to the bluez stack, which is a mandatory for the BT SAP profile.
>>>
>>> Could you please, let me know what is the plan to release these
>>> patches as part of Bluez?
>>>
>>> These patches seem to be suffecient. But, may need to add another
>>> D-Bus property to emit to the UI layers to take 16 character
>>PIN code.
>
> Those patches are obsolete as this part has changed significantly.
> Most of this should be supported in kernel and not bluez now.
>
> Waldek
^ permalink raw reply
* RE: About the BT_SECURITY_HIGH support in Bluez stack
From: Waldemar.Rymarkiewicz @ 2011-04-13 10:56 UTC (permalink / raw)
To: braghave, johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <91156ff5702cf87ea80f2285c5c92855.squirrel@www.codeaurora.org>
Hi,
>> I was looking at the archived conversations below,
>>
>> http://marc.info/?t=128290950000001&r=1&w=2
>>
>> I see, there is some effort in adding this BT_SECURITY_HIGH suuport
>> in to the bluez stack, which is a mandatory for the BT SAP profile.
>>
>> Could you please, let me know what is the plan to release these
>> patches as part of Bluez?
>>
>> These patches seem to be suffecient. But, may need to add another
>> D-Bus property to emit to the UI layers to take 16 character
>PIN code.
Those patches are obsolete as this part has changed significantly.
Most of this should be supported in kernel and not bluez now.
Waldek
^ permalink raw reply
* [PATCH] Fix unregistering a2dp sep while it is locked
From: Luiz Augusto von Dentz @ 2011-04-13 9:20 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
If sep is locked it should not be unregistered until properly unlocked.
---
audio/a2dp.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/audio/a2dp.c b/audio/a2dp.c
index 719658b..fe627c1 100644
--- a/audio/a2dp.c
+++ b/audio/a2dp.c
@@ -1741,6 +1741,9 @@ void a2dp_remove_sep(struct a2dp_sep *sep)
}
}
+ if (sep->locked)
+ return;
+
a2dp_unregister_sep(sep);
}
@@ -2342,7 +2345,9 @@ gboolean a2dp_sep_lock(struct a2dp_sep *sep, struct avdtp *session)
gboolean a2dp_sep_unlock(struct a2dp_sep *sep, struct avdtp *session)
{
+ struct a2dp_server *server = sep->server;
avdtp_state_t state;
+ GSList *l;
state = avdtp_sep_get_state(sep->lsep);
@@ -2350,6 +2355,17 @@ gboolean a2dp_sep_unlock(struct a2dp_sep *sep, struct avdtp *session)
DBG("SEP %p unlocked", sep->lsep);
+ if (sep->type == AVDTP_SEP_TYPE_SOURCE)
+ l = server->sources;
+ else
+ l = server->sinks;
+
+ /* Unregister sep if it was removed */
+ if (g_slist_find(l, sep) == NULL) {
+ a2dp_unregister_sep(sep);
+ return TRUE;
+ }
+
if (!sep->stream || state == AVDTP_STATE_IDLE)
return TRUE;
--
1.7.1
^ permalink raw reply related
* Re: About the BT_SECURITY_HIGH support in Bluez stack
From: braghave @ 2011-04-13 7:29 UTC (permalink / raw)
To: braghave; +Cc: linux-bluetooth, waldemar.rymarkiewicz
In-Reply-To: <6274c94659d0fd65491ca3370cf69db4.squirrel@www.codeaurora.org>
Adding the subject,
Thanks,
--
Bhaktha
Qualcomm India, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
> Hi All,
>
> I was looking at the archived conversations below,
>
> http://marc.info/?t=128290950000001&r=1&w=2
>
> I see, there is some effort in adding this BT_SECURITY_HIGH suuport in to
> the bluez
> stack, which is a mandatory for the BT SAP profile.
>
> Could you please, let me know what is the plan to release these patches as
> part of
> Bluez?
>
> These patches seem to be suffecient. But, may need to add another D-Bus
> property to emit to the UI layers to take 16 character PIN code.
>
>
> Thanks,
>
> --
> Bhaktha
>
> Qualcomm India, on behalf of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
> --
>
>
>
^ permalink raw reply
* (no subject)
From: braghave @ 2011-04-13 7:27 UTC (permalink / raw)
To: linux-bluetooth, waldemar.rymarkiewicz
Hi All,
I was looking at the archived conversations below,
http://marc.info/?t=128290950000001&r=1&w=2
I see, there is some effort in adding this BT_SECURITY_HIGH suuport in to
the bluez
stack, which is a mandatory for the BT SAP profile.
Could you please, let me know what is the plan to release these patches as
part of
Bluez?
These patches seem to be suffecient. But, may need to add another D-Bus
property to emit to the UI layers to take 16 character PIN code.
Thanks,
--
Bhaktha
Qualcomm India, on behalf of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
--
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Thomas Gleixner @ 2011-04-12 18:28 UTC (permalink / raw)
To: Gustavo F. Padovan
Cc: Marcel Holtmann, Vinicius Costa Gomes, Keith Packard,
linux-kernel, linux-bluetooth, Ingo Molnar
In-Reply-To: <20110412180933.GA2836@joana>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 557 bytes --]
On Tue, 12 Apr 2011, Gustavo F. Padovan wrote:
> * Gustavo F. Padovan <padovan@profusion.mobi> [2011-04-11 19:25:04 -0300]:
> > * Thomas Gleixner <tglx@linutronix.de> [2011-04-12 00:19:32 +0200]:
> > It is armed at each HCI command we send. In the close path we send out an HCI
> > RESET command that rearms it.
>
> I applied v2 patch from Vinícius that fix all the symptoms. Now we have more time
> to find the real cause of this bug. However I still have no idea, I'm not able
> to reproduce it.
You might poke Ingo. He had a reproducer.
Thanks,
tglx
^ permalink raw reply
* Re: Endless print of uhci_result_common: failed with status 440000
From: Gustavo F. Padovan @ 2011-04-12 18:26 UTC (permalink / raw)
To: Alan Stern
Cc: Zdenek Kabelac, USB list, Linux Kernel Mailing List,
Thomas Gleixner, linux-bluetooth
In-Reply-To: <Pine.LNX.4.44L0.1104121210250.2000-100000@iolanthe.rowland.org>
* Alan Stern <stern@rowland.harvard.edu> [2011-04-12 12:10:56 -0400]:
> On Tue, 12 Apr 2011, Zdenek Kabelac wrote:
>
> > 2011/4/11 Alan Stern <stern@rowland.harvard.edu>:
> > > On Mon, 11 Apr 2011, Zdenek Kabelac wrote:
> > >
> > >> > I've created:
> > >> >
> > >> > https://bugzilla.kernel.org/show_bug.cgi?id=33062
> > >> >
> > >> > and I'm cc-ing linux-bluetooth.
> > >> >
> > >>
> > >> In fact this Ooops might be related to:
> > >>
> > >> http://marc.info/?l=linux-kernel&m=130207593728273&w=2
> > >
> > > It might be. ?Did you try reverting the patch mentioned in that email?
> > >
> >
> > Yep - it looks like the patch
> > http://marc.info/?l=linux-bluetooth&m=130230770920378&w=2
> > solved my problem with weird deadlocks.
I pushed a patch that fixes this in a better way, it's on the bluetooth-2.6
tree (should arrive to linus tree in some days).
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: 2.6.39-rc2 regression: X201s fails to resume b77dcf8460ae57d4eb9fd3633eb4f97b8fb20716
From: Gustavo F. Padovan @ 2011-04-12 18:09 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Marcel Holtmann, Vinicius Costa Gomes, Keith Packard,
linux-kernel, linux-bluetooth
In-Reply-To: <20110411222504.GE2195@joana>
* Gustavo F. Padovan <padovan@profusion.mobi> [2011-04-11 19:25:04 -0300]:
> * Thomas Gleixner <tglx@linutronix.de> [2011-04-12 00:19:32 +0200]:
>=20
> > On Tue, 12 Apr 2011, Thomas Gleixner wrote:
> > > On Mon, 11 Apr 2011, Marcel Holtmann wrote:
> > >=20
> > > > Hi Thomas,
> > > >=20
> > > > > > > > Can the bluetooth folks please have a look at that ASAP? Th=
e obvious
> > > > > > > > fast fix for Linus tree is to revert the second hunk for no=
w, but this
> > > > > > > > needs to be fixed proper.
> > > > > > >=20
> > > > > > > Who will submit this patch? I'd rather have your name on it s=
o that
> > > > > > > people come complain at you...
> > > > > >=20
> > > > > > I took a shot at it and just sent a patch (also attached for co=
nvenience)=20
> > > > > > that should solve the problem.
> > > > >=20
> > > > > Aaarg. No. That patch reverts both hunks.
> > > > >=20
> > > > > --- a/net/bluetooth/hci_core.c
> > > > > +++ b/net/bluetooth/hci_core.c
> > > > > @@ -586,9 +586,6 @@ static int hci_dev_do_close(struct hci_dev *h=
dev)
> > > > > hci_req_cancel(hdev, ENODEV);
> > > > > hci_req_lock(hdev);
> > > > > =20
> > > > > - /* Stop timer, it might be running */
> > > > > - del_timer_sync(&hdev->cmd_timer);
> > > > > -
> > > > > if (!test_and_clear_bit(HCI_UP, &hdev->flags)) {
> > > > > hci_req_unlock(hdev);
> > > > > return 0;
> > > > >=20
> > > > > As I said before you need that first hunk to stay for the case wh=
ere
> > > > > there is no device up and you return via the !HCI_UP check. You j=
ust
> > > > > moved back to the state before as the stupid timer is active for
> > > > > whatever reason even when HCI_UP is not set.
> > > >=20
> > > > if I read this right then we have the case that we arm this timer f=
or no
> > > > real reason. A device in !HCI_UP should have nothing running. Certa=
inly
> > > > not the cmd_timer since it will never process any commands.
> > > >=20
> > > > According to Gustavo, the problem is really in the hci_reset logic =
were
> > > > we arm the timer even when shutting down the device.
> > >=20
> > > The reason why the original patch was sent is, that the timer was
> > > running when the thing went out via the !HCI_UP path, which caused the
> > > whole thing to explode in the first place. I had no time to figure out
> > > why, but moving the del_timer_sync above the
> > > if (!test_and_clear_bit(HCI_UP, &hdev->flags)) solved it.
> >=20
> > Oops. Hit send too fast.
> >=20
> > Then it broke the resume on Keith machine and reverting just the hunk
> > which disarms the timer in the=20
> >=20
> > if (hdev->sent_cmd) {
> >=20
> > path made both scenarios working. So there are two problems:
> >=20
> > 1) Why do we need the del_timer_sync() above the !HCI_UP check
>=20
> That is still a mysterious to me, the real bug the hiding here. I'm tryin=
g to
> track this down but no luck yet.
>=20
> >=20
> > 2) Why gets the timer rearmed after that
>=20
> It is armed at each HCI command we send. In the close path we send out an=
HCI
> RESET command that rearms it.
I applied v2 patch from Vin=EDcius that fix all the symptoms. Now we have m=
ore time
to find the real cause of this bug. However I still have no idea, I'm not a=
ble
to reproduce it.
--=20
Gustavo F. Padovan
http://profusion.mobi
^ 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