* Re: Read Characteristic Value vs. Read Long Characteristic Values
From: Anderson Lizardo @ 2011-01-26 18:28 UTC (permalink / raw)
To: Brian Gix; +Cc: BlueZ development
In-Reply-To: <1296064762.2656.137.camel@ubuntuLab1>
On Wed, Jan 26, 2011 at 1:59 PM, Brian Gix <bgix@codeaurora.org> wrote:
> Hi Anderson,
>
> On Wed, 2011-01-26 at 09:58 -0400, Anderson Lizardo wrote:
>> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
>> <anderson.lizardo@openbossa.org> wrote:
>> > Looks like more a PTS bug, but makes me wonder if it is not better for
>> > BlueZ to have separate procedures instead of this "automatic" usage of
>> > read blob request ?
>>
>> BTW, the test which presented this issue with sending spurious read
>> blob request is named "Read Characteristic Descriptors – by client". I
>> also can see that the behavior you implemented satisfies both "Read
>> Long Characteristic Value - by client" and "Read Long Characteristic
>> Descriptor - by client" tests. All theses tests come from the GATT TS
>> document.
>
> Can you tell me the specific Test Case number(s) that you are having
> difficulty testing? I do not have a current release of the PTS tool
> available to me at this time, although I do know that PTS is developed
> in parallel, and is just as prone to bugs as the rest of us. I should be
> able to test this stuff against the PTS guys at UPF week after next, and
> talk to the guys who are writing it.
At least these break with the current implementation:
TP/GAR/CL/BV-06-C (PTS does not expect a Read blob request after Read Request)
TP/GAR/CL/BI-12-C (test procedure expects Read Blob Request, not Read Request)
TP/GAR/CL/BI-13-C (same as above)
TP/GAR/CL/BI-14-C (same as above)
TP/GAR/CL/BI-28-C (same as above)
TP/GAR/CL/BV-07-C (same as above)
Except for the first test case, the specific requirement for a Read
Blob Request is defined on the test procedure of the GATT TS document
itself, so in these cases I don't think it's PTS bug.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: Read Characteristic Value vs. Read Long Characteristic Values
From: Brian Gix @ 2011-01-26 17:59 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: BlueZ development
In-Reply-To: <AANLkTi=gZQ2Ps2yoXT7+08E3AruB5pAAy+ib+wBcQY4S@mail.gmail.com>
Hi Anderson,
On Wed, 2011-01-26 at 09:58 -0400, Anderson Lizardo wrote:
> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
> > Looks like more a PTS bug, but makes me wonder if it is not better for
> > BlueZ to have separate procedures instead of this "automatic" usage of
> > read blob request ?
>
> BTW, the test which presented this issue with sending spurious read
> blob request is named "Read Characteristic Descriptors – by client". I
> also can see that the behavior you implemented satisfies both "Read
> Long Characteristic Value - by client" and "Read Long Characteristic
> Descriptor - by client" tests. All theses tests come from the GATT TS
> document.
Can you tell me the specific Test Case number(s) that you are having
difficulty testing? I do not have a current release of the PTS tool
available to me at this time, although I do know that PTS is developed
in parallel, and is just as prone to bugs as the rest of us. I should be
able to test this stuff against the PTS guys at UPF week after next, and
talk to the guys who are writing it.
Thanks,
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
From: Brian Gix @ 2011-01-26 17:54 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Johan Hedberg, Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <1295993092.2656.114.camel@ubuntuLab1>
Hi Luiz, Vinicius & all,
On Tue, 2011-01-25 at 14:04 -0800, Brian Gix wrote:
> Hi Luiz & all,
>
> On Tue, 2011-01-25 at 23:44 +0200, Luiz Augusto von Dentz wrote:
> > Hi,
> >
> > On Tue, Jan 25, 2011 at 8:35 PM, Brian Gix <bgix@codeaurora.org> wrote:
> > > Hi Johan,
> > >
> > > On Tue, 2011-01-25 at 19:59 +0200, Johan Hedberg wrote:
> > >> Hi Brian,
> > >>
> > >> On Tue, Jan 25, 2011, Brian Gix wrote:
> > >> > >From Page 607:
> > >> > "If both devices have out of band authentication data, then the
> > >> > Authentication Requirements Flags shall be ignored when selecting the
> > >> > pairing method and the Out of Band pairing method shall be used. If both
> > >> > devices have not set the MITM option in the Authentication Requirements
> > >> > Flags, then the IO capabilities shall be ignored and the Just Works
> > >> > association model shall be used. Otherwise the IO capabilities of the
> > >> > devices shall be used to determine the pairing method as defined in
> > >> > Table 2.4."
> > >> >
> > >> > In the test case I ran, only One device (i.e. NOT BOTH) had the MITM
> > >> > option set. So my reading is that the IO Capabilities should be ignored,
> > >> > and JUST_WORKS used.
> > >>
> > >> It certainly is an unusual form of English. It's saying "If both devices
> > >> have <x>", i.e. the condition <x> needs to be fulfilled by both devices
> > >> for the statement to be true. In this case the condition is "not set the
> > >> MITM option", i.e. both devices need to fulfill the condition "not set
> > >> the MITM option". Doesn't that then mean that it's not enough for one
> > >> device to not set the MITM flag, but both devices need to have it unset
> > >> for just-works to take place?
> > >
> > > Yes, it is very unfortunate and awkward English.
> > >
> > > I am going to look for any errata that might be more explicit, so that
> > > an absolute truth table based on: MITM, OOB, and IO-Caps can be
> > > constructed.
> > >
> > > But the Truth table as I understood it from conversations at UPFs and
> > > WGs and in my notes was:
> > >
> > > 1. If BOTH devices have OOB available, it is used and results in MITM
> > > 2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM
> > > 3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used
> > > and MAY or MAY NOT result in MITM.
> >
> > At least for ssp yapparently you are right that may or may not result
> > on MITM being used, this is the code we use on BlueZ:
> >
> > if (*auth == 0x00 || *auth == 0x04) {
> > /* If remote requests dedicated bonding follow that lead */
> > if (device_get_auth(device) == 0x02 ||
> > device_get_auth(device) == 0x03) {
> >
> > /* If both remote and local IO capabilities allow MITM
> > * then require it, otherwise don't */
> > if (device_get_cap(device) == 0x03 ||
> > agent_cap == 0x03)
> > *auth = 0x02;
> > else
> > *auth = 0x03;
> > }
> >
> > /* If remote indicates no bonding then follow that. This
> > * is important since the kernel might give general bonding
> > * as default. */
> > if (device_get_auth(device) == 0x00 ||
> > device_get_auth(device) == 0x01)
> > *auth = 0x00;
> >
> > /* If remote requires MITM then also require it, unless
> > * our IO capability is NoInputNoOutput (so some
> > * just-works security cases can be tested) */
> > if (device_get_auth(device) != 0xff &&
> > (device_get_auth(device) & 0x01) &&
> > agent_cap != 0x03)
> > *auth |= 0x01;
> > }
> >
> > So we only set MITM if the other side also support it, hopefully it
> > works the same way on LE. I still think it is a waste of time for no
> > bonding case to use just-works when MITM was marked as required by one
> > of parties, but I guess pretty everybody does that way.
> >
> > > In every case, MITM outcome is known, and propagated up the stack.
> > >
> > > I have nothing to prove this, but it appears to be what the mature
> > > stacks were using at UPF in Barcelona. But it is apparent that the spec
> > > is not 100% clear, and that an errata is required to explicitly spell it
> > > out.
> > >
> > > I am going to either find the errata if it exists, or propose one to the
> > > Core Working Group if it doesn't. Whatever the outcome, I will post it
> > > here.
>
> I have filed errata #4249. This errata can be looked up on
> bluetooth.org in the specifications area under number:
> "4249"
> title:
> "Clarification of STK generation"
> Part:
> "Security Manager 4.0"
> Paragraph:
> "2.3.5.1 Selecting STK Generation Method"
I got a response from Steven Wenhem of CSR and the CSWG and he offered
the opinion on the errata (4249) that aligns with my understanding of
the truth table:
1. If BOTH devices have OOB available, it is used and results in MITM
2. If NEITHER device wants MITM, JUST_WORKS used resulting in no MITM
3, If One or more want MITM, the IO Caps Table 2.4 on page 608 is used
and MAY or MAY NOT result in MITM.
Note that this is an opinion only at this point, and has not been
approved or adopted. I believe that it is how more than one stack with
a more mature SM currently work, though.
Based on other conversations with members of the working group, I
believe that it is also generally accepted that a device with weak
security requirements (such as JUST WORKS) should *never* Reject the
pairing attempt because the remote device requests stronger (MITM)
security. It is the responsibility of the Strong Security device to
reject the pairing if it will not meet the minimum security requirements
of the Strong Security Device.
This principle applies to not only MITM, but also the Key Length, which
is specified in the same SM packets. The key length used will be the
MIN of the two devices "max key length" field, but either side can
reject the pairing if the resulting length is shorter than it's Minimum
key length.
But again, these are stated opinions only, and not published
(specification) fact.
--
Brian Gix
bgix@codeaurora.org
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [RFC 1/1] Device initialization and controller type resolving
From: Gustavo F. Padovan @ 2011-01-26 17:37 UTC (permalink / raw)
To: André Dieb; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimqtWzKS4H+veJE2PCXH0o5CLJwrspMTfQyd=AR@mail.gmail.com>
Hi André,
* André Dieb <andre.dieb@signove.com> [2011-01-26 12:34:02 -0200]:
> From: André Dieb Martins <andre.dieb@signove.com>
>
> This patch proposes to use LMP features in order to resolve the controller
> type. Currently there's very few code (mostly inside drivers) that cares
> about differentiating controller types (BR/EDR, BR/EDR/LE, LE only, AMP).
>
> Once determined dev_type, the idea would be to implement controller-type
> specific initialization procedures. There's an initialization code for BR/EDR
> devices and some early adaptation for BR/EDR/LE, but nothing regarding
> LE-only - and I'm willing to tackle that, based on your pointers.
>
> Would it be better to always let drivers modify their device's dev_type?
>
> What would be the correct approach?
>
> PS: Please don't bother the CC2540 hack. Consider it a joke :-).
>
> Signed-off-by: André Dieb Martins <andre.dieb@signove.com>
> ---
> include/net/bluetooth/hci.h | 78 ++++++++++++++++++++++++++++++-------
> include/net/bluetooth/hci_core.h | 3 +
> net/bluetooth/hci_core.c | 8 ++--
> net/bluetooth/hci_event.c | 24 ++++++++++++
> net/bluetooth/hci_sysfs.c | 4 ++
> 5 files changed, 98 insertions(+), 19 deletions(-)
Please rebase your patch against bluetooth-next-2.6. And run your patch
against the scripts/checkpatch.pl, it does not follow the styles requirements
for the Linux Kernel.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] add Atheros BT AR9285 fw supported
From: Gustavo F. Padovan @ 2011-01-26 17:30 UTC (permalink / raw)
To: Cho, Yu-Chen; +Cc: marcel, linux-bluetooth, linux-kernel, jlee
In-Reply-To: <edc8dae4f78c3c93397e1bd34a7e2337c4aaeb88.1296032839.git.acho@novell.com>
Hi Cho,
* Cho, Yu-Chen <acho@novell.com> [2011-01-26 17:10:59 +0800]:
> Add the btusb.c blacklist [03f0:311d] for Atheros AR9285 Malbec BT
> and add to ath3k.c ath3-1.fw (md5:1211fa34c09e10ba48381586b7c3883d)
> supported this device.
>
> Signed-off-by: Cho, Yu-Chen <acho@novell.com>
> ---
> drivers/bluetooth/ath3k.c | 2 ++
> drivers/bluetooth/btusb.c | 3 +++
> 2 files changed, 5 insertions(+), 0 deletions(-)
applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Set connection state to BT_DISCONN to avoid multiple responses
From: Gustavo F. Padovan @ 2011-01-26 17:21 UTC (permalink / raw)
To: tim.bao; +Cc: linux-bluetooth
In-Reply-To: <20110126171815.GC27017@joana>
* Gustavo F. Padovan <padovan@profusion.mobi> [2011-01-26 15:18:15 -0200]:
> Hi Bao,
>
> * tim.bao@gmail.com <tim.bao@gmail.com> [2011-01-19 21:22:09 +0800]:
>
> > From: Bao Liang <tim.bao@gmail.com>
> >
> > This patch fixes a minor issue that two connection responses will be sent
> > for one L2CAP connection request. If the L2CAP connection request is first
> > blocked due to security reason and responded with reason "security block",
> > the state of the connection remains BT_CONNECT2. If a pairing procedure
> > completes successfully before the ACL connection is down, local host will
> > send another connection complete response. See the following packets
> > captured by hcidump.
> >
> > 2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
> > 0000: 0c 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00 ........A.S.....
> > ... ...
> >
> > 2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
> > status 0x00 handle 12
> > ... ...
> >
> > 2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
> > L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
> > Connection successful
> > ---
> > net/bluetooth/l2cap.c | 5 +++--
> > 1 files changed, 3 insertions(+), 2 deletions(-)
>
> Patch has been applied. Thanks.
I had to revert it, your patch doesn't have a Signed-off-by: line. Please send
me that.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Set connection state to BT_DISCONN to avoid multiple responses
From: Gustavo F. Padovan @ 2011-01-26 17:18 UTC (permalink / raw)
To: tim.bao; +Cc: linux-bluetooth
In-Reply-To: <1295443329-26860-1-git-send-email-tim.bao@gmail.com>
Hi Bao,
* tim.bao@gmail.com <tim.bao@gmail.com> [2011-01-19 21:22:09 +0800]:
> From: Bao Liang <tim.bao@gmail.com>
>
> This patch fixes a minor issue that two connection responses will be sent
> for one L2CAP connection request. If the L2CAP connection request is first
> blocked due to security reason and responded with reason "security block",
> the state of the connection remains BT_CONNECT2. If a pairing procedure
> completes successfully before the ACL connection is down, local host will
> send another connection complete response. See the following packets
> captured by hcidump.
>
> 2010-12-07 22:21:24.928096 < ACL data: handle 12 flags 0x00 dlen 16
> 0000: 0c 00 01 00 03 19 08 00 41 00 53 00 03 00 00 00 ........A.S.....
> ... ...
>
> 2010-12-07 22:21:35.791747 > HCI Event: Auth Complete (0x06) plen 3
> status 0x00 handle 12
> ... ...
>
> 2010-12-07 22:21:35.872372 > ACL data: handle 12 flags 0x02 dlen 16
> L2CAP(s): Connect rsp: dcid 0x0054 scid 0x0040 result 0 status 0
> Connection successful
> ---
> net/bluetooth/l2cap.c | 5 +++--
> 1 files changed, 3 insertions(+), 2 deletions(-)
Patch has been applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv3] Bluetooth: fix crash by disabling tasklet in sock accept
From: Gustavo F. Padovan @ 2011-01-26 17:13 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1295859204-20599-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-01-24 10:53:24 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Crash can happen when tasklet handling connect/disconnect requests
> preempts socket accept. Can be reproduced with "l2test -r" on one
> side and several "l2test -c -b 1000 -i hci0 -P 10 <bdaddr>" on the
> other side.
>
> disable taskets in socket accept and change lock_sock and release_sock
> to bh_lock_sock and bh_unlock_sock since we have to use spinlocks and
> there is no need to mark sock as owned by user.
>
> ...
> [ 3555.897247] Unable to handle kernel NULL pointer dereference at virtual
> address 000000bc
> [ 3555.915039] pgd = cab9c000
> [ 3555.917785] [000000bc] *pgd=8bf3d031, *pte=00000000, *ppte=00000000
> [ 3555.928314] Internal error: Oops: 17 [#1] PREEMPT
> [ 3555.999786] CPU: 0 Not tainted (2.6.32.21-13874-g67918ef #65)
> ...
> [ 3556.005981] PC is at bt_accept_unlink+0x20/0x58 [bluetooth]
> [ 3556.011627] LR is at bt_accept_dequeue+0x3c/0xe8 [bluetooth]
> ...
> [ 3556.161285] [<bf0007fc>] (bt_accept_unlink+0x20/0x58 [bluetooth]) from
> [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth])
> [ 3556.172729] [<bf000870>] (bt_accept_dequeue+0x3c/0xe8 [bluetooth]) from
> [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap])
> [ 3556.184082] [<bf324df8>] (l2cap_sock_accept+0x100/0x15c [l2cap]) from
> [<c026a0a8>] (sys_accept4+0x120/0x1e0)
> [ 3556.193969] [<c026a0a8>] (sys_accept4+0x120/0x1e0) from [<c002c9a0>]
> (ret_fast_syscall+0x0/0x2c)
> [ 3556.202819] Code: e5813000 e5901164 e580c160 e580c15c (e1d13bbc)
> ...
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/af_bluetooth.c | 13 +++++++++----
> 1 files changed, 9 insertions(+), 4 deletions(-)
Patch is applied now. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: [PATCHv2] Bluetooth: Do not use assignments in IF conditions
From: Gustavo F. Padovan @ 2011-01-26 17:09 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1294759220-5002-2-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2011-01-11 17:20:20 +0200]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> Fix checkpatch warnings concerning assignments in if conditions.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/af_bluetooth.c | 6 ++++--
> net/bluetooth/cmtp/capi.c | 3 ++-
> net/bluetooth/cmtp/core.c | 9 ++++++---
> net/bluetooth/hci_core.c | 12 +++++++++---
> net/bluetooth/hci_event.c | 22 ++++++++++++++--------
> net/bluetooth/hidp/core.c | 9 ++++++---
> net/bluetooth/l2cap.c | 5 ++++-
> 7 files changed, 45 insertions(+), 21 deletions(-)
Patch has been applied. Thanks.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: Read Characteristic Value vs. Read Long Characteristic Values
From: Anderson Lizardo @ 2011-01-26 14:54 UTC (permalink / raw)
To: Brian Gix; +Cc: BlueZ development
In-Reply-To: <AANLkTi=gZQ2Ps2yoXT7+08E3AruB5pAAy+ib+wBcQY4S@mail.gmail.com>
Hi Brian,
On Wed, Jan 26, 2011 at 9:58 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> Looks like more a PTS bug, but makes me wonder if it is not better for
>> BlueZ to have separate procedures instead of this "automatic" usage of
>> read blob request ?
>
> BTW, the test which presented this issue with sending spurious read
> blob request is named "Read Characteristic Descriptors – by client". I
> also can see that the behavior you implemented satisfies both "Read
> Long Characteristic Value - by client" and "Read Long Characteristic
> Descriptor - by client" tests. All theses tests come from the GATT TS
> document.
Another update... Test "Read Long Characteristic Value – Invalid
handle" expects a Read Blob request specifically. The only way I see
to satisfy it is to provide a separate "read long characteristic
value" procedure separate from the "read characteristic value". Any
other ideas?
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [RFC 1/1] Device initialization and controller type resolving
From: André Dieb @ 2011-01-26 14:34 UTC (permalink / raw)
To: linux-bluetooth
From: André Dieb Martins <andre.dieb@signove.com>
This patch proposes to use LMP features in order to resolve the controller
type. Currently there's very few code (mostly inside drivers) that cares
about differentiating controller types (BR/EDR, BR/EDR/LE, LE only, AMP).
Once determined dev_type, the idea would be to implement controller-type
specific initialization procedures. There's an initialization code for BR/EDR
devices and some early adaptation for BR/EDR/LE, but nothing regarding
LE-only - and I'm willing to tackle that, based on your pointers.
Would it be better to always let drivers modify their device's dev_type?
What would be the correct approach?
PS: Please don't bother the CC2540 hack. Consider it a joke :-).
Signed-off-by: André Dieb Martins <andre.dieb@signove.com>
---
include/net/bluetooth/hci.h | 78 ++++++++++++++++++++++++++++++-------
include/net/bluetooth/hci_core.h | 3 +
net/bluetooth/hci_core.c | 8 ++--
net/bluetooth/hci_event.c | 24 ++++++++++++
net/bluetooth/hci_sysfs.c | 4 ++
5 files changed, 98 insertions(+), 19 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index 036fdae..ae9f095 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -55,6 +55,8 @@
/* HCI controller types */
#define HCI_BREDR 0x00
#define HCI_AMP 0x01
+#define HCI_BREDRLE 0x02
+#define HCI_LE 0x03
/* HCI device quirks */
enum {
@@ -163,6 +165,8 @@ enum {
#define LE_LINK 0x80
/* LMP features */
+
+/* byte 0 */
#define LMP_3SLOT 0x01
#define LMP_5SLOT 0x02
#define LMP_ENCRYPT 0x04
@@ -172,6 +176,7 @@ enum {
#define LMP_HOLD 0x40
#define LMP_SNIFF 0x80
+/* byte 1 */
#define LMP_PARK 0x01
#define LMP_RSSI 0x02
#define LMP_QUALITY 0x04
@@ -181,22 +186,65 @@ enum {
#define LMP_ULAW 0x40
#define LMP_ALAW 0x80
-#define LMP_CVSD 0x01
-#define LMP_PSCHEME 0x02
+/* byte 2 */
+#define LMP_CVSD 0x01
+#define LMP_PSCHEME 0x02
#define LMP_PCONTROL 0x04
-
-#define LMP_ESCO 0x80
-
-#define LMP_EV4 0x01
-#define LMP_EV5 0x02
-#define LMP_LE 0x40
-
-#define LMP_SNIFF_SUBR 0x02
-#define LMP_EDR_ESCO_2M 0x20
-#define LMP_EDR_ESCO_3M 0x40
-#define LMP_EDR_3S_ESCO 0x80
-
-#define LMP_SIMPLE_PAIR 0x08
+#define LMP_TSYNC 0x08
+#define LMP_FLOWLAGLSB 0x10
+#define LMP_FLOWLAGMB 0x20
+#define LMP_FLOWLAGMSB 0x40
+#define LMP_BROADCAST_ENCRYPTION 0x80
+
+/* byte 3 */
+// 0x01 reserved
+#define LMP_ENHANCED_DATA_RATE_2MBPS 0x02
+#define LMP_ENHANCED_DATA_RATE_3MBPS 0x04
+#define LMP_ENHANCED_INQUIRY_SCAN 0x08
+#define LMP_INTERLACED_INQUIRY_SCAN 0x10
+#define LMP_INTERLACED_PAGE_SCAN 0x20
+#define LMP_RSSI_WITH_INQUIRY_RES 0x40
+#define LMP_ESCO 0x80
+
+/* byte 4 */
+#define LMP_EV4 0x01
+#define LMP_EV5 0x02
+// 0x04 reserved
+#define LMP_AFH_CAPABLE_SLAVE 0x08
+#define LMP_AFH_CLASSIF_SLAVE 0x10
+#define LMP_NOT_BREDR 0x20
+#define LMP_LE 0x40
+#define LMP_3EDR 0x80
+
+/* byte 5 */
+#define LMP_5EDR 0x01
+#define LMP_SNIFF_SUBR 0x02
+#define LMP_PAUSE_ENCRYP 0x04
+#define LMP_AFH_CAPABLE_MASTER 0x08
+#define LMP_AFH_CLASSIF_MASTER 0x10
+#define LMP_EDR_ESCO_2M 0x20
+#define LMP_EDR_ESCO_3M 0x40
+#define LMP_EDR_3S_ESCO 0x80
+
+/* byte 6 */
+#define LMP_EXT_INQ_RESPONSE 0x01
+#define LMP_SIMUL_LE_BREDR_SAME_DEVICE 0x02
+// 0x04 reserved for Core V4.0
+#define LMP_SIMPLE_PAIR 0x08
+#define LMP_ENCAPSULATED_PDU 0x10
+#define LMP_ERR_DATA_REPORT 0x20
+#define LMP_NONFLUSH_PACKET_BOUNDARY_FLAG 0x40
+// 0x80 reserved for Core V4.0
+
+/* byte 7 */
+#define LMP_LINK_SUPERVISION_TIMEOUT_CHANGED_EVENT 0x01
+#define LMP_INQ_TX_POWER_LEVEL 0x02
+#define LMP_ENHANCED_POWER_CONTROL 0x04
+// 0x08 reserved
+// 0x10 reserved
+// 0x20 reserved
+// 0x40 reserved
+// 0x80 reserved
/* Connection modes */
#define HCI_CM_ACTIVE 0x0000
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index cfbe56c..9a86281 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -480,7 +480,10 @@ void hci_conn_del_sysfs(struct hci_conn *conn);
#define lmp_sniffsubr_capable(dev) ((dev)->features[5] & LMP_SNIFF_SUBR)
#define lmp_esco_capable(dev) ((dev)->features[3] & LMP_ESCO)
#define lmp_ssp_capable(dev) ((dev)->features[6] & LMP_SIMPLE_PAIR)
+
#define lmp_le_capable(dev) ((dev)->features[4] & LMP_LE)
+#define lmp_bredr_unsupported(dev) ((dev)->features[4] & LMP_NOT_BREDR)
+#define lmp_le_only(dev) (lmp_le_capable(dev) &&
lmp_bredr_unsupported(dev))
/* ----- HCI protocols ----- */
struct hci_proto {
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 0e98ffb..b110114 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -259,6 +259,8 @@ static void hci_le_init_req(struct hci_dev *hdev,
unsigned long opt)
{
BT_DBG("%s", hdev->name);
+ BT_INFO("%s LE-specific initialization", hdev->name);
+
/* Read LE buffer size */
hci_send_cmd(hdev, HCI_OP_LE_READ_BUFFER_SIZE, 0, NULL);
}
@@ -501,10 +503,6 @@ int hci_dev_open(__u16 dev)
if (test_bit(HCI_QUIRK_RAW_DEVICE, &hdev->quirks))
set_bit(HCI_RAW, &hdev->flags);
- /* Treat all non BR/EDR controllers as raw devices for now */
- if (hdev->dev_type != HCI_BREDR)
- set_bit(HCI_RAW, &hdev->flags);
-
if (hdev->open(hdev)) {
ret = -EIO;
goto done;
@@ -514,6 +512,8 @@ int hci_dev_open(__u16 dev)
atomic_set(&hdev->cmd_cnt, 1);
set_bit(HCI_INIT, &hdev->flags);
+ BT_INFO("Initializing %s", hdev->name);
+
//__hci_request(hdev, hci_reset_req, 0, HZ);
ret = __hci_request(hdev, hci_init_req, 0,
msecs_to_jiffies(HCI_INIT_TIMEOUT));
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 57560fb..18932a2 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -445,6 +445,16 @@ static void hci_cc_read_local_commands(struct
hci_dev *hdev, struct sk_buff *skb
memcpy(hdev->commands, rp->commands, sizeof(hdev->commands));
}
+#define is_texas_dongle(hdev) \
+ (hdev->features[0] == 0x00 && \
+ hdev->features[1] == 0x00 && \
+ hdev->features[2] == 0x00 && \
+ hdev->features[3] == 0x60 && \
+ hdev->features[4] == 0x00 && \
+ hdev->features[5] == 0x00 && \
+ hdev->features[6] == 0x00 && \
+ hdev->features[7] == 0x00)
+
static void hci_cc_read_local_features(struct hci_dev *hdev, struct
sk_buff *skb)
{
struct hci_rp_read_local_features *rp = (void *) skb->data;
@@ -498,6 +508,20 @@ static void hci_cc_read_local_features(struct
hci_dev *hdev, struct sk_buff *skb
hdev->features[2], hdev->features[3],
hdev->features[4], hdev->features[5],
hdev->features[6], hdev->features[7]);
+
+ /* Fix features endianess bug on CC2540 firmware */
+ if (is_texas_dongle(hdev)) {
+ hdev->features[3] = 0x00;
+ hdev->features[4] = 0x60;
+ }
+
+ if (lmp_le_capable(hdev) && lmp_bredr_unsupported(hdev)) {
+ hdev->dev_type = HCI_LE;
+ BT_INFO("%s is a LE-only controller", hdev->name);
+ } else if (lmp_le_capable(hdev)) {
+ hdev->dev_type = HCI_BREDRLE;
+ BT_INFO("%s is a BR/EDR/LE controller", hdev->name);
+ }
}
static void hci_cc_read_buffer_size(struct hci_dev *hdev, struct sk_buff *skb)
diff --git a/net/bluetooth/hci_sysfs.c b/net/bluetooth/hci_sysfs.c
index 5fce3d6..5846297 100644
--- a/net/bluetooth/hci_sysfs.c
+++ b/net/bluetooth/hci_sysfs.c
@@ -196,6 +196,10 @@ static inline char *host_typetostr(int type)
return "BR/EDR";
case HCI_AMP:
return "AMP";
+ case HCI_BREDRLE:
+ return "BR/EDR/LE";
+ case HCI_LE:
+ return "LE";
default:
return "UNKNOWN";
}
--
1.6.1
^ permalink raw reply related
* Re: Read Characteristic Value vs. Read Long Characteristic Values
From: Anderson Lizardo @ 2011-01-26 13:58 UTC (permalink / raw)
To: Brian Gix; +Cc: BlueZ development
In-Reply-To: <AANLkTi=4HoUKdda-GCrTQEtLSScuxB4D+btoRy+QsMG_@mail.gmail.com>
On Wed, Jan 26, 2011 at 9:33 AM, Anderson Lizardo
<anderson.lizardo@openbossa.org> wrote:
> Looks like more a PTS bug, but makes me wonder if it is not better for
> BlueZ to have separate procedures instead of this "automatic" usage of
> read blob request ?
BTW, the test which presented this issue with sending spurious read
blob request is named "Read Characteristic Descriptors – by client". I
also can see that the behavior you implemented satisfies both "Read
Long Characteristic Value - by client" and "Read Long Characteristic
Descriptor - by client" tests. All theses tests come from the GATT TS
document.
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH 2/2 v3] Fix fetching non-empty single owner vCard
From: Johan Hedberg @ 2011-01-26 13:36 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1296048387-2854-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Wed, Jan 26, 2011, Rafal Michalski wrote:
> Previously only empty owner vCard fetching was handled.
> This patch makes that fetching empty (by default) and non-empty
> (filled somehow by the user) single owner vCard is handled.
> ---
> plugins/phonebook-tracker.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: Read Characteristic Value vs. Read Long Characteristic Values
From: Anderson Lizardo @ 2011-01-26 13:33 UTC (permalink / raw)
To: Brian Gix; +Cc: BlueZ development
In-Reply-To: <1295984785.2656.98.camel@ubuntuLab1>
On Tue, Jan 25, 2011 at 3:46 PM, Brian Gix <bgix@codeaurora.org> wrote:
> As far as test case coverage per the qualification test specification, I
> do not believe that there is a problem. Any non long "Reads" can be
> tested by reading < 22 octet attributes, and long read tests by reading
>>= 22 octet attributes.
Now that you mentioned this topic, the issue that brought this thread
is that there is a specific qualification test where PTS sends a 22
bytes characteristic value, expecting a single Read Request to be
sent, and it refuses to answer to any further Read Blob Requests (i.e.
it does not send any response PDUs). This makes the client (e.g.
igatttool) wait forever for a answer or timeout.
Looks like more a PTS bug, but makes me wonder if it is not better for
BlueZ to have separate procedures instead of this "automatic" usage of
read blob request ?
Regards,
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* [PATCH 2/2 v3] Fix fetching non-empty single owner vCard
From: Rafal Michalski @ 2011-01-26 13:26 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
Previously only empty owner vCard fetching was handled.
This patch makes that fetching empty (by default) and non-empty
(filled somehow by the user) single owner vCard is handled.
---
plugins/phonebook-tracker.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 4e37f1c..ceaef81 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1922,7 +1922,8 @@ void *phonebook_get_entry(const char *folder, const char *id,
data->cb = cb;
data->vcardentry = TRUE;
- if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0)
+ if (g_str_has_prefix(id, CONTACT_ID_PREFIX) == TRUE ||
+ g_strcmp0(id, TRACKER_DEFAULT_CONTACT_ME) == 0)
query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
id, id, id, id, id, id, id, id, id);
else
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH 2/2 v2] Fix fetching non-empty single owner vCard
From: Johan Hedberg @ 2011-01-26 12:49 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1296045187-28072-2-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Wed, Jan 26, 2011, Rafal Michalski wrote:
> Previously only empty owner vCard fetching was handled.
> This patch makes that fetching empty (by default) and non-empty
> (filled somehow by the user) single owner vCard is handled.
> ---
> plugins/phonebook-tracker.c | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
Still one coding style issue here:
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index 4e37f1c..353b5cb 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -1922,7 +1922,8 @@ void *phonebook_get_entry(const char *folder, const char *id,
> data->cb = cb;
> data->vcardentry = TRUE;
>
> - if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0)
> + if (g_str_has_prefix(id, CONTACT_ID_PREFIX) == TRUE ||
> + g_strcmp0(id, TRACKER_DEFAULT_CONTACT_ME) == 0)
> query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
> id, id, id, id, id, id, id, id, id);
The split second line of the if-statment should be indented by at least
two tabs so that it's distinguishable from the rest of the code. Please
send a v3.
Johan
^ permalink raw reply
* Re: [PATCH 1/2 v2] Remove unnecessary ordering from single vCard query
From: Johan Hedberg @ 2011-01-26 12:46 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1296045187-28072-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Wed, Jan 26, 2011, Rafal Michalski wrote:
> Previously ordering for query called CONTACTS_QUERY_FROM_URI was applied.
> It is not needed since always only one vCard (with id specified)
> is fetched.
> ---
> plugins/phonebook-tracker.c | 9 +++------
> 1 files changed, 3 insertions(+), 6 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] plugins: hciops: remove scan disable on poweroff
From: Pavan Savoy @ 2011-01-26 12:39 UTC (permalink / raw)
To: pavan.savoy, linux-bluetooth, Pavan Savoy
In-Reply-To: <20110126113608.GA9658@jh-x301>
On Wed, Jan 26, 2011 at 5:06 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Pavan,
>
> On Wed, Jan 26, 2011, pavan.savoy@gmail.com wrote:
>> From: Pavan Savoy <pavan_savoy@sify.com>
>>
>> remove sending of the scan disable command when the
>> device is being powered off.
>>
>> Signed-off-by: Pavan Savoy <pavan_savoy@sify.com>
>> ---
>> plugins/hciops.c | 5 -----
>> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> Pushed upstream after I added some extra info to the commit message and
> removed the signed-off-by line (since we don't use that in user space).
Thanks Johan..
> Johan
>
^ permalink raw reply
* [PATCH 2/2 v2] Fix fetching non-empty single owner vCard
From: Rafal Michalski @ 2011-01-26 12:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
In-Reply-To: <1296045187-28072-1-git-send-email-michalski.raf@gmail.com>
Previously only empty owner vCard fetching was handled.
This patch makes that fetching empty (by default) and non-empty
(filled somehow by the user) single owner vCard is handled.
---
plugins/phonebook-tracker.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index 4e37f1c..353b5cb 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -1922,7 +1922,8 @@ void *phonebook_get_entry(const char *folder, const char *id,
data->cb = cb;
data->vcardentry = TRUE;
- if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0)
+ if (g_str_has_prefix(id, CONTACT_ID_PREFIX) == TRUE ||
+ g_strcmp0(id, TRACKER_DEFAULT_CONTACT_ME) == 0)
query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
id, id, id, id, id, id, id, id, id);
else
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2 v2] Remove unnecessary ordering from single vCard query
From: Rafal Michalski @ 2011-01-26 12:33 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
Previously ordering for query called CONTACTS_QUERY_FROM_URI was applied.
It is not needed since always only one vCard (with id specified)
is fetched.
---
plugins/phonebook-tracker.c | 9 +++------
1 files changed, 3 insertions(+), 6 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index e60cf74..4e37f1c 100644
--- a/plugins/phonebook-tracker.c
+++ b/plugins/phonebook-tracker.c
@@ -788,11 +788,9 @@
"\"NOTACALL\" \"false\" \"false\" " \
"<%s> " \
"WHERE {" \
-" <%s> a nco:PersonContact ;" \
-" nco:nameFamily ?_key ." \
+" <%s> a nco:PersonContact ." \
" OPTIONAL {<%s> nco:hasAffiliation ?_role .}" \
-"}" \
-"ORDER BY ?_key tracker:id(<%s>)"
+"}"
#define CONTACTS_OTHER_QUERY_FROM_URI \
"SELECT fn:concat(\"TYPE_OTHER\", \"\31\", nco:phoneNumber(?t))"\
@@ -1926,8 +1924,7 @@ void *phonebook_get_entry(const char *folder, const char *id,
if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0)
query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
- id, id, id, id, id, id, id, id,
- id, id);
+ id, id, id, id, id, id, id, id, id);
else
query = g_strdup_printf(CONTACTS_OTHER_QUERY_FROM_URI,
id, id, id);
--
1.6.3.3
^ permalink raw reply related
* Re: [PATCH] plugins: hciops: remove scan disable on poweroff
From: Johan Hedberg @ 2011-01-26 11:36 UTC (permalink / raw)
To: pavan.savoy; +Cc: linux-bluetooth, Pavan Savoy
In-Reply-To: <1296040915-5519-1-git-send-email-pavan_savoy@sify.com>
Hi Pavan,
On Wed, Jan 26, 2011, pavan.savoy@gmail.com wrote:
> From: Pavan Savoy <pavan_savoy@sify.com>
>
> remove sending of the scan disable command when the
> device is being powered off.
>
> Signed-off-by: Pavan Savoy <pavan_savoy@sify.com>
> ---
> plugins/hciops.c | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
Pushed upstream after I added some extra info to the commit message and
removed the signed-off-by line (since we don't use that in user space).
Johan
^ permalink raw reply
* Re: [PATCH 1/2] Remove unnecessary ordering from single vCard query
From: Johan Hedberg @ 2011-01-26 11:29 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1296039665-3948-1-git-send-email-michalski.raf@gmail.com>
Hi Rafal,
On Wed, Jan 26, 2011, Rafal Michalski wrote:
> Previously ordering for query called CONTACTS_QUERY_FROM_URI was applied.
> It is not needed since always only one vCard (with id specified)
> is fetched.
> ---
> plugins/phonebook-tracker.c | 6 ++----
> 1 files changed, 2 insertions(+), 4 deletions(-)
Doesn't compile:
plugins/phonebook.c: In function 'phonebook_get_entry':
plugins/phonebook.c:1928: error: too many arguments for format
make[1]: *** [plugins/phonebook.o] Error 1
Did you forget to compile with ./bootstrap-configure? Never submit
patches without first checking that they compile cleanly this way.
Johan
^ permalink raw reply
* Re: [PATCH] plugins: hciops: remove scan disable on poweroff
From: Pavan Savoy @ 2011-01-26 11:26 UTC (permalink / raw)
To: Pavan Savoy, linux-bluetooth
In-Reply-To: <20110126111617.GA31721@jh-x301>
On Wed, Jan 26, 2011 at 4:46 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Pavan,
>
> On Tue, Jan 25, 2011, Pavan Savoy wrote:
>> From: Pavan Savoy <pavan_savoy@sify.com>
>>
>> remove sending of the scan disable command when the
>> device is being powered off.
>>
>> Signed-off-by: Pavan Savoy <pavan_savoy@sify.com>
>> ---
>> plugins/hciops.c | 5 -----
>> 1 files changed, 0 insertions(+), 5 deletions(-)
>
> The patch seems to be corrupted (looks like the whitespace is messed
> up):
>
> Applying: plugins: hciops: remove scan disable on poweroff
> fatal: corrupt patch at line 10
> Patch failed at 0001 plugins: hciops: remove scan disable on poweroff
>
> Could you try re-sending it e.g. with git send-email?
Yes, have sent it now, may be it was corrupted because it was
forwarded from a mail which
got it via git send-email.
I wasn't registered to linux-bluetooth, with the mail ID with which i
have smtp ..
so I hope it's ok now..
> Johan
>
^ permalink raw reply
* [PATCH] plugins: hciops: remove scan disable on poweroff
From: pavan.savoy @ 2011-01-26 11:21 UTC (permalink / raw)
To: linux-bluetooth, johan.hedberg; +Cc: Pavan Savoy
From: Pavan Savoy <pavan_savoy@sify.com>
remove sending of the scan disable command when the
device is being powered off.
Signed-off-by: Pavan Savoy <pavan_savoy@sify.com>
---
plugins/hciops.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 719ef01..59a15a0 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -335,14 +335,9 @@ static int hciops_set_pairable(int index, gboolean pairable)
static int hciops_power_off(int index)
{
struct dev_info *dev = &devs[index];
- uint8_t mode = SCAN_DISABLED;
DBG("hci%d", index);
- if (hci_send_cmd(dev->sk, OGF_HOST_CTL,
- OCF_WRITE_SCAN_ENABLE, 1, &mode) < 0)
- return -errno;
-
if (ioctl(dev->sk, HCIDEVDOWN, index) < 0 && errno != EALREADY)
return -errno;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 2/2] Fix fetching non-empty single owner vCard
From: Luiz Augusto von Dentz @ 2011-01-26 11:19 UTC (permalink / raw)
To: Rafal Michalski; +Cc: linux-bluetooth
In-Reply-To: <1296039665-3948-2-git-send-email-michalski.raf@gmail.com>
Hi,
On Wed, Jan 26, 2011 at 1:01 PM, Rafal Michalski
<michalski.raf@gmail.com> wrote:
> Previously only empty owner vCard fetching was handled.
> This patch makes that fetching empty (by default) and non-empty
> (filled somehow by the user) single owner vCard is handled.
> ---
> plugins/phonebook-tracker.c | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
> index aee159c..8fe8ade 100644
> --- a/plugins/phonebook-tracker.c
> +++ b/plugins/phonebook-tracker.c
> @@ -1922,7 +1922,9 @@ void *phonebook_get_entry(const char *folder, const char *id,
> data->cb = cb;
> data->vcardentry = TRUE;
>
> - if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0)
> + if (strncmp(id, CONTACT_ID_PREFIX, strlen(CONTACT_ID_PREFIX)) == 0 ||
> + strncmp(id, TRACKER_DEFAULT_CONTACT_ME,
> + strlen(TRACKER_DEFAULT_CONTACT_ME)) == 0)
> query = g_strdup_printf(CONTACTS_QUERY_FROM_URI, id, id, id, id,
> id, id, id, id, id, id, id, id,
> id, id);
The strncmp combine with strlen looks like it could be replaced by
g_str_has_prefix, also the code that you are adding it probably need
to be a full match not just the prefix than use g_strcmp0 otherwise
g_str_has_prefix can probably be used there too.
--
Luiz Augusto von Dentz
Computer Engineer
^ 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