* 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: [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 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: [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: [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: 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
* [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] 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
* 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] 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: 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: [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: 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
* [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: [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
* 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
* [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
* [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 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 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
* Re: [PATCH] Add handling of TITLE contact's field in vCard
From: Johan Hedberg @ 2010-09-15 12:49 UTC (permalink / raw)
To: Rafał Michalski; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikjKRY_ZBjNeyJrsSObb4qVNfNgdpdUzghmYrD8@mail.gmail.com>
Hi Rafal,
On Wed, Sep 15, 2010, Rafał Michalski wrote:
> 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).
> ---
> plugins/phonebook-tracker.c | 23 ++++++++++++-----------
> plugins/vcard.c | 4 ++++
> plugins/vcard.h | 1 +
> 3 files changed, 17 insertions(+), 11 deletions(-)
Thanks for the patch. It's now upstream.
Johan
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: Claudio Takahasi @ 2010-09-15 13:30 UTC (permalink / raw)
To: Andrzej Kaczmarek, linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <20100915081047.GA15065@jh-x301>
On Wed, Sep 15, 2010 at 5:10 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> 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
> --
Hi Andrzej,
I did some testing with OOB last year.
See my branch git://git.infradead.org/users/cktakahasi/bluez.git
oob-displayyesno
About the API changes. MAYBE, Hash and Randomizer could be only
adapter properties.
For the remote Hash and Randomizer still not clear to me what is the
best way to allow external apps to set those values, but in my opinion
BlueZ should not know the OOB mechanism, only the capability is
enough.
Regards,
Claudio
^ permalink raw reply
* Re: [PATCH 00/10] Media API
From: Johan Hedberg @ 2010-09-15 13:35 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1284387337-18822-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Mon, Sep 13, 2010, Luiz Augusto von Dentz wrote:
> Luiz Augusto von Dentz (10):
> Add media API documentation
> Add rule to enabling talking to org.bluez.MediaEndpoint
> Add option to enable/disable unix ipc via audio.conf
> Add support for media transport in gstreamer plugin
> Add simple-endpoint test script
> Add initial implementation of org.bluez.Media spec
> Introduce headset_get_inband
> Update a2dp transport delay when it changes
> Remove local cache for nrec and inband
> Add proper checks for MediaTransport.SetProperty
>
> Makefile.am | 6 +-
> audio/a2dp-codecs.h | 116 ++++++++
> audio/a2dp.c | 749 +++++++++++++++++++++++++++++++++++++++++--------
> audio/a2dp.h | 15 +
> audio/avdtp.c | 88 +++----
> audio/avdtp.h | 5 +-
> audio/gsta2dpsink.c | 33 ++-
> audio/gsta2dpsink.h | 1 +
> audio/gstavdtpsink.c | 609 +++++++++++++++++++++++++++++++++++++++-
> audio/gstavdtpsink.h | 6 +
> audio/headset.c | 10 +
> audio/headset.h | 1 +
> audio/main.c | 9 -
> audio/manager.c | 66 +++++
> audio/manager.h | 2 +
> audio/media.c | 689 +++++++++++++++++++++++++++++++++++++++++++++
> audio/media.h | 54 ++++
> audio/sink.c | 179 ++-----------
> audio/source.c | 174 ++----------
> audio/transport.c | 758 ++++++++++++++++++++++++++++++++++++++++++++++++++
> audio/transport.h | 36 +++
> audio/unix.c | 1 +
> doc/media-api.txt | 169 +++++++++++
> src/bluetooth.conf | 1 +
> test/simple-endpoint | 126 +++++++++
> 25 files changed, 3395 insertions(+), 508 deletions(-)
> create mode 100644 audio/a2dp-codecs.h
> create mode 100644 audio/media.c
> create mode 100644 audio/media.h
> create mode 100644 audio/transport.c
> create mode 100644 audio/transport.h
> create mode 100644 doc/media-api.txt
> create mode 100755 test/simple-endpoint
All patches have been pushed upstream now (with the few minor changes
that we discussed). Next step: talk to PulseAudio guys and get this
merged there too.
Johan
^ permalink raw reply
* Re: [RFC] D-Bus API for out of band association model
From: jaikumar Ganesh @ 2010-09-15 17:13 UTC (permalink / raw)
To: Claudio Takahasi
Cc: Andrzej Kaczmarek, linux-bluetooth, par-gunnar.p.hjalmdahl
In-Reply-To: <AANLkTimm++uSFQmkKHF+vHzp=Kc0tYpzb+xqq=eG6jnW@mail.gmail.com>
Hi,
On Wed, Sep 15, 2010 at 6:30 AM, Claudio Takahasi
<claudio.takahasi@openbossa.org> wrote:
> On Wed, Sep 15, 2010 at 5:10 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> 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
>> --
>
> Hi Andrzej,
>
> I did some testing with OOB last year.
> See my branch git://git.infradead.org/users/cktakahasi/bluez.git
> oob-displayyesno
>
> About the API changes. MAYBE, Hash and Randomizer could be only
> adapter properties.
> For the remote Hash and Randomizer still not clear to me what is the
> best way to allow external apps to set those values, but in my opinion
> BlueZ should not know the OOB mechanism, only the capability is
> enough.
[Resending, because the mail to linux-bluetooth bounced. Sorry if some
folks got it twice]
We started to work on this API too last week. Not complete yet to post
to the mailing list.
The approach we took was this:
a) Since OOB authentication is just another means of authentication
compared to Passkey, Pin entry,
we added an agent API (similar to the lines of other
authentication mechanisms) that will ask for the Out Of Band data.
b) We added an API to the adapter to get the local Out of Band Data
c) Currently, RegisterAgent is called to register with the
capabilities. Since OOB is part of the capabilities data structure, we
added OOB to agent structure which already has the capabilities.
d) We added an API variant of createPairedDevice which will be used
for OutOfBand Pairing. When the device agent is created, the OOB field
in agent is updated.
e) When a capability request comes from the remote side the agent OOB
field is checked. It will be set if the pairing is initiated locally
through d).
For incoming pairing requests if the Agent has OOB field set but
there is no device specific agent, we need to make an Agent API call
asking if
there is OOB data for this remote device.
We left it to the users of the API - regarding the OOB channel to use.
It can be NFC or any other trusted channel.
Comments ?
Regards,
Jaikumar
>
> Regards,
> Claudio
> --
> 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: Possible regression with skb_clone() in 2.6.36
From: Gustavo F. Padovan @ 2010-09-15 18:42 UTC (permalink / raw)
To: Mat Martineau; +Cc: linux-bluetooth, netdev, linux-kernel, marcel, davem
In-Reply-To: <20100910194509.GC19693@vigoh>
Hi Mat,
* Gustavo F. Padovan <padovan@profusion.mobi> [2010-09-10 16:45:09 -0300]:
> Hi Mat,
>
> * Mat Martineau <mathewm@codeaurora.org> [2010-09-10 09:53:31 -0700]:
>
> >
> > Gustavo -
> >
> > I'm not sure why the streaming code used to work, but this does not
> > look like an skb_clone() problem. Your patch to remove the
> > skb_clone() call in l2cap_streaming_send() addresses the root cause of
> > this crash.
> >
> > On Wed, 8 Sep 2010, Gustavo F. Padovan wrote:
> >
> > > 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() we workaround the problem. The
> > > patch is good anyway because it saves memory and time.
> > >
> > > By now I have no idea on how to fix this.
> > >
> > > <snip>
> >
> > This has to do with the sk->sk_wmem_alloc accounting that controls the
> > amount of write buffer space used on the socket.
> >
> > When the L2CAP streaming mode socket segments its data, it allocates
> > memory using sock_alloc_send_skb() (via bt_skb_send_alloc()). Before
> > that allocation call returns, skb_set_owner_w() is called on the new
> > skb. This adds to sk->sk_wmem_alloc and sets skb->destructor so that
> > sk->sk_wmem_alloc is correctly updated when the skb is freed.
> >
> > When that skb is cloned, the clone is not "owned" by the write buffer.
> > The clone's destructor is set to NULL in __skb_clone(). The version
> > of l2cap_streaming_send() that runs out of memory is passing the
> > non-owned skb clone down to the HCI layer. The original skb (the one
> > that's "owned by w") is immediately freed, which adjusts
> > sk->sk_wmem_alloc back down - the socket thinks it has unlimited write
> > buffer space. As a result, bt_skb_send_alloc() never blocks waiting
> > for buffer space (or returns EAGAIN for nonblocking writes) and the
> > HCI send queue keeps growing.
>
> If the problem is what you are saying, add a skb_set_owner_w(skb, sk) on
> the cloned skb should solve the problem, but it doesn't. That's exactly
> what tcp_transmit_skb() does. Also that just appeared in 2.6.36, is was
> working fine before, i.e, we have a regression here.
I've run some other tests and what you said also fixes the problem for
Streaming Mode. If I use skb_set_owner_w() on the cloned skb, everything
works fine. But we still have the problem for ERTM as I described.
send() blocks wainting for memory. The regression is there yet.
:(
>
> >
> > This isn't a problem for the ERTM sends, because the original skbs are
> > kept in the ERTM tx queue until they are acked. Once they're acked,
> > the write buffer space is freed and additional skbs can be allocated.
>
> It affects ERTM as well, but in that case the kernel doesn't crash
> because ERTM block on sending trying to allocate memory. Then we are not
> able to receive any ack (everything stays queued in sk_backlog_queue as
> the sk is owned by the user) and ERTM stalls.
>
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox