* Re: [PATCH] Set security level to MEDIUM for mcap instances created from HDP plugin
From: Elvis Pfützenreuter @ 2011-03-23 12:36 UTC (permalink / raw)
To: Santiago Carot-Nemesio; +Cc: linux-bluetooth
In-Reply-To: <1300882066-7273-1-git-send-email-sancane@gmail.com>
Hi,
On 23 Mar 2011, at 09:07 , Santiago Carot-Nemesio wrote:
> Some health devices without IO capabilities can't connect to mcap
> instances when security level is set to HIGH. This patch enables
> above devices to connect to Health instances avoiding the MITM
> problem.
> ---
> health/hdp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/health/hdp.c b/health/hdp.c
> index d4a2a30..3c2dce1 100644
> --- a/health/hdp.c
> +++ b/health/hdp.c
> @@ -1329,7 +1329,7 @@ static gboolean update_adapter(struct hdp_adapter *hdp_adapter)
> goto update;
>
> adapter_get_address(hdp_adapter->btd_adapter, &addr);
> - hdp_adapter->mi = mcap_create_instance(&addr, BT_IO_SEC_HIGH, 0, 0,
> + hdp_adapter->mi = mcap_create_instance(&addr, BT_IO_SEC_MEDIUM, 0, 0,
> mcl_connected, mcl_reconnected,
> mcl_disconnected, mcl_uncached,
> NULL, /* CSP is not used by now */
> --
> 1.7.4.1
Tested here com Nonin 9650 oximeter, works perfectly.
^ permalink raw reply
* [PATCH 2/2] Fix memory leak of matched device drivers list
From: Claudio Takahasi @ 2011-03-23 12:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
src/device.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/src/device.c b/src/device.c
index b4d13f2..771a908 100644
--- a/src/device.c
+++ b/src/device.c
@@ -1111,8 +1111,7 @@ static GSList *device_match_driver(struct btd_device *device,
/* match pattern driver */
match = device_match_pattern(device, *uuid, profiles);
- for (; match; match = match->next)
- uuids = g_slist_append(uuids, match->data);
+ uuids = g_slist_concat(uuids, match);
}
return uuids;
--
1.7.4.1
^ permalink raw reply related
* Re: how to set adapter to master with bluez 4.69?
From: Brian J. Murrell @ 2011-03-23 12:20 UTC (permalink / raw)
To: Brad Midgley; +Cc: linux-bluetooth
In-Reply-To: <4D89DCE6.7050106@interlinx.bc.ca>
[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]
Experimenting again this morning with both the mouse and the headset
connected both with the B/T adapter as master and the eSCO connection as
slave (since I can't seem to influence that), it was working fairly
stably. Every now and then all devices would just completely
disconnected and then they would all reconnect.
However this most recent disconnect of all devices resulted in the mouse
reconnecting immediately but the headset went through a dozen or two
reconnection attempts (i.e. as observed by watching the output of
hcitool con with "watch -n 0") before it finally got reconnected.
This is in contrast to where I can have a completely stable (i.e. days
on end without a single hiccup) connection with just the mouse.
This really is frustrating. ~sigh~
With all of the time I have pissed away on this, if I knew of a B/T
adapter/chipset that would absolutely work stably with multiple devices
(mouse, headset, etc.) I would just run out and buy one, but as it is, I
am on my third B/T adapter here and still nothing works stably -- as
opposed to my laptop where multiple devices seem to cohabitate nicely.
Hrm, Given that I have multiple B/T adapters here, I don't suppose I'd
have any better luck by using another B/T adapter and just assigning 1
device to each, would I?
Cheers,
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* [PATCH 1/2] Remove unnecessary btd_driver_data struct
From: Claudio Takahasi @ 2011-03-23 12:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <AANLkTin6PCLVm5H1o0gBFhX_XipETYCxia4ASdqjPNpL@mail.gmail.com>
---
src/device.c | 29 ++++++-----------------------
1 files changed, 6 insertions(+), 23 deletions(-)
diff --git a/src/device.c b/src/device.c
index e9d9e65..b4d13f2 100644
--- a/src/device.c
+++ b/src/device.c
@@ -67,12 +67,6 @@
/* When all services should trust a remote device */
#define GLOBAL_TRUST "[all]"
-struct btd_driver_data {
- guint id;
- struct btd_device_driver *driver;
- void *priv;
-};
-
struct btd_disconnect_data {
guint id;
disconnect_watch watch;
@@ -120,7 +114,7 @@ struct btd_device {
GSList *uuids;
GSList *services; /* Primary services path */
GSList *primaries; /* List of primary services */
- GSList *drivers; /* List of driver_data */
+ GSList *drivers; /* List of device drivers */
GSList *watches; /* List of disconnect_data */
gboolean temporary;
struct agent *agent;
@@ -413,15 +407,12 @@ static DBusMessage *set_trust(DBusConnection *conn, DBusMessage *msg,
return dbus_message_new_method_return(msg);
}
-static void driver_remove(struct btd_driver_data *driver_data,
+static void driver_remove(struct btd_device_driver *driver,
struct btd_device *device)
{
- struct btd_device_driver *driver = driver_data->driver;
-
driver->remove(device);
- device->drivers = g_slist_remove(device->drivers, driver_data);
- g_free(driver_data);
+ device->drivers = g_slist_remove(device->drivers, driver);
}
static gboolean do_disconnect(gpointer user_data)
@@ -1145,26 +1136,21 @@ void device_probe_drivers(struct btd_device *device, GSList *profiles)
for (list = device_drivers; list; list = list->next) {
struct btd_device_driver *driver = list->data;
GSList *probe_uuids;
- struct btd_driver_data *driver_data;
probe_uuids = device_match_driver(device, driver, profiles);
if (!probe_uuids)
continue;
- driver_data = g_new0(struct btd_driver_data, 1);
-
err = driver->probe(device, probe_uuids);
if (err < 0) {
error("%s driver probe failed for device %s",
driver->name, addr);
- g_free(driver_data);
g_slist_free(probe_uuids);
continue;
}
- driver_data->driver = driver;
- device->drivers = g_slist_append(device->drivers, driver_data);
+ device->drivers = g_slist_append(device->drivers, driver);
g_slist_free(probe_uuids);
}
@@ -1198,8 +1184,7 @@ static void device_remove_drivers(struct btd_device *device, GSList *uuids)
DBG("Removing drivers for %s", dstaddr);
for (list = device->drivers; list; list = next) {
- struct btd_driver_data *driver_data = list->data;
- struct btd_device_driver *driver = driver_data->driver;
+ struct btd_device_driver *driver = list->data;
const char **uuid;
next = list->next;
@@ -1214,9 +1199,7 @@ static void device_remove_drivers(struct btd_device *device, GSList *uuids)
driver->remove(device);
device->drivers = g_slist_remove(device->drivers,
- driver_data);
- g_free(driver_data);
-
+ driver);
break;
}
}
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2] Fix strict aliasing issue
From: Rafal Michalski @ 2011-03-23 12:11 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
This patch changes type of "pending" flag to uint32_t type.
Pointer to this flag is passed to hci_clear_bit function as void * and
then casted to uint32_t * again. Previously unsigned long type made some
unexpected performance which occured after violating strict aliasing
rule. This patch fixes this problem and this solution is much easier than
solution of changing types of many object (from uint32_t to unsigned long,
including changing type for castng in hci_*_bit function family), which
is overcomplicated. Also, not all objects can be changed, like
hci_dev_info struct, since it is violating compatibility rules between
kernel and user spaces.
---
plugins/hciops.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/plugins/hciops.c b/plugins/hciops.c
index 4225cd8..69627eb 100644
--- a/plugins/hciops.c
+++ b/plugins/hciops.c
@@ -111,7 +111,7 @@ static struct dev_info {
uint16_t did_version;
gboolean up;
- unsigned long pending;
+ uint32_t pending;
GIOChannel *io;
guint watch_id;
--
1.6.3.3
^ permalink raw reply related
* [PATCH] Set security level to MEDIUM for mcap instances created from HDP plugin
From: Santiago Carot-Nemesio @ 2011-03-23 12:07 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Santiago Carot-Nemesio
Some health devices without IO capabilities can't connect to mcap
instances when security level is set to HIGH. This patch enables
above devices to connect to Health instances avoiding the MITM
problem.
---
health/hdp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/health/hdp.c b/health/hdp.c
index d4a2a30..3c2dce1 100644
--- a/health/hdp.c
+++ b/health/hdp.c
@@ -1329,7 +1329,7 @@ static gboolean update_adapter(struct hdp_adapter *hdp_adapter)
goto update;
adapter_get_address(hdp_adapter->btd_adapter, &addr);
- hdp_adapter->mi = mcap_create_instance(&addr, BT_IO_SEC_HIGH, 0, 0,
+ hdp_adapter->mi = mcap_create_instance(&addr, BT_IO_SEC_MEDIUM, 0, 0,
mcl_connected, mcl_reconnected,
mcl_disconnected, mcl_uncached,
NULL, /* CSP is not used by now */
--
1.7.4.1
^ permalink raw reply related
* Re: BlueZ health device interface, problems with link security level?
From: Santiago Carot @ 2011-03-23 11:47 UTC (permalink / raw)
To: Elvis Pfützenreuter
Cc: Johan Hedberg, james.steele, wjturner, linux-bluetooth
In-Reply-To: <04A63FE3-17AC-4C4C-A5B7-CDACC10A8917@signove.com>
Hello,
2011/3/23 Elvis Pfützenreuter <epx@signove.com>:
>
> On 23 Mar 2011, at 06:26 , Johan Hedberg wrote:
>
>> Hi,
>>
>> On Wed, Mar 23, 2011, Santiago Carot wrote:
>>>>> There has been discussion whether BlueZ HDP is correct or not in this
>>>>> respect. The HDP specification says that devices SHOULD require authenticated
>>>>> and encrypted connections (which maps to SEC_HIGH) while some devices are
>>>>> known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD',
>>>>> not 'SHALL'.
>>>>
>>>> An "authenticated" connection has a slightly ambiguous meaning in
>>>> Bluetooth since 2.1+EDR, since you can have an authenticated link that
>>>> does not have any MITM protection.
>>>>
>>>> I think the correct behavior is that HDP should be using "Level 2"
>>>> (from GAP in the Core specification), where HDP wants the strongest
>>>> level of security it can achieve with a device, but it does not want to
>>>> exclude devices that do not have the capability to support input/output.
>>>>
>>>> There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ
>>>> and Security Level 2 in GAP. I believe that the intention of Level 2
>>>> is to propose that MITM protection is needed - however it will happily
>>>> accept security where no MITM protection has been achieved (this being
>>>> the difference between Level 2 and Level 3). BlueZ however does not
>>>> seem to propose MITM protection for SEC_MEDIUM - which would be important
>>>> for HDP (at least in the BlueZ <-> BlueZ case).
>>>
>>> I remember that issue with we were developing HDP and MCAP. We set
>>> SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS.
>>> The problem doing that is related with devices that don't support MITM
>>> protection (In fact if they don't have any
>>> user input capabilities). This may be a good opportunity to go back
>>> about this issue. What do you think?
>>>
>>> In any case, such as Elvis has said, you can disable sspmode to get
>>> HDP working without modify BlueZ code.
>>
>> Either I just don't remember correctly how SEC_MEDIUM is supposed to
>> work or then there's some confusion here. Medium security will require
>> encryption. The main difference that high security brings is that
>> unauthenticated link keys will not be accepted. Furthermore, you should
>> also be able to get an authenticated link key with medium security as
>> long as both sides have the IO capabilities for it and at least one side
>> requires MITM protection (only if *neither* side requires MITM will Just
>> Works be triggered).
>
> So it is a matter of testing HDP with Nonin oximeter (which works with
> HIGH security) having BlueZ set to MEDIUM. If it works ok, we should
> submit a patch to change HDP to MEDIUM.
I'm agree. I'm going to send a patch fixing that
^ permalink raw reply
* Re: BlueZ health device interface, problems with link security level?
From: Elvis Pfützenreuter @ 2011-03-23 11:44 UTC (permalink / raw)
To: Johan Hedberg; +Cc: Santiago Carot, james.steele, wjturner, linux-bluetooth
In-Reply-To: <20110323092612.GA16903@jh-x301>
On 23 Mar 2011, at 06:26 , Johan Hedberg wrote:
> Hi,
>
> On Wed, Mar 23, 2011, Santiago Carot wrote:
>>>> There has been discussion whether BlueZ HDP is correct or not in this
>>>> respect. The HDP specification says that devices SHOULD require authenticated
>>>> and encrypted connections (which maps to SEC_HIGH) while some devices are
>>>> known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD',
>>>> not 'SHALL'.
>>>
>>> An "authenticated" connection has a slightly ambiguous meaning in
>>> Bluetooth since 2.1+EDR, since you can have an authenticated link that
>>> does not have any MITM protection.
>>>
>>> I think the correct behavior is that HDP should be using "Level 2"
>>> (from GAP in the Core specification), where HDP wants the strongest
>>> level of security it can achieve with a device, but it does not want to
>>> exclude devices that do not have the capability to support input/output.
>>>
>>> There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ
>>> and Security Level 2 in GAP. I believe that the intention of Level 2
>>> is to propose that MITM protection is needed - however it will happily
>>> accept security where no MITM protection has been achieved (this being
>>> the difference between Level 2 and Level 3). BlueZ however does not
>>> seem to propose MITM protection for SEC_MEDIUM - which would be important
>>> for HDP (at least in the BlueZ <-> BlueZ case).
>>
>> I remember that issue with we were developing HDP and MCAP. We set
>> SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS.
>> The problem doing that is related with devices that don't support MITM
>> protection (In fact if they don't have any
>> user input capabilities). This may be a good opportunity to go back
>> about this issue. What do you think?
>>
>> In any case, such as Elvis has said, you can disable sspmode to get
>> HDP working without modify BlueZ code.
>
> Either I just don't remember correctly how SEC_MEDIUM is supposed to
> work or then there's some confusion here. Medium security will require
> encryption. The main difference that high security brings is that
> unauthenticated link keys will not be accepted. Furthermore, you should
> also be able to get an authenticated link key with medium security as
> long as both sides have the IO capabilities for it and at least one side
> requires MITM protection (only if *neither* side requires MITM will Just
> Works be triggered).
So it is a matter of testing HDP with Nonin oximeter (which works with
HIGH security) having BlueZ set to MEDIUM. If it works ok, we should
submit a patch to change HDP to MEDIUM.
^ permalink raw reply
* Re: how to set adapter to master with bluez 4.69?
From: Brian J. Murrell @ 2011-03-23 11:43 UTC (permalink / raw)
To: Brad Midgley; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=N_5BaEOaaFsTHhNF82Vo83bzeNuzqmd9rMU3j@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]
On 11-03-14 11:29 AM, Brad Midgley wrote:
> Brian,
Hey Brad,
> iirc, the hcitool output tells you the role of the local adapter in
> the connection. So when you see 'master' in that list, it's what you
> want. You should also be requesting master when you try hcitool.
Does the above still jive with all of this:
$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: SLAVE ACCEPT
Notice the B/T adapter's link mode is set to slave, yet...
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
In the connection with the mouse, the B/T adapter is master.
I can change it successfully:
brian@pc:~$ sudo hciconfig hci0 lm master,accept
brian@pc:~$ hciconfig hci0 lm
hci0: Type: BR/EDR Bus: USB
BD Address: 00:02:72:1E:E0:12 ACL MTU: 1021:7 SCO MTU: 64:1
Link mode: ACCEPT MASTER
Which doesn't change the connection with the mouse:
$ hcitool con
Connections:
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
When I connect the headset using the bluetooth-applet:
$ hcitool con
Connections:
< eSCO 00:18:6B:E5:4F:7E handle 6 state 1 lm SLAVE
< ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
The connection with the headset itself has the B/T adapter as master but
this eSCO connection is slave?
Oh wait. The eSCO connection disappeared now:
$ hcitool con
Connections:
< ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
Now that I play something through the headset it comes back:
Connections:
< eSCO 00:18:6B:E5:4F:7E handle 6 state 1 lm SLAVE
< ACL 00:18:6B:E5:4F:7E handle 12 state 1 lm MASTER AUTH ENCRYPT
> ACL 00:1F:20:0F:30:6A handle 11 state 1 lm MASTER
I guess that eSCO connection is only active when there is audio sent to
the headset perhaps.
I sure wish I could get all of this to work reliably. Even if I had to
follow a recipe of manual steps -- something I have not yet been able to
figure out with any consistency.
b.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
^ permalink raw reply
* Re: BlueZ health device interface, problems with link security level?
From: Johan Hedberg @ 2011-03-23 9:26 UTC (permalink / raw)
To: Santiago Carot; +Cc: james.steele, epx, wjturner, linux-bluetooth
In-Reply-To: <AANLkTin2vUmA5Y0Vx_JuoBJ9XviTqgDQsGzde=g+0PP=@mail.gmail.com>
Hi,
On Wed, Mar 23, 2011, Santiago Carot wrote:
> > > There has been discussion whether BlueZ HDP is correct or not in this
> > > respect. The HDP specification says that devices SHOULD require authenticated
> > > and encrypted connections (which maps to SEC_HIGH) while some devices are
> > > known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD',
> > > not 'SHALL'.
> >
> > An "authenticated" connection has a slightly ambiguous meaning in
> > Bluetooth since 2.1+EDR, since you can have an authenticated link that
> > does not have any MITM protection.
> >
> > I think the correct behavior is that HDP should be using "Level 2"
> > (from GAP in the Core specification), where HDP wants the strongest
> > level of security it can achieve with a device, but it does not want to
> > exclude devices that do not have the capability to support input/output.
> >
> > There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ
> > and Security Level 2 in GAP. I believe that the intention of Level 2
> > is to propose that MITM protection is needed - however it will happily
> > accept security where no MITM protection has been achieved (this being
> > the difference between Level 2 and Level 3). BlueZ however does not
> > seem to propose MITM protection for SEC_MEDIUM - which would be important
> > for HDP (at least in the BlueZ <-> BlueZ case).
>
> I remember that issue with we were developing HDP and MCAP. We set
> SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS.
> The problem doing that is related with devices that don't support MITM
> protection (In fact if they don't have any
> user input capabilities). This may be a good opportunity to go back
> about this issue. What do you think?
>
> In any case, such as Elvis has said, you can disable sspmode to get
> HDP working without modify BlueZ code.
Either I just don't remember correctly how SEC_MEDIUM is supposed to
work or then there's some confusion here. Medium security will require
encryption. The main difference that high security brings is that
unauthenticated link keys will not be accepted. Furthermore, you should
also be able to get an authenticated link key with medium security as
long as both sides have the IO capabilities for it and at least one side
requires MITM protection (only if *neither* side requires MITM will Just
Works be triggered).
Johan
^ permalink raw reply
* Re: BlueZ health device interface, problems with link security level?
From: Santiago Carot @ 2011-03-23 9:17 UTC (permalink / raw)
To: james.steele; +Cc: epx, wjturner, linux-bluetooth
In-Reply-To: <7970713F1B9E4F489FABBDEAE1C93BC001241842F415@EMEXM3131.dir.svc.accenture.com>
Hello Elvis, James
2011/3/22 <james.steele@accenture.com>
>
> Hi,
>
> >> I've gotten the device to correctly connect and exchange data if I
> >> modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM
> >> instead, so the MITM protection isn't required. I'm not sure if I'm
> >> doing something else wrong and BT_IO_SEC_HIGH should work, or if there
> >> is indeed a problem in the BlueZ code (and if so what the correct
> >> solution is).
> >>
> >> Does anyone else have the unmodified BlueZ code working correctly with
> >> health devices?
>
> > Another known workaround is to disable SSP mode with hciconfig
> > (hciconfig hciX sspmode 0).
>
> > There has been discussion whether BlueZ HDP is correct or not in this
> > respect. The HDP specification says that devices SHOULD require authenticated
> > and encrypted connections (which maps to SEC_HIGH) while some devices are
> > known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD',
> > not 'SHALL'.
>
> An "authenticated" connection has a slightly ambiguous meaning in
> Bluetooth since 2.1+EDR, since you can have an authenticated link that
> does not have any MITM protection.
>
> I think the correct behavior is that HDP should be using "Level 2"
> (from GAP in the Core specification), where HDP wants the strongest
> level of security it can achieve with a device, but it does not want to
> exclude devices that do not have the capability to support input/output.
>
> There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ
> and Security Level 2 in GAP. I believe that the intention of Level 2
> is to propose that MITM protection is needed - however it will happily
> accept security where no MITM protection has been achieved (this being
> the difference between Level 2 and Level 3). BlueZ however does not
> seem to propose MITM protection for SEC_MEDIUM - which would be important
> for HDP (at least in the BlueZ <-> BlueZ case).
>
I remember that issue with we were developing HDP and MCAP. We set
SEC_HIGH in HDP to get encrypted channels and to pass Bluetooth PTS.
The problem doing that is related with devices that don't support MITM
protection (In fact if they don't have any
user input capabilities). This may be a good opportunity to go back
about this issue. What do you think?
In any case, such as Elvis has said, you can disable sspmode to get
HDP working without modify BlueZ code.
Regards
Santiago
^ permalink raw reply
* Bluetooth git tree
From: Bing Zhao @ 2011-03-23 0:10 UTC (permalink / raw)
To: Gustavo F. Padovan; +Cc: Marcel Holtmann, linux-bluetooth@vger.kernel.org
Hi Gustavo,
I'm planning to add SD8787 support to 'btmrvl' driver.
Should I get started from the git tree below?
git://git.kernel.org/pub/scm/linux/kernel/git/padovan/bluetooth-next-2.6.gi=
t
Thanks,
Bing
^ permalink raw reply
* Re: [PATCH] Remove unused fields in btd_driver_data struct
From: Claudio Takahasi @ 2011-03-22 21:36 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth; +Cc: Johan Hedberg
In-Reply-To: <20110322211036.GA7180@jh-x301>
Hi Johan,
On Tue, Mar 22, 2011 at 9:10 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Tue, Mar 22, 2011, Claudio Takahasi wrote:
>> ---
>> src/device.c | 2 --
>> 1 files changed, 0 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/device.c b/src/device.c
>> index e9d9e65..5121064 100644
>> --- a/src/device.c
>> +++ b/src/device.c
>> @@ -68,9 +68,7 @@
>> #define GLOBAL_TRUST "[all]"
>>
>> struct btd_driver_data {
>> - guint id;
>> struct btd_device_driver *driver;
>> - void *priv;
>> };
>
> Why is btd_driver_data needed at all if btd_device_driver is the only
> thing that it contains (i.e. why can't places pointing to
> btd_driver_data just point to btd_device_driver directly)?
>
> Johan
>
I did a quick look in the code, we can point directly to the
btd_device_driver and remove the btd_driver_data struct.
This structure was added by the commit b76fbc7d in 2008, I don't think
that there is a plan to use it :-)
"*priv" was never used and "guint id;" seems to be added by mistake.
Please ignore this patch, I will send another patch removing
btd_driver_data struct.
Claudio.
^ permalink raw reply
* Re: [PATCH] Remove unused fields in btd_driver_data struct
From: Johan Hedberg @ 2011-03-22 21:10 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1300827396-8043-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Tue, Mar 22, 2011, Claudio Takahasi wrote:
> ---
> src/device.c | 2 --
> 1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/src/device.c b/src/device.c
> index e9d9e65..5121064 100644
> --- a/src/device.c
> +++ b/src/device.c
> @@ -68,9 +68,7 @@
> #define GLOBAL_TRUST "[all]"
>
> struct btd_driver_data {
> - guint id;
> struct btd_device_driver *driver;
> - void *priv;
> };
Why is btd_driver_data needed at all if btd_device_driver is the only
thing that it contains (i.e. why can't places pointing to
btd_driver_data just point to btd_device_driver directly)?
Johan
^ permalink raw reply
* [PATCH] Remove unused fields in btd_driver_data struct
From: Claudio Takahasi @ 2011-03-22 20:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
src/device.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/src/device.c b/src/device.c
index e9d9e65..5121064 100644
--- a/src/device.c
+++ b/src/device.c
@@ -68,9 +68,7 @@
#define GLOBAL_TRUST "[all]"
struct btd_driver_data {
- guint id;
struct btd_device_driver *driver;
- void *priv;
};
struct btd_disconnect_data {
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Fix ATT error code response for authentication
From: Claudio Takahasi @ 2011-03-22 20:51 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
This patch fix the error code in the Error Response PDU. If an attribute
requires authentication and the link security level doesn't meet the
requirements the server should reply Insufficient Authentication(0x05).
---
src/attrib-server.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/src/attrib-server.c b/src/attrib-server.c
index 74a1c8d..9543da6 100644
--- a/src/attrib-server.c
+++ b/src/attrib-server.c
@@ -167,11 +167,12 @@ static uint8_t att_check_reqs(struct gatt_channel *channel, uint8_t opcode,
{
/* FIXME: currently, it is assumed an encrypted link is enough for
* authentication. This will allow to enable the SMP negotiation once
- * it is on upstream kernel. */
+ * it is on upstream kernel. High security level should be mapped
+ * to authentication and medium to encryption permission. */
if (!channel->encrypted)
channel->encrypted = g_attrib_is_encrypted(channel->attrib);
if (reqs == ATT_AUTHENTICATION && !channel->encrypted)
- return ATT_ECODE_INSUFF_ENC;
+ return ATT_ECODE_INSUFF_AUTHEN;
switch (opcode) {
case ATT_OP_READ_BY_GROUP_REQ:
--
1.7.4.1
^ permalink raw reply related
* android: bluetoothd hung after bluetooth had been turned off
From: Vitaly Wool @ 2011-03-22 19:11 UTC (permalink / raw)
To: linux-bluetooth
Greetings,
I'd got a nasty hang in my Android phone when I turned bluetooth off
from the UI while the music was playing over bluetooth connection.
After some investigation I concluded that bluetoothd was stuck. It was
not able to perform the a2dp_cleanup() and bluetooth_close().
bluetoothd call stack analysis showed that poll function was called
with an infinite timeout argument (-1).
The timeout is initialized in g_main_context_prepare() to -1. As far
as I understand, it may then be set either to the timeout value
provided by source->source_funcs->prepare(), or to 0 if there is data
pending. But as long as all the channels are g_io_unix, the timeout
will remain set to -1 if there's no data ATM.
I guess if the interface is taken down, it is expected that poll
function quits with POLLERR set in revents but that hasn't happened.
Isn't it reasonable to still have a timeout for poll to avoid such
situations?
The Android version is Gingerbread so BlueZ is 4.69.
Any help would be greatly appreciated.
Thanks,
Vitaly
^ permalink raw reply
* Re: BlueZ health device interface, problems with link security level?
From: james.steele @ 2011-03-22 18:46 UTC (permalink / raw)
To: epx, wjturner; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikTJsY3-WY12hD0yTbU3u7ovW3C1CHic2WReoZq@mail.gmail.com>
Hi,
>> I've gotten the device to correctly connect and exchange data if I
>> modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM
>> instead, so the MITM protection isn't required. I'm not sure if I'm
>> doing something else wrong and BT_IO_SEC_HIGH should work, or if there
>> is indeed a problem in the BlueZ code (and if so what the correct
>> solution is).
>>
>> Does anyone else have the unmodified BlueZ code working correctly with
>> health devices?
> Another known workaround is to disable SSP mode with hciconfig
> (hciconfig hciX sspmode 0).
> There has been discussion whether BlueZ HDP is correct or not in this
> respect. The HDP specification says that devices SHOULD require authenticated
> and encrypted connections (which maps to SEC_HIGH) while some devices are
> known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD',
> not 'SHALL'.
An "authenticated" connection has a slightly ambiguous meaning in
Bluetooth since 2.1+EDR, since you can have an authenticated link that
does not have any MITM protection.
I think the correct behavior is that HDP should be using "Level 2"
(from GAP in the Core specification), where HDP wants the strongest
level of security it can achieve with a device, but it does not want to
exclude devices that do not have the capability to support input/output.
There does seem to be a slight discrepancy between SEC_MEDIUM in BlueZ
and Security Level 2 in GAP. I believe that the intention of Level 2
is to propose that MITM protection is needed - however it will happily
accept security where no MITM protection has been achieved (this being
the difference between Level 2 and Level 3). BlueZ however does not
seem to propose MITM protection for SEC_MEDIUM - which would be important
for HDP (at least in the BlueZ <-> BlueZ case).
James Steele
Software Engineer
Accenture
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited.
^ permalink raw reply
* Re: accessing Link key within the Bluetooth module
From: Gustavo F. Padovan @ 2011-03-22 17:16 UTC (permalink / raw)
To: Suraj Sumangala; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <4D8825C7.1000904@Atheros.com>
Hi Suraj,
* Suraj Sumangala <suraj@Atheros.com> [2011-03-22 09:59:59 +0530]:
> Hi Johan,
>
> On 3/21/2011 7:18 PM, Johan Hedberg wrote:
> > Hi Suraj,
> >
> > That list only gets populated if you've enabled the management interface
> > (enable_mgmt=1 module option) and have a matching user space version
> > with management interface support.
>
> Thanks,
> The link key is required for creating an AMP connection.
>
> Does it make sense to depend the AMP module on the "enable_mgmt" feature?
Yes, but does not use enable_mgmt in your code.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* Re: BlueZ health device interface, problems with link security level?
From: Elvis Pfützenreuter @ 2011-03-22 16:47 UTC (permalink / raw)
To: Bill Turner; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimxiLzu=3Cx_LqmVo3+HCcBJ_JzWuYLXJ_kKhEz@mail.gmail.com>
Hi,
On 22 Mar 2011, at 13:37 , Bill Turner wrote:
> I've run into a problem trying to use the BlueZ health device plugin
> (BlueZ 4.89), related to the Bluetooth link security level requested
> and the device capabilities. I'm connecting to an Omron BP792IT blood
> pressure monitor and have it correctly paired with my system.
>
> The problem I have is when the MCAP instance is created
> (mcap_create_instance, in health/hdp.c), it uses BT_IO_SEC_HIGH, which
> sets the link authentication requirement to 5 (MITM protection
> required, general bonding). Since the BP monitor doesn't have any
> user input capabilities (IO capabilities returns 3, NoInputNoOutput),
> the request to change the link authentication level fails, and the
> connection is refused.
>
> I've gotten the device to correctly connect and exchange data if I
> modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM
> instead, so the MITM protection isn't required. I'm not sure if I'm
> doing something else wrong and BT_IO_SEC_HIGH should work, or if there
> is indeed a problem in the BlueZ code (and if so what the correct
> solution is).
>
> Does anyone else have the unmodified BlueZ code working correctly with
> health devices?
Another known workaround is to disable SSP mode with hciconfig
(hciconfig hciX sspmode 0).
There has been discussion whether BlueZ HDP is correct or not in this
respect. The HDP specification says that devices SHOULD require authenticated
and encrypted connections (which maps to SEC_HIGH) while some devices are
known not to use authentication (SEC_MEDIUM). But the word in spec is 'SHOULD',
not 'SHALL'.
^ permalink raw reply
* BlueZ health device interface, problems with link security level?
From: Bill Turner @ 2011-03-22 16:37 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=Kohr02dZOFS4HJknp=keMTCN47jYFOdJBN7Ze@mail.gmail.com>
I've run into a problem trying to use the BlueZ health device plugin
(BlueZ 4.89), related to the Bluetooth link security level requested
and the device capabilities. I'm connecting to an Omron BP792IT blood
pressure monitor and have it correctly paired with my system.
The problem I have is when the MCAP instance is created
(mcap_create_instance, in health/hdp.c), it uses BT_IO_SEC_HIGH, which
sets the link authentication requirement to 5 (MITM protection
required, general bonding). Since the BP monitor doesn't have any
user input capabilities (IO capabilities returns 3, NoInputNoOutput),
the request to change the link authentication level fails, and the
connection is refused.
I've gotten the device to correctly connect and exchange data if I
modify the call to mcap_create_instance to use BT_IO_SEC_MEDIUM
instead, so the MITM protection isn't required. I'm not sure if I'm
doing something else wrong and BT_IO_SEC_HIGH should work, or if there
is indeed a problem in the BlueZ code (and if so what the correct
solution is).
Does anyone else have the unmodified BlueZ code working correctly with
health devices?
--
Bill Turner
Senior Software Engineer
Visionary Mobile Corp.
--
Bill Turner
Senior Software Engineer
Visionary Mobile Corp.
^ permalink raw reply
* Re: [PATCH] rfcomm/core.c avoid dangling pointer, check session
From: John W. Linville @ 2011-03-22 14:14 UTC (permalink / raw)
To: David Fries; +Cc: linux-bluetooth, linux-kernel
In-Reply-To: <20110322023810.GG22204@spacedout.fries.net>
On Mon, Mar 21, 2011 at 09:38:10PM -0500, David Fries wrote:
> rfcomm_process_sessions is calling rfcomm_process_rx, but
> in this case the session is closed and freed leaving a
> dangling pointer that blows up when rfcomm_process_rx returns
> and rfcomm_process_dlcs is called with the now dangling session
> pointer.
Please trim this commit log substantially before the patch is merged...
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* [PATCH v3] Add release all sessions when adapter is switched off
From: Dmitriy Paliy @ 2011-03-22 12:29 UTC (permalink / raw)
To: linux-bluetooth, johan.hedberg; +Cc: Dmitriy Paliy
In-Reply-To: <1300796947-1518-1-git-send-email-dmitriy.paliy@nokia.com>
All sessions should be released when adapter is switched off. Then a new
RequestSession method call always results in change from power off to power
on such ensuring operational mode. Otherwise, it is possible to end up in
adapter state being powered off after RequestSession succeded.
g_slist_free is not called after g_slist_foreach because the list is updated
using g_slist_remove inside of session_free, which is called for each element
by g_slist_foreach.
---
src/adapter.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index cc4f43e..691b963 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -2507,6 +2507,15 @@ static void set_mode_complete(struct btd_adapter *adapter)
DBG("");
+ /*
+ * g_slist_free is not called after g_slist_foreach because the list is
+ * updated using g_slist_remove in session_remove which is called by
+ * session_free, which is called for each element by g_slist_foreach.
+ */
+ if (adapter->mode == MODE_OFF)
+ g_slist_foreach(adapter->mode_sessions, (GFunc) session_free,
+ NULL);
+
if (adapter->pending_mode == NULL)
return;
--
1.7.1
^ permalink raw reply related
* [PATCH 0/1 v3] Add release all sessions when adapter is switched off
From: Dmitriy Paliy @ 2011-03-22 12:29 UTC (permalink / raw)
To: linux-bluetooth, johan.hedberg
Hi,
This proposal includes also comment in the code on why g_slist_free is not
used after g_slist_foreach.
Br,
Dmitriy
^ permalink raw reply
* [PATCH] Fix strict aliasing issue
From: Rafal Michalski @ 2011-03-22 12:19 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Rafal Michalski
This patch adjust type of some variables to type used by the kernel.
It avoids some unexpected performance which may occur after violating
strict aliasing rule.
---
lib/hci.h | 4 ++--
lib/hci_lib.h | 6 +++---
tools/hcisecfilter.c | 20 ++++++++++----------
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/lib/hci.h b/lib/hci.h
index d2d4f77..a8e6c12 100644
--- a/lib/hci.h
+++ b/lib/hci.h
@@ -2268,8 +2268,8 @@ struct sockaddr_hci {
#define HCI_CHANNEL_CONTROL 1
struct hci_filter {
- uint32_t type_mask;
- uint32_t event_mask[2];
+ unsigned long type_mask;
+ unsigned long event_mask[2];
uint16_t opcode;
};
diff --git a/lib/hci_lib.h b/lib/hci_lib.h
index 725eb05..c0c43c2 100644
--- a/lib/hci_lib.h
+++ b/lib/hci_lib.h
@@ -163,17 +163,17 @@ char *lmp_featurestostr(uint8_t *features, char *pref, int width);
static inline void hci_set_bit(int nr, void *addr)
{
- *((uint32_t *) addr + (nr >> 5)) |= (1 << (nr & 31));
+ *((unsigned long *) addr + (nr >> 5)) |= (1 << (nr & 31));
}
static inline void hci_clear_bit(int nr, void *addr)
{
- *((uint32_t *) addr + (nr >> 5)) &= ~(1 << (nr & 31));
+ *((unsigned long *) addr + (nr >> 5)) &= ~(1 << (nr & 31));
}
static inline int hci_test_bit(int nr, void *addr)
{
- return *((uint32_t *) addr + (nr >> 5)) & (1 << (nr & 31));
+ return *((unsigned long *) addr + (nr >> 5)) & (1 << (nr & 31));
}
/* HCI filter tools */
diff --git a/tools/hcisecfilter.c b/tools/hcisecfilter.c
index 9ad4ce0..4512baa 100644
--- a/tools/hcisecfilter.c
+++ b/tools/hcisecfilter.c
@@ -35,15 +35,15 @@
int main(void)
{
- uint32_t type_mask;
- uint32_t event_mask[2];
- uint32_t ocf_mask[4];
+ unsigned long type_mask;
+ unsigned long event_mask[2];
+ unsigned long ocf_mask[4];
/* Packet types */
memset(&type_mask, 0, sizeof(type_mask));
hci_set_bit(HCI_EVENT_PKT, &type_mask);
- printf("Type mask: { 0x%02x }\n", type_mask);
+ printf("Type mask: { 0x%02lx }\n", type_mask);
/* Events */
memset(event_mask, 0, sizeof(event_mask));
@@ -66,7 +66,7 @@ int main(void)
hci_set_bit(EVT_SYNC_CONN_CHANGED, event_mask);
hci_set_bit(EVT_EXTENDED_INQUIRY_RESULT, event_mask);
- printf("Event mask: { 0x%08x, 0x%08x }\n",
+ printf("Event mask: { 0x%08lx, 0x%08lx }\n",
event_mask[0], event_mask[1]);
/* OGF_LINK_CTL */
@@ -81,7 +81,7 @@ int main(void)
hci_set_bit(OCF_READ_CLOCK_OFFSET, ocf_mask);
hci_set_bit(OCF_READ_LMP_HANDLE, ocf_mask);
- printf("OGF_LINK_CTL: { 0x%08x, 0x%08x, 0x%08x, 0x%02x }\n",
+ printf("OGF_LINK_CTL: { 0x%08lx, 0x%08lx, 0x%08lx, 0x%02lx }\n",
ocf_mask[0], ocf_mask[1], ocf_mask[2], ocf_mask[3]);
/* OGF_LINK_POLICY */
@@ -90,7 +90,7 @@ int main(void)
hci_set_bit(OCF_READ_LINK_POLICY, ocf_mask);
hci_set_bit(OCF_READ_DEFAULT_LINK_POLICY, ocf_mask);
- printf("OGF_LINK_POLICY: { 0x%08x, 0x%08x, 0x%08x, 0x%02x }\n",
+ printf("OGF_LINK_POLICY: { 0x%08lx, 0x%08lx, 0x%08lx, 0x%02lx }\n",
ocf_mask[0], ocf_mask[1], ocf_mask[2], ocf_mask[3]);
/* OGF_HOST_CTL */
@@ -124,7 +124,7 @@ int main(void)
hci_set_bit(OCF_READ_INQ_RESPONSE_TX_POWER_LEVEL, ocf_mask);
hci_set_bit(OCF_READ_DEFAULT_ERROR_DATA_REPORTING, ocf_mask);
- printf("OGF_HOST_CTL: { 0x%08x, 0x%08x, 0x%08x, 0x%02x }\n",
+ printf("OGF_HOST_CTL: { 0x%08lx, 0x%08lx, 0x%08lx, 0x%02lx }\n",
ocf_mask[0], ocf_mask[1], ocf_mask[2], ocf_mask[3]);
/* OGF_INFO_PARAM */
@@ -137,7 +137,7 @@ int main(void)
hci_set_bit(OCF_READ_COUNTRY_CODE, ocf_mask);
hci_set_bit(OCF_READ_BD_ADDR, ocf_mask);
- printf("OGF_INFO_PARAM: { 0x%08x, 0x%08x, 0x%08x, 0x%02x }\n",
+ printf("OGF_INFO_PARAM: { 0x%08lx, 0x%08lx, 0x%08lx, 0x%02lx }\n",
ocf_mask[0], ocf_mask[1], ocf_mask[2], ocf_mask[3]);
/* OGF_STATUS_PARAM */
@@ -148,7 +148,7 @@ int main(void)
hci_set_bit(OCF_READ_AFH_MAP, ocf_mask);
hci_set_bit(OCF_READ_CLOCK, ocf_mask);
- printf("OGF_STATUS_PARAM: { 0x%08x, 0x%08x, 0x%08x, 0x%02x }\n",
+ printf("OGF_STATUS_PARAM: { 0x%08lx, 0x%08lx, 0x%08lx, 0x%02lx }\n",
ocf_mask[0], ocf_mask[1], ocf_mask[2], ocf_mask[3]);
return 0;
--
1.6.3.3
^ permalink raw reply related
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