* New subscription request to list Bluez-devel from tang705@yahoo.com.cn
From: bluez-devel-owner @ 2010-08-26 2:57 UTC (permalink / raw)
To: bluez-devel-owner
Your authorization is required for a mailing list subscription request
approval:
For: tang705@yahoo.com.cn
List: bluez-devel@lists.sourceforge.net
At your convenience, visit:
https://lists.sourceforge.net/lists/admindb/bluez-devel
to process the request.
^ permalink raw reply
* Re: [PATCH 02/22] Add eL2cap new features macro definition
From: haijun liu @ 2010-08-26 6:59 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100826010116.GC16062@vigoh>
Hi Gustavo,
On Thu, Aug 26, 2010 at 9:01 AM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
>
> We don't need the L2CAP_FEAT_RESERVED here.
>
Thank you, we'll remove it.
^ permalink raw reply
* [PATCH] Fix handling empty fields in VCARDs
From: Lukasz Pawlik @ 2010-08-26 7:45 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-handling-empty-fields-in-VCARDs.patch --]
[-- Type: text/x-patch, Size: 5038 bytes --]
From 4bb29cdaf4a9923ab62973c38914ebb67f718d64 Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Thu, 26 Aug 2010 09:10:26 +0200
Subject: [PATCH] Fix handling empty fields in VCARDs
Previously even mandatory TEL field was not printed in VCARD if it was
empty. This patch fix this. Now tag TEL will be printed if phone number
is not set in phonebook. This patch also fix handling category string
for VCARDs in version 2.1 for url field.
---
plugins/vcard.c | 51 ++++++++++++++++++++++++++++++++-------------------
1 files changed, 32 insertions(+), 19 deletions(-)
diff --git a/plugins/vcard.c b/plugins/vcard.c
index a20ab4d..a163d1b 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -256,7 +256,7 @@ static void vcard_printf_number(GString *vcards, uint8_t format,
vcard_printf(vcards, buf, number);
}
-static void vcard_printf_tag(GString *vcards, const char *tag,
+static void vcard_printf_tag(GString *vcards, uint8_t format, const char *tag,
const char *category, const char *fld)
{
char *separator = "", *type = "";
@@ -265,9 +265,10 @@ static void vcard_printf_tag(GString *vcards, const char *tag,
if (tag == NULL || strlen(tag) == 0)
return;
- if (fld == NULL || strlen(fld) == 0)
+ if (fld == NULL || strlen(fld) == 0){
+ vcard_printf(vcards, "%s:", tag);
return;
-
+ }
if (category && strlen(category)) {
separator = ";";
type = "TYPE=";
@@ -280,8 +281,9 @@ static void vcard_printf_tag(GString *vcards, const char *tag,
vcard_printf(vcards, "%s:%s", buf, fld);
}
-static void vcard_printf_slash_tag(GString *vcards, const char *tag,
- const char *category, const char *fld)
+static void vcard_printf_slash_tag(GString *vcards, uint8_t format,
+ const char *tag, const char *category,
+ const char *fld)
{
int len;
char *separator = "", *type = "";
@@ -290,9 +292,10 @@ static void vcard_printf_slash_tag(GString *vcards, const char *tag,
if (tag == NULL || strlen(tag) == 0)
return;
- if (fld == NULL || (len = strlen(fld)) == 0)
+ if (fld == NULL || (len = strlen(fld)) == 0){
+ vcard_printf(vcards, "%s:", tag);
return;
-
+ }
if (category && strlen(category)) {
separator = ";";
type = "TYPE=";
@@ -314,9 +317,10 @@ static void vcard_printf_email(GString *vcards, uint8_t format,
char field[LEN_MAX];
int len = 0;
- if (!address || !(len = strlen(address)))
+ if (!address || !(len = strlen(address))){
+ vcard_printf(vcards, "EMAIL:");
return;
-
+ }
switch (category){
case EMAIL_TYPE_HOME:
if (format == FORMAT_VCARD21)
@@ -358,9 +362,10 @@ static gboolean org_fields_present(struct phonebook_contact *contact)
static void vcard_printf_org(GString *vcards,
struct phonebook_contact *contact)
{
- if (org_fields_present(contact) == FALSE)
+ if (org_fields_present(contact) == FALSE){
+ vcard_printf(vcards, "ORG:");
return;
-
+ }
vcard_printf(vcards, "ORG:%s;%s;%s", contact->company,
contact->department, contact->title);
}
@@ -428,9 +433,13 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_fullname(vcards, contact->fullname);
if (filter & FILTER_TEL) {
- GSList *l;
+ GSList *l = contact->numbers;
- for (l = contact->numbers; l; l = l->next) {
+ if (g_slist_length(l) == 0)
+ vcard_printf_number(vcards, format, NULL, 1,
+ TEL_TYPE_OTHER);
+
+ for (; l; l = l->next) {
struct phonebook_number *number = l->data;
vcard_printf_number(vcards, format, number->tel, 1,
@@ -439,9 +448,13 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
}
if (filter & FILTER_EMAIL) {
- GSList *l;
+ GSList *l = contact->emails;
+
+ if (g_slist_length(l) == 0)
+ vcard_printf_email(vcards, format, NULL,
+ EMAIL_TYPE_OTHER);
- for (l = contact->emails; l; l = l->next){
+ for (; l; l = l->next){
struct phonebook_email *email = l->data;
vcard_printf_email(vcards, format, email->address, email->type);
@@ -452,18 +465,18 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_adr(vcards, contact);
if (filter & FILTER_BDAY)
- vcard_printf_tag(vcards, "BDAY", NULL, contact->birthday);
+ vcard_printf_tag(vcards, format, "BDAY", NULL, contact->birthday);
if (filter & FILTER_NICKNAME)
- vcard_printf_slash_tag(vcards, "NICKNAME", NULL,
+ vcard_printf_slash_tag(vcards, format, "NICKNAME", NULL,
contact->nickname);
if (filter & FILTER_URL)
- vcard_printf_slash_tag(vcards, "URL", "INTERNET",
+ vcard_printf_slash_tag(vcards, format, "URL", "INTERNET",
contact->website);
if (filter & FILTER_PHOTO)
- vcard_printf_tag(vcards, "PHOTO", NULL, contact->photo);
+ vcard_printf_tag(vcards, format, "PHOTO", NULL, contact->photo);
if (filter & FILTER_ORG)
vcard_printf_org(vcards, contact);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Fix handling empty fields in VCARDs
From: Johan Hedberg @ 2010-08-26 8:15 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimB9Tvxt6zZKzfHwhGc_j8MnGTo1DbeH-pYoQpe@mail.gmail.com>
Hi Lukasz,
> From 4bb29cdaf4a9923ab62973c38914ebb67f718d64 Mon Sep 17 00:00:00 2001
> From: Lukasz Pawlik <lucas.pawlik@gmail.com>
> Date: Thu, 26 Aug 2010 09:10:26 +0200
> Subject: [PATCH] Fix handling empty fields in VCARDs
>
> Previously even mandatory TEL field was not printed in VCARD if it was
> empty. This patch fix this. Now tag TEL will be printed if phone number
> is not set in phonebook. This patch also fix handling category string
> for VCARDs in version 2.1 for url field.
> ---
> plugins/vcard.c | 51 ++++++++++++++++++++++++++++++++-------------------
> 1 files changed, 32 insertions(+), 19 deletions(-)
In general the patch seems fine, but you need to fix your editor
settings when dealing with BlueZ code. It seems like you're using spaces
for indentation when the coding style is tabs-only:
> - for (l = contact->numbers; l; l = l->next) {
> + if (g_slist_length(l) == 0)
> + vcard_printf_number(vcards, format, NULL, 1,
> + TEL_TYPE_OTHER);
All of the above three added lines are indented with spaces.
> + for (; l; l = l->next) {
This added line is indented with tabs. How did you manage to get your
editor to produce such mixed results?
> + if (g_slist_length(l) == 0)
> + vcard_printf_email(vcards, format, NULL,
> + EMAIL_TYPE_OTHER);
The first line is tabs but the two others use spaces!?
> - for (l = contact->emails; l; l = l->next){
> + for (; l; l = l->next){
Again spaces here.
Please enable whitespace visualization and use proper editor settings to
avoid these issues in the future. Thanks.
Johan
^ permalink raw reply
* [PATCH] Fix handling empty fields in VCARDs
From: Lukasz Pawlik @ 2010-08-26 9:48 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Fix-handling-empty-fields-in-VCARDs.patch --]
[-- Type: text/x-patch, Size: 5044 bytes --]
From c9a89b18acf88ac0546ba72d0a169d9c2f18656d Mon Sep 17 00:00:00 2001
From: Lukasz Pawlik <lucas.pawlik@gmail.com>
Date: Thu, 26 Aug 2010 11:33:33 +0200
Subject: [PATCH] Fix handling empty fields in VCARDs
Previously even mandatory TEL field was not printed in VCARD if it was
empty. This patch fix this. Now tag TEL will be printed if phone number
is not set in phonebook. This patch also fix handling category string
for VCARDs in version 2.1 for url field.
---
plugins/vcard.c | 54 ++++++++++++++++++++++++++++++++++++------------------
1 files changed, 36 insertions(+), 18 deletions(-)
diff --git a/plugins/vcard.c b/plugins/vcard.c
index a20ab4d..c4c4c5a 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -256,7 +256,7 @@ static void vcard_printf_number(GString *vcards, uint8_t format,
vcard_printf(vcards, buf, number);
}
-static void vcard_printf_tag(GString *vcards, const char *tag,
+static void vcard_printf_tag(GString *vcards, uint8_t format, const char *tag,
const char *category, const char *fld)
{
char *separator = "", *type = "";
@@ -265,12 +265,15 @@ static void vcard_printf_tag(GString *vcards, const char *tag,
if (tag == NULL || strlen(tag) == 0)
return;
- if (fld == NULL || strlen(fld) == 0)
+ if (fld == NULL || strlen(fld) == 0){
+ vcard_printf(vcards, "%s:", tag);
return;
+ }
if (category && strlen(category)) {
separator = ";";
- type = "TYPE=";
+ if (format == FORMAT_VCARD30)
+ type = "TYPE=";
} else {
category = "";
}
@@ -280,8 +283,9 @@ static void vcard_printf_tag(GString *vcards, const char *tag,
vcard_printf(vcards, "%s:%s", buf, fld);
}
-static void vcard_printf_slash_tag(GString *vcards, const char *tag,
- const char *category, const char *fld)
+static void vcard_printf_slash_tag(GString *vcards, uint8_t format,
+ const char *tag, const char *category,
+ const char *fld)
{
int len;
char *separator = "", *type = "";
@@ -290,12 +294,15 @@ static void vcard_printf_slash_tag(GString *vcards, const char *tag,
if (tag == NULL || strlen(tag) == 0)
return;
- if (fld == NULL || (len = strlen(fld)) == 0)
+ if (fld == NULL || (len = strlen(fld)) == 0){
+ vcard_printf(vcards, "%s:", tag);
return;
+ }
if (category && strlen(category)) {
separator = ";";
- type = "TYPE=";
+ if (format == FORMAT_VCARD30)
+ type = "TYPE=";
} else {
category = "";
}
@@ -314,9 +321,10 @@ static void vcard_printf_email(GString *vcards, uint8_t format,
char field[LEN_MAX];
int len = 0;
- if (!address || !(len = strlen(address)))
+ if (!address || !(len = strlen(address))){
+ vcard_printf(vcards, "EMAIL:");
return;
-
+ }
switch (category){
case EMAIL_TYPE_HOME:
if (format == FORMAT_VCARD21)
@@ -358,8 +366,10 @@ static gboolean org_fields_present(struct phonebook_contact *contact)
static void vcard_printf_org(GString *vcards,
struct phonebook_contact *contact)
{
- if (org_fields_present(contact) == FALSE)
+ if (org_fields_present(contact) == FALSE){
+ vcard_printf(vcards, "ORG:");
return;
+ }
vcard_printf(vcards, "ORG:%s;%s;%s", contact->company,
contact->department, contact->title);
@@ -428,9 +438,13 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_fullname(vcards, contact->fullname);
if (filter & FILTER_TEL) {
- GSList *l;
+ GSList *l = contact->numbers;
- for (l = contact->numbers; l; l = l->next) {
+ if (g_slist_length(l) == 0)
+ vcard_printf_number(vcards, format, NULL, 1,
+ TEL_TYPE_OTHER);
+
+ for (; l; l = l->next) {
struct phonebook_number *number = l->data;
vcard_printf_number(vcards, format, number->tel, 1,
@@ -439,9 +453,13 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
}
if (filter & FILTER_EMAIL) {
- GSList *l;
+ GSList *l = contact->emails;
+
+ if (g_slist_length(l) == 0)
+ vcard_printf_email(vcards, format, NULL,
+ EMAIL_TYPE_OTHER);
- for (l = contact->emails; l; l = l->next){
+ for (; l; l = l->next){
struct phonebook_email *email = l->data;
vcard_printf_email(vcards, format, email->address, email->type);
@@ -452,18 +470,18 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
vcard_printf_adr(vcards, contact);
if (filter & FILTER_BDAY)
- vcard_printf_tag(vcards, "BDAY", NULL, contact->birthday);
+ vcard_printf_tag(vcards, format, "BDAY", NULL, contact->birthday);
if (filter & FILTER_NICKNAME)
- vcard_printf_slash_tag(vcards, "NICKNAME", NULL,
+ vcard_printf_slash_tag(vcards, format, "NICKNAME", NULL,
contact->nickname);
if (filter & FILTER_URL)
- vcard_printf_slash_tag(vcards, "URL", "INTERNET",
+ vcard_printf_slash_tag(vcards, format, "URL", "INTERNET",
contact->website);
if (filter & FILTER_PHOTO)
- vcard_printf_tag(vcards, "PHOTO", NULL, contact->photo);
+ vcard_printf_tag(vcards, format, "PHOTO", NULL, contact->photo);
if (filter & FILTER_ORG)
vcard_printf_org(vcards, contact);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 13/22] Add three new options for l2cap_options which used in setsockopt & getsockopt
From: David Vrabel @ 2010-08-26 10:41 UTC (permalink / raw)
To: haijun liu; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=8xVks--xcLXEQ_=sHfP3fY+Wvyctu5K_kMDG-@mail.gmail.com>
haijun liu wrote:
> From 897b281d14ba4cf9a5fbbf5ba65b84c85e688737 Mon Sep 17 00:00:00 2001
> From: haijun.liu <haijun.liu@atheros.com>
> Date: Mon, 23 Aug 2010 00:00:26 +0800
> Subject: [PATCH 13/22] Add three new options for l2cap_options which
> used in setsockopt & getsockopt.
>
> ---
> include/net/bluetooth/l2cap.h | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index d0ae9f5..4f87aec 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -65,6 +65,9 @@ struct l2cap_options {
> __u8 fcs;
> __u8 max_tx;
> __u16 txwin_size;
> + __u8 hschan_req;
This isn't the API that was agreed. See Mat Martineau's "Bluetooth:
Add socket option definitions for AMP" patch.
> + __u8 guaranteed;
Selecting guaranteed without being able to specify flow specs doesn't
seem useful.
I would like to see support for best-effort links merged first before
guaranteed links are considered.
> + __u8 reconfig;
I'd suggest removing this unless there's a profile/application that will
make use of it. I'd have thought that channel reconfiguration was
something the L2CAP stack does automatically when moving channels
between BR/EDR and AMP radios.
> };
David
--
David Vrabel, Senior Software Engineer, Drivers
CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562
Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/
Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
^ permalink raw reply
* Re: [PATCH] Fix handling empty fields in VCARDs
From: Johan Hedberg @ 2010-08-26 11:28 UTC (permalink / raw)
To: Lukasz Pawlik; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimN_hk1n7rDSBMpDP4-7ECV-4fm0NqHHwz0VBjo@mail.gmail.com>
Hi Lukasz,
On Thu, Aug 26, 2010, Lukasz Pawlik wrote:
> From c9a89b18acf88ac0546ba72d0a169d9c2f18656d Mon Sep 17 00:00:00 2001
> From: Lukasz Pawlik <lucas.pawlik@gmail.com>
> Date: Thu, 26 Aug 2010 11:33:33 +0200
> Subject: [PATCH] Fix handling empty fields in VCARDs
>
> Previously even mandatory TEL field was not printed in VCARD if it was
> empty. This patch fix this. Now tag TEL will be printed if phone number
> is not set in phonebook. This patch also fix handling category string
> for VCARDs in version 2.1 for url field.
> ---
> plugins/vcard.c | 54 ++++++++++++++++++++++++++++++++++++------------------
> 1 files changed, 36 insertions(+), 18 deletions(-)
Thanks. The patch is now upstream. Btw, it's written vCard and not VCARD
(I fixed this for you manually).
Johan
^ permalink raw reply
* [PATCH] Bluetooth: BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar Rymarkiewicz @ 2010-08-27 11:44 UTC (permalink / raw)
To: linux-bluetooth
Cc: par-gunnar.p.hjalmdahl, joakim.xj.ceder, johan.hedberg,
Waldemar Rymarkiewicz
The security level BT_SECURITY_HIGH expects secure connection
and a minimum 16 digit pin code used for bonding. It's requitred by the
Sim Access Profile.
Patch on behalf of ST-Ericsson SA.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
include/net/bluetooth/hci.h | 17 +++++++
include/net/bluetooth/hci_core.h | 4 ++
net/bluetooth/hci_conn.c | 97 +++++++++++++++++++++++++++++++-------
net/bluetooth/hci_event.c | 4 ++
net/bluetooth/hci_sock.c | 3 +
net/bluetooth/rfcomm/core.c | 10 ++++-
6 files changed, 116 insertions(+), 19 deletions(-)
mode change 100644 => 100755 include/net/bluetooth/hci.h
mode change 100644 => 100755 include/net/bluetooth/hci_core.h
mode change 100644 => 100755 net/bluetooth/hci_conn.c
mode change 100644 => 100755 net/bluetooth/hci_event.c
mode change 100644 => 100755 net/bluetooth/rfcomm/core.c
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
old mode 100644
new mode 100755
index bcbdd6d..34a6fbf
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -99,6 +99,7 @@ enum {
#define HCISETLINKMODE _IOW('H', 226, int)
#define HCISETACLMTU _IOW('H', 227, int)
#define HCISETSCOMTU _IOW('H', 228, int)
+#define HCISETCONNINFO _IOW('H', 229, int)
#define HCIBLOCKADDR _IOW('H', 230, int)
#define HCIUNBLOCKADDR _IOW('H', 231, int)
@@ -224,6 +225,15 @@ enum {
#define HCI_AT_GENERAL_BONDING 0x04
#define HCI_AT_GENERAL_BONDING_MITM 0x05
+/* Link Key types */
+#define HCI_LK_COMBINATION 0x00
+#define HCI_LK_LOCAL_UNIT 0x01
+#define HCI_LK_REMOTE_UNIT 0x02
+#define HCI_LK_DEBUG_COMBINATION 0x03
+#define HCI_LK_UNAUTHENTICATED_COMBINATION 0x04
+#define HCI_LK_AUTHENTICATED_COMBINATION 0x05
+#define HCI_LK_CHANGEED_COMBINATION_KEY 0x06
+
/* ----- HCI Commands ---- */
#define HCI_OP_INQUIRY 0x0401
struct hci_cp_inquiry {
@@ -1022,9 +1032,16 @@ struct hci_conn_info_req {
struct hci_conn_info conn_info[0];
};
+struct hci_set_conn_info_req {
+ bdaddr_t bdaddr;
+ __u8 pin_len;
+ __u8 key_type;
+};
+
struct hci_auth_info_req {
bdaddr_t bdaddr;
__u8 type;
+ __u8 level;
};
struct hci_inquiry_req {
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
old mode 100644
new mode 100755
index 4568b93..9eb2da3
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -183,6 +183,8 @@ struct hci_conn {
__u32 link_mode;
__u8 auth_type;
__u8 sec_level;
+ __u8 key_type;
+ __u8 pin_len;
__u8 power_save;
__u16 disc_timeout;
unsigned long pend;
@@ -430,6 +432,8 @@ int hci_get_dev_info(void __user *arg);
int hci_get_conn_list(void __user *arg);
int hci_get_conn_info(struct hci_dev *hdev, void __user *arg);
int hci_get_auth_info(struct hci_dev *hdev, void __user *arg);
+int hci_set_conn_info(struct hci_dev *hdev, void __user *arg);
+
int hci_inquiry(void __user *arg);
struct bdaddr_list *hci_blacklist_lookup(struct hci_dev *hdev, bdaddr_t *bdaddr);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
old mode 100644
new mode 100755
index 0b1e460..ed7a007
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -233,6 +233,8 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst)
conn->mode = HCI_CM_ACTIVE;
conn->state = BT_OPEN;
conn->auth_type = HCI_AT_GENERAL_BONDING;
+ conn->key_type = 0xff;
+ conn->pin_len = 0;
conn->power_save = 1;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
@@ -433,15 +435,11 @@ int hci_conn_check_link_mode(struct hci_conn *conn)
EXPORT_SYMBOL(hci_conn_check_link_mode);
/* Authenticate remote device */
-static int hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
+static void hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
{
BT_DBG("conn %p", conn);
- if (sec_level > conn->sec_level)
- conn->sec_level = sec_level;
- else if (conn->link_mode & HCI_LM_AUTH)
- return 1;
-
+ conn->sec_level = sec_level;
conn->auth_type = auth_type;
if (!test_and_set_bit(HCI_CONN_AUTH_PEND, &conn->pend)) {
@@ -450,8 +448,20 @@ static int hci_conn_auth(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
hci_send_cmd(conn->hdev, HCI_OP_AUTH_REQUESTED,
sizeof(cp), &cp);
}
+}
- return 0;
+/* Encrypt the the link */
+static void hci_conn_encrypt(struct hci_conn *conn)
+{
+ BT_DBG("conn %p", conn);
+
+ if (!test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend)) {
+ struct hci_cp_set_conn_encrypt cp;
+ cp.handle = cpu_to_le16(conn->handle);
+ cp.encrypt = 1;
+ hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT,
+ sizeof(cp), &cp);
+ }
}
/* Enable security */
@@ -459,28 +469,54 @@ int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type)
{
BT_DBG("conn %p", conn);
+ /* For sdp we do not need the link key. */
if (sec_level == BT_SECURITY_SDP)
return 1;
+ /* For non 2.1 devices and low security level we do not need the
+ link key. */
if (sec_level == BT_SECURITY_LOW &&
(!conn->ssp_mode || !conn->hdev->ssp_mode))
return 1;
- if (conn->link_mode & HCI_LM_ENCRYPT)
- return hci_conn_auth(conn, sec_level, auth_type);
-
+ /* For other security levels we need link key. */
+ if (!(conn->link_mode & HCI_LM_AUTH))
+ goto do_auth;
+
+ /* An authenticated combination key has sufficient security for any
+ security level. */
+ if (conn->key_type == HCI_LK_AUTHENTICATED_COMBINATION)
+ goto do_encrypt;
+
+ /* An unauthenticated combination key has sufficient security for
+ security level 1 and 2. */
+ if (conn->key_type == HCI_LK_UNAUTHENTICATED_COMBINATION
+ && (sec_level == BT_SECURITY_MEDIUM
+ || sec_level == BT_SECURITY_LOW))
+ goto do_encrypt;
+
+ /* A combination key has always sufficient security for the security
+ levels 1 or 2. High security level requires that the combination key
+ was generated using the maximum PIN code length (16).
+ For pre 2.1 units. */
+ if ((conn->key_type == HCI_LK_COMBINATION))
+ if ((sec_level != BT_SECURITY_HIGH) || (conn->pin_len >= 16))
+ goto do_encrypt;
+
+do_auth:
if (test_and_set_bit(HCI_CONN_ENCRYPT_PEND, &conn->pend))
return 0;
- if (hci_conn_auth(conn, sec_level, auth_type)) {
- struct hci_cp_set_conn_encrypt cp;
- cp.handle = cpu_to_le16(conn->handle);
- cp.encrypt = 1;
- hci_send_cmd(conn->hdev, HCI_OP_SET_CONN_ENCRYPT,
- sizeof(cp), &cp);
- }
-
+ hci_conn_auth(conn, sec_level, auth_type);
return 0;
+
+do_encrypt:
+ if (conn->link_mode & HCI_LM_ENCRYPT)
+ return 1; /* sufficient link key */
+ else{
+ hci_conn_encrypt(conn);
+ return 0; /* auth pending */
+ }
}
EXPORT_SYMBOL(hci_conn_security);
@@ -713,6 +749,30 @@ int hci_get_conn_info(struct hci_dev *hdev, void __user *arg)
return copy_to_user(ptr, &ci, sizeof(ci)) ? -EFAULT : 0;
}
+int hci_set_conn_info(struct hci_dev *hdev, void __user *arg)
+{
+ struct hci_set_conn_info_req req;
+ struct hci_conn *conn;
+
+ if (copy_from_user(&req, arg, sizeof(req))) {
+ BT_DBG("copy from user failed");
+ return -EFAULT;
+ }
+
+ hci_dev_lock_bh(hdev);
+ conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &req.bdaddr);
+ if (conn) {
+ conn->pin_len = req.pin_len;
+ conn->key_type = req.key_type;
+ }
+ hci_dev_unlock_bh(hdev);
+
+ if (!conn)
+ return -ENOENT;
+
+ return 0;
+}
+
int hci_get_auth_info(struct hci_dev *hdev, void __user *arg)
{
struct hci_auth_info_req req;
@@ -725,6 +785,7 @@ int hci_get_auth_info(struct hci_dev *hdev, void __user *arg)
conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &req.bdaddr);
if (conn)
req.type = conn->auth_type;
+ req.level = conn->sec_level;
hci_dev_unlock_bh(hdev);
if (!conn)
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
old mode 100644
new mode 100755
index bfef5ba..6d6b04c
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -1521,6 +1521,10 @@ static inline void hci_link_key_notify_evt(struct hci_dev *hdev, struct sk_buff
conn = hci_conn_hash_lookup_ba(hdev, ACL_LINK, &ev->bdaddr);
if (conn) {
hci_conn_hold(conn);
+ /* For Changed Combination Link Key the only link key has
+ * been changed, not link key type. */
+ if (conn->key_type != HCI_LK_CHANGEED_COMBINATION_KEY)
+ conn->key_type = ev->key_type;
conn->disc_timeout = HCI_DISCONN_TIMEOUT;
hci_conn_put(conn);
}
diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index 83acd16..502a7b0 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -269,6 +269,9 @@ static inline int hci_sock_bound_ioctl(struct sock *sk, unsigned int cmd, unsign
case HCIGETCONNINFO:
return hci_get_conn_info(hdev, (void __user *) arg);
+ case HCISETCONNINFO:
+ return hci_set_conn_info(hdev, (void __user *) arg);
+
case HCIGETAUTHINFO:
return hci_get_auth_info(hdev, (void __user *) arg);
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
old mode 100644
new mode 100755
index 7dca91b..2e248d5
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2086,7 +2086,15 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
continue;
if (!status)
- set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+ if (d->sec_level != BT_SECURITY_HIGH)
+ set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+ else
+ if ((conn->key_type == HCI_LK_AUTHENTICATED_COMBINATION)
+ || (conn->key_type == HCI_LK_COMBINATION
+ && conn->pin_len >= 16))
+ set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
+ else
+ set_bit(RFCOMM_AUTH_REJECT, &d->flags);
else
set_bit(RFCOMM_AUTH_REJECT, &d->flags);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar Rymarkiewicz @ 2010-08-27 11:45 UTC (permalink / raw)
To: linux-bluetooth
Cc: par-gunnar.p.hjalmdahl, joakim.xj.ceder, johan.hedberg,
Waldemar Rymarkiewicz
The security level BT_SECURITY_HIGH expects secure connection
and a minimum 16 digit pin code used for bonding. It's requitred by the
Sim Access Profile.
Patch on behalf of ST-Ericsson SA.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
lib/hci.h | 8 +++++++-
src/dbus-hci.c | 33 ++++++++++++++++++++++++++++-----
src/security.c | 38 ++++++++++++++++++++++++++++++++++----
3 files changed, 69 insertions(+), 10 deletions(-)
mode change 100644 => 100755 lib/bluetooth.h
mode change 100644 => 100755 lib/hci.h
mode change 100644 => 100755 lib/l2cap.h
mode change 100644 => 100755 lib/rfcomm.h
mode change 100644 => 100755 src/btio.c
mode change 100644 => 100755 src/btio.h
mode change 100644 => 100755 src/dbus-hci.c
mode change 100644 => 100755 src/security.c
diff --git a/lib/bluetooth.h b/lib/bluetooth.h
old mode 100644
new mode 100755
diff --git a/lib/hci.h b/lib/hci.h
old mode 100644
new mode 100755
index 512dab9..a313929
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -96,7 +96,7 @@ enum {
#define HCISETLINKMODE _IOW('H', 226, int)
#define HCISETACLMTU _IOW('H', 227, int)
#define HCISETSCOMTU _IOW('H', 228, int)
-
+#define HCISETCONNINFO _IOW('H', 229, int)
#define HCIBLOCKADDR _IOW('H', 230, int)
#define HCIUNBLOCKADDR _IOW('H', 231, int)
@@ -2326,9 +2326,15 @@ struct hci_conn_info_req {
struct hci_conn_info conn_info[0];
};
+struct hci_set_conn_info_req {
+ bdaddr_t bdaddr;
+ uint8_t pin_len;
+ uint8_t key_type;
+};
struct hci_auth_info_req {
bdaddr_t bdaddr;
uint8_t type;
+ uint8_t level;
};
struct hci_inquiry_req {
diff --git a/lib/l2cap.h b/lib/l2cap.h
old mode 100644
new mode 100755
diff --git a/lib/rfcomm.h b/lib/rfcomm.h
old mode 100644
new mode 100755
diff --git a/src/btio.c b/src/btio.c
old mode 100644
new mode 100755
diff --git a/src/btio.h b/src/btio.h
old mode 100644
new mode 100755
diff --git a/src/dbus-hci.c b/src/dbus-hci.c
old mode 100644
new mode 100755
index 9055ffe..177f536
--- a/src/dbus-hci.c
+++ b/src/dbus-hci.c
@@ -165,6 +165,8 @@ static void pincode_cb(struct agent *agent, DBusError *err,
{
struct btd_adapter *adapter = device_get_adapter(device);
pin_code_reply_cp pr;
+ struct hci_auth_info_req ar;
+ struct hci_set_conn_info_req cr;
bdaddr_t sba, dba;
size_t len;
int dev;
@@ -180,13 +182,30 @@ static void pincode_cb(struct agent *agent, DBusError *err,
adapter_get_address(adapter, &sba);
device_get_address(device, &dba);
- if (err) {
- hci_send_cmd(dev, OGF_LINK_CTL,
- OCF_PIN_CODE_NEG_REPLY, 6, &dba);
- goto done;
- }
+ if (err)
+ goto reject;
len = strlen(pincode);
+ memset(&ar, 0, sizeof(ar));
+ bacpy(&ar.bdaddr, &dba);
+ if (ioctl(dev, HCIGETAUTHINFO, (unsigned long) &ar) < 0) {
+ error("Can't get auth info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
+
+ if (ar.level == BT_SECURITY_HIGH && len < 16) {
+ error("Not enough secure PIN (expected 16 digit PIN, but got \
+ %d digit).", len);
+ goto reject;
+ }
+
+ bacpy(&cr.bdaddr, &dba);
+ cr.pin_len = len;
+ cr.key_type = 0xff;
+ if (ioctl(dev, HCISETCONNINFO, (unsigned long) &cr) < 0) {
+ error("Can't set conn info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
set_pin_length(&sba, len);
@@ -196,7 +215,11 @@ static void pincode_cb(struct agent *agent, DBusError *err,
pr.pin_len = len;
hci_send_cmd(dev, OGF_LINK_CTL, OCF_PIN_CODE_REPLY,
PIN_CODE_REPLY_CP_SIZE, &pr);
+ goto done;
+reject:
+ hci_send_cmd(dev, OGF_LINK_CTL,
+ OCF_PIN_CODE_NEG_REPLY, 6, &dba);
done:
hci_close_dev(dev);
}
diff --git a/src/security.c b/src/security.c
old mode 100644
new mode 100755
index 667f1f1..b25d1e4
--- a/src/security.c
+++ b/src/security.c
@@ -309,6 +309,7 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
char sa[18], da[18];
uint8_t type;
int err;
+ int pinlen;
if (!get_adapter_and_device(sba, dba, &adapter, &device, FALSE))
device = NULL;
@@ -325,9 +326,11 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
DBG("HCIGETAUTHINFO failed %s (%d)",
strerror(errno), errno);
req.type = 0x00;
+ req.level = BT_SECURITY_LOW;
}
- DBG("kernel auth requirements = 0x%02x", req.type);
+ DBG("kernel auth requirements = 0x%02x and security level = 0x%02x", \
+ req.type, req.level);
if (main_opts.debug_keys && device && device_get_debug_key(device, key))
type = 0x03;
@@ -341,18 +344,34 @@ static void link_key_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
DBG("link key type = 0x%02x", type);
+ pinlen = read_pin_length(sba, dba);
+ DBG("stored link key type = 0x%02x pin_len = %d", type, pinlen);
+
/* Don't use unauthenticated combination keys if MITM is
- * required */
- if (type == 0x04 && req.type != 0xff && (req.type & 0x01))
+ * required and also don't use combination link keys authenticated with
+ * an PIN code len < 16 if security level BT_SECURITY_HIGH is required*/
+ if ((type == 0x04 && req.type != 0xff && (req.type & 0x01)) ||
+ (type == 0x00 && req.level == BT_SECURITY_HIGH && pinlen < 16))
hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY,
6, dba);
else {
link_key_reply_cp lr;
+ struct hci_set_conn_info_req cr;
memcpy(lr.link_key, key, 16);
bacpy(&lr.bdaddr, dba);
- hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_REPLY,
+ bacpy(&cr.bdaddr, dba);
+ cr.pin_len = pinlen;
+ cr.key_type = type;
+
+ if (ioctl(dev, HCISETCONNINFO, (unsigned long) &cr) < 0) {
+ error("Can't set conn info: %s (%d)", strerror(errno),
+ errno);
+ hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_NEG_REPLY,
+ 6, dba);
+ } else
+ hci_send_cmd(dev, OGF_LINK_CTL, OCF_LINK_KEY_REPLY,
LINK_KEY_REPLY_CP_SIZE, &lr);
}
}
@@ -523,6 +542,7 @@ static void pin_code_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
pin_code_reply_cp pr;
struct hci_conn_info_req *cr;
struct hci_conn_info *ci;
+ struct hci_auth_info_req ar;
char sa[18], da[18], pin[17];
int pinlen;
@@ -542,10 +562,20 @@ static void pin_code_request(int dev, bdaddr_t *sba, bdaddr_t *dba)
}
ci = cr->conn_info;
+ memset(&ar, 0, sizeof(ar));
+ bacpy(&ar.bdaddr, dba);
+ if (ioctl(dev, HCIGETAUTHINFO, (unsigned long) &ar) < 0) {
+ error("Can't get auth info: %s (%d)", strerror(errno), errno);
+ goto reject;
+ }
memset(pin, 0, sizeof(pin));
pinlen = read_pin_code(sba, dba, pin);
if (pinlen > 0) {
+ if (ar.level == BT_SECURITY_HIGH && pinlen < 16) {
+ error("Not 16 digit pin code.");
+ goto reject;
+ }
set_pin_length(sba, pinlen);
memcpy(pr.pin_code, pin, pinlen);
pr.pin_len = pinlen;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Bastien Nocera @ 2010-08-27 12:12 UTC (permalink / raw)
To: Waldemar Rymarkiewicz
Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
johan.hedberg
In-Reply-To: <1282909526-19374-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
On Fri, 2010-08-27 at 13:45 +0200, Waldemar Rymarkiewicz wrote:
> The security level BT_SECURITY_HIGH expects secure connection
> and a minimum 16 digit pin code used for bonding. It's requitred by the
> Sim Access Profile.
How is user-space (meaning the pairing agent) supposed to handle that?
I'd need to make changes to gnome-bluetooth to use longer PIN codes for
the maximum security.
Cheers
^ permalink raw reply
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-08-27 12:26 UTC (permalink / raw)
To: hadess
Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
johan.hedberg, arunkr.singh
In-Reply-To: <1282911133.835.30.camel@localhost.localdomain>
Hi,
>-----Original Message-----
>From: Bastien Nocera [mailto:hadess@hadess.net]
>Sent: Friday, August 27, 2010 2:12 PM
>To: Rymarkiewicz Waldemar
>Cc: linux-bluetooth@vger.kernel.org;
>par-gunnar.p.hjalmdahl@stericsson.com;
>joakim.xj.ceder@stericsson.com; johan.hedberg@gmail.com
>Subject: Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
>
>On Fri, 2010-08-27 at 13:45 +0200, Waldemar Rymarkiewicz wrote:
>> The security level BT_SECURITY_HIGH expects secure connection and a
>> minimum 16 digit pin code used for bonding. It's requitred
>by the Sim
>> Access Profile.
>
>How is user-space (meaning the pairing agent) supposed to handle that?
>I'd need to make changes to gnome-bluetooth to use longer PIN
>codes for the maximum security.
>
>Cheers
>
I assume that user will know that the 16 digit pin is requred, so should be enough to let the user type 16 digit in an agent I guess.
Usually a service that requires high security will generate right pin code.
Originaly the high security level was planned to require max pin code lenght as I know.
Thanks,
/Waldek
^ permalink raw reply
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Bastien Nocera @ 2010-08-27 12:32 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
johan.hedberg, arunkr.singh
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480976E15A2C@EXMB04.eu.tieto.com>
On Fri, 2010-08-27 at 15:26 +0300, Waldemar.Rymarkiewicz@tieto.com
wrote:
> Hi,
>
> >-----Original Message-----
> >From: Bastien Nocera [mailto:hadess@hadess.net]
> >Sent: Friday, August 27, 2010 2:12 PM
> >To: Rymarkiewicz Waldemar
> >Cc: linux-bluetooth@vger.kernel.org;
> >par-gunnar.p.hjalmdahl@stericsson.com;
> >joakim.xj.ceder@stericsson.com; johan.hedberg@gmail.com
> >Subject: Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
> >
> >On Fri, 2010-08-27 at 13:45 +0200, Waldemar Rymarkiewicz wrote:
> >> The security level BT_SECURITY_HIGH expects secure connection and a
> >> minimum 16 digit pin code used for bonding. It's requitred
> >by the Sim
> >> Access Profile.
> >
> >How is user-space (meaning the pairing agent) supposed to handle that?
> >I'd need to make changes to gnome-bluetooth to use longer PIN
> >codes for the maximum security.
> >
> >Cheers
> >
>
> I assume that user will know that the 16 digit pin is requred, so
> should be enough to let the user type 16 digit in an agent I guess.
> Usually a service that requires high security will generate right pin
> code.
How would they know? Pairing the device isn't connecting to the
service... Furthermore, gnome-bluetooth's wizard takes a lot of care
generating pin codes for the user by default, so we'd need to know that
a 16 digit pin code is required.
Supporting 16 digits pin code would probably require interface changes.
And I was under the impression that the PIN code's length didn't come
into account for the creation of the encryption, just for the initial
challenge-response needed to verify the device is who it says it is.
> Originaly the high security level was planned to require max pin code
> lenght as I know.
^ permalink raw reply
* Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Johan Hedberg @ 2010-08-27 12:45 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480976E15A2C@EXMB04.eu.tieto.com>
Hi Waldemar,
On Fri, Aug 27, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> I assume that user will know that the 16 digit pin is requred, so
> should be enough to let the user type 16 digit in an agent I guess.
> Usually a service that requires high security will generate right pin
> code.
I don't think "the user should know" is enough here, so we may need to
think about ways that we could relay this info to the agent (maybe a
special adapter property or an extra parameter in the PIN request agent
callback).
> Originaly the high security level was planned to require max pin code
> lenght as I know.
That's correct, however the UI side hasn't really been considered so
far.
In general about the patches, I suspect it'll take a bit longer than
usual to get them in since the code you're touching is one of the most
sensitive ones with respect to breakage. We've finetuned it multiple
times over the last few years to get rid of IOP issues, security
vulnerabilities and to make sure all qualification tests pass. Another
reason for an expected delay is that you're introducing changes to the
kernel interface and that always requires some extra reviewing.
So how well have you tested the patches? I.e. how confident are you that
you're not introducing any regressions? Scenarios that would need to be
tested before an upstream merge are (and I'm probably forgetting several
of them):
- legacy pairing acceptor & initiator
- security mode 3 acceptor & initiator
- ssp acceptor & initiator
- renewed link key handling for both debug and normal keys
- security level upgrading (i.e. connect first to a low security socket
and then over the same ACL to a higher security socket)
- complete and partial failure scenarios for all of the above
Additionally all these test should be done against several different
controllers due to differences in HCI interface behavior (event
ordering, error codes, etc). In that list I'd include at least one CSR,
and one Broadcom adapter and any other adapters from other manufacturers
that you can get hold of.
So how many of these tests do you already have covered? I'm not very
comfortable with pushing the patches upstream before most of the above
scenarios have been tested and verified not to introduce any
regressions.
Johan
^ permalink raw reply
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-08-27 13:32 UTC (permalink / raw)
To: johan.hedberg
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <20100827124524.GA9484@jh-x301>
Johan,
>-----Original Message-----
>From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
>Sent: Friday, August 27, 2010 2:45 PM
>Hi Waldemar,
>
>On Fri, Aug 27, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
>> I assume that user will know that the 16 digit pin is requred, so
>> should be enough to let the user type 16 digit in an agent I guess.
>> Usually a service that requires high security will generate
>right pin
>> code.
>
>I don't think "the user should know" is enough here, so we may
>need to think about ways that we could relay this info to the
>agent (maybe a special adapter property or an extra parameter
>in the PIN request agent callback).
I agree and I guess adding a new property is more convenient then braking existing agen api.
>> Originaly the high security level was planned to require max
>pin code
>> lenght as I know.
>
>That's correct, however the UI side hasn't really been
>considered so far.
>
>In general about the patches, I suspect it'll take a bit
>longer than usual to get them in since the code you're
>touching is one of the most sensitive ones with respect to
>breakage. We've finetuned it multiple times over the last few
>years to get rid of IOP issues, security vulnerabilities and
>to make sure all qualification tests pass. Another reason for
>an expected delay is that you're introducing changes to the
>kernel interface and that always requires some extra reviewing.
I'm aware of that and I actually expected delay. Sending those patches I have been rather more interesting in starting some disscution on this topic, then get it up streamed now.
>So how well have you tested the patches? I.e. how confident
>are you that you're not introducing any regressions? Scenarios
>that would need to be tested before an upstream merge are (and
>I'm probably forgetting several of them):
>
>- legacy pairing acceptor & initiator
>- security mode 3 acceptor & initiator
>- ssp acceptor & initiator
>- renewed link key handling for both debug and normal keys
>- security level upgrading (i.e. connect first to a low security socket
> and then over the same ACL to a higher security socket)
>- complete and partial failure scenarios for all of the above
>
>Additionally all these test should be done against several
>different controllers due to differences in HCI interface
>behavior (event ordering, error codes, etc). In that list I'd
>include at least one CSR, and one Broadcom adapter and any
>other adapters from other manufacturers that you can get hold of.
>
>So how many of these tests do you already have covered? I'm
>not very comfortable with pushing the patches upstream before
>most of the above scenarios have been tested and verified not
>to introduce any regressions.
>
>Johan
>
To be honest, I did not check all mentioned use cases. I did tests against lagacy and ssp parring and security level upgrading.
So, I will put more effort into testing to be sure.
However, I would appreciate any comments to the changes as I'm not sure what was originally assumed for the high security level. What's more, I'am not happy that the link key request and the pin code request are handled in bluez. It makes that bluez need to pass it to the kernel as it's needed there. I used ioctl for that. Some comments on this?
Thanks,
/Waldek
^ permalink raw reply
* Re: [PATCH 1/1] Bluetooth: Add socket option definitions for AMP
From: Mat Martineau @ 2010-08-27 18:06 UTC (permalink / raw)
To: David Vrabel; +Cc: linux-bluetooth, marcel, rshaffer, linux-arm-msm
In-Reply-To: <4C6BE410.1020505@csr.com>
David -
On Wed, 18 Aug 2010, David Vrabel wrote:
> Mat Martineau wrote:
>> This adds a new BT_AMP socket option to control the use of AMP channels.
>> It is for use with the SOL_BLUETOOTH option level on L2CAP sockets.
>>
>> Available option values are defined as:
>>
>> [lots of nice documentation]
>
> Why is none of this documentation in the code?
>
> I believe we also agreed that this policy could be changed at any point
> in the life time of the channel so this should be documented as well.
>
>> +#define BT_AMP 8
>
> Suggest BT_AMP_POLICY, BT_AMP_POLICY_REQUIRE_BR_EDR etc. Just in case
> there are other AMP related socket options in the future.
>
>> +#define BT_AMP_REQUIRE_BR_EDR 0
>> +#define BT_AMP_PREFER_AMP 1
>> +#define BT_AMP_PREFER_BR_EDR 2
Thanks for the helpful feedback - I'll add the documentation, adjust
the names, and repost.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH] Bluetooth: BT_SECURITY_HIGH requires 16 digit pin code
From: Antonio Ospite @ 2010-08-27 19:45 UTC (permalink / raw)
To: Waldemar Rymarkiewicz
Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
johan.hedberg
In-Reply-To: <1282909460-19337-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
[-- Attachment #1: Type: text/plain, Size: 662 bytes --]
On Fri, 27 Aug 2010 13:44:20 +0200
Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> wrote:
> The security level BT_SECURITY_HIGH expects secure connection
> and a minimum 16 digit pin code used for bonding. It's requitred by the
typo:
s/requitred/required/
> Sim Access Profile.
>
> Patch on behalf of ST-Ericsson SA.
>
> Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
[...]
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Bluetooth: BT_SECURITY_HIGH requires 16 digit pin code
From: Gustavo F. Padovan @ 2010-08-27 19:55 UTC (permalink / raw)
To: Waldemar Rymarkiewicz
Cc: linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
johan.hedberg
In-Reply-To: <1282909460-19337-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi Waldemar,
* Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com> [2010-08-27 13:44:20 +0200]:
> The security level BT_SECURITY_HIGH expects secure connection
> and a minimum 16 digit pin code used for bonding. It's requitred by the
> Sim Access Profile.
>
> Patch on behalf of ST-Ericsson SA.
>
> Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
> ---
> include/net/bluetooth/hci.h | 17 +++++++
> include/net/bluetooth/hci_core.h | 4 ++
> net/bluetooth/hci_conn.c | 97 +++++++++++++++++++++++++++++++-------
> net/bluetooth/hci_event.c | 4 ++
> net/bluetooth/hci_sock.c | 3 +
> net/bluetooth/rfcomm/core.c | 10 ++++-
> 6 files changed, 116 insertions(+), 19 deletions(-)
> mode change 100644 => 100755 include/net/bluetooth/hci.h
> mode change 100644 => 100755 include/net/bluetooth/hci_core.h
> mode change 100644 => 100755 net/bluetooth/hci_conn.c
> mode change 100644 => 100755 net/bluetooth/hci_event.c
> mode change 100644 => 100755 net/bluetooth/rfcomm/core.c
You are changing the files modes. Don't do that.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Johan Hedberg @ 2010-08-27 20:11 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480976E15A78@EXMB04.eu.tieto.com>
Hi Waldek,
On Fri, Aug 27, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> However, I would appreciate any comments to the changes as I'm not
> sure what was originally assumed for the high security level.
Your assumptions were more or less correct. Additionally there should be
the check for encryption key size (to fulfill SAP requirements), though
that'd require at least a 3.0 capable controller if for the standardized
HCI command.
> What's more, I'am not happy that the link key request and the pin code
> request are handled in bluez. It makes that bluez need to pass it to
> the kernel as it's needed there. I used ioctl for that. Some comments
> on this?
I'm not happy with it either. In fact, the arbitrary split of security
logic between kernel and userspace has caused us lots of grief,
especially with SSP. Because of this, the plan for BlueZ 5.x is to move
most security related logic to the kernel side. The only thing remaining
in userspace is security policy requiring user interaction (e.g.
answering user confirmation requests) and persistent link key storage
(runtime storage will be added to the kernel side). The promiscuous HCI
socket will go away from bluetoothd so the daemon doesn't always wake up
when there's some HCI traffic.
To make all this possible we're designing a new protocol between kernel
and userspace. Hopefully we'll get the first bits, at least a
preliminary specification, upstream within the next month or so. Because
of this I'm wondering if the new ioctl that you're adding is really
worth it. Maybe we should just wait for BlueZ 5.x with this. That'd also
give us the possibility of adding a new parameter to
Agent.RequestPinCode since we need to break the agent API anyway (e.g.
add an incoming just-works pairing callback).
Johan
^ permalink raw reply
* Cannot build BlueZ Release 4.70...
From: Ho, Albert O @ 2010-08-28 7:12 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org; +Cc: marcel@holtmann.org
Hi, I attempted to build Release 4.70 but it's not buildable. Using source=
s either from bluez-4.70.tar.gz (www.bluez.org) or from git results to comp=
ile errors. The offending lines are all in attrib-server.c & all are 'unde=
fined references to xxxxx'. Same setup can build 4.69. Pls advise. =20
Regards
Albert
^ permalink raw reply
* Re: Cannot build BlueZ Release 4.70...
From: Johan Hedberg @ 2010-08-28 8:22 UTC (permalink / raw)
To: Ho, Albert O; +Cc: linux-bluetooth@vger.kernel.org, marcel@holtmann.org
In-Reply-To: <CF9C39F99A89134C9CF9C4CCB68B8DDF25AB2D2864@orsmsx501.amr.corp.intel.com>
Hi Albert,
On Sat, Aug 28, 2010, Ho, Albert O wrote:
> Hi, I attempted to build Release 4.70 but it's not buildable. Using
> sources either from bluez-4.70.tar.gz (www.bluez.org) or from git
> results to compile errors. The offending lines are all in
> attrib-server.c & all are 'undefined references to xxxxx'. Same setup
> can build 4.69. Pls advise.
It compiles fine for me. You'll need to copy-paste the exact errors you
get as well as the configure script options that you used.
Johan
^ permalink raw reply
* [PATCH] Add support for GDBus security handlers
From: Marcel Holtmann @ 2010-08-29 1:29 UTC (permalink / raw)
To: linux-bluetooth
---
gdbus/gdbus.h | 19 +++++++
gdbus/object.c | 159 ++++++++++++++++++++++++++++++++++++++++++++++++--------
2 files changed, 156 insertions(+), 22 deletions(-)
diff --git a/gdbus/gdbus.h b/gdbus/gdbus.h
index c3e7252..42d4f73 100644
--- a/gdbus/gdbus.h
+++ b/gdbus/gdbus.h
@@ -55,6 +55,11 @@ typedef void (* GDBusDestroyFunction) (void *user_data);
typedef DBusMessage * (* GDBusMethodFunction) (DBusConnection *connection,
DBusMessage *message, void *user_data);
+typedef guint32 GDBusPendingReply;
+
+typedef void (* GDBusSecurityFunction) (DBusConnection *connection,
+ DBusMessage *message, GDBusPendingReply pending);
+
typedef enum {
G_DBUS_METHOD_FLAG_DEPRECATED = (1 << 0),
G_DBUS_METHOD_FLAG_NOREPLY = (1 << 1),
@@ -75,6 +80,7 @@ typedef struct {
const char *reply;
GDBusMethodFunction function;
GDBusMethodFlags flags;
+ unsigned int privilege;
} GDBusMethodTable;
typedef struct {
@@ -89,6 +95,11 @@ typedef struct {
GDBusPropertyFlags flags;
} GDBusPropertyTable;
+typedef struct {
+ unsigned int privilege;
+ GDBusSecurityFunction function;
+} GDBusSecurityTable;
+
gboolean g_dbus_register_interface(DBusConnection *connection,
const char *path, const char *name,
const GDBusMethodTable *methods,
@@ -99,6 +110,14 @@ gboolean g_dbus_register_interface(DBusConnection *connection,
gboolean g_dbus_unregister_interface(DBusConnection *connection,
const char *path, const char *name);
+gboolean g_dbus_register_security(const GDBusSecurityTable *security);
+gboolean g_dbus_unregister_security(const GDBusSecurityTable *security);
+
+void g_dbus_pending_success(DBusConnection *connection,
+ GDBusPendingReply pending);
+void g_dbus_pending_error(DBusConnection *connection,
+ GDBusPendingReply pending, DBusMessage *error);
+
DBusMessage *g_dbus_create_error(DBusMessage *message, const char *name,
const char *format, ...)
__attribute__((format(printf, 3, 4)));
diff --git a/gdbus/object.c b/gdbus/object.c
index ff69641..a367f93 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -52,6 +52,13 @@ struct interface_data {
GDBusDestroyFunction destroy;
};
+struct security_data {
+ GDBusPendingReply pending;
+ DBusMessage *message;
+ const GDBusMethodTable *method;
+ void *iface_user_data;
+};
+
static void print_arguments(GString *gstr, const char *sig,
const char *direction)
{
@@ -208,6 +215,114 @@ static DBusMessage *introspect(DBusConnection *connection,
return reply;
}
+static DBusHandlerResult process_message(DBusConnection *connection,
+ DBusMessage *message, const GDBusMethodTable *method,
+ void *iface_user_data)
+{
+ DBusMessage *reply;
+
+ reply = method->function(connection, message, iface_user_data);
+
+ if (method->flags & G_DBUS_METHOD_FLAG_NOREPLY) {
+ if (reply != NULL)
+ dbus_message_unref(reply);
+ return DBUS_HANDLER_RESULT_HANDLED;
+ }
+
+ if (method->flags & G_DBUS_METHOD_FLAG_ASYNC) {
+ if (reply == NULL)
+ return DBUS_HANDLER_RESULT_HANDLED;
+ }
+
+ if (reply == NULL)
+ return DBUS_HANDLER_RESULT_NEED_MEMORY;
+
+ dbus_connection_send(connection, reply, NULL);
+ dbus_message_unref(reply);
+
+ return DBUS_HANDLER_RESULT_HANDLED;
+}
+
+static GDBusPendingReply next_pending = 1;
+static GSList *pending_security = NULL;
+
+static const GDBusSecurityTable *security_table = NULL;
+
+void g_dbus_pending_success(DBusConnection *connection,
+ GDBusPendingReply pending)
+{
+ GSList *list;
+
+ for (list = pending_security; list; list = list->next) {
+ struct security_data *secdata = list->data;
+ DBusHandlerResult result;
+
+ if (secdata->pending != pending)
+ continue;
+
+ pending_security = g_slist_remove(pending_security, secdata);
+
+ result = process_message(connection, secdata->message,
+ secdata->method, secdata->iface_user_data);
+
+ dbus_message_unref(secdata->message);
+ g_free(secdata);
+ return;
+ }
+}
+
+void g_dbus_pending_error(DBusConnection *connection,
+ GDBusPendingReply pending, DBusMessage *error)
+{
+ GSList *list;
+
+ for (list = pending_security; list; list = list->next) {
+ struct security_data *secdata = list->data;
+
+ if (secdata->pending != pending)
+ continue;
+
+ pending_security = g_slist_remove(pending_security, secdata);
+
+ if (error != NULL) {
+ dbus_connection_send(connection, error, NULL);
+ dbus_message_unref(error);
+ }
+
+ dbus_message_unref(secdata->message);
+ g_free(secdata);
+ return;
+ }
+}
+
+static gboolean check_privilege(DBusConnection *conn, DBusMessage *msg,
+ const GDBusMethodTable *method, void *iface_user_data)
+{
+ const GDBusSecurityTable *security;
+
+ for (security = security_table; security && security->function &&
+ security->privilege; security++) {
+ struct security_data *secdata;
+
+ if (security->privilege != method->privilege)
+ continue;
+
+ secdata = g_new(struct security_data, 1);
+ secdata->pending = next_pending++;
+ secdata->message = dbus_message_ref(msg);
+ secdata->method = method;
+ secdata->iface_user_data = iface_user_data;
+
+ pending_security = g_slist_prepend(pending_security, secdata);
+
+ security->function(conn, secdata->message, secdata->pending);
+
+ return TRUE;
+ }
+
+ return FALSE;
+}
+
static void generic_unregister(DBusConnection *connection, void *user_data)
{
struct generic_data *data = user_data;
@@ -249,8 +364,6 @@ static DBusHandlerResult generic_message(DBusConnection *connection,
for (method = iface->methods; method &&
method->name && method->function; method++) {
- DBusMessage *reply;
-
if (dbus_message_is_method_call(message, iface->name,
method->name) == FALSE)
continue;
@@ -259,26 +372,12 @@ static DBusHandlerResult generic_message(DBusConnection *connection,
method->signature) == FALSE)
continue;
- reply = method->function(connection, message, iface->user_data);
-
- if (method->flags & G_DBUS_METHOD_FLAG_NOREPLY) {
- if (reply != NULL)
- dbus_message_unref(reply);
+ if (check_privilege(connection, message, method,
+ iface->user_data) == TRUE)
return DBUS_HANDLER_RESULT_HANDLED;
- }
-
- if (method->flags & G_DBUS_METHOD_FLAG_ASYNC) {
- if (reply == NULL)
- return DBUS_HANDLER_RESULT_HANDLED;
- }
- if (reply == NULL)
- return DBUS_HANDLER_RESULT_NEED_MEMORY;
-
- dbus_connection_send(connection, reply, NULL);
- dbus_message_unref(reply);
-
- return DBUS_HANDLER_RESULT_HANDLED;
+ return process_message(connection, message, method,
+ iface->user_data);
}
return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
@@ -362,11 +461,10 @@ static struct generic_data *object_path_ref(DBusConnection *connection,
}
data = g_new0(struct generic_data, 1);
+ data->refcount = 1;
data->introspect = g_strdup(DBUS_INTROSPECT_1_0_XML_DOCTYPE_DECL_NODE "<node></node>");
- data->refcount = 1;
-
if (!dbus_connection_register_object_path(connection, path,
&generic_table, data)) {
g_free(data->introspect);
@@ -556,6 +654,23 @@ gboolean g_dbus_unregister_interface(DBusConnection *connection,
return TRUE;
}
+gboolean g_dbus_register_security(const GDBusSecurityTable *security)
+{
+ if (security_table != NULL)
+ return FALSE;
+
+ security_table = security;
+
+ return TRUE;
+}
+
+gboolean g_dbus_unregister_security(const GDBusSecurityTable *security)
+{
+ security_table = NULL;
+
+ return TRUE;
+}
+
DBusMessage *g_dbus_create_error_valist(DBusMessage *message, const char *name,
const char *format, va_list args)
{
--
1.7.2.2
^ permalink raw reply related
* RE: Cannot build BlueZ Release 4.70...
From: Ho, Albert O @ 2010-08-29 5:18 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth@vger.kernel.org, marcel@holtmann.org
In-Reply-To: <20100828082256.GA23228@jh-x301>
Hi Johan,
The configure line invocation is taken from README file. Below are copy-pa=
ste exact errors.
Regards,
Albert
src/attrib-server.o: In function `send_notification':
attrib-server.c:(.text+0x1da): undefined reference to `enc_notification'
attrib-server.c:(.text+0x211): undefined reference to `g_attrib_send'
src/attrib-server.o: In function `connect_event':
attrib-server.c:(.text+0x863): undefined reference to `g_attrib_new'
attrib-server.c:(.text+0x885): undefined reference to `g_attrib_register'
src/attrib-server.o: In function `channel_destroy':
attrib-server.c:(.text+0x8b9): undefined reference to `g_attrib_unregister_=
all'
attrib-server.c:(.text+0x8c2): undefined reference to `g_attrib_unref'
src/attrib-server.o: In function `channel_handler':
attrib-server.c:(.text+0x964): undefined reference to `dec_read_by_grp_req'
attrib-server.c:(.text+0x990): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0x9b2): undefined reference to `g_attrib_send'
attrib-server.c:(.text+0x9e9): undefined reference to `dec_read_req'
attrib-server.c:(.text+0xa39): undefined reference to `enc_read_resp'
attrib-server.c:(.text+0xa64): undefined reference to `dec_read_by_type_req=
'
attrib-server.c:(.text+0xbcc): undefined reference to `enc_read_by_type_res=
p'
attrib-server.c:(.text+0xbd8): undefined reference to `att_data_list_free'
attrib-server.c:(.text+0xc01): undefined reference to `dec_find_info_req'
attrib-server.c:(.text+0xd7b): undefined reference to `enc_find_info_resp'
attrib-server.c:(.text+0xd86): undefined reference to `att_data_list_free'
attrib-server.c:(.text+0xf52): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0xf7c): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0xfac): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0xfd3): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0xff7): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0x1011): undefined reference to `enc_read_by_grp_res=
p'
attrib-server.c:(.text+0x101d): undefined reference to `att_data_list_free'
attrib-server.c:(.text+0x106d): undefined reference to `enc_error_resp'
attrib-server.c:(.text+0x1092): undefined reference to `enc_error_resp'
collect2: ld returned 1 exit status
make[1]: *** [src/bluetoothd] Error 1
make: *** [all] Error 2
-----Original Message-----
From: Johan Hedberg [mailto:johan.hedberg@gmail.com]=20
Sent: Saturday, August 28, 2010 1:23 AM
To: Ho, Albert O
Cc: linux-bluetooth@vger.kernel.org; marcel@holtmann.org
Subject: Re: Cannot build BlueZ Release 4.70...
Hi Albert,
On Sat, Aug 28, 2010, Ho, Albert O wrote:
> Hi, I attempted to build Release 4.70 but it's not buildable. Using
> sources either from bluez-4.70.tar.gz (www.bluez.org) or from git
> results to compile errors. The offending lines are all in
> attrib-server.c & all are 'undefined references to xxxxx'. Same setup
> can build 4.69. Pls advise.
It compiles fine for me. You'll need to copy-paste the exact errors you
get as well as the configure script options that you used.
Johan
^ permalink raw reply
* Re: Cannot build BlueZ Release 4.70...
From: alok barsode @ 2010-08-29 8:45 UTC (permalink / raw)
To: Ho, Albert O
Cc: Johan Hedberg, linux-bluetooth@vger.kernel.org,
marcel@holtmann.org
In-Reply-To: <CF9C39F99A89134C9CF9C4CCB68B8DDF25AB2D28E0@orsmsx501.amr.corp.intel.com>
Hi Albert,
On Sun, Aug 29, 2010 at 10:48 AM, Ho, Albert O <albert.o.ho@intel.com> wrot=
e:
> Hi Johan,
>
> The configure line invocation is taken from README file. =A0Below are cop=
y-paste exact errors.
I tried building using bootstrap-configure and it built fine.
But when I tried building with ./bootstrap and ./configure it gave
the same errors as mentioned.
Maybe we missed some configure option ?
Cheers,
Alok.
>
> Regards,
> Albert
>
>
> src/attrib-server.o: In function `send_notification':
> attrib-server.c:(.text+0x1da): undefined reference to `enc_notification'
> attrib-server.c:(.text+0x211): undefined reference to `g_attrib_send'
> src/attrib-server.o: In function `connect_event':
> attrib-server.c:(.text+0x863): undefined reference to `g_attrib_new'
> attrib-server.c:(.text+0x885): undefined reference to `g_attrib_register'
> src/attrib-server.o: In function `channel_destroy':
> attrib-server.c:(.text+0x8b9): undefined reference to `g_attrib_unregiste=
r_all'
> attrib-server.c:(.text+0x8c2): undefined reference to `g_attrib_unref'
> src/attrib-server.o: In function `channel_handler':
> attrib-server.c:(.text+0x964): undefined reference to `dec_read_by_grp_re=
q'
> attrib-server.c:(.text+0x990): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0x9b2): undefined reference to `g_attrib_send'
> attrib-server.c:(.text+0x9e9): undefined reference to `dec_read_req'
> attrib-server.c:(.text+0xa39): undefined reference to `enc_read_resp'
> attrib-server.c:(.text+0xa64): undefined reference to `dec_read_by_type_r=
eq'
> attrib-server.c:(.text+0xbcc): undefined reference to `enc_read_by_type_r=
esp'
> attrib-server.c:(.text+0xbd8): undefined reference to `att_data_list_free=
'
> attrib-server.c:(.text+0xc01): undefined reference to `dec_find_info_req'
> attrib-server.c:(.text+0xd7b): undefined reference to `enc_find_info_resp=
'
> attrib-server.c:(.text+0xd86): undefined reference to `att_data_list_free=
'
> attrib-server.c:(.text+0xf52): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0xf7c): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0xfac): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0xfd3): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0xff7): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0x1011): undefined reference to `enc_read_by_grp_r=
esp'
> attrib-server.c:(.text+0x101d): undefined reference to `att_data_list_fre=
e'
> attrib-server.c:(.text+0x106d): undefined reference to `enc_error_resp'
> attrib-server.c:(.text+0x1092): undefined reference to `enc_error_resp'
> collect2: ld returned 1 exit status
> make[1]: *** [src/bluetoothd] Error 1
> make: *** [all] Error 2
>
>
> -----Original Message-----
> From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
> Sent: Saturday, August 28, 2010 1:23 AM
> To: Ho, Albert O
> Cc: linux-bluetooth@vger.kernel.org; marcel@holtmann.org
> Subject: Re: Cannot build BlueZ Release 4.70...
>
> Hi Albert,
>
> On Sat, Aug 28, 2010, Ho, Albert O wrote:
>> Hi, I attempted to build Release 4.70 but it's not buildable. =A0Using
>> sources either from bluez-4.70.tar.gz (www.bluez.org) or from git
>> results to compile errors. =A0The offending lines are all in
>> attrib-server.c & all are 'undefined references to xxxxx'. =A0Same setup
>> can build 4.69. =A0Pls advise.
>
> It compiles fine for me. You'll need to copy-paste the exact errors you
> get as well as the configure script options that you used.
>
> 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 =A0http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Cannot build BlueZ Release 4.70...
From: Johan Hedberg @ 2010-08-29 10:19 UTC (permalink / raw)
To: alok barsode
Cc: Ho, Albert O, linux-bluetooth@vger.kernel.org,
marcel@holtmann.org
In-Reply-To: <AANLkTi=K6rdg+Pck7FjbDP-LTn=5sXrLVX9Nz8RPqi0v@mail.gmail.com>
Hi,
On Sun, Aug 29, 2010, alok barsode wrote:
> > The configure line invocation is taken from README file. Below are
> > copy-paste exact errors.
>
> I tried building using bootstrap-configure and it built fine. But
> when I tried building with ./bootstrap and ./configure it gave the
> same errors as mentioned.
> Maybe we missed some configure option ?
I still can't seem to reproduce this. I just tried "./bootstrap &&
./configure && make" with a clean git tree and it compiles fine.
Downloading the official tarball for 4.70 and doing "./configure &&
make" works fine too. I wonder if the autotools or gcc version has
something to do with this?
Johan
^ permalink raw reply
* [PATCH] Use simpler error callbacks for GDBus security hooks
From: Marcel Holtmann @ 2010-08-29 10:32 UTC (permalink / raw)
To: linux-bluetooth
---
gdbus/gdbus.h | 9 +++++++--
gdbus/object.c | 29 +++++++++++++++++++++++------
2 files changed, 30 insertions(+), 8 deletions(-)
diff --git a/gdbus/gdbus.h b/gdbus/gdbus.h
index 42d4f73..553918c 100644
--- a/gdbus/gdbus.h
+++ b/gdbus/gdbus.h
@@ -58,7 +58,7 @@ typedef DBusMessage * (* GDBusMethodFunction) (DBusConnection *connection,
typedef guint32 GDBusPendingReply;
typedef void (* GDBusSecurityFunction) (DBusConnection *connection,
- DBusMessage *message, GDBusPendingReply pending);
+ GDBusPendingReply pending);
typedef enum {
G_DBUS_METHOD_FLAG_DEPRECATED = (1 << 0),
@@ -116,7 +116,12 @@ gboolean g_dbus_unregister_security(const GDBusSecurityTable *security);
void g_dbus_pending_success(DBusConnection *connection,
GDBusPendingReply pending);
void g_dbus_pending_error(DBusConnection *connection,
- GDBusPendingReply pending, DBusMessage *error);
+ GDBusPendingReply pending,
+ const char *name, const char *format, ...)
+ __attribute__((format(printf, 4, 5)));
+void g_dbus_pending_error_valist(DBusConnection *connection,
+ GDBusPendingReply pending, const char *name,
+ const char *format, va_list args);
DBusMessage *g_dbus_create_error(DBusMessage *message, const char *name,
const char *format, ...)
diff --git a/gdbus/object.c b/gdbus/object.c
index a367f93..48530f2 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -271,22 +271,26 @@ void g_dbus_pending_success(DBusConnection *connection,
}
}
-void g_dbus_pending_error(DBusConnection *connection,
- GDBusPendingReply pending, DBusMessage *error)
+void g_dbus_pending_error_valist(DBusConnection *connection,
+ GDBusPendingReply pending, const char *name,
+ const char *format, va_list args)
{
GSList *list;
for (list = pending_security; list; list = list->next) {
struct security_data *secdata = list->data;
+ DBusMessage *reply;
if (secdata->pending != pending)
continue;
pending_security = g_slist_remove(pending_security, secdata);
- if (error != NULL) {
- dbus_connection_send(connection, error, NULL);
- dbus_message_unref(error);
+ reply = g_dbus_create_error_valist(secdata->message,
+ name, format, args);
+ if (reply != NULL) {
+ dbus_connection_send(connection, reply, NULL);
+ dbus_message_unref(reply);
}
dbus_message_unref(secdata->message);
@@ -295,6 +299,19 @@ void g_dbus_pending_error(DBusConnection *connection,
}
}
+void g_dbus_pending_error(DBusConnection *connection,
+ GDBusPendingReply pending,
+ const char *name, const char *format, ...)
+{
+ va_list args;
+
+ va_start(args, format);
+
+ g_dbus_pending_error_valist(connection, pending, name, format, args);
+
+ va_end(args);
+}
+
static gboolean check_privilege(DBusConnection *conn, DBusMessage *msg,
const GDBusMethodTable *method, void *iface_user_data)
{
@@ -315,7 +332,7 @@ static gboolean check_privilege(DBusConnection *conn, DBusMessage *msg,
pending_security = g_slist_prepend(pending_security, secdata);
- security->function(conn, secdata->message, secdata->pending);
+ security->function(conn, secdata->pending);
return TRUE;
}
--
1.7.2.2
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox