* 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
* Re: [PATCH] plugins: hciops: remove scan disable on poweroff
From: Johan Hedberg @ 2011-01-26 11:16 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinGAorqPagx_hLakiSoadbOQKv5OE4KBSa1fr5q@mail.gmail.com>
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?
Johan
^ permalink raw reply
* [PATCH 2/2] Fix fetching non-empty single owner vCard
From: Rafal Michalski @ 2011-01-26 11:01 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
In-Reply-To: <1296039665-3948-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 | 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);
--
1.6.3.3
^ permalink raw reply related
* [PATCH 1/2] Remove unnecessary ordering from single vCard query
From: Rafal Michalski @ 2011-01-26 11:01 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 | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/plugins/phonebook-tracker.c b/plugins/phonebook-tracker.c
index e60cf74..aee159c 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))"\
--
1.6.3.3
^ permalink raw reply related
* Re: why scan_disable during hciops_power_off
From: Pavan Savoy @ 2011-01-26 10:51 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <AANLkTikm4nn8Y-89U7Rzvyr+csLR-t2_6WOjQGe1J-2M@mail.gmail.com>
On Tue, Jan 25, 2011 at 9:47 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> On Tue, Jan 25, 2011 at 9:41 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
>> Hi Johan,
>>
>>> > >> 1. are there controllers there which even after doing hci0 down,
>>> > >> allows other devices to be scanned?
>>> > >> for those what do hci0 down mean ? radio not switched off ?
>>> > >
>>> > > Good point, perhaps this is driver dependent, so we do it just be safe guard.
>>> >
>>> > I hope all devices and drivers out there consider the hci0 down as the
>>> > radio OFF,
>>> > I don't think there is a reason for it to be otherwise....
>>> > so why the safe-guard ?
>>>
>>> IIRC Marcel added this due to paranoia with the non-connectable GAP test
>>> case with the BITE tester. The test kept failing even though the device
>>> was in DOWN state.
>>
>> we also had the case where we considered non-connectable as off when the
>> HCI devdown was not working properly. However this is a long time ago
>> and has been fixed properly. So we might can remove this now.
>
> Oo...
> I want to send the patch, I want to send the patch ..
> Can I please .....
i've posted the patch..
>
>> Regards
>>
>> Marcel
>>
>>
>>
>
^ permalink raw reply
* [PATCH] add Atheros BT AR9285 fw supported
From: Cho, Yu-Chen @ 2011-01-26 9:10 UTC (permalink / raw)
To: marcel, padovan, linux-bluetooth, linux-kernel; +Cc: acho, jlee
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(-)
diff --git a/drivers/bluetooth/ath3k.c b/drivers/bluetooth/ath3k.c
index 949ed09..5b494b8 100644
--- a/drivers/bluetooth/ath3k.c
+++ b/drivers/bluetooth/ath3k.c
@@ -39,6 +39,8 @@ static struct usb_device_id ath3k_table[] = {
/* Atheros AR3011 with sflash firmware*/
{ USB_DEVICE(0x0CF3, 0x3002) },
+ /* Atheros AR9285 Malbec with sflash firmware */
+ { USB_DEVICE(0x03F0, 0x311D) },
{ } /* Terminating entry */
};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 1da773f..4cefa91 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -102,6 +102,9 @@ static struct usb_device_id blacklist_table[] = {
/* Atheros 3011 with sflash firmware */
{ USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE },
+ /* Atheros AR9285 Malbec with sflash firmware */
+ { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
+
/* Broadcom BCM2035 */
{ USB_DEVICE(0x0a5c, 0x2035), .driver_info = BTUSB_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = BTUSB_WRONG_SCO_MTU },
--
1.7.1
^ permalink raw reply related
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
From: Brian Gix @ 2011-01-25 22:04 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Johan Hedberg, Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <AANLkTimir1fqsO5EfuHN2dQtsJQ2SVDajpuANo8C05EF@mail.gmail.com>
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"
The Core Working Group (CWG) is meeting this week in Israel, and our guy
on the group, Brian Redding, has told me that he will try to get some
face time for it. So in the next day or two, we could either get a
definitive statement, or at least a few comments. If you don't have
access to the BT Sigs errata system, let me know & I will copy the
errata here.
>
>
--
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: Luiz Augusto von Dentz @ 2011-01-25 21:44 UTC (permalink / raw)
To: Brian Gix; +Cc: Johan Hedberg, Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <1295980540.2656.85.camel@ubuntuLab1>
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.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Read Characteristic Value vs. Read Long Characteristic Values
From: Brian Gix @ 2011-01-25 19:46 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: BlueZ development
In-Reply-To: <AANLkTikrjgmAK9pzoJtnNJwQHraiaCnb8XVP55gAEKeH@mail.gmail.com>
Hi Anderson,
On Tue, 2011-01-25 at 15:07 -0400, Anderson Lizardo wrote:
> Hi Brian,
>
> On the implementation you did for Long Characteristic value read, you
> integrated the Read Blob Request handling into the existing "Read
> Characteristic Value" implementation. From my understanding of the
> code, the read blob request is issued if the response PDU size is
> greater than or equal to LE ATT_MTU (23).
>
> The problem I see with this approach is that if the client knows that
> the characteristic value is exactly 22 bytes (which makes total PDU
> size equal to 23 with the opcode), a spurious read blob request (and
> corresponding response) is sent. How could we avoid this overhead?
>
> My idea was to separate the procedures, having a "Read Long
> Characteristic Value" and revert Read Characteristic Value to read
> only the first ATT_MTU - 1 bytes as before. For characteristic values
> which the client knows to be within ATT_MTU - 1 bytes (of if it only
> cares about these bytes at the time) it would use the latter. For
> cases where value length is unknown, it would use the former.
>
> This would also allow us to better map to GATT procedures and have
> fine control on the client implementation and on our test tool
> (igatttool).
>
>>From a practical perspective, the only attributes that would be
*exactly* 22 octets would be strings which defy attempts for a client to
predict their length without knowing what the content is ahead of time.
You are correct that if a *profile* defines a particular characteristic
attribute value to be exactly 22 octets, that this would result in
result it a harmless extra read.
For string reads this is not really a useless extra operation, because
it does supply definitive termination of the string, which per ATT
protocol cannot be provided any other way.
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.
--
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
* Read Characteristic Value vs. Read Long Characteristic Values
From: Anderson Lizardo @ 2011-01-25 19:07 UTC (permalink / raw)
To: BlueZ development, Brian Gix
Hi Brian,
On the implementation you did for Long Characteristic value read, you
integrated the Read Blob Request handling into the existing "Read
Characteristic Value" implementation. From my understanding of the
code, the read blob request is issued if the response PDU size is
greater than or equal to LE ATT_MTU (23).
The problem I see with this approach is that if the client knows that
the characteristic value is exactly 22 bytes (which makes total PDU
size equal to 23 with the opcode), a spurious read blob request (and
corresponding response) is sent. How could we avoid this overhead?
My idea was to separate the procedures, having a "Read Long
Characteristic Value" and revert Read Characteristic Value to read
only the first ATT_MTU - 1 bytes as before. For characteristic values
which the client knows to be within ATT_MTU - 1 bytes (of if it only
cares about these bytes at the time) it would use the latter. For
cases where value length is unknown, it would use the former.
This would also allow us to better map to GATT procedures and have
fine control on the client implementation and on our test tool
(igatttool).
Any other ideas?
--
Anderson Lizardo
OpenBossa Labs - INdT
Manaus - Brazil
^ permalink raw reply
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
From: Brian Gix @ 2011-01-25 18:35 UTC (permalink / raw)
To: Johan Hedberg
Cc: Luiz Augusto von Dentz, Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <20110125175922.GA16442@jh-x301>
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.
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.
--
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: Johan Hedberg @ 2011-01-25 17:59 UTC (permalink / raw)
To: Brian Gix; +Cc: Luiz Augusto von Dentz, Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <1295974727.2656.57.camel@ubuntuLab1>
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?
Johan
^ permalink raw reply
* Permission Denied (EACCES) when attempting RFCOMM connection
From: Andrew MacIsaac @ 2011-01-25 17:38 UTC (permalink / raw)
To: linux-bluetooth
Hello,
I am trying to get a simple RFCOMM client/server example to work
between two Ubuntu 10.04.1 LTS installations. The examples I am using
are the rfcomm-server and rfcomm-client found here: http://people.csail.mit.edu/albert/bluez-intro/x502.html
I have four of these Ubuntu installations in total, and between two of
them this example works without any problems, however between the
other two I always get EACCES errors when attempting to perform
connect(). All of the machines have the libbluetooth3 version
4.60-0ubuntu8 installed. If I run l2ping between the machines where I
am experiencing this error, or from one of the working ones to one of
the ones that is giving me problems, I get a permission denied error
as well:
sudo l2ping 00:02:72:AC:BE:D7
Can't connect: Permission denied
The following are the hcidumps of one of the failed client-server
sessions followed by the working one. I can see that the failed one
is trying to use authentication, but running
sudo hciconfig hci0 noauth
on both ends has had no effect.
FAILED:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1295913294.810214 < HCI Command: Create Connection (0x01|0x0005) plen 13
C0 BE AC 72 02 00 18 CC 02 00 00 00 01
1295913294.812852 > HCI Event: Command Status (0x0f) plen 4
00 01 05 04
1295913297.584461 > HCI Event: Role Change (0x12) plen 8
00 C0 BE AC 72 02 00 01
1295913297.758436 > HCI Event: Connect Complete (0x03) plen 11
00 0B 00 C0 BE AC 72 02 00 01 00
1295913297.758481 < HCI Command: Read Remote Supported Features (0x01|
0x001b) plen 2
0B 00
1295913297.760422 > HCI Event: Max Slots Change (0x1b) plen 3
0B 00 05
1295913297.762426 > HCI Event: Command Status (0x0f) plen 4
00 01 1B 04
1295913297.764415 > HCI Event: Read Remote Supported Features (0x0b)
plen 11
00 0B 00 FF FF 8F FE 9B FF 79 83
1295913297.764432 < HCI Command: Read Remote Extended Features (0x01|
0x001c) plen 3
0B 00 01
1295913297.767419 > HCI Event: Command Status (0x0f) plen 4
00 01 1C 04
1295913297.771425 > HCI Event: Read Remote Extended Features (0x23)
plen 13
00 0B 00 01 01 01 00 00 00 00 00 00 00
1295913297.771459 < HCI Command: Authentication Requested (0x01|
0x0011) plen 2
0B 00
1295913297.773413 > HCI Event: Command Status (0x0f) plen 4
00 01 11 04
1295913297.804036 < HCI Command: Remote Name Request (0x01|0x0019)
plen 10
C0 BE AC 72 02 00 02 00 00 00
1295913297.853420 > HCI Event: Link Key Request (0x17) plen 6
C0 BE AC 72 02 00
1295913297.855404 > HCI Event: Command Status (0x0f) plen 4
00 01 19 04
1295913297.855421 < HCI Command: Link Key Request Negative Reply (0x01|
0x000c) plen 6
C0 BE AC 72 02 00
1295913297.859401 > HCI Event: Command Complete (0x0e) plen 10
01 0C 04 00 C0 BE AC 72 02 00
1295913297.861401 > HCI Event: IO Capability Request (0x31) plen 6
C0 BE AC 72 02 00
1295913297.861540 < HCI Command: IO Capability Request Negative Reply
(0x01|0x0034) plen 7
C0 BE AC 72 02 00 18
1295913297.863413 > HCI Event: Command Complete (0x0e) plen 10
01 34 04 00 C0 BE AC 72 02 00
1295913297.865404 > HCI Event: Simple Pairing Complete (0x36) plen 7
05 C0 BE AC 72 02 00
1295913297.867400 > HCI Event: Auth Complete (0x06) plen 3
05 0B 00
1295913297.911393 > HCI Event: Remote Name Req Complete (0x07) plen 255
00 C0 BE AC 72 02 00 66 69 6C 65 73 65 72 76 65 72 2D 31 2D
30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1295913299.864140 < HCI Command: Disconnect (0x01|0x0006) plen 3
0B 00 13
1295913299.868112 > HCI Event: Command Status (0x0f) plen 4
00 01 06 04
1295913299.945109 > HCI Event: Disconn Complete (0x05) plen 4
00 0B 00 16
SUCCESSFUL:
HCI sniffer - Bluetooth packet analyzer ver 1.42
device: hci0 snap_len: 1028 filter: 0xffffffff
1295913138.120190 < HCI Command: Create Connection (0x01|0x0005) plen 13
DE D2 B0 6C 23 00 18 CC 02 00 00 00 01
1295913139.994246 > HCI Event: Command Status (0x0f) plen 4
00 01 05 04
1295913143.297146 > HCI Event: Role Change (0x12) plen 8
00 DE D2 B0 6C 23 00 01
1295913144.020230 > HCI Event: Connect Complete (0x03) plen 11
00 2E 00 DE D2 B0 6C 23 00 01 00
1295913144.020284 < HCI Command: Read Remote Supported Features (0x01|
0x001b) plen 2
2E 00
1295913144.021047 > HCI Event: Page Scan Repetition Mode Change (0x20)
plen 7
DE D2 B0 6C 23 00 00
1295913144.022043 > HCI Event: Max Slots Change (0x1b) plen 3
2E 00 05
1295913144.029093 > HCI Event: Command Status (0x0f) plen 4
00 01 1B 04
1295913144.029110 < HCI Command: Remote Name Request (0x01|0x0019)
plen 10
DE D2 B0 6C 23 00 02 00 00 00
1295913144.042183 > HCI Event: Read Remote Supported Features (0x0b)
plen 11
00 2E 00 FF FF 8F FE 9B FF 79 83
1295913144.042219 < ACL data: handle 46 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
1295913144.050136 > HCI Event: Command Status (0x0f) plen 4
00 01 19 04
1295913144.071127 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.073166 > ACL data: handle 46 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0080
1295913144.073187 < ACL data: handle 46 flags 0x02 dlen 10
L2CAP(s): Info req: type 3
1295913144.081133 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.084145 > ACL data: handle 46 flags 0x02 dlen 20
L2CAP(s): Info rsp: type 3 result 0
Unknown (len 8)
1295913144.084165 < ACL data: handle 46 flags 0x02 dlen 12
L2CAP(s): Connect req: psm 3 scid 0x0040
1295913144.092113 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.105080 > ACL data: handle 46 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 1 status 0
Connection pending - No futher information available
1295913144.106153 > ACL data: handle 46 flags 0x02 dlen 10
L2CAP(s): Info req: type 2
1295913144.106166 < ACL data: handle 46 flags 0x02 dlen 16
L2CAP(s): Info rsp: type 2 result 0
Extended feature mask 0x0080
1295913144.117181 > ACL data: handle 46 flags 0x02 dlen 10
L2CAP(s): Info req: type 3
1295913144.117193 < ACL data: handle 46 flags 0x02 dlen 20
L2CAP(s): Info rsp: type 3 result 0
Unknown (len 8)
1295913144.129071 > ACL data: handle 46 flags 0x02 dlen 16
L2CAP(s): Connect rsp: dcid 0x0040 scid 0x0040 result 0 status 0
Connection successful
1295913144.129095 < ACL data: handle 46 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 1013
1295913144.131162 > HCI Event: Remote Name Req Complete (0x07) plen 255
00 DE D2 B0 6C 23 00 6C 69 6E 75 78 2D 64 65 76 2D 30 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
1295913144.134154 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.137148 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.147181 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.147191 > ACL data: handle 46 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 1013
1295913144.149079 > ACL data: handle 46 flags 0x02 dlen 16
L2CAP(s): Config req: dcid 0x0040 flags 0x00 clen 4
MTU 1013
1295913144.149097 < ACL data: handle 46 flags 0x02 dlen 18
L2CAP(s): Config rsp: scid 0x0040 flags 0x00 result 0 clen 4
MTU 1013
1295913144.149133 < ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 0 pf 1 ilen 0 fcs 0x1c
1295913144.158153 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.160111 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.162150 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
1295913144.162184 < ACL data: handle 46 flags 0x02 dlen 18
L2CAP(d): cid 0x0040 len 14 [psm 3]
RFCOMM(s): PN CMD: cr 1 dlci 0 pf 0 ilen 10 fcs 0x70 mcc_len 8
dlci 2 frame_type 0 credit_flow 15 pri 7 ack_timer 0
frame_size 1008 max_retrans 0 credits 7
1295913144.170142 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.172052 > ACL data: handle 46 flags 0x02 dlen 18
L2CAP(d): cid 0x0040 len 14 [psm 3]
RFCOMM(s): PN RSP: cr 0 dlci 0 pf 0 ilen 10 fcs 0xaa mcc_len 8
dlci 2 frame_type 0 credit_flow 14 pri 7 ack_timer 0
frame_size 1008 max_retrans 0 credits 7
1295913144.172082 < ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): SABM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x59
1295913144.180152 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.181179 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 2 pf 1 ilen 0 fcs 0x92
1295913144.181220 < ACL data: handle 46 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
1295913144.183165 > ACL data: handle 46 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC CMD: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
1295913144.183209 < ACL data: handle 46 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 1 dlci 0 pf 0 ilen 4 fcs 0x70 mcc_len 2
dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
1295913144.192141 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.194056 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.195060 > ACL data: handle 46 flags 0x02 dlen 12
L2CAP(d): cid 0x0040 len 8 [psm 3]
RFCOMM(s): MSC RSP: cr 0 dlci 0 pf 0 ilen 4 fcs 0xaa mcc_len 2
dlci 2 fc 0 rtc 1 rtr 1 ic 0 dv 1 b1 1 b2 1 b3 0 len 0
1295913144.195104 < ACL data: handle 46 flags 0x02 dlen 9
L2CAP(d): cid 0x0040 len 5 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 2 pf 1 ilen 0 fcs 0x86 credits 33
1295913144.195119 < ACL data: handle 46 flags 0x02 dlen 14
L2CAP(d): cid 0x0040 len 10 [psm 3]
RFCOMM(d): UIH: cr 1 dlci 2 pf 0 ilen 6 fcs 0x9a
68 65 6C 6C 6F 21
1295913144.195133 < ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 2 pf 1 ilen 0 fcs 0xb8
1295913144.196121 > ACL data: handle 46 flags 0x02 dlen 9
L2CAP(d): cid 0x0040 len 5 [psm 3]
RFCOMM(d): UIH: cr 0 dlci 2 pf 1 ilen 0 fcs 0x5c credits 33
1295913144.202165 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.206151 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 02 00
1295913144.207169 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): DISC: cr 0 dlci 2 pf 1 ilen 0 fcs 0xd9
1295913144.207206 < ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 0 dlci 2 pf 1 ilen 0 fcs 0xf3
1295913144.209223 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 2 pf 1 ilen 0 fcs 0x92
1295913144.209299 < ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): DM: cr 0 dlci 2 pf 1 ilen 0 fcs 0x12
1295913144.217193 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.219152 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913144.219157 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): DM: cr 1 dlci 2 pf 1 ilen 0 fcs 0x73
1295913146.203916 < ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): DISC: cr 1 dlci 0 pf 1 ilen 0 fcs 0xfd
1295913146.203965 < ACL data: handle 46 flags 0x02 dlen 12
L2CAP(s): Disconn req: dcid 0x0040 scid 0x0040
1295913146.206144 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): DISC: cr 0 dlci 0 pf 1 ilen 0 fcs 0x9c
1295913146.213138 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913146.215152 > HCI Event: Number of Completed Packets (0x13) plen 5
01 2E 00 01 00
1295913146.215157 > ACL data: handle 46 flags 0x02 dlen 8
L2CAP(d): cid 0x0040 len 4 [psm 3]
RFCOMM(s): UA: cr 1 dlci 0 pf 1 ilen 0 fcs 0xd7
1295913146.217135 > ACL data: handle 46 flags 0x02 dlen 12
L2CAP(s): Disconn rsp: dcid 0x0040 scid 0x0040
1295913148.215868 < HCI Command: Disconnect (0x01|0x0006) plen 3
2E 00 13
1295913148.224078 > HCI Event: Command Status (0x0f) plen 4
00 01 06 04
1295913148.235139 > HCI Event: Disconn Complete (0x05) plen 4
00 2E 00 16
Any assistance in resolving this would be appreciated.
Thanks,
Andrew
--
Andrew MacIsaac | Computer Engineer
Spark Integration Technologies Inc.
1880 West First Ave, Suite 200, Vancouver, BC, V6J 1G5 | T 604 736 6675 x 109 | F 604 648 9544
http://www.sparkintegration.com
------------------------------------------------------------------------
Confidentiality Warning:
========================
This message contains confidential information and is intended
only for the use individual(s) as named. If you are not the named
addressee you are hereby notified that any review,
retransmission, conversion to hard copy, copying, circulation
dissemination, or other use of this message and any attachments
is strictly prohibited. If you are not the intended recipient, please
notify the sender immediately by e-mail and delete this e-mail
from your system.
Disclaimer:
===========
E-mail transmission cannot be guaranteed to be secure or
error-free as information could be intercepted, corrupted, lost,
destroyed, arrive late or incomplete, or contain viruses. The
sender therefore does not accept liability for any errors or
omissions in the contents of this message, which arise as a
result of e-mail transmission. If verification is required please
request a hard-copy version.
------------------------------------------------------------------------
^ permalink raw reply
* Re: LE Kernel (bluetooth-le-2.6) and LE Security Manager
From: Brian Gix @ 2011-01-25 17:10 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <1295974727.2656.57.camel@ubuntuLab1>
Hi Luiz & Vinicius,
On Tue, 2011-01-25 at 08:58 -0800, Brian Gix wrote:
> On Tue, 2011-01-25 at 10:35 +0200, Luiz Augusto von Dentz wrote:
> > Hi Vinicius,
> >
> > On Mon, Jan 24, 2011 at 11:34 PM, Vinicius Costa Gomes
> > <vinicius.gomes@openbossa.org> wrote:
> > > Hi Brian,
> > >
> > > On 11:03 Mon 24 Jan, Brian Gix wrote:
> > >> Hi Vinicius,
> > >>
> > >> I am sorry that it has taken so long to test the snapshot that you
> > >> placed on gitorious, but I have now done so.
> > >>
> > >> On Fri, 2010-12-03 at 19:05 -0300, Vinicius Costa Gomes wrote:
> > >> > Hi Brian,
> > >> >
> > >> > On 11:11 Fri 03 Dec, Brian Gix wrote:
> > >> > >
> > >> > > Hi Claudio, Johan & All,
> > >> > >
> > >> > > Is this LE capable kernel that Ville is working on, the development stream
> > >> > > for the LE Security Manager? And if so, is it in a partial fleshed out
> > >> > > state?
> > >> >
> > >> > There is a simple implementation of SMP here[1] on my "devel" branch. I am
> > >> > cleaning it up for sending it for review.
> > >> >
> > >> > If you want to help, have any comments or just want to tell us what you are
> > >> > working on, please drop by #bluez on freenode, or send an email.
> > >>
> > >> I have been able to verify that the Just Works negotiation of the Short
> > >> Term Key does work against an independent implementation of the LE
> > >> Security Manager, as long as I have requested no MITM protection. I
> > >> have the following comments:
> > >>
> > >> 1. You currently reject security if I *do* request MITM protection.
> > >> This should not be done. The correct functionality should be to
> > >> continue the negotiation. Even though I requested MITM, it will be
> > >> clear to both sides that JUST_WORKS methodology has been used, and so
> > >> when the Keys are generated and exchanged, both sides will indicate in
> > >> their Key Database that they are no-MITM keys. If I then actually
> > >> *needed* MITM protection, then whatever functionality requiring that
> > >> level of security will fail with an insufficient security error code.
> > >> However, security should *never* be rejected unless there is a
> > >> fundamental incompatibility such as no level of security actually
> > >> supported. This is the only functionality that I found to be actually
> > >> incorrect.
> > >>
> > >
> > > I was assuming that the meaning of setting the MITM protection bit, was that
> > > it was *requiring* MITM protection, and when that couldn't be fulfilled the
> > > Pairing Request should be rejected.
> > >
> > > So my assumption was incorrect, going to fix it soon.
> >
> > Well the spec says it is a requirement:
> >
> > "If the STK generation method does not result in an STK that provides
> > sufficient security properties then the device shall send the Pairing
> > Failed command with the error code “Authentication Requirements”" -
> > 2.3.5.1 Selecting STK Generation Method - Page 608
My interpretation of the paragraph at the end of page 608 is that if a
device realizes that the security level that will results will not meet
it's minimum security requirements, then it may reject and abort the
pairing.
I think it is a bad reading, though, for a device to reject a pairing if
it thinks that the *other* device will not be satisfied. However that
is the case here. In this case, it was the device that did *not* have
the MITM option set (the low security device) that was rejecting the
device *with* the MITM option set.
>
> >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.
>
> Remember the phone use case: When it needs to pair with a remote device,
> it is usually a GATT client that can support any level of security. It
> does not know if this new remote device requires MITM security, or No
> security. However as the link Master and Initiator, it has to choose
> one. It Chooses MITM, and if the remote side supports MITM, then
> pairing proceeds with a resulting MITM protection level. If the remote
> device is a simple dumb device with no security, it also needs to
> proceed without failing, but this time it completes with NO-MITM as the
> protection level. If it fails because the remote doesn't require
> security, then there is a fundamental incompatibility between the
> devices, which in the SIG we have tried to avoid.
>
> >
> > In my interpretation this is exactly what should happen when MITM is
> > set but there is no way to generate an authenticated key as Table 2.4:
> > Mapping of IO Capabilities to STK Generation Method suggest, in other
> > words if one of sides has NoInputNoOutput and MITM is set we should
> > return "Authentication Requirements" error.
> >
>
--
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-25 16:58 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Vinicius Costa Gomes, linux-bluetooth
In-Reply-To: <AANLkTi=uByqBUVKD8UYwt5ZByvHwu6WpapG=BtUrFkzE@mail.gmail.com>
On Tue, 2011-01-25 at 10:35 +0200, Luiz Augusto von Dentz wrote:
> Hi Vinicius,
>
> On Mon, Jan 24, 2011 at 11:34 PM, Vinicius Costa Gomes
> <vinicius.gomes@openbossa.org> wrote:
> > Hi Brian,
> >
> > On 11:03 Mon 24 Jan, Brian Gix wrote:
> >> Hi Vinicius,
> >>
> >> I am sorry that it has taken so long to test the snapshot that you
> >> placed on gitorious, but I have now done so.
> >>
> >> On Fri, 2010-12-03 at 19:05 -0300, Vinicius Costa Gomes wrote:
> >> > Hi Brian,
> >> >
> >> > On 11:11 Fri 03 Dec, Brian Gix wrote:
> >> > >
> >> > > Hi Claudio, Johan & All,
> >> > >
> >> > > Is this LE capable kernel that Ville is working on, the development stream
> >> > > for the LE Security Manager? And if so, is it in a partial fleshed out
> >> > > state?
> >> >
> >> > There is a simple implementation of SMP here[1] on my "devel" branch. I am
> >> > cleaning it up for sending it for review.
> >> >
> >> > If you want to help, have any comments or just want to tell us what you are
> >> > working on, please drop by #bluez on freenode, or send an email.
> >>
> >> I have been able to verify that the Just Works negotiation of the Short
> >> Term Key does work against an independent implementation of the LE
> >> Security Manager, as long as I have requested no MITM protection. I
> >> have the following comments:
> >>
> >> 1. You currently reject security if I *do* request MITM protection.
> >> This should not be done. The correct functionality should be to
> >> continue the negotiation. Even though I requested MITM, it will be
> >> clear to both sides that JUST_WORKS methodology has been used, and so
> >> when the Keys are generated and exchanged, both sides will indicate in
> >> their Key Database that they are no-MITM keys. If I then actually
> >> *needed* MITM protection, then whatever functionality requiring that
> >> level of security will fail with an insufficient security error code.
> >> However, security should *never* be rejected unless there is a
> >> fundamental incompatibility such as no level of security actually
> >> supported. This is the only functionality that I found to be actually
> >> incorrect.
> >>
> >
> > I was assuming that the meaning of setting the MITM protection bit, was that
> > it was *requiring* MITM protection, and when that couldn't be fulfilled the
> > Pairing Request should be rejected.
> >
> > So my assumption was incorrect, going to fix it soon.
>
> Well the spec says it is a requirement:
>
> "If the STK generation method does not result in an STK that provides
> sufficient security properties then the device shall send the Pairing
> Failed command with the error code “Authentication Requirements”" -
> 2.3.5.1 Selecting STK Generation Method - Page 608
>>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.
Remember the phone use case: When it needs to pair with a remote device,
it is usually a GATT client that can support any level of security. It
does not know if this new remote device requires MITM security, or No
security. However as the link Master and Initiator, it has to choose
one. It Chooses MITM, and if the remote side supports MITM, then
pairing proceeds with a resulting MITM protection level. If the remote
device is a simple dumb device with no security, it also needs to
proceed without failing, but this time it completes with NO-MITM as the
protection level. If it fails because the remote doesn't require
security, then there is a fundamental incompatibility between the
devices, which in the SIG we have tried to avoid.
>
> In my interpretation this is exactly what should happen when MITM is
> set but there is no way to generate an authenticated key as Table 2.4:
> Mapping of IO Capabilities to STK Generation Method suggest, in other
> words if one of sides has NoInputNoOutput and MITM is set we should
> return "Authentication Requirements" error.
>
--
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
* [PATCH] plugins: hciops: remove scan disable on poweroff
From: Pavan Savoy @ 2011-01-25 16:33 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1295973136-30908-1-git-send-email-pavan_savoy@sify.com>
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: why scan_disable during hciops_power_off
From: Pavan Savoy @ 2011-01-25 16:17 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Johan Hedberg, Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <1295971902.1520.52.camel@aeonflux>
On Tue, Jan 25, 2011 at 9:41 PM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Johan,
>
>> > >> 1. are there controllers there which even after doing hci0 down,
>> > >> allows other devices to be scanned?
>> > >> for those what do hci0 down mean ? radio not switched off ?
>> > >
>> > > Good point, perhaps this is driver dependent, so we do it just be safe guard.
>> >
>> > I hope all devices and drivers out there consider the hci0 down as the
>> > radio OFF,
>> > I don't think there is a reason for it to be otherwise....
>> > so why the safe-guard ?
>>
>> IIRC Marcel added this due to paranoia with the non-connectable GAP test
>> case with the BITE tester. The test kept failing even though the device
>> was in DOWN state.
>
> we also had the case where we considered non-connectable as off when the
> HCI devdown was not working properly. However this is a long time ago
> and has been fixed properly. So we might can remove this now.
Oo...
I want to send the patch, I want to send the patch ..
Can I please .....
> Regards
>
> Marcel
>
>
>
^ permalink raw reply
* Re: [PATCH] bluetooth: Fix for security block issue.
From: Marcel Holtmann @ 2011-01-25 16:13 UTC (permalink / raw)
To: Lukasz Rymanowski
Cc: linux-bluetooth, linus.walleij, par-gunnar.p.hjalmdahl, padovan
In-Reply-To: <1295965639-16683-1-git-send-email-lukasz.rymanowski@tieto.com>
Hi Lukasz,
> It can happen that controller will schedule ACL data
> containing L2CAP connect request to host just before
> encryption change event, even though link is encrypted on
> LMP level before L2CAP connect request come.
> With this fix, L2CAP layer will handle such scenario.
I really don't like to have a work around for this. It is clearly a bug
in the controller.
Regards
Marcel
^ permalink raw reply
* Re: why scan_disable during hciops_power_off
From: Marcel Holtmann @ 2011-01-25 16:11 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Pavan Savoy, Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <20110125160830.GA14610@jh-x301>
Hi Johan,
> > >> 1. are there controllers there which even after doing hci0 down,
> > >> allows other devices to be scanned?
> > >> for those what do hci0 down mean ? radio not switched off ?
> > >
> > > Good point, perhaps this is driver dependent, so we do it just be safe guard.
> >
> > I hope all devices and drivers out there consider the hci0 down as the
> > radio OFF,
> > I don't think there is a reason for it to be otherwise....
> > so why the safe-guard ?
>
> IIRC Marcel added this due to paranoia with the non-connectable GAP test
> case with the BITE tester. The test kept failing even though the device
> was in DOWN state.
we also had the case where we considered non-connectable as off when the
HCI devdown was not working properly. However this is a long time ago
and has been fixed properly. So we might can remove this now.
Regards
Marcel
^ permalink raw reply
* Re: why scan_disable during hciops_power_off
From: Johan Hedberg @ 2011-01-25 16:08 UTC (permalink / raw)
To: Pavan Savoy; +Cc: Luiz Augusto von Dentz, linux-bluetooth
In-Reply-To: <AANLkTimxHnqd9hp_Uu9DCXokq2Zj0bBb-3aJqRXE_AdE@mail.gmail.com>
Hi,
On Tue, Jan 25, 2011, Pavan Savoy wrote:
> >> 1. are there controllers there which even after doing hci0 down,
> >> allows other devices to be scanned?
> >> for those what do hci0 down mean ? radio not switched off ?
> >
> > Good point, perhaps this is driver dependent, so we do it just be safe guard.
>
> I hope all devices and drivers out there consider the hci0 down as the
> radio OFF,
> I don't think there is a reason for it to be otherwise....
> so why the safe-guard ?
IIRC Marcel added this due to paranoia with the non-connectable GAP test
case with the BITE tester. The test kept failing even though the device
was in DOWN state.
Johan
^ permalink raw reply
* Re: why scan_disable during hciops_power_off
From: Pavan Savoy @ 2011-01-25 15:58 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimUJoUmYorKNdNJPke_GJbAr6AK-ercNGr1uRRA@mail.gmail.com>
On Tue, Jan 25, 2011 at 8:57 PM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi,
>
> On Tue, Jan 25, 2011 at 3:12 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
>> when hciops gets a set_powered with powered=0, then hciops_power_off is called.
>> However in here we write the SCAN_ENABLE (=0) to the device and then
>> do the HCIDEVDOWN...
>>
>> so couple of questions,
>> 1. are there controllers there which even after doing hci0 down,
>> allows other devices to be scanned?
>> for those what do hci0 down mean ? radio not switched off ?
>
> Good point, perhaps this is driver dependent, so we do it just be safe guard.
I hope all devices and drivers out there consider the hci0 down as the
radio OFF,
I don't think there is a reason for it to be otherwise....
so why the safe-guard ?
>> 2. what happens to the response? in case hci0 down is considered as
>> say close of UART?
>> There is a case I have a combo chip, and I need to keep UART opened,
>> because someone else is using the UART, and then
>> I do this power_off, the hci0 interface is down, and bluetooth just
>> dumps down the scan_disable and quits, but the response
>> which comes from the device has no takers....
>>
>> so shouldn't hciops use a hci_send_req before HCIDEVDOWN ?
>
> It should and Im almost sure we do send it before, if we do sent it
> latter than it is probably a bug.
we do send it before, but don't really care about the response.
I was mentioning here use of hci_send_req instead of hci_send_cmd
before HCIDEVDOWN, so
that the function waits for response and finishes up work before the DEVDOWN....
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
^ permalink raw reply
* Re: why scan_disable during hciops_power_off
From: Luiz Augusto von Dentz @ 2011-01-25 15:27 UTC (permalink / raw)
To: Pavan Savoy; +Cc: linux-bluetooth
In-Reply-To: <AANLkTinQdwaAQk6LU_uLJ60YFOthhuwu5rL2gzZUXZ-k@mail.gmail.com>
Hi,
On Tue, Jan 25, 2011 at 3:12 PM, Pavan Savoy <pavan_savoy@sify.com> wrote:
> when hciops gets a set_powered with powered=0, then hciops_power_off is called.
> However in here we write the SCAN_ENABLE (=0) to the device and then
> do the HCIDEVDOWN...
>
> so couple of questions,
> 1. are there controllers there which even after doing hci0 down,
> allows other devices to be scanned?
> for those what do hci0 down mean ? radio not switched off ?
Good point, perhaps this is driver dependent, so we do it just be safe guard.
> 2. what happens to the response? in case hci0 down is considered as
> say close of UART?
> There is a case I have a combo chip, and I need to keep UART opened,
> because someone else is using the UART, and then
> I do this power_off, the hci0 interface is down, and bluetooth just
> dumps down the scan_disable and quits, but the response
> which comes from the device has no takers....
>
> so shouldn't hciops use a hci_send_req before HCIDEVDOWN ?
It should and Im almost sure we do send it before, if we do sent it
latter than it is probably a bug.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Refusing SCO from non-connected headset
From: Mike @ 2011-01-25 14:54 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Gustavo F. Padovan
In-Reply-To: <AANLkTinwD7W66qfpxQWJ62UPwSJjF+msYNwac90SEEu=@mail.gmail.com>
On Mon, Jan 24, 2011 at 9:38 PM, Mike <puffy.taco@gmail.com> wrote:
> On Mon, Jan 24, 2011 at 9:07 PM, Gustavo F. Padovan
> <padovan@profusion.mobi> wrote:
>> Hi Mike,
>>
>> * Mike <puffy.taco@gmail.com> [2011-01-24 20:35:51 -0600]:
>>
>>> I get the following error when I try to dial a phone number from my
>>> cell phone and am connected using HFP:
>>>
>>> bluetoothd[14651]: audio/main.c:sco_server_cb() Refusing SCO from
>>> non-connected headset
>>
>> Please post full logs of bluetoothd -nd
>
> Log is pasted below. One thing to note, if I comment out the section
> of audio/main.c that is the "if (device->headset) {" block (around
> line 102), then the connection goes through as a gateway. I can then
> see SCO packets scroll by in hcidump, though pulseaudio does not seem
> to notice so I have no way of playing that audio. The log though is
> of unaltered source.
>
Here is a log of sdptool browse on the device. Still trying to figure
out why "device->headset" is set, because it doesn't support that
profile. A grep through this log for 1108 only shows up under a
"Profile Descriptor List" category.
Browsing 00:17:E3:3B:4F:DD ...
Service RecHandle: 0x0
Service Class ID List:
"SDP Server" (0x1000)
Protocol Descriptor List:
"L2CAP" (0x0100)
"SDP" (0x0001)
Profile Descriptor List:
"SDP Server" (0x1000)
Version: 0x0100
Service Name: Dialup Networking Gateway
Service Description: Dialup Networking Gateway
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x10001
Service Class ID List:
"Dialup Networking" (0x1103)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 1
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"Dialup Networking" (0x1103)
Version: 0x0100
Service Name: Voice Gateway
Service Description: Headset Audio Gateway
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x10003
Service Class ID List:
"Headset Audio Gateway" (0x1112)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 3
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"Headset" (0x1108)
Version: 0x0100
Service Name: Handsfree Voice Gateway
Service Description: Handsfree Voice Gateway
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x10007
Service Class ID List:
"Handsfree Audio Gateway" (0x111f)
"Generic Audio" (0x1203)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 7
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"Handsfree" (0x111e)
Version: 0x0105
Service Name: OBEX Object Push
Service Description: OBEX Object Push
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x10008
Service Class ID List:
"OBEX Object Push" (0x1105)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 8
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"OBEX Object Push" (0x1105)
Version: 0x0100
Service Name: OBEX File Transfer
Service Description: OBEX File Transfer
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x10009
Service Class ID List:
"OBEX File Transfer" (0x1106)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 9
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"OBEX File Transfer" (0x1106)
Version: 0x0100
Service Name: Image Push
Service Description: Image Push
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x1000a
Service Class ID List:
"Imaging Responder" (0x111b)
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 10
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"Imaging" (0x111a)
Version: 0x0100
Service Name: Audio Source
Service Description: Audio Source
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x1000d
Service Class ID List:
"Audio Source" (0x110a)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 25
"AVDTP" (0x0019)
uint16: 0x100
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"Advanced Audio" (0x110d)
Version: 0x0100
Service Name: Audio Video Remote Control Target
Service Description: Audio Video Remote Control Target
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x1000e
Service Class ID List:
"AV Remote Target" (0x110c)
Protocol Descriptor List:
"L2CAP" (0x0100)
PSM: 23
"AVCTP" (0x0017)
uint16: 0x100
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
Profile Descriptor List:
"AV Remote Target" (0x110c)
Version: 0x0100
Service Name: SyncML Data Synchronization
Service Description: SyncML Data Synchronization
Service Provider: /a/mobile/system/cl.gif
Service RecHandle: 0x10010
Service Class ID List:
UUID 128: 00000002-0000-1000-8000-0002ee000002
Protocol Descriptor List:
"L2CAP" (0x0100)
"RFCOMM" (0x0003)
Channel: 12
"OBEX" (0x0008)
Language Base Attr List:
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
code_ISO639: 0x6672
encoding: 0x6a
base_offset: 0xc800
code_ISO639: 0x6573
encoding: 0x6a
base_offset: 0xc803
code_ISO639: 0x7074
encoding: 0x6a
base_offset: 0xc806
^ permalink raw reply
* [PATCH] bluetooth: Fix for security block issue.
From: Lukasz Rymanowski @ 2011-01-25 14:27 UTC (permalink / raw)
To: linux-bluetooth
Cc: linus.walleij, par-gunnar.p.hjalmdahl, padovan, marcel,
Lukasz Rymanowski
It can happen that controller will schedule ACL data
containing L2CAP connect request to host just before
encryption change event, even though link is encrypted on
LMP level before L2CAP connect request come.
With this fix, L2CAP layer will handle such scenario.
Signed-off-by: Lukasz Rymanowski <lukasz.rymanowski@tieto.com>
---
include/net/bluetooth/l2cap.h | 8 +++++++
net/bluetooth/l2cap.c | 46 +++++++++++++++++++++++++++++++++++++++++
2 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
index 7f88a87..f1a5bd8 100644
--- a/include/net/bluetooth/l2cap.h
+++ b/include/net/bluetooth/l2cap.h
@@ -262,6 +262,11 @@ struct l2cap_chan_list {
long num;
};
+struct l2cap_pend_conn_req {
+ struct l2cap_cmd_hdr cmd;
+ struct l2cap_conn_req conn_req;
+};
+
struct l2cap_conn {
struct hci_conn *hcon;
@@ -276,6 +281,9 @@ struct l2cap_conn {
__u8 info_ident;
struct timer_list info_timer;
+ struct timer_list encrypt_timer;
+
+ struct l2cap_pend_conn_req *p_req;
spinlock_t lock;
diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
index d99b6b7..09181c7 100644
--- a/net/bluetooth/l2cap.c
+++ b/net/bluetooth/l2cap.c
@@ -57,6 +57,7 @@
#define VERSION "2.15"
+#define ENCRYPT_TIMEOUT (20) /* 20 ms */
static int disable_ertm;
static u32 l2cap_feat_mask = L2CAP_FEAT_FIXED_CHAN;
@@ -75,6 +76,7 @@ static void l2cap_busy_work(struct work_struct *work);
static void __l2cap_sock_close(struct sock *sk, int reason);
static void l2cap_sock_close(struct sock *sk);
static void l2cap_sock_kill(struct sock *sk);
+static void l2cap_encrypt_timeout(unsigned long arg);
static int l2cap_build_conf_req(struct sock *sk, void *data);
static struct sk_buff *l2cap_build_cmd(struct l2cap_conn *conn,
@@ -707,6 +709,8 @@ static struct l2cap_conn *l2cap_conn_add(struct hci_conn *hcon, u8 status)
setup_timer(&conn->info_timer, l2cap_info_timeout,
(unsigned long) conn);
+ setup_timer(&conn->encrypt_timer, l2cap_encrypt_timeout,
+ (unsigned long) conn);
conn->disc_reason = 0x13;
return conn;
@@ -735,6 +739,11 @@ static void l2cap_conn_del(struct hci_conn *hcon, int err)
if (conn->info_state & L2CAP_INFO_FEAT_MASK_REQ_SENT)
del_timer_sync(&conn->info_timer);
+ if (conn->p_req)
+ del_timer_sync(&conn->encrypt_timer);
+
+ kfree(conn->p_req);
+
hcon->l2cap_data = NULL;
kfree(conn);
}
@@ -2982,6 +2991,28 @@ static inline int l2cap_connect_req(struct l2cap_conn *conn, struct l2cap_cmd_hd
/* Check if the ACL is secure enough (if not SDP) */
if (psm != cpu_to_le16(0x0001) &&
!hci_conn_check_link_mode(conn->hcon)) {
+ /* Let's give a chance to Encryption Change Evt.*/
+ if (!conn->p_req) {
+ conn->p_req = kzalloc(sizeof(*conn->p_req), GFP_KERNEL);
+ if (conn->p_req) {
+ BT_DBG("Create pending connection req %p.",
+ conn->p_req);
+
+ memcpy(&conn->p_req->cmd, cmd, sizeof(*cmd));
+ memcpy(&conn->p_req->conn_req, req,
+ sizeof(*req));
+
+ mod_timer(&conn->encrypt_timer, jiffies +
+ msecs_to_jiffies(ENCRYPT_TIMEOUT));
+
+ /*
+ * We will restart l2cap_conn_req in
+ * l2cap_encrypt_timeout.
+ */
+ bh_unlock_sock(parent);
+ return 0;
+ }
+ }
conn->disc_reason = 0x05;
result = L2CAP_CR_SEC_BLOCK;
goto response;
@@ -3147,6 +3178,21 @@ static inline int l2cap_connect_rsp(struct l2cap_conn *conn, struct l2cap_cmd_hd
return 0;
}
+static void l2cap_encrypt_timeout(unsigned long arg)
+{
+ struct l2cap_conn *conn = (void *) arg;
+
+ BUG_ON(conn->p_req == NULL);
+
+ BT_DBG("conn %p, p_req %p", conn, conn->p_req);
+
+ (void)l2cap_connect_req(conn, &conn->p_req->cmd,
+ (u8 *)&conn->p_req->conn_req);
+
+ kfree(conn->p_req);
+ conn->p_req = NULL;
+}
+
static inline void set_default_fcs(struct l2cap_pinfo *pi)
{
/* FCS is enabled only in ERTM or streaming mode, if one or both
--
1.7.0.4
/Lukasz
on behalf of STEricsson
^ permalink raw reply related
* why scan_disable during hciops_power_off
From: Pavan Savoy @ 2011-01-25 13:12 UTC (permalink / raw)
To: linux-bluetooth
when hciops gets a set_powered with powered=0, then hciops_power_off is called.
However in here we write the SCAN_ENABLE (=0) to the device and then
do the HCIDEVDOWN...
so couple of questions,
1. are there controllers there which even after doing hci0 down,
allows other devices to be scanned?
for those what do hci0 down mean ? radio not switched off ?
2. what happens to the response? in case hci0 down is considered as
say close of UART?
There is a case I have a combo chip, and I need to keep UART opened,
because someone else is using the UART, and then
I do this power_off, the hci0 interface is down, and bluetooth just
dumps down the scan_disable and quits, but the response
which comes from the device has no takers....
so shouldn't hciops use a hci_send_req before HCIDEVDOWN ?
regards,
Pavan
^ 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