* [PATCHv4 3/3] Bluetooth: check L2CAP length in first ACL fragment
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Current Bluetooth code assembles fragments of big L2CAP packets
in l2cap_recv_acldata and then checks allowed L2CAP size in
assemled L2CAP packet (pi->imtu < skb->len).
The patch moves allowed L2CAP size check to the early stage when
we receive the first fragment of L2CAP packet. We do not need to
reserve and keep L2CAP fragments for bad packets.
Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
and Gustavo Padovan <padovan@profusion.mobi>.
Trace below is received when using stress tools sending big
fragmented L2CAP packets.
...
[ 1712.798492] swapper: page allocation failure. order:4, mode:0x4020
[ 1712.804809] [<c0031870>] (unwind_backtrace+0x0/0xdc) from [<c00a1f70>]
(__alloc_pages_nodemask+0x4)
[ 1712.814666] [<c00a1f70>] (__alloc_pages_nodemask+0x47c/0x4d4) from
[<c00a1fd8>] (__get_free_pages+)
[ 1712.824645] [<c00a1fd8>] (__get_free_pages+0x10/0x3c) from [<c026eb5c>]
(__alloc_skb+0x4c/0xfc)
[ 1712.833465] [<c026eb5c>] (__alloc_skb+0x4c/0xfc) from [<bf28c738>]
(l2cap_recv_acldata+0xf0/0x1f8 )
[ 1712.843322] [<bf28c738>] (l2cap_recv_acldata+0xf0/0x1f8 [l2cap]) from
[<bf0094ac>] (hci_rx_task+0x)
...
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index ce8f5e4..3aa2e9c 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4654,6 +4654,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
if (flags & ACL_START) {
struct l2cap_hdr *hdr;
+ struct sock *sk;
+ u16 cid;
int len;
if (conn->rx_len) {
@@ -4673,6 +4675,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
hdr = (struct l2cap_hdr *) skb->data;
len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
+ cid = __le16_to_cpu(hdr->cid);
if (len == skb->len) {
/* Complete frame received */
@@ -4689,6 +4692,19 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
goto drop;
}
+ sk = l2cap_get_chan_by_scid(&conn->chan_list, cid);
+
+ if (sk && l2cap_pi(sk)->imtu < len - L2CAP_HDR_SIZE) {
+ BT_ERR("Frame exceeding recv MTU (len %d, MTU %d)",
+ len, l2cap_pi(sk)->imtu);
+ bh_unlock_sock(sk);
+ l2cap_conn_unreliable(conn, ECOMM);
+ goto drop;
+ }
+
+ if (sk)
+ bh_unlock_sock(sk);
+
/* Allocate skb for the complete frame (with header) */
conn->rx_skb = bt_skb_alloc(len, GFP_ATOMIC);
if (!conn->rx_skb)
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 2/3] Bluetooth: check for l2cap header in start fragment
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
BLUETOOTH SPECIFICATION Version 4.0 [Vol 3] page 36 mentioned
"Note: Start Fragments always begin with the Basic L2CAP header
of a PDU."
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
---
net/bluetooth/l2cap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index 9fad312..ce8f5e4 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -4664,7 +4664,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
l2cap_conn_unreliable(conn, ECOMM);
}
- if (skb->len < 2) {
+ /* Start fragment always begin with Basic L2CAP header */
+ if (skb->len < L2CAP_HDR_SIZE) {
BT_ERR("Frame is too short (len %d)", skb->len);
l2cap_conn_unreliable(conn, ECOMM);
goto drop;
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 1/3] Bluetooth: fix MTU L2CAP configuration parameter
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284550124-31201-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
When receiving L2CAP negative configuration response with respect
to MTU parameter we modify wrong field. MTU here means proposed
value of MTU that the remote device intends to transmit. So for local
L2CAP socket it is pi->imtu.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
---
net/bluetooth/l2cap.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index c784703..9fad312 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -2771,10 +2771,10 @@ static int l2cap_parse_conf_rsp(struct sock *sk, void *rsp, int len, void *data,
case L2CAP_CONF_MTU:
if (val < L2CAP_DEFAULT_MIN_MTU) {
*result = L2CAP_CONF_UNACCEPT;
- pi->omtu = L2CAP_DEFAULT_MIN_MTU;
+ pi->imtu = L2CAP_DEFAULT_MIN_MTU;
} else
- pi->omtu = val;
- l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->omtu);
+ pi->imtu = val;
+ l2cap_add_conf_opt(&ptr, L2CAP_CONF_MTU, 2, pi->imtu);
break;
case L2CAP_CONF_FLUSH_TO:
--
1.7.0.4
^ permalink raw reply related
* [PATCHv4 0/3] Bluetooth: L2CAP robustness fixes
From: Emeltchenko Andrei @ 2010-09-15 11:28 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Fixes increase L2CAP robustness to DOS attacks to BT stack.
Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
and Gustavo Padovan <padovan@profusion.mobi>.
Andrei Emeltchenko (3):
Bluetooth: fix MTU L2CAP configuration parameter
Bluetooth: check for l2cap header in start fragment
Bluetooth: check L2CAP length in first ACL fragment
net/bluetooth/l2cap.c | 25 +++++++++++++++++++++----
1 files changed, 21 insertions(+), 4 deletions(-)
^ permalink raw reply
* Re: [PATCHv3 3/3] Bluetooth: check L2CAP length in first ACL fragment
From: Andrei Emeltchenko @ 2010-09-15 11:17 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: linux-bluetooth
In-Reply-To: <20100914182147.GB5398@vigoh>
Hi Gustavo,
On Tue, Sep 14, 2010 at 9:21 PM, Gustavo F. Padovan
<padovan@profusion.mobi> wrote:
> Hi Andrei,
>
> * Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-09-09 10:43:01 +0300]:
>
>> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>>
>> Current Bluetooth code assembles fragments of big L2CAP packets
>> in l2cap_recv_acldata and then checks allowed L2CAP size in
>> assemled L2CAP packet (pi->imtu < skb->len).
>>
>> The patch moves allowed L2CAP size check to the early stage when
>> we receive the first fragment of L2CAP packet. We do not need to
>> reserve and keep L2CAP fragments for bad packets.
>>
>> Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
>>
>> Trace below is received when using stress tools sending big
>> fragmented L2CAP packets.
>> ...
>> [ 1712.798492] swapper: page allocation failure. order:4, mode:0x4020
>> [ 1712.804809] [<c0031870>] (unwind_backtrace+0x0/0xdc) from [<c00a1f70>]
>> (__alloc_pages_nodemask+0x4)
>> [ 1712.814666] [<c00a1f70>] (__alloc_pages_nodemask+0x47c/0x4d4) from
>> [<c00a1fd8>] (__get_free_pages+)
>> [ 1712.824645] [<c00a1fd8>] (__get_free_pages+0x10/0x3c) from [<c026eb5c>]
>> (__alloc_skb+0x4c/0xfc)
>> [ 1712.833465] [<c026eb5c>] (__alloc_skb+0x4c/0xfc) from [<bf28c738>]
>> (l2cap_recv_acldata+0xf0/0x1f8 )
>> [ 1712.843322] [<bf28c738>] (l2cap_recv_acldata+0xf0/0x1f8 [l2cap]) from
>> [<bf0094ac>] (hci_rx_task+0x)
>> ...
>>
>> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>> ---
>> net/bluetooth/l2cap.c | 17 +++++++++++++++++
>> 1 files changed, 17 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
>> index ce8f5e4..c95fbd8 100644
>> --- a/net/bluetooth/l2cap.c
>> +++ b/net/bluetooth/l2cap.c
>> @@ -4654,6 +4654,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>>
>> if (flags & ACL_START) {
>> struct l2cap_hdr *hdr;
>> + struct sock *sk;
>> + u16 cid;
>> int len;
>>
>> if (conn->rx_len) {
>> @@ -4673,6 +4675,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>>
>> hdr = (struct l2cap_hdr *) skb->data;
>> len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
>> + cid = __le16_to_cpu(hdr->cid);
>>
>> if (len == skb->len) {
>> /* Complete frame received */
>> @@ -4689,6 +4692,20 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>> goto drop;
>> }
>>
>> + sk = l2cap_get_chan_by_scid(&conn->chan_list, cid);
>> +
>> + if (sk && l2cap_pi(sk)->imtu < len) {
>> + BT_ERR("Frame exceeding recv MTU (len %d, MTU %d)",
>> + len, l2cap_pi(sk)->imtu);
>
> I think you have to check if the imtu is less than (len -
> L2CAP_HDR_SIZE) because we don't count the header in the MTU.
>
>> + conn->rx_len = 0; /* needed? */
>
> It's not needed. rx_len is always zero here.
>
Thanks, I will fix those issues.
Regards,
Andrei
^ permalink raw reply
* Re: [PATCH] Bluetooth: remove extra newline from debug output
From: Ville Tervo @ 2010-09-15 10:29 UTC (permalink / raw)
To: ext Emeltchenko Andrei; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1283952413-22791-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Wed, Sep 08, 2010 at 03:26:53PM +0200, ext Emeltchenko Andrei wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/rfcomm/core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 16b79f3..a7e4f2d 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1698,7 +1698,7 @@ static int rfcomm_recv_frame(struct rfcomm_session *s, struct sk_buff *skb)
> break;
>
> default:
> - BT_ERR("Unknown packet type 0x%02x\n", type);
> + BT_ERR("Unknown packet type 0x%02x", type);
> break;
> }
> kfree_skb(skb);
--
Ville
^ permalink raw reply
* [PATCH] Add handling of TITLE contact's field in vCard
From: Rafał Michalski @ 2010-09-15 10:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafał Michalski
[-- Attachment #1: Type: text/plain, Size: 1 bytes --]
[-- Attachment #2: 0001-Add-handling-of-TITLE-contact-s-field-in-vCard.patch --]
[-- Type: text/x-patch, Size: 5142 bytes --]
From fffde75fb874b9db4afbb51dc0d8d7a72ed04ef0 Mon Sep 17 00:00:00 2001
From: Rafal Michalski <michalski.raf@gmail.com>
Date: Wed, 15 Sep 2010 09:16:11 +0200
Subject: [PATCH] Add handling of TITLE contact's field in vCard
After pulling contacts this field wasn't presented in downloaded vCard
structure in spite of that it existed (not empty). Now it shows downloaded
TITLE field (using database query).
---
| 23 ++++++++++++-----------
| 4 ++++
| 1 +
3 files changed, 17 insertions(+), 11 deletions(-)
--git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 43c2e28..3161927 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 36
-#define PULL_QUERY_COL_AMOUNT 37
+#define CONTACTS_ID_COL 37
+#define PULL_QUERY_COL_AMOUNT 38
#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 33
-#define COL_SENT 34
-#define COL_ANSWERED 35
+#define COL_DATE 34
+#define COL_SENT 35
+#define COL_ANSWERED 36
#define ADDR_FIELD_AMOUNT 7
#define CONTACTS_QUERY_ALL \
@@ -68,7 +68,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "\"NOTACALL\" \"false\" \"false\" ?c " \
+ "nco:title(?a) \"NOTACALL\" \"false\" \"false\" ?c " \
"WHERE { " \
"?c a nco:PersonContact . " \
"OPTIONAL { ?c nco:hasPhoneNumber ?h . \
@@ -119,7 +119,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"?call a nmo:Call ; " \
@@ -171,7 +171,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"?call a nmo:Call ; " \
@@ -223,7 +223,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"?call a nmo:Call ; " \
@@ -273,7 +273,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(?c) " \
- "nmo:receivedDate(?call) " \
+ "nco:title(?a) nmo:receivedDate(?call) " \
"nmo:isSent(?call) nmo:isAnswered(?call) ?c " \
"WHERE { " \
"{ " \
@@ -349,7 +349,7 @@
"nco:role(?a) nco:pobox(?pw) nco:extendedAddress(?pw) " \
"nco:streetAddress(?pw) nco:locality(?pw) nco:region(?pw) " \
"nco:postalcode(?pw) nco:country(?pw) nco:contactUID(<%s>) " \
- "\"NOTACALL\" \"false\" \"false\" <%s> " \
+ "nco:title(?a) \"NOTACALL\" \"false\" \"false\" <%s> " \
"WHERE { " \
"<%s> a nco:Contact . " \
"OPTIONAL { <%s> nco:hasPhoneNumber ?h . \
@@ -865,6 +865,7 @@ add_entry:
contact->department = g_strdup(reply[23]);
contact->role = g_strdup(reply[24]);
contact->uid = g_strdup(reply[32]);
+ contact->title = g_strdup(reply[33]);
set_call_type(contact, reply[COL_DATE], reply[COL_SENT],
reply[COL_ANSWERED]);
--git a/plugins/vcard.c b/plugins/vcard.c
index e277ced..bc22177 100644
--- a/plugins/vcard.c
+++ b/plugins/vcard.c
@@ -539,6 +539,9 @@ void phonebook_add_contact(GString *vcards, struct phonebook_contact *contact,
if (filter & FILTER_ROLE)
vcard_printf_tag(vcards, format, "ROLE", NULL, contact->role);
+ if (filter & FILTER_TITLE)
+ vcard_printf_tag(vcards, format, "TITLE", NULL, contact->title);
+
if (filter & FILTER_X_IRMC_CALL_DATETIME)
vcard_printf_datetime(vcards, contact);
@@ -597,6 +600,7 @@ void phonebook_contact_free(struct phonebook_contact *contact)
g_free(contact->company);
g_free(contact->department);
g_free(contact->role);
+ g_free(contact->title);
g_free(contact->datetime);
g_free(contact);
}
--git a/plugins/vcard.h b/plugins/vcard.h
index 0ed51b9..d1c225e 100644
--- a/plugins/vcard.h
+++ b/plugins/vcard.h
@@ -79,6 +79,7 @@ struct phonebook_contact {
char *company;
char *department;
char *role;
+ char *title;
char *datetime;
int calltype;
};
--
1.6.3.3
^ permalink raw reply related
* Re: Request for input regarding new driver in MFD for GPS_Bluetooth_FM controller CG2900
From: Par-Gunnar Hjalmdahl @ 2010-09-15 10:14 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Alan Cox, linus.walleij, linux-kernel, linux-bluetooth
In-Reply-To: <AANLkTinctyN3d4o8vq-8pAH67FaoAXOiX3=kobWkNTms@mail.gmail.com>
Hi Pavan,
Thanks for your comments and sorry for me taking time to answer your mail.
See below for answers.
>
> ok bit more of information ....
> We don;t use the hciattach, instead we have our own daemon which opens
> up the UART and installs the line discipline (not N_HCI, but similar
> one called N_SHARED) when the hciconfig hci0 up happens or even when
> /dev/radio0 (FM V4L2 device) happens or when generic GPS character
> device (/dev/tigps) happens...
:-) We also have our own user space application for opening the UART
and setting the line disc since we don't want to depend completely on
hciattach, which contains more than we need, and also misses stuff
that we want to do towards our specific controller. I just used it as
an example since that is the common BlueZ way to open the Bluetooth
transport.
>
> There is non-mailine driver which gets modified to get into mainline @
> http://git.omapzoom.org/?p=kernel/omap.git;a=tree;f=drivers/misc/ti-
> st;h=028ff4a739d7b59b94d0c613b5ef510ff338b65d;hb=refs/heads/p-android-
> omap-2.6.32
>
> feel free to have a look at it...
> Yes our solution too works with BlueZ and non-exactly a MFD driver but
> it is a simple platform device driver .. by looks of things the driver
> can run as is for your chip too .. (except for the firmware search and
> download part .. may be...).
Your code is in a lot of ways similar to ours (which is not so strange
since you address the same market with your chip as we do with ours),
but there are several differences that would at least for now make it
impossible for us to use your driver. When we post our first patches
(which will hopefully be in a few days) you can see for yourself. But
I don't think there is a simple way for us to re-use your driver.
>
> and note when we would want to support SPI transport for the same, we
> plan a SPI-TTY driver ('ala usb-serial) where-in we can install this
> N_TI_WL line discipline on that /dev/ttySPI0 device, and the SPI
> related stuff to be handled by the spi-tty.c which registers itself as
> a tty_device and a tty_driver ....
Our SPI usage will be a bit different, where we don't use TTY for our
driver. We will use the SPI directly instead.
>
> regards,
> Pavan
>
> On Fri, Sep 10, 2010 at 2:07 PM, Pavan Savoy <pavan_savoy@sify.com>
> wrote:
> > Can you directly make use of the ti-st driver which is currently
> staged?
> > It has _EXACTLY_ the same thing.... which is REALLY REALLY surprising
> !!!
:-) As I said earlier this is quite natural since both TI and
ST-Ericsson address the same market segments.
/P-G
^ permalink raw reply
* Re: [PATCH] Bluetooth: Don't clear the blacklist when closing the HCI device
From: Ville Tervo @ 2010-09-15 9:49 UTC (permalink / raw)
To: ext johan.hedberg@gmail.com
Cc: linux-bluetooth@vger.kernel.org,
Hedberg Johan (Nokia-MS/Helsinki)
In-Reply-To: <1284017559-13510-1-git-send-email-johan.hedberg@gmail.com>
On Thu, Sep 09, 2010 at 09:32:39AM +0200, ext johan.hedberg@gmail.com wrote:
> From: Johan Hedberg <johan.hedberg@nokia.com>
>
> Clearing the blacklist in hci_dev_do_close() would mean that user space
> needs to do extra work to re-block devices after a DEVDOWN-DEVUP cycle.
> This patch removes the clearing of the blacklist in this case and
> thereby saves user space from the extra work.
>
> Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com>
Acked-by: Ville Tervo <ville.tervo@nokia.com>
> ---
> net/bluetooth/hci_core.c | 1 -
> 1 files changed, 0 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
> index c52f091..bc2a052 100644
> --- a/net/bluetooth/hci_core.c
> +++ b/net/bluetooth/hci_core.c
> @@ -562,7 +562,6 @@ static int hci_dev_do_close(struct hci_dev *hdev)
> hci_dev_lock_bh(hdev);
> inquiry_cache_flush(hdev);
> hci_conn_hash_flush(hdev);
> - hci_blacklist_clear(hdev);
> hci_dev_unlock_bh(hdev);
>
> hci_notify(hdev, HCI_DEV_DOWN);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Waldemar.Rymarkiewicz @ 2010-09-15 9:18 UTC (permalink / raw)
To: marcel, suraj; +Cc: Suraj.Sumangala, linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1284522264.2405.89.camel@localhost.localdomain>
Hi Marcel,=20
>if we talk about the SAP server role found in a mobile phone,=20
>then that support clearly needs to interact with the telephony=20
>stack. Since when SAP is active the telephony stack needs to=20
>be suspended and all SIM transaction being forwarded.
I agree, but a telephony stack needs to care about its state when SAP is ac=
tive. Not all linux based mobile platforms use ofono.
>Currently I would be thinking that the SAP implementation=20
>should be done inside oFono actually. Since then you have=20
>direct access to the hardware. The D-Bus approach just doesn't=20
>sound correct to me. I could be of course wrong, but I can't=20
>wrap my mind around on how you can make this work.
I assume that ofono should handle sap transactions (as it's kind of hardwar=
e abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did fo=
r sap transactions in spec (http://www.wirelessmodemapi.com/), and not impl=
ement sap profile itself. Again, not all use ofono as telephony stack.
Sorry, I don't know ofono well. What's the interface between ofono and blue=
z?=20
>Even with file descriptor passing this doesn't look like the=20
>right approach. If we need a hardware abstraction than we=20
>either use oFono or we have to create some SAP hardware access=20
>abstraction.
I agree with this too. I prefere to have a sap implementation as bluez plug=
in, but we need to define api for sim operations which could be implemented=
in ofono or other proprietary stacks. I guess dbus was intended to be kind=
of hw abstraction api.
Some time ago Claudio sent proposal implementation of sap server where he d=
efined api for a driver to sim.
Regards,
/Waldek=
^ permalink raw reply
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Nicolas GUILBAUD @ 2010-09-15 8:56 UTC (permalink / raw)
To: Suraj Sumangala
Cc: Suraj Sumangala, Marcel Holtmann, linux-bluetooth,
Jothikumar Mothilal
In-Reply-To: <4C9082C8.9030502@Atheros.com>
>-----Message d'origine-----
>De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth->owner@vger.kernel.org] De la part de Suraj =
Sumangala
>Envoy=E9=A0: mercredi 15 septembre 2010 10:25
>=C0=A0: Nicolas GUILBAUD
>Cc=A0: Suraj Sumangala; Marcel Holtmann; =
linux-bluetooth@vger.kernel.org; >Jothikumar Mothilal
>Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>
>Hi Nicolas,
>
>On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
>> Hello Marcel and Suraj,
>>
>> I agree with Marcel, because in standard Mobile phone implementation, =
the >SIM card is directly connected to the Modem. To access the SIM =
card, AT >command (or proprietary commands) are needed, oFono implements =
both of them >to access SIM card in Modem side, but in my understanding =
there is no >possibilities to disconnect modem (in oFono) due to SIM =
SAP.
>>
>> In the case where SIM card is connected to the Application processor =
>(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any >SIM implementation in Linux, may be we have to specify it.
>>
>Other than transferring APDUs, SAP profile also specifies operations on =
>the SIM cards like SIM Reset, SIM power on/off, Getting Card reader=20
>status etc.
>
>How do we do these operations case of mobile phones?
There are specific interfaces, you can find example of interface in =
Nokia Wireless Open API (uicc_fp.pdf) in =
http://www.wirelessmodemapi.com/, register is free.
SIM reset is an OFF command following by ON command (ATR comes with ON), =
card status is a local information...=20
Best Regards,
Nicolas.
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-15 8:24 UTC (permalink / raw)
To: Nicolas GUILBAUD
Cc: Suraj Sumangala, Marcel Holtmann, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <A9AC1023FCA4654D92AC24C2A8F6A09201A2B923@renesas4bis.renesas-rdf.local>
Hi Nicolas,
On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
> Hello Marcel and Suraj,
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.
>
> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it.
>
Other than transferring APDUs, SAP profile also specifies operations on
the SIM cards like SIM Reset, SIM power on/off, Getting Card reader
status etc.
How do we do these operations case of mobile phones?
>
> Best Regards,
>
> Nicolas.
Regards
Suraj
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: Johan Hedberg @ 2010-09-15 8:10 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <1284537527-22783-1-git-send-email-andrzej.kaczmarek@tieto.com>
Hi Andrzej,
On Wed, Sep 15, 2010, Andrzej Kaczmarek wrote:
> On behalf of ST-Ericsson SA, below is our proposal of API for out of band
> association model. To give you a bit more overview how this will be integrated
> into BlueZ:
>
> .RequestRemoteOobData should be called from hcid_dbus_request_io_cap to
> check if any data was exchange/retrieved from remote device. Returned data
> will be stored (if any) and used to reply with proper IO capabilities as well
> as to to return retrieved data. This will involve some changes in flow from
> io_capa_request onwards.
>
> Please let me know if you have any comments. Implementation will follow.
I'd prefer to do this completely internally in bluetoothd through a
plugin. Do you see any reasons why not to do it that way? We still need
some UI to call CreatePairedDevice but a plugin that knows about local
platform specific OOB mechanisms (e.g. NFC) could provide the core
daemon with enough info to set the IO capabilities correctly and provide
the necessary OOB values.
Johan
^ permalink raw reply
* [RFC] D-Bus API for out of band association model
From: Andrzej Kaczmarek @ 2010-09-15 7:58 UTC (permalink / raw)
To: linux-bluetooth; +Cc: par-gunnar.p.hjalmdahl, Andrzej Kaczmarek
Hi,
On behalf of ST-Ericsson SA, below is our proposal of API for out of band
association model. To give you a bit more overview how this will be integrated
into BlueZ:
.RequestRemoteOobData should be called from hcid_dbus_request_io_cap to
check if any data was exchange/retrieved from remote device. Returned data
will be stored (if any) and used to reply with proper IO capabilities as well
as to to return retrieved data. This will involve some changes in flow from
io_capa_request onwards.
Please let me know if you have any comments. Implementation will follow.
BR,
Andrzej
---
doc/adapter-api.txt | 14 ++++++++++++++
doc/agent-api.txt | 14 ++++++++++++++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/doc/adapter-api.txt b/doc/adapter-api.txt
index 6098c76..0dd628e 100644
--- a/doc/adapter-api.txt
+++ b/doc/adapter-api.txt
@@ -5,6 +5,7 @@ Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
Copyright (C) 2005-2006 Johan Hedberg <johan.hedberg@nokia.com>
Copyright (C) 2005-2006 Claudio Takahasi <claudio.takahasi@indt.org.br>
Copyright (C) 2006-2007 Luiz von Dentz <luiz.dentz@indt.org.br>
+Copyright (C) 2010 ST-Ericsson SA <andrzej.kaczmarek@tieto.com>
Adapter hierarchy
@@ -173,6 +174,19 @@ Methods dict GetProperties()
Possible errors: org.bluez.Error.DoesNotExist
+ struct{
+ array{byte}, array{byte}
+ } GetLocalOobData()
+
+ Retrieves current C and R values used for out-of-band
+ bonding association model.
+
+ The return value is struct containing two arrays of
+ bytes, C and R values retrieved from local device.
+
+ Possible errors: org.bluez.Error.InProgress
+ org.bluez.Error.Failed
+
Signals PropertyChanged(string name, variant value)
This signal indicates a changed value of the given
diff --git a/doc/agent-api.txt b/doc/agent-api.txt
index d8d35c0..323ccf1 100644
--- a/doc/agent-api.txt
+++ b/doc/agent-api.txt
@@ -3,6 +3,7 @@ BlueZ D-Bus Agent API description
Copyright (C) 2004-2010 Marcel Holtmann <marcel@holtmann.org>
Copyright (C) 2005-2006 Johan Hedberg <johan.hedberg@nokia.com>
+Copyright (C) 2010 ST-Ericsson SA <andrzej.kaczmarek@tieto.com>
Agent hierarchy
@@ -68,6 +69,19 @@ Methods void Release()
Possible errors: org.bluez.Error.Rejected
org.bluez.Error.Canceled
+ struct{
+ array{byte}, array{byte}
+ } RequestRemoteOobData(object device)
+
+ This method gets called when the service daemon
+ needs out-of-band data for an authentication.
+
+ The return value should be struct containing two
+ arrays of bytes, C and R values retrieved from
+ remote device.
+
+ Possible errors: org.bluez.Error.NoData
+
void Authorize(object device, string uuid)
This method gets called when the service daemon
--
1.7.0.4
^ permalink raw reply related
* RE: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Nicolas GUILBAUD @ 2010-09-15 7:32 UTC (permalink / raw)
To: Suraj Sumangala, Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth, Jothikumar Mothilal
In-Reply-To: <4C906430.90900@Atheros.com>
Hello Marcel and Suraj,
-----Message d'origine-----
De=A0: linux-bluetooth-owner@vger.kernel.org =
[mailto:linux-bluetooth-owner@vger.kernel.org] De la part de Suraj =
Sumangala
Envoy=E9=A0: mercredi 15 septembre 2010 08:14
=C0=A0: Marcel Holtmann
Cc=A0: Suraj Sumangala; linux-bluetooth@vger.kernel.org; Jothikumar =
Mothilal
Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>Hi Marcel,
>
>On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
>> Hi Suraj,
>>
>>>
>>> I would really appreciate if you can give me any idea about working
>>> around the above mentioned issues.
>>
>> if we talk about the SAP server role found in a mobile phone, then =
that
>> support clearly needs to interact with the telephony stack. Since =
when
>> SAP is active the telephony stack needs to be suspended and all SIM
>> transaction being forwarded.
>>
>> Currently I would be thinking that the SAP implementation should be =
done
>> inside oFono actually. Since then you have direct access to the
>> hardware. The D-Bus approach just doesn't sound correct to me. I =
could
>> be of course wrong, but I can't wrap my mind around on how you can =
make
>> this work.
>>
>> Even with file descriptor passing this doesn't look like the right
>> approach. If we need a hardware abstraction than we either use oFono =
or
>> we have to create some SAP hardware access abstraction.
>
>The advantage I thought d-bus has would be the generic interface it=20
>could provide. But, if we have a system with direct access to the Sim=20
>access hardware, D-bus could possibly become a bottleneck.
>
>I would really appreciate if others who have worked with Sim Access and =
>OFono can give their comments.
>
>Also, please share some information on regarding the SIM reader=20
>implementation in linux based systems.
>
>>
>> The SAP client role found a carkit is obviously a different story.
>>
>> Regards
>>
>> Marcel
>>
>>
>Regards
>Suraj
I agree with Marcel, because in standard Mobile phone implementation, =
the SIM card is directly connected to the Modem. To access the SIM card, =
AT command (or proprietary commands) are needed, oFono implements both =
of them to access SIM card in Modem side, but in my understanding there =
is no possibilities to disconnect modem (in oFono) due to SIM SAP.
In the case where SIM card is connected to the Application processor =
(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any SIM implementation in Linux, may be we have to specify it.=20
Best Regards,
Nicolas.
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-15 6:14 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1284522264.2405.89.camel@localhost.localdomain>
Hi Marcel,
On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>>
>> I would really appreciate if you can give me any idea about working
>> around the above mentioned issues.
>
> if we talk about the SAP server role found in a mobile phone, then that
> support clearly needs to interact with the telephony stack. Since when
> SAP is active the telephony stack needs to be suspended and all SIM
> transaction being forwarded.
>
> Currently I would be thinking that the SAP implementation should be done
> inside oFono actually. Since then you have direct access to the
> hardware. The D-Bus approach just doesn't sound correct to me. I could
> be of course wrong, but I can't wrap my mind around on how you can make
> this work.
>
> Even with file descriptor passing this doesn't look like the right
> approach. If we need a hardware abstraction than we either use oFono or
> we have to create some SAP hardware access abstraction.
The advantage I thought d-bus has would be the generic interface it
could provide. But, if we have a system with direct access to the Sim
access hardware, D-bus could possibly become a bottleneck.
I would really appreciate if others who have worked with Sim Access and
OFono can give their comments.
Also, please share some information on regarding the SIM reader
implementation in linux based systems.
>
> The SAP client role found a carkit is obviously a different story.
>
> Regards
>
> Marcel
>
>
Regards
Suraj
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Marcel Holtmann @ 2010-09-15 3:44 UTC (permalink / raw)
To: Suraj Sumangala
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <4C8F160B.4010401@Atheros.com>
Hi Suraj,
> >> Below is the Sim Access Profile server role API discription.
> >> Please let me know your comments.
> >
> > my obvious question is why do we wanna do this over D-Bus and not
> > connect it directly to the hardware via a plugin?
>
> You meant creating something like a tty device and let the hardware
> connect directly to this?
>
> The initial plan was to use a D-Bus file descriptor and transfer the SAP
> packets to the agent over it.
>
> The problem was the SAP packet format is specified by the Bluetooth SAP
> spec. I could not relate it to any generic packet format ( Like HF, HS,
> DUN can be mapped to an AT parser).
>
> I am not sure if any existing card reader implementation could parse it
> to extract SIM card related data (APDU) without additional support for it.
>
> Another reason I thought about D-Bus was because, most of the SAP
> operations are Request/Response type like Reset, SimOn etc.
>
> It mapped better with a Method/Signal communication than packet transfer.
>
> Some of the card reader implementation I checked had proprietary packet
> format. So not sure how we could interface with them.
> >
> > Remember that SIM transaction are timing critical and just relaying them
> > over D-Bus doesn't sound the right approach right now. While of course
> > even bluetoothd can't guarantee and response time, it is clearly better
> > than over D-Bus.
> >
>
> I would really appreciate if you can give me any idea about working
> around the above mentioned issues.
if we talk about the SAP server role found in a mobile phone, then that
support clearly needs to interact with the telephony stack. Since when
SAP is active the telephony stack needs to be suspended and all SIM
transaction being forwarded.
Currently I would be thinking that the SAP implementation should be done
inside oFono actually. Since then you have direct access to the
hardware. The D-Bus approach just doesn't sound correct to me. I could
be of course wrong, but I can't wrap my mind around on how you can make
this work.
Even with file descriptor passing this doesn't look like the right
approach. If we need a hardware abstraction than we either use oFono or
we have to create some SAP hardware access abstraction.
The SAP client role found a carkit is obviously a different story.
Regards
Marcel
^ permalink raw reply
* Re: [PATCHv3 3/3] Bluetooth: check L2CAP length in first ACL fragment
From: Gustavo F. Padovan @ 2010-09-14 18:21 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1284018181-29928-4-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-09-09 10:43:01 +0300]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Current Bluetooth code assembles fragments of big L2CAP packets
> in l2cap_recv_acldata and then checks allowed L2CAP size in
> assemled L2CAP packet (pi->imtu < skb->len).
>
> The patch moves allowed L2CAP size check to the early stage when
> we receive the first fragment of L2CAP packet. We do not need to
> reserve and keep L2CAP fragments for bad packets.
>
> Updated version after comments from Mat Martineau <mathewm@codeaurora.org>
>
> Trace below is received when using stress tools sending big
> fragmented L2CAP packets.
> ...
> [ 1712.798492] swapper: page allocation failure. order:4, mode:0x4020
> [ 1712.804809] [<c0031870>] (unwind_backtrace+0x0/0xdc) from [<c00a1f70>]
> (__alloc_pages_nodemask+0x4)
> [ 1712.814666] [<c00a1f70>] (__alloc_pages_nodemask+0x47c/0x4d4) from
> [<c00a1fd8>] (__get_free_pages+)
> [ 1712.824645] [<c00a1fd8>] (__get_free_pages+0x10/0x3c) from [<c026eb5c>]
> (__alloc_skb+0x4c/0xfc)
> [ 1712.833465] [<c026eb5c>] (__alloc_skb+0x4c/0xfc) from [<bf28c738>]
> (l2cap_recv_acldata+0xf0/0x1f8 )
> [ 1712.843322] [<bf28c738>] (l2cap_recv_acldata+0xf0/0x1f8 [l2cap]) from
> [<bf0094ac>] (hci_rx_task+0x)
> ...
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap.c | 17 +++++++++++++++++
> 1 files changed, 17 insertions(+), 0 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index ce8f5e4..c95fbd8 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -4654,6 +4654,8 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>
> if (flags & ACL_START) {
> struct l2cap_hdr *hdr;
> + struct sock *sk;
> + u16 cid;
> int len;
>
> if (conn->rx_len) {
> @@ -4673,6 +4675,7 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
>
> hdr = (struct l2cap_hdr *) skb->data;
> len = __le16_to_cpu(hdr->len) + L2CAP_HDR_SIZE;
> + cid = __le16_to_cpu(hdr->cid);
>
> if (len == skb->len) {
> /* Complete frame received */
> @@ -4689,6 +4692,20 @@ static int l2cap_recv_acldata(struct hci_conn *hcon, struct sk_buff *skb, u16 fl
> goto drop;
> }
>
> + sk = l2cap_get_chan_by_scid(&conn->chan_list, cid);
> +
> + if (sk && l2cap_pi(sk)->imtu < len) {
> + BT_ERR("Frame exceeding recv MTU (len %d, MTU %d)",
> + len, l2cap_pi(sk)->imtu);
I think you have to check if the imtu is less than (len -
L2CAP_HDR_SIZE) because we don't count the header in the MTU.
> + conn->rx_len = 0; /* needed? */
It's not needed. rx_len is always zero here.
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Bluetooth: remove extra newline from debug output
From: Andrei Emeltchenko @ 2010-09-14 13:49 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1283952413-22791-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
ping
On Wed, Sep 8, 2010 at 4:26 PM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/rfcomm/core.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
> index 16b79f3..a7e4f2d 100644
> --- a/net/bluetooth/rfcomm/core.c
> +++ b/net/bluetooth/rfcomm/core.c
> @@ -1698,7 +1698,7 @@ static int rfcomm_recv_frame(struct rfcomm_session *s, struct sk_buff *skb)
> break;
>
> default:
> - BT_ERR("Unknown packet type 0x%02x\n", type);
> + BT_ERR("Unknown packet type 0x%02x", type);
> break;
> }
> kfree_skb(skb);
> --
> 1.7.0.4
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCHv3 0/3] Bluetooth: L2CAP robustness fixes
From: Andrei Emeltchenko @ 2010-09-14 13:48 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1284018181-29928-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
ping
On Thu, Sep 9, 2010 at 10:42 AM, Emeltchenko Andrei
<Andrei.Emeltchenko.news@gmail.com> wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Fixes increase L2CAP robustness to DOS attacks to BT stack.
>
> Andrei Emeltchenko (3):
> Bluetooth: fix MTU L2CAP configuration parameter
> Bluetooth: check for l2cap header in start fragment
> Bluetooth: check L2CAP length in first ACL fragment
>
> net/bluetooth/l2cap.c | 26 ++++++++++++++++++++++----
> 1 files changed, 22 insertions(+), 4 deletions(-)
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: set LE advertise not working...
From: Ville Tervo @ 2010-09-14 11:41 UTC (permalink / raw)
To: ext Mike Tsai
Cc: Claudio Takahasi, Anderson Lizardo, Pavan Savoy, Anderson Briglia,
linux-bluetooth@vger.kernel.org
In-Reply-To: <35B17FE5076C7040809188FBE7913F983F2381E185@SC1EXMB-MBCL.global.atheros.com>
On Fri, Sep 10, 2010 at 11:35:50PM +0200, ext Mike Tsai wrote:
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Claudio Takahasi
> Sent: Friday, September 10, 2010 2:03 PM
> To: Anderson Lizardo
> Cc: Pavan Savoy; Anderson Briglia; linux-bluetooth@vger.kernel.org
> Subject: Re: set LE advertise not working...
>
> On Fri, Sep 10, 2010 at 5:35 PM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
> > On Fri, Sep 10, 2010 at 3:01 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> >> No, I don't suppose my controller was in a advertising state.. even if
> >> it was why the return 0x0c? (command disallowed ..)
> >>
> >> I wanted to know whether you have some HCI-VS commands which sort of
> >> enable the LE (AMP/radio/controller) ?
> >> Is it only then the leadv command works? Or does it just works right-away.
> >> I have one of those all in 1 chips.. bt/fm-rx-tx/gps so I am wondering
> >> should I do something to enable BLE and is it some sort of un-spoken
> >> standard?
> >
> > Does LE scan work for this same hardware?
> >
> > Do you have some windows software to test this hardware ? if so, you
> > can try putting one device in advertise mode there , then attempt
> > lescan on the other (from linux)... If it works, most probably the
> > hardware might require some initialization...
> >
> > At least some hardware requires firmware upload and vendor specific
> > one-time initialization which (I think) is out of scope for hciconfig.
> >
> > Regards,
> > --
> > Anderson Lizardo
> > OpenBossa Labs - INdT
> > Manaus - Brazil
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
> > Hi All,
>
> > I noticed that some LE hardwares don't allow to enable scanning or
> > advertising when inquiry scan and/or page scan are enabled.
> > Try to disable it using hciconfig or the D-Bus method before to start
> > LE operations.
>
> > Regards,
> > Claudio.
>
> Hello,
>
> Now I remember, dual mode devices (BR/EDR/LE) are not allowed to work as peripheral (or slave) device. The default advertising mode is "connectable indirect advertising mode". When you try to enable the advertising, you are trying to make this dual mode device as a potential slave to other LE masters and that's why the controller rejects the command.
>
Where is this stated?
> Scan should work though.
>
> I don't think you can ever connect 2 dual mode devices together, you need a single mode device (LE only) as the slave,
Well my two dual mode controllers connect fine with eachother.
--
Ville
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-14 6:28 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Suraj Sumangala, linux-bluetooth@vger.kernel.org,
Jothikumar Mothilal
In-Reply-To: <1284442946.2405.50.camel@localhost.localdomain>
Hi Marcel,
On 9/14/2010 11:12 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Below is the Sim Access Profile server role API discription.
>> Please let me know your comments.
>
> my obvious question is why do we wanna do this over D-Bus and not
> connect it directly to the hardware via a plugin?
You meant creating something like a tty device and let the hardware
connect directly to this?
The initial plan was to use a D-Bus file descriptor and transfer the SAP
packets to the agent over it.
The problem was the SAP packet format is specified by the Bluetooth SAP
spec. I could not relate it to any generic packet format ( Like HF, HS,
DUN can be mapped to an AT parser).
I am not sure if any existing card reader implementation could parse it
to extract SIM card related data (APDU) without additional support for it.
Another reason I thought about D-Bus was because, most of the SAP
operations are Request/Response type like Reset, SimOn etc.
It mapped better with a Method/Signal communication than packet transfer.
Some of the card reader implementation I checked had proprietary packet
format. So not sure how we could interface with them.
>
> Remember that SIM transaction are timing critical and just relaying them
> over D-Bus doesn't sound the right approach right now. While of course
> even bluetoothd can't guarantee and response time, it is clearly better
> than over D-Bus.
>
I would really appreciate if you can give me any idea about working
around the above mentioned issues.
> Regards
>
> Marcel
>
>
Regards
Suraj
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Marcel Holtmann @ 2010-09-14 5:42 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth, Jothikumar.Mothilal
In-Reply-To: <1284374584-12282-1-git-send-email-suraj@atheros.com>
Hi Suraj,
> Below is the Sim Access Profile server role API discription.
> Please let me know your comments.
my obvious question is why do we wanna do this over D-Bus and not
connect it directly to the hardware via a plugin?
Remember that SIM transaction are timing critical and just relaying them
over D-Bus doesn't sound the right approach right now. While of course
even bluetoothd can't guarantee and response time, it is clearly better
than over D-Bus.
Regards
Marcel
^ permalink raw reply
* Re: [RFC] BlueZ D-Bus Sim Access Profile Server API description
From: Suraj Sumangala @ 2010-09-14 5:00 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org, Jothikumar Mothilal
In-Reply-To: <20100913164718.GA9448@jh-x301>
Hi,
On 9/13/2010 10:17 PM, Johan Hedberg wrote:
> Why would you want to expose these extra SAP profile details to the
> Agent? The bluetoothd side should take care of all details like this
> whenever possible. The only relevant data that needs to be transmitted
> from the Agent to bluetoothd in this case is the ATR and bluetoothd can
> then proceed with creating a proper SAP response packet based on that.
>
>> How do we map the D-Bus error return to the ResultCode?
>
> You'd need to define some sort of mapping table yourself. The list of
> possible result codes is quite short (8 in SAP 1.1) so this shouldn't be
> too hard. E.g. "Error, card not accessible" (0x02) could map to the
> D-Bus error org.bluez.SapError.CardNotAccessible.
The idea was to return the ResultCode as a string from the agent and map
it to the corresponding code in the server.
If we can define error codes for each result, that would be fine.
>
> Johan
Regards
Suraj
^ permalink raw reply
* Re: MP3 over A2DP issue
From: pl bossart @ 2010-09-13 22:09 UTC (permalink / raw)
To: 박찬열; +Cc: linux-bluetooth
In-Reply-To: <001301cb4efe$f723f660$e56be320$%park@samsung.com>
> Could you send me "bluetoothd" log?
I tried again on a different laptop with a clean Fedora install. Same
issue, cannot send mp3 to the headset (worked fine with decode/sbc
encode):
[ume@plb ~]$ gst-launch filesrc location=~/AURAL/Audio/maxwork.mp3 !
mp3parse ! a2dpsink device=00:0B:E4:94:31:9D
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
0:00:00.019779029 2452 0x83cfc98 ERROR avdtpsink
audio/gstavdtpsink.c:1328:gst_avdtp_sink_audioservice_recv:<avdtpsink>
BT_OPEN failed : Invalid argument(22)
0:00:00.019809767 2452 0x83cfc98 ERROR avdtpsink
audio/gstavdtpsink.c:1085:gst_avdtp_sink_configure:<avdtpsink> Error
while receiving device confirmation
0:00:00.020036315 2452 0x83cfc98 ERROR avdtpsink
audio/gstavdtpsink.c:1328:gst_avdtp_sink_audioservice_recv:<avdtpsink>
BT_START_STREAM failed : Success(0)
0:00:00.020050426 2452 0x83cfc98 ERROR avdtpsink
audio/gstavdtpsink.c:937:gst_avdtp_sink_stream_start:<avdtpsink> Error
while stream start confirmation
WARNING: from element
/GstPipeline:pipeline0/GstA2dpSink:a2dpsink0/GstAvdtpSink:avdtpsink:
Internal data flow problem.
Additional debug info:
gstbasesink.c(3436): gst_base_sink_chain_unlocked ():
/GstPipeline:pipeline0/GstA2dpSink:a2dpsink0/GstAvdtpSink:avdtpsink:
Received buffer without a new-segment. Assuming timestamps start from 0.
ERROR: from element /GstPipeline:pipeline0/GstFileSrc:filesrc0:
Internal data flow error.
Additional debug info:
gstbasesrc.c(2559): gst_base_src_loop ():
/GstPipeline:pipeline0/GstFileSrc:filesrc0:
streaming task paused, reason error (-5)
Execution ended after 1757132 ns.
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...
And I see the following messages in /var/log/messages:
Sep 13 16:40:51 localhost kernel: usb 4-2: Product: ThinkPad Bluetooth
with Enhanced Data Rate II
Sep 13 16:40:51 localhost kernel: Bluetooth: Core ver 2.15
Sep 13 16:40:51 localhost kernel: Bluetooth: HCI device and connection
manager initialized
Sep 13 16:40:51 localhost kernel: Bluetooth: HCI socket layer initialized
Sep 13 16:40:51 localhost kernel: Bluetooth: Generic Bluetooth USB
driver ver 0.6
Sep 13 16:40:51 localhost kernel: thinkpad_acpi: rfkill switch
tpacpi_bluetooth_sw: radio is unblocked
Sep 13 16:40:57 localhost bluetoothd[1647]: Bluetooth daemon 4.64
Sep 13 16:40:58 localhost bluetoothd[1651]: Starting SDP server
Sep 13 16:40:58 localhost kernel: Bluetooth: L2CAP ver 2.14
Sep 13 16:40:58 localhost kernel: Bluetooth: L2CAP socket layer initialized
Sep 13 16:40:58 localhost bluetoothd[1651]: Parsing
/etc/bluetooth/network.conf failed: No such file or directory
Sep 13 16:40:58 localhost kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Sep 13 16:40:58 localhost kernel: Bluetooth: BNEP filters: protocol multicast
Sep 13 16:40:58 localhost bluetoothd[1651]: bridge pan0 created
Sep 13 16:40:58 localhost bluetoothd[1651]: Parsing
/etc/bluetooth/input.conf failed: No such file or directory
Sep 13 16:40:58 localhost bluetoothd[1651]: Parsing
/etc/bluetooth/audio.conf failed: No such file or directory
Sep 13 16:40:58 localhost bluetoothd[1651]: HCI dev 0 registered
Sep 13 16:40:58 localhost kernel: Bluetooth: SCO (Voice Link) ver 0.6
Sep 13 16:40:58 localhost kernel: Bluetooth: SCO socket layer initialized
Sep 13 16:40:58 localhost bluetoothd[1651]: HCI dev 0 up
Sep 13 16:40:58 localhost bluetoothd[1651]: Starting security manager 0
Sep 13 16:40:58 localhost bluetoothd[1651]: Parsing
/etc/bluetooth/serial.conf failed: No such file or directory
Sep 13 16:40:58 localhost kernel: Bluetooth: RFCOMM TTY layer initialized
Sep 13 16:40:58 localhost kernel: Bluetooth: RFCOMM socket layer initialized
Sep 13 16:40:58 localhost kernel: Bluetooth: RFCOMM ver 1.11
Sep 13 16:40:58 localhost bluetoothd[1651]: Adapter
/org/bluez/1647/hci0 has been enabled
Sep 13 16:42:01 localhost bluetoothd[1651]: link_key_request
(sba=00:22:68:EB:F8:5D, dba=00:0B:E4:94:31:9D)
Sep 13 16:42:02 localhost bluetoothd[1651]: link_key_request
(sba=00:22:68:EB:F8:5D, dba=00:0B:E4:94:31:9D)
Sep 13 16:42:04 localhost bluetoothd[1651]: Badly formated or
unrecognized command: AT+CSRSF=1,1,1,1,1,7
Sep 13 16:42:48 localhost bluetoothd[1651]: seid 2 not available or locked
Sep 13 16:42:48 localhost bluetoothd[1651]: seid not opened
No idea if this is due to a bad configuration or a bad headset...
I also see a bunch of bt-usb messages, not sure if this is related
Sep 13 16:40:51 localhost kernel: usbcore: registered new interface driver btusb
Sep 13 16:41:01 localhost kernel: btusb_intr_complete: hci0 urb
f3ff1b00 failed to resubmit (1)
Sep 13 16:41:01 localhost kernel: btusb_bulk_complete: hci0 urb
f3ff1980 failed to resubmit (1)
Sep 13 16:41:01 localhost kernel: btusb_bulk_complete: hci0 urb
f3ff1780 failed to resubmit (1)
Sep 13 16:42:08 localhost kernel: btusb_intr_complete: hci0 urb
f21c0180 failed to resubmit (1)
Sep 13 16:42:08 localhost kernel: btusb_bulk_complete: hci0 urb
f21c0b00 failed to resubmit (1)
Sep 13 16:42:08 localhost kernel: btusb_bulk_complete: hci0 urb
f21c0000 failed to resubmit (1)
Sep 13 16:42:18 localhost kernel: btusb_intr_complete: hci0 urb
f0eb2180 failed to resubmit (1)
Sep 13 16:42:18 localhost kernel: btusb_bulk_complete: hci0 urb
f0eb2a80 failed to resubmit (1)
Sep 13 16:42:18 localhost kernel: btusb_bulk_complete: hci0 urb
f0eb2100 failed to resubmit (1)
Sep 13 16:42:40 localhost kernel: btusb_intr_complete: hci0 urb
f0d99900 failed to resubmit (1)
Sep 13 16:42:40 localhost kernel: btusb_bulk_complete: hci0 urb
f0d99780 failed to resubmit (1)
Sep 13 16:42:40 localhost kernel: btusb_bulk_complete: hci0 urb
f0d99f00 failed to resubmit (1)
Sep 13 16:42:50 localhost kernel: btusb_intr_complete: hci0 urb
f0d82000 failed to resubmit (1)
Sep 13 16:42:50 localhost kernel: btusb_bulk_complete: hci0 urb
f0d82e00 failed to resubmit (1)
Sep 13 16:42:50 localhost kernel: btusb_bulk_complete: hci0 urb
f0d82200 failed to resubmit (1)
Thanks for your feedback,
-Pierre
^ 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