* [PATCH] Solve compilation problem when SBC variable is not active
From: Jose Antonio Santos Cadenas @ 2010-08-31 14:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Jose Antonio Santos Cadenas
In-Reply-To: <AANLkTinHLGYkji4Eoxu_QReDQCHndB7r319jB-2butVT@mail.gmail.com>
The inclusion of src/attrib-server.c file by default in the daemon
source needs also to compile by default attrib_sources, not only
when SBC is active.
---
Makefile.am | 5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 47478c2..5684e99 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -79,9 +79,6 @@ sbc_sbcdec_LDADD = sbc/libsbc.la
sbc_sbcenc_SOURCES = sbc/sbcenc.c sbc/formats.h
sbc_sbcenc_LDADD = sbc/libsbc.la
-attrib_sources = attrib/att.h attrib/att.c attrib/gatt.h attrib/gatt.c \
- attrib/gattrib.h attrib/gattrib.c
-
if SNDFILE
noinst_PROGRAMS += sbc/sbctester
@@ -90,6 +87,8 @@ sbc_sbctest_CFLAGS = @SNDFILE_CFLAGS@
endif
endif
+attrib_sources = attrib/att.h attrib/att.c attrib/gatt.h attrib/gatt.c \
+ attrib/gattrib.h attrib/gattrib.c
if NETLINK
plugin_LTLIBRARIES += plugins/netlink.la
--
1.7.0.4
^ permalink raw reply related
* [PATCH] Add handling for more than one address with in vCard structure
From: Rafał Michalski @ 2010-08-31 7:36 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Add-handling-for-more-than-one-address-with-in-vCard.patch --]
[-- Type: text/x-patch, Size: 16135 bytes --]
From 9a56973f11afbba0135a419de232303ff4cc262e Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Mon, 30 Aug 2010 16:03:12 +0200
Subject: [PATCH] Add handling for more than one address with in vCard structure
After pulling contacts only fields (pobox, extended, street, locality,
region, postal, country) of one address were present in downloaded vCard
structure (under ADR tag) in spite of that there can be more adresses
stored on phonebook. To solve this problem extending number of columns and
queries of database was needed especially. Distinguish between two types of
address (HOME and WORK) is supported.
---
plugins/phonebook-tracker.c | 139 +++++++++++++++++++++++++++++++++++++------
plugins/vcard.c | 92 +++++++++++++++++++++--------
plugins/vcard.h | 26 ++++++--
3 files changed, 208 insertions(+), 49 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 1f1f693..e17995d 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -43,16 +43,16 @@
#define TRACKER_RESOURCES_INTERFACE "org.freedesktop.Tracker1.Resources"
#define TRACKER_DEFAULT_CONTACT_ME "http://www.semanticdesktop.org/ontologies/2007/03/22/nco#default-contact-me"
-#define CONTACTS_ID_COL 28
-#define PULL_QUERY_COL_AMOUNT 29
+#define CONTACTS_ID_COL 35
+#define PULL_QUERY_COL_AMOUNT 36
#define COL_HOME_NUMBER 0
#define COL_HOME_EMAIL 7
#define COL_WORK_NUMBER 8
#define COL_FAX_NUMBER 16
#define COL_WORK_EMAIL 17
-#define COL_DATE 25
-#define COL_SENT 26
-#define COL_ANSWERED 27
+#define COL_DATE 32
+#define COL_SENT 33
+#define COL_ANSWERED 34
#define CONTACTS_QUERY_ALL \
"SELECT ?v nco:fullname(?c) " \
@@ -64,7 +64,9 @@
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
- "nco:role(?a) " \
+ "nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
+ "nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
+ "nco:postalcode(?pw) nco:country(?pw) " \
"\"NOTACALL\" \"false\" \"false\" ?c " \
"WHERE { " \
"?c a nco:PersonContact . " \
@@ -84,6 +86,7 @@
"?c nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"}"
@@ -112,7 +115,9 @@
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
- "nco:role(?a) " \
+ "nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
+ "nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
+ "nco:postalcode(?pw) nco:country(?pw) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
@@ -133,6 +138,7 @@
"?c nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} ORDER BY DESC(nmo:receivedDate(?call))"
@@ -161,7 +167,9 @@
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
- "nco:role(?a) " \
+ "nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
+ "nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
+ "nco:postalcode(?pw) nco:country(?pw) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
@@ -182,6 +190,7 @@
"?c nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} ORDER BY DESC(nmo:receivedDate(?call))"
@@ -210,7 +219,9 @@
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew)" \
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
- "nco:role(?a) " \
+ "nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
+ "nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
+ "nco:postalcode(?pw) nco:country(?pw) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
@@ -230,6 +241,7 @@
"?c nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} ORDER BY DESC(nmo:sentDate(?call))"
@@ -257,7 +269,9 @@
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew) " \
"nco:birthDate(?c) nco:nickname(?c) nco:websiteUrl(?c) " \
"nco:photo(?c) nco:fullname(?o) nco:department(?a) " \
- "nco:role(?a) " \
+ "nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
+ "nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
+ "nco:postalcode(?pw) nco:country(?pw) " \
"nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
@@ -277,6 +291,7 @@
"OPTIONAL { ?c nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} UNION { " \
@@ -295,6 +310,7 @@
"OPTIONAL { ?c nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . } " \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . } " \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"} } ORDER BY DESC(nmo:receivedDate(?call))"
@@ -329,7 +345,9 @@
"nco:postalcode(?p) nco:country(?p) ?f nco:emailAddress(?ew)" \
"nco:birthDate(<%s>) nco:nickname(<%s>) nco:websiteUrl(<%s>) " \
"nco:photo(<%s>) nco:fullname(?o) nco:department(?a) " \
- "nco:role(?a) " \
+ "nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
+ "nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
+ "nco:postalcode(?pw) nco:country(?pw) " \
"\"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:Contact . " \
@@ -349,6 +367,7 @@
"<%s> nco:hasAffiliation ?a . " \
"OPTIONAL { ?a nco:hasPhoneNumber ?w . }" \
"OPTIONAL { ?a nco:hasEmailAddress ?ew . }" \
+ "OPTIONAL { ?a nco:hasPostalAddress ?pw . } " \
"OPTIONAL { ?a nco:org ?o . } " \
"} " \
"}"
@@ -721,6 +740,73 @@ static void add_email(struct phonebook_contact *contact, const char *address,
contact->emails = g_slist_append(contact->emails, email);
}
+static struct phonebook_address *find_address(GSList *addresses,
+ struct phonebook_address *address)
+{
+ GSList *l;
+
+ for (l = addresses; l; l = l->next) {
+ struct phonebook_address *addr = l->data;
+ if (g_strcmp0(addr->pobox, address->pobox) == 0 &&
+ g_strcmp0(addr->extended, address->extended) == 0 &&
+ g_strcmp0(addr->street, address->street) == 0 &&
+ g_strcmp0(addr->locality, address->locality) == 0 &&
+ g_strcmp0(addr->region, address->region) == 0 &&
+ g_strcmp0(addr->postal, address->postal) == 0 &&
+ g_strcmp0(addr->country, address->country) == 0 &&
+ addr->type == address->type)
+ return addr;
+ }
+
+ return NULL;
+}
+
+static gboolean address_fields_present(struct phonebook_address *address)
+{
+ if (address->pobox && strlen(address->pobox))
+ return TRUE;
+ if (address->extended && strlen(address->extended))
+ return TRUE;
+ if (address->street && strlen(address->street))
+ return TRUE;
+ if (address->locality && strlen(address->locality))
+ return TRUE;
+ if (address->region && strlen(address->region))
+ return TRUE;
+ if (address->postal && strlen(address->postal))
+ return TRUE;
+ if (address->country && strlen(address->country))
+ return TRUE;
+
+ return FALSE;
+}
+
+static void add_address(struct phonebook_contact *contact,
+ struct phonebook_address *address)
+{
+ struct phonebook_address *addr;
+
+ if (address == NULL || address_fields_present(address) == FALSE)
+ return;
+
+ /* Not adding address if there is already added with the same value */
+ if (find_address(contact->addresses, address))
+ return;
+
+ addr = g_new0(struct phonebook_address, 1);
+
+ addr->pobox = g_strdup(address->pobox);
+ addr->extended = g_strdup(address->extended);
+ addr->street = g_strdup(address->street);
+ addr->locality = g_strdup(address->locality);
+ addr->region = g_strdup(address->region);
+ addr->postal = g_strdup(address->postal);
+ addr->country = g_strdup(address->country);
+ addr->type = address->type;
+
+ contact->addresses = g_slist_append(contact->addresses, addr);
+}
+
static GString *gen_vcards(GSList *contacts,
const struct apparam_field *params)
{
@@ -803,13 +889,6 @@ add_entry:
contact->additional = g_strdup(reply[4]);
contact->prefix = g_strdup(reply[5]);
contact->suffix = g_strdup(reply[6]);
- contact->pobox = g_strdup(reply[9]);
- contact->extended = g_strdup(reply[10]);
- contact->street = g_strdup(reply[11]);
- contact->locality = g_strdup(reply[12]);
- contact->region = g_strdup(reply[13]);
- contact->postal = g_strdup(reply[14]);
- contact->country = g_strdup(reply[15]);
contact->birthday = g_strdup(reply[18]);
contact->nickname = g_strdup(reply[19]);
contact->website = g_strdup(reply[20]);
@@ -831,6 +910,30 @@ add_numbers:
add_email(contact, reply[COL_HOME_EMAIL], EMAIL_TYPE_HOME);
add_email(contact, reply[COL_WORK_EMAIL], EMAIL_TYPE_WORK);
+ /* Adding addresses */
+ struct phonebook_address home_addr = { g_strdup(reply[9]),
+ g_strdup(reply[10]),
+ g_strdup(reply[11]),
+ g_strdup(reply[12]),
+ g_strdup(reply[13]),
+ g_strdup(reply[14]),
+ g_strdup(reply[15]),
+ ADDR_TYPE_HOME
+ };
+
+ struct phonebook_address work_addr = { g_strdup(reply[25]),
+ g_strdup(reply[26]),
+ g_strdup(reply[27]),
+ g_strdup(reply[28]),
+ g_strdup(reply[29]),
+ g_strdup(reply[30]),
+ g_strdup(reply[31]),
+ ADDR_TYPE_WORK
+ };
+
+ add_address(contact, &home_addr);
+ add_address(contact, &work_addr);
+
DBG("contact %p", contact);
/* Adding contacts data to wrapper struct - this data will be used to
diff --git a/plugins/vcard.c b/plugins/vcard.c
index 09f4f40..e7e4cc7 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -155,21 +155,21 @@ static gboolean contact_fields_present(struct phonebook_contact * contact)
return FALSE;
}
-static gboolean address_fields_present(struct phonebook_contact *contact)
+static gboolean address_fields_present(struct phonebook_address *address)
{
- if (contact->pobox && strlen(contact->pobox))
+ if (address->pobox && strlen(address->pobox))
return TRUE;
- if (contact->extended && strlen(contact->extended))
+ if (address->extended && strlen(address->extended))
return TRUE;
- if (contact->street && strlen(contact->street))
+ if (address->street && strlen(address->street))
return TRUE;
- if (contact->locality && strlen(contact->locality))
+ if (address->locality && strlen(address->locality))
return TRUE;
- if (contact->region && strlen(contact->region))
+ if (address->region && strlen(address->region))
return TRUE;
- if (contact->postal && strlen(contact->postal))
+ if (address->postal && strlen(address->postal))
return TRUE;
- if (contact->country && strlen(contact->country))
+ if (address->country && strlen(address->country))
return TRUE;
return FALSE;
@@ -376,18 +376,43 @@ static void vcard_printf_org(GString *vcards,
contact->department, contact->title);
}
-static void vcard_printf_adr(GString *vcards,
- struct phonebook_contact *contact)
+static void vcard_printf_address(GString *vcards, uint8_t format,
+ struct phonebook_address *addr)
{
- if (address_fields_present(contact) == FALSE) {
+ char buf[LEN_MAX];
+ const char *category_string = "";
+
+ if (!addr || address_fields_present(addr) == FALSE) {
vcard_printf(vcards, "ADR:");
return;
}
- vcard_printf(vcards, "ADR:%s;%s;%s;%s;%s;%s;%s", contact->pobox,
- contact->extended, contact->street,
- contact->locality, contact->region,
- contact->postal, contact->country);
+ switch (addr->type) {
+ case ADDR_TYPE_HOME:
+ if (format == FORMAT_VCARD21)
+ category_string = "HOME";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=HOME";
+ break;
+ case ADDR_TYPE_WORK:
+ if (format == FORMAT_VCARD21)
+ category_string = "WORK";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=WORK";
+ break;
+ default:
+ if (format == FORMAT_VCARD21)
+ category_string = "OTHER";
+ else if (format == FORMAT_VCARD30)
+ category_string = "TYPE=OTHER";
+ break;
+ }
+
+ snprintf(buf, LEN_MAX, "%s;%s;%s;%s;%s;%s;%s",
+ addr->pobox, addr->extended, addr->street,
+ addr->locality, addr->region, addr->postal, addr->country);
+
+ vcard_printf(vcards, "ADR;%s:%s", category_string, buf);
}
static void vcard_printf_datetime(GString *vcards,
@@ -468,8 +493,17 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
}
}
- if (filter & FILTER_ADR)
- vcard_printf_adr(vcards, contact);
+ if (filter & FILTER_ADR) {
+ GSList *l = contact->addresses;
+
+ if (g_slist_length(l) == 0)
+ vcard_printf_address(vcards, format, NULL);
+
+ for (; l; l = l->next) {
+ struct phonebook_address *addr = l->data;
+ vcard_printf_address(vcards, format, addr);
+ }
+ }
if (filter & FILTER_BDAY)
vcard_printf_tag(vcards, format, "BDAY", NULL,
@@ -512,6 +546,20 @@ static void email_free(gpointer data, gpointer user_data)
g_free(email);
}
+static void address_free(gpointer data, gpointer user_data)
+{
+ struct phonebook_address *addr = data;
+
+ g_free(addr->pobox);
+ g_free(addr->extended);
+ g_free(addr->street);
+ g_free(addr->locality);
+ g_free(addr->region);
+ g_free(addr->postal);
+ g_free(addr->country);
+ g_free(addr);
+}
+
void phonebook_contact_free(struct phonebook_contact *contact)
{
if (contact == NULL)
@@ -523,19 +571,15 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_slist_foreach(contact->emails, email_free, NULL);
g_slist_free(contact->emails);
+ g_slist_foreach(contact->addresses, address_free, NULL);
+ g_slist_free(contact->addresses);
+
g_free(contact->fullname);
g_free(contact->given);
g_free(contact->family);
g_free(contact->additional);
g_free(contact->prefix);
g_free(contact->suffix);
- g_free(contact->pobox);
- g_free(contact->extended);
- g_free(contact->street);
- g_free(contact->locality);
- g_free(contact->region);
- g_free(contact->postal);
- g_free(contact->country);
g_free(contact->birthday);
g_free(contact->nickname);
g_free(contact->website);
diff --git a/plugins/vcard.h b/plugins/vcard.h
index a22dfc1..c8cac36 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -40,6 +40,12 @@ enum phonebook_call_type {
CALL_TYPE_OUTGOING,
};
+enum phonebook_address_type {
+ ADDR_TYPE_HOME,
+ ADDR_TYPE_WORK,
+ ADDR_TYPE_OTHER,
+};
+
struct phonebook_number {
char *tel;
int type;
@@ -50,6 +56,18 @@ struct phonebook_email {
int type;
};
+struct phonebook_address
+{
+ char *pobox;
+ char *extended;
+ char *street;
+ char *locality;
+ char *region;
+ char *postal;
+ char *country;
+ int type;
+};
+
struct phonebook_contact {
char *fullname;
char *given;
@@ -57,15 +75,9 @@ struct phonebook_contact {
char *additional;
GSList *numbers;
GSList *emails;
+ GSList *addresses;
char *prefix;
char *suffix;
- char *pobox;
- char *extended;
- char *street;
- char *locality;
- char *region;
- char *postal;
- char *country;
char *birthday;
char *nickname;
char *website;
--
1.6.3.3
^ permalink raw reply related
* Re: Check for connections and disable bluetooth in shell
From: Gustavo F. Padovan @ 2010-08-31 6:04 UTC (permalink / raw)
To: Jonathan Haug; +Cc: linux-bluetooth
In-Reply-To: <1283234299.1702.12.camel@josua>
Hi Jonathan,
* Jonathan Haug <jonathanhaug@wolke7.net> [2010-08-31 07:58:19 +0200]:
>
> Dear bluetooth-experts,
>
> I want to disable bluetooth on my system (via commandline), if there is
> no active bluetooth connection -- without being root.
>
> Therefor I need a way to
>
> 1. check if there is an active bluetooth connection
'hcitool conn' can show that to you.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Check for connections and disable bluetooth in shell
From: Jonathan Haug @ 2010-08-31 5:58 UTC (permalink / raw)
To: linux-bluetooth
Dear bluetooth-experts,
I want to disable bluetooth on my system (via commandline), if there is
no active bluetooth connection -- without being root.
Therefor I need a way to
1. check if there is an active bluetooth connection
2. disable bluetooth without being root
For the second part I found
dbus-send --system --type=method_call --dest=org.bluez $(dbus-send
--system --print-reply --dest=org.bluez / org.bluez.Manager.ListAdapters
| awk -F'"' '/at/ {print $2}') org.bluez.Adapter.SetProperty
string:Powered variant:boolean:false
but this doesn't really disable bluetooth: I'm still able to deactivate
bluetooth in the panel.
For the first part I could not find a solution so far.
I'm running Ubuntu 10.04.
Thanks for your help!
Jonathan Haug
^ permalink raw reply
* [PATCH] Bluetooth: Simplify L2CAP Streaming mode sending
From: Gustavo F. Padovan @ 2010-08-30 23:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: netdev, linux-kernel, marcel
In-Reply-To: <1283209824-8795-1-git-send-email-padovan@profusion.mobi>
As we don't have any error control on the Streaming mode, i.e., we don't
need to keep a copy of the skb for later resending we don't need to
call skb_clone() on it.
Then we can go one further here, and dequeue the skb before sending it,
that also means we don't need to look to sk->sk_send_head anymore.
This patch fixes a bug in Streaming mode sending procedure, the call to
skb_clone() was making the system run into OOM condition. I never got
that before 2.6.36, so I'm think that we acctually have regression
there.
Anyway, the patch saves memory and time when sending Streaming mode
data, so it is good to mainline.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 24 +++++++-----------------
1 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index fadf26b..80e98cd 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1441,33 +1441,23 @@ static inline void l2cap_do_send(struct sock *sk, struct sk_buff *skb)
static void l2cap_streaming_send(struct sock *sk)
{
- struct sk_buff *skb, *tx_skb;
+ struct sk_buff *skb;
struct l2cap_pinfo *pi = l2cap_pi(sk);
u16 control, fcs;
- while ((skb = sk->sk_send_head)) {
- tx_skb = skb_clone(skb, GFP_ATOMIC);
-
- control = get_unaligned_le16(tx_skb->data + L2CAP_HDR_SIZE);
+ while ((skb = skb_dequeue(TX_QUEUE(sk)))) {
+ control = get_unaligned_le16(skb->data + L2CAP_HDR_SIZE);
control |= pi->next_tx_seq << L2CAP_CTRL_TXSEQ_SHIFT;
- put_unaligned_le16(control, tx_skb->data + L2CAP_HDR_SIZE);
+ put_unaligned_le16(control, skb->data + L2CAP_HDR_SIZE);
if (pi->fcs == L2CAP_FCS_CRC16) {
- fcs = crc16(0, (u8 *)tx_skb->data, tx_skb->len - 2);
- put_unaligned_le16(fcs, tx_skb->data + tx_skb->len - 2);
+ fcs = crc16(0, (u8 *)skb->data, skb->len - 2);
+ put_unaligned_le16(fcs, skb->data + skb->len - 2);
}
- l2cap_do_send(sk, tx_skb);
+ l2cap_do_send(sk, skb);
pi->next_tx_seq = (pi->next_tx_seq + 1) % 64;
-
- if (skb_queue_is_last(TX_QUEUE(sk), skb))
- sk->sk_send_head = NULL;
- else
- sk->sk_send_head = skb_queue_next(TX_QUEUE(sk), skb);
-
- skb = skb_dequeue(TX_QUEUE(sk));
- kfree_skb(skb);
}
}
--
1.7.2.2
^ permalink raw reply related
* Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-08-30 23:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: netdev, linux-kernel, marcel
I've been experiencing some problems when running the L2CAP Streaming mode in
2.6.36. The system quickly runs in an Out Of Memory condition and crash. That
wasn't happening before, so I think we may have a regression here (I didn't find
where yet). The crash log is below.
The following patch does not fix the regression, but shows that removing the
skb_clone() call from l2cap_streaming_send() makes the problem goes away. The
patch is good anyway since it saves memory and time when sending Streaming mode
packets.
[ 5066.137533] Bluetooth: L2CAP ver 2.15
[ 5066.137873] Bluetooth: L2CAP socket layer initialized
[ 5066.545179] Bluetooth: RFCOMM TTY layer initialized
[ 5066.545879] Bluetooth: RFCOMM socket layer initialized
[ 5066.546582] Bluetooth: RFCOMM ver 1.11
[ 5092.268021] l2test invoked oom-killer: gfp_mask=0x4d0, order=0, oom_adj=0, oom_score_adj=0
[ 5092.268872] Pid: 3897, comm: l2test Not tainted 2.6.36-rc3 #5
[ 5092.269863] Call Trace:
[ 5092.270265] [<ffffffff8138b6a6>] ? _raw_spin_unlock+0x26/0x30
[ 5092.270878] [<ffffffff810c0827>] T.427+0x77/0x1e0
[ 5092.271874] [<ffffffff811b85e7>] ? security_real_capable_noaudit+0x37/0x60
[ 5092.272956] [<ffffffff810c0e3a>] out_of_memory+0x2ca/0x2f0
[ 5092.273894] [<ffffffff810c3d43>] __alloc_pages_nodemask+0x693/0x6b0
[ 5092.274871] [<ffffffff810ea3e6>] cache_alloc_refill+0x2d6/0x5c0
[ 5092.275864] [<ffffffff810ea805>] __kmalloc+0x135/0x150
[ 5092.276876] [<ffffffff8130f2ae>] __alloc_skb+0x6e/0x150
[ 5092.277865] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.278652] [<ffffffff8130ace2>] sock_alloc_send_pskb+0x1c2/0x320
[ 5092.278927] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.279864] [<ffffffff81312add>] ? memcpy_fromiovec+0x6d/0x90
[ 5092.280864] [<ffffffff8130ae50>] sock_alloc_send_skb+0x10/0x20
[ 5092.281867] [<ffffffffa00e600f>] l2cap_create_iframe_pdu+0x9f/0x2c0 [l2cap]
[ 5092.282865] [<ffffffffa00e84b9>] l2cap_sock_sendmsg+0x5d9/0x910 [l2cap]
[ 5092.283932] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
[ 5092.284865] [<ffffffff8130725b>] sock_sendmsg+0xdb/0x100
[ 5092.285652] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
[ 5092.285864] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
[ 5092.286864] [<ffffffff813073c0>] sys_sendto+0xf0/0x130
[ 5092.287864] [<ffffffff8138b60b>] ? _raw_spin_unlock_irq+0x2b/0x40
[ 5092.288872] [<ffffffff81093cfd>] ? trace_hardirqs_on_caller+0x13d/0x180
[ 5092.289927] [<ffffffff81093d4d>] ? trace_hardirqs_on+0xd/0x10
[ 5092.290864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.291649] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.291864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.292864] [<ffffffff8130740f>] sys_send+0xf/0x20
[ 5092.293870] [<ffffffff8132ccd6>] compat_sys_socketcall+0x146/0x1f0
[ 5092.294875] [<ffffffff81053ee4>] sysenter_dispatch+0x7/0x30
[ 5092.295673] Mem-Info:
[ 5092.295863] DMA per-cpu:
[ 5092.296214] CPU 0: hi: 0, btch: 1 usd: 0
[ 5092.296925] DMA32 per-cpu:
[ 5092.297298] CPU 0: hi: 90, btch: 15 usd: 85
[ 5092.297864] active_anon:504 inactive_anon:543 isolated_anon:0
[ 5092.297865] active_file:14 inactive_file:3 isolated_file:0
[ 5092.297866] unevictable:0 dirty:0 writeback:3 unstable:0
[ 5092.297866] free:728 slab_reclaimable:559 slab_unreclaimable:39895
[ 5092.297867] mapped:12 shmem:35 pagetables:84 bounce:0
[ 5092.299944] DMA free:1064kB min:124kB low:152kB high:184kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15768kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:14916kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
[ 5092.301862] lowmem_reserve[]: 0 236 236 236
[ 5092.303134] DMA32 free:1848kB min:1904kB low:2380kB high:2856kB active_anon:2016kB inactive_anon:2172kB active_file:56kB inactive_file:12kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:242380kB mlocked:0kB dirty:0kB writeback:12kB mapped:48kB shmem:140kB slab_reclaimable:2236kB slab_unreclaimable:144664kB kernel_stack:456kB pagetables:336kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:103 all_unreclaimable? yes
[ 5092.304962] lowmem_reserve[]: 0 0 0 0
[ 5092.306066] DMA: 0*4kB 1*8kB 0*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 1064kB
[ 5092.307862] DMA32: 10*4kB 2*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 1*512kB 1*1024kB 0*2048kB 0*4096kB = 1848kB
[ 5092.309467] 52 total pagecache pages
[ 5092.309862] 0 pages in swap cache
[ 5092.310317] Swap cache stats: add 0, delete 0, find 0/0
[ 5092.310862] Free swap = 0kB
[ 5092.311260] Total swap = 0kB
[ 5092.313796] 65530 pages RAM
[ 5092.313868] 22603 pages reserved
[ 5092.314324] 206 pages shared
[ 5092.314862] 39353 pages non-shared
[ 5092.315348] [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name
[ 5092.315867] [ 1] 0 1 438 19 0 0 0 init
[ 5092.316871] [ 1018] 0 1018 537 75 0 -17 -1000 udevd
[ 5092.318867] [ 2217] 101 2217 606 39 0 0 0 dbus-daemon
[ 5092.319865] [ 2825] 0 2825 481 29 0 0 0 dhcpcd
[ 5092.320865] [ 3497] 0 3497 1091 83 0 0 0 sshd
[ 5092.321969] [ 3535] 0 3535 477 31 0 0 0 agetty
[ 5092.322864] [ 3536] 0 3536 477 30 0 0 0 agetty
[ 5092.323864] [ 3537] 0 3537 477 29 0 0 0 agetty
[ 5092.325937] [ 3538] 0 3538 477 31 0 0 0 agetty
[ 5092.326865] [ 3539] 0 3539 477 31 0 0 0 agetty
[ 5092.327864] [ 3540] 0 3540 477 31 0 0 0 agetty
[ 5092.328864] [ 3541] 0 3541 1738 105 0 0 0 sshd
[ 5092.329865] [ 3545] 0 3545 745 72 0 0 0 bash
[ 5092.330864] [ 3550] 0 3550 706 43 0 0 0 screen
[ 5092.331866] [ 3551] 0 3551 772 124 0 0 0 screen
[ 5092.332965] [ 3552] 0 3552 745 77 0 0 0 bash
[ 5092.333865] [ 3557] 0 3557 745 77 0 0 0 bash
[ 5092.334867] [ 3562] 0 3562 536 75 0 -17 -1000 udevd
[ 5092.336865] [ 3567] 0 3567 536 75 0 -17 -1000 udevd
[ 5092.337865] [ 3887] 0 3887 935 54 0 0 0 bluetoothd
[ 5092.338864] [ 3896] 0 3896 458 24 0 0 0 l2test
[ 5092.339864] [ 3897] 0 3897 458 24 0 0 0 l2test
[ 5092.340933] [ 3942] 0 3942 458 29 0 0 0 l2test
[ 5092.341863] Kernel panic - not syncing: Out of memory and no killable processes...
[ 5092.341864]
[ 5092.342864] Pid: 3897, comm: l2test Not tainted 2.6.36-rc3 #5
[ 5092.343862] Call Trace:
[ 5092.344934] [<ffffffff813884d9>] panic+0x8c/0x199
[ 5092.345621] [<ffffffff810c0e54>] out_of_memory+0x2e4/0x2f0
[ 5092.345864] [<ffffffff810c3d43>] __alloc_pages_nodemask+0x693/0x6b0
[ 5092.346894] [<ffffffff810ea3e6>] cache_alloc_refill+0x2d6/0x5c0
[ 5092.347864] [<ffffffff810ea805>] __kmalloc+0x135/0x150
[ 5092.348871] [<ffffffff8130f2ae>] __alloc_skb+0x6e/0x150
[ 5092.349865] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.350628] [<ffffffff8130ace2>] sock_alloc_send_pskb+0x1c2/0x320
[ 5092.350935] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.351864] [<ffffffff81312add>] ? memcpy_fromiovec+0x6d/0x90
[ 5092.352864] [<ffffffff8130ae50>] sock_alloc_send_skb+0x10/0x20
[ 5092.353867] [<ffffffffa00e600f>] l2cap_create_iframe_pdu+0x9f/0x2c0 [l2cap]
[ 5092.354865] [<ffffffffa00e84b9>] l2cap_sock_sendmsg+0x5d9/0x910 [l2cap]
[ 5092.355864] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
[ 5092.356864] [<ffffffff8130725b>] sock_sendmsg+0xdb/0x100
[ 5092.357612] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
[ 5092.357931] [<ffffffff8138ba3c>] ? restore_args+0x0/0x30
[ 5092.358864] [<ffffffff813073c0>] sys_sendto+0xf0/0x130
[ 5092.359864] [<ffffffff8138b60b>] ? _raw_spin_unlock_irq+0x2b/0x40
[ 5092.360929] [<ffffffff81093cfd>] ? trace_hardirqs_on_caller+0x13d/0x180
[ 5092.361866] [<ffffffff81093d4d>] ? trace_hardirqs_on+0xd/0x10
[ 5092.362864] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.363653] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.364868] [<ffffffff810d3a00>] ? might_fault+0x40/0x90
[ 5092.365865] [<ffffffff8130740f>] sys_send+0xf/0x20
[ 5092.366945] [<ffffffff8132ccd6>] compat_sys_socketcall+0x146/0x1f0
[ 5092.367865] [<ffffffff81053ee4>] sysenter_dispatch+0x7/0x30
-------
Gustavo F. Padovan (1):
Bluetooth: Simplify L2CAP Streaming mode sending
^ permalink raw reply
* [PATCH] Bluetooth: Simplify L2CAP Streaming mode sending
From: Gustavo F. Padovan @ 2010-08-30 23:04 UTC (permalink / raw)
To: linux-bluetooth; +Cc: netdev, linux-kernel, marcel
As we don't have any error control on the Streaming mode, i.e., we don't
need to keep a copy of the skb for later resending we don't need to
call skb_clone() on it.
Then we can go one further here, and dequeue the skb before sending it,
that also means we don't need to look to sk->sk_send_head anymore.
This patch fixes a bug in Streaming mode sending procedure, the call to
skb_clone() was making the system run into OOM condition. I never got
that before 2.6.36, so I'm think that we acctually have regression
there.
Anyway, the patch saves memory and time when sending Streaming mode
data, so it is good to mainline.
Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 24 +++++++-----------------
1 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index fadf26b..80e98cd 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -1441,33 +1441,23 @@ static inline void l2cap_do_send(struct sock *sk, struct sk_buff *skb)
static void l2cap_streaming_send(struct sock *sk)
{
- struct sk_buff *skb, *tx_skb;
+ struct sk_buff *skb;
struct l2cap_pinfo *pi = l2cap_pi(sk);
u16 control, fcs;
- while ((skb = sk->sk_send_head)) {
- tx_skb = skb_clone(skb, GFP_ATOMIC);
-
- control = get_unaligned_le16(tx_skb->data + L2CAP_HDR_SIZE);
+ while ((skb = skb_dequeue(TX_QUEUE(sk)))) {
+ control = get_unaligned_le16(skb->data + L2CAP_HDR_SIZE);
control |= pi->next_tx_seq << L2CAP_CTRL_TXSEQ_SHIFT;
- put_unaligned_le16(control, tx_skb->data + L2CAP_HDR_SIZE);
+ put_unaligned_le16(control, skb->data + L2CAP_HDR_SIZE);
if (pi->fcs == L2CAP_FCS_CRC16) {
- fcs = crc16(0, (u8 *)tx_skb->data, tx_skb->len - 2);
- put_unaligned_le16(fcs, tx_skb->data + tx_skb->len - 2);
+ fcs = crc16(0, (u8 *)skb->data, skb->len - 2);
+ put_unaligned_le16(fcs, skb->data + skb->len - 2);
}
- l2cap_do_send(sk, tx_skb);
+ l2cap_do_send(sk, skb);
pi->next_tx_seq = (pi->next_tx_seq + 1) % 64;
-
- if (skb_queue_is_last(TX_QUEUE(sk), skb))
- sk->sk_send_head = NULL;
- else
- sk->sk_send_head = skb_queue_next(TX_QUEUE(sk), skb);
-
- skb = skb_dequeue(TX_QUEUE(sk));
- kfree_skb(skb);
}
}
--
1.7.2.2
^ permalink raw reply related
* [PATCH] Store new local name before writing it to HCI
From: Daniel Örstadius @ 2010-08-30 14:35 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 386 bytes --]
Store new local name to the filesystem and emit property changed
before actually writing the name to the chip. Avoids writing the
name twice by using a boolean variable in the btd_adapter struct.
The flag is needed since the name is read immediately after setting
it and since the name could be changed by using for example
hciconfig (in which case the flag would not be set).
/Daniel
[-- Attachment #2: 0001-Store-new-local-name-before-writing-it-to-HCI.patch --]
[-- Type: text/x-patch, Size: 2922 bytes --]
From 140d4d7f194c5da2fbf6584d8de3cdff68b70fec Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Mon, 30 Aug 2010 16:54:09 +0300
Subject: [PATCH] Store new local name before writing it to HCI
Store new local name to the filesystem and emit property changed
before actually writing the name to the chip. Avoids writing the
name twice by using a boolean variable in the btd_adapter struct.
The flag is needed since the name is read immediately after setting
it and since the name could be changed by using for example
hciconfig (in which case the flag would not be set).
---
src/adapter.c | 35 ++++++++++++++++++++++-------------
1 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 377bacc..0dbb295 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -137,6 +137,8 @@ struct btd_adapter {
gint ref;
GSList *powered_callbacks;
+
+ gboolean name_stored;
};
static void adapter_set_pairable_timeout(struct btd_adapter *adapter,
@@ -950,17 +952,21 @@ void adapter_update_local_name(bdaddr_t *bdaddr, uint8_t status, void *ptr)
strncpy((char *) dev->name, (char *) rp.name, MAX_NAME_LENGTH);
- write_local_name(bdaddr, (char *) dev->name);
+ if (!adapter->name_stored) {
+ write_local_name(bdaddr, (char *) dev->name);
- update_ext_inquiry_response(adapter);
+ name = g_strdup((char *) dev->name);
- name = g_strdup((char *) dev->name);
+ if (connection)
+ emit_property_changed(connection, adapter->path,
+ ADAPTER_INTERFACE, "Name",
+ DBUS_TYPE_STRING, &name);
+ g_free(name);
+ }
- if (connection)
- emit_property_changed(connection, adapter->path,
- ADAPTER_INTERFACE, "Name",
- DBUS_TYPE_STRING, &name);
- g_free(name);
+ adapter->name_stored = FALSE;
+
+ update_ext_inquiry_response(adapter);
}
void adapter_setname_complete(bdaddr_t *local, uint8_t status)
@@ -998,16 +1004,18 @@ static DBusMessage *set_name(DBusConnection *conn, DBusMessage *msg,
if (strncmp(name, (char *) dev->name, MAX_NAME_LENGTH) == 0)
goto done;
- if (!adapter->up) {
- strncpy((char *) adapter->dev.name, name, MAX_NAME_LENGTH);
- write_local_name(&adapter->bdaddr, name);
- emit_property_changed(connection, adapter->path,
+ strncpy((char *) adapter->dev.name, name, MAX_NAME_LENGTH);
+ write_local_name(&adapter->bdaddr, name);
+ emit_property_changed(connection, adapter->path,
ADAPTER_INTERFACE, "Name",
DBUS_TYPE_STRING, &name);
- } else {
+
+ if (adapter->up) {
int err = adapter_ops->set_name(adapter->dev_id, name);
if (err < 0)
return failed_strerror(msg, err);
+
+ adapter->name_stored = TRUE;
}
done:
@@ -2504,6 +2512,7 @@ int adapter_stop(struct btd_adapter *adapter)
adapter->cache_enable = TRUE;
adapter->pending_cod = 0;
adapter->off_requested = FALSE;
+ adapter->name_stored = FALSE;
call_adapter_powered_callbacks(adapter, FALSE);
--
1.6.0.4
^ permalink raw reply related
* RE: [PATCH] Bluetooth: BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-08-30 6:58 UTC (permalink / raw)
To: padovan; +Cc: linux-bluetooth
In-Reply-To: <20100827195550.GA11191@vigoh>
Oops, I missed that. It was done automatically somehow. It wasn't my intention of doing this.
Will fix it.
Thanks,
/Waldek
>-----Original Message-----
>From: Gustavo F. Padovan [mailto:pao@profusion.mobi] On Behalf
>Of Gustavo F. Padovan
>Sent: Friday, August 27, 2010 9:56 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] Bluetooth: BT_SECURITY_HIGH requires 16
>digit pin code
>
>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: [RFCOMM] Cannot complete connections into Ubuntu
From: Shreesh Holla @ 2010-08-30 6:53 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=j6ch9_oQwb0xK9xPZ5btMUSqoHx4D8N8YM6nt@mail.gmail.com>
----- Original Message ----
From: Luiz Augusto von Dentz <luiz.dentz@gmail.com>
To: Shreesh Holla <hshreesh@yahoo.com>
Cc: linux-bluetooth@vger.kernel.org
Sent: Tue, August 24, 2010 8:00:11 PM
Subject: Re: [RFCOMM] Cannot complete connections into Ubuntu
Hi,
On Mon, Aug 23, 2010 at 3:22 AM, Shreesh Holla <hshreesh@yahoo.com> wrote:
> Hi,
>
> I'm running Ubuntu with 2.6.32.24 kernel.
> I have a simple RFCOMM program running on Windows Mobile which would connect
> into the Ubuntu machine. Of course I have the corresponding service running on
> the Ubuntu machine. The RFCOMM port numbers do match up.
>
> This was working a few days back and now with no changes(i.e. the same
> executable), it refuses to work anymore.
>
> So is there some configuration needed now?
>
> I have the dongle running in Ubuntu as : hciconfig hci0 noauth noencrypt pscan
------ Luis says:
>>Had you tried the latest bluez, I did some changes to pair that solve
>>some problem with RFCOMM and ssp. If that doesn't help maybe you
>>should try to produce some logs of the so we can take a look.
>>Regards,
>>--
>>Luiz Augusto von Dentz
>>Computer Engineer
Luis,
It seems the problem is in aborting an open RFCOMM connection. And this seems to
be an issue even with the 2.6.29 kernel. If I do abort a connection i.e. not
gracefully i.e. by killing the applications then this is what I see:
- The connection is refused until reboot
- I tried to reset by doing a hciconfig hci0 reset AND also hciconfig hci0
up/down
- When I do a reset actually the VM hangs completely i.e. the only way is to
power off and restart the VM
- I do have two Bluetooth dongles - but I dont think that could be any issue.
So, fundamentally as long as I do a graceful shutdown of the RFCOMM connections
all seems to be fine. This issue happens sometimes on the first abort. But
definitely within three attempts. This is what I have been able to figure out
since my last e-mail.
Do let me know if this helps. If you would need more details such as the hcidump
logs or dmesg logs - I ca send that too.
Thanks,
Shreesh
^ permalink raw reply
* Re: Cannot build BlueZ Release 4.70...
From: alok barsode @ 2010-08-29 13:58 UTC (permalink / raw)
To: alok barsode, Ho, Albert O, linux-bluetooth@vger.kernel.org,
marcel@holtmann.org
In-Reply-To: <20100829101959.GA10891@jh-x301>
Hi Johan,
On Sun, Aug 29, 2010 at 3:49 PM, Johan Hedberg <johan.hedberg@gmail.com> wr=
ote:
> Hi,
>
> On Sun, Aug 29, 2010, alok barsode wrote:
>> > The configure line invocation is taken from README file. =A0Below are
>> > copy-paste exact errors.
>>
>> I tried building using bootstrap-configure and it built fine. =A0But
>> when I tried building with ./bootstrap and ./configure =A0it 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?
I dont think this is a autotools issue.(my autoconf ver is 2.64 and
automake ver is 1.11
gcc version is 4.4.1. which are fairly new).
If I give "--enable-alsa" option to configure it builds fine.
acinclude.m4 sets the SBC variable if either alsa or gstreamer or
test are enabled via configure.
In Makefile.am , the attrib_sources are put under SBC conditional.
I dont have much idea about attrib, maybe put the attrib_sources under
a ATTRIBPLUGIN conditional might solve this issue?
Cheers,
Alok.
>
> Johan
>
^ permalink raw reply
* new kmemleak in kernel 2.6.35.4
From: Toralf Förster @ 2010-08-29 11:20 UTC (permalink / raw)
To: linux-bluetooth
Hello
with this version I observed this kmemleak which seems to be new since 2.6.34
at my ThinkPad T400 at an almost stable Gentoo Linux (which however might be
rather related to suspend2ram) :
unreferenced object 0xf5333e00 (size 192):
comm "async/29", pid 2911, jiffies 43041559 (age 24568.685s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 02 c7 34 65 e4 26 ce 11 ..........4e.&..
00 00 00 00 00 58 f0 f5 01 00 00 00 00 00 00 00 .....X..........
backtrace:
[<c122f8d7>] kmemleak_alloc+0x27/0x50
[<c109c34f>] kmem_cache_alloc+0x9f/0xe0
[<c11d393f>] __alloc_skb+0x2f/0x100
[<f9b4ab0c>] hci_send_cmd+0x2c/0xf0 [bluetooth]
[<f9b4abe9>] hci_reset_req+0x19/0x20 [bluetooth]
[<f9b4b170>] __hci_request+0x70/0xe0 [bluetooth]
[<f9b4b338>] hci_dev_do_close+0x158/0x1b0 [bluetooth]
[<f9b4b3cb>] hci_unregister_dev+0x3b/0xa0 [bluetooth]
[<f9cc1a8c>] btusb_disconnect+0x4c/0xa0 [btusb]
[<f863839b>] usb_unbind_interface+0x3b/0x160 [usbcore]
[<c118902c>] __device_release_driver+0x4c/0xa0
[<c1189130>] device_release_driver+0x20/0x30
[<f86386ef>] usb_driver_release_interface+0x6f/0x80 [usbcore]
[<f8638722>] usb_rebind_intf+0x22/0x80 [usbcore]
[<f86387fd>] do_unbind_rebind+0x5d/0x90 [usbcore]
[<f86388e3>] usb_resume+0xb3/0xc0 [usbcore]
--
MfG/Kind regards
Toralf Förster
pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
^ 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
* 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
* 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: 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
* [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: 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
* 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: [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
* 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] 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 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] 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] 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
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