* Re: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Johan Hedberg @ 2010-09-02 13:51 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <99B09243E1A5DA4898CDD8B7001114480979219655@EXMB04.eu.tieto.com>
Hi Waldek,
On Thu, Sep 02, 2010, Waldemar.Rymarkiewicz@tieto.com wrote:
> I've completed more tests on the patches and didn't faced any problems
> do far. Legacy paring, ssp, sec mode 3, refresh existing keys and
> security upgrading have finished with success. I did the tests for
> bluez as initiator and again when bluez was an acceptor. All tests
> were done against different controllers CSR (1.1, 2.0, 2.1), Broadcom
> (2.0, 2.1), ST-Ericsson (2.1). I also tried different combinations of
> the controllers in the same use case.
>
> So, I'm pretty sure that it will not introduce any regression.
Ok, that's good to hear.
> Aditionally, we plan to bring this to the UPF and it would be
> appreciated if also other would have that possibility for regression
> testing.
I'll be at the UPF too, so this might be possible.
> If it comes to interaction with the agent I would do this in a
> seperate patch which will contain a new property when 16 digit pin
> code is required.
That's fine.
> I attached slightly updated patches.
Thanks. However, the kernel patch and new ioctl will need comments at
least from Marcel. Once we add an ioctl we're stuck with it for quite
some time and have to maintain it, no matter what kind of newer/better
kernel-userspace interfaces we come up with. So the choice of accepting
a new ioctl isn't so easy.
One thing that you'd definitely need to fix in your patches is to keep
at least the same level of support that the current BlueZ has with
kernels that don't have the new ioctl. Right now your patch would make
legacy pairing fail in such cases which is not acceptable. Only with a
major version change (5.x) would it be possible to consider requiring a
newer kernel version in order to have essential functionality in place.
With all this in mind I'd still prefer it if we postpone the feature
addition until the point where we have a more flexible kernel-userspace
API in place and most of the security logic and information on the
kernel side.
Johan
^ permalink raw reply
* [PATCH] Make sure discovery don't interfere with bonding
From: Luiz Augusto von Dentz @ 2010-09-02 14:04 UTC (permalink / raw)
To: linux-bluetooth
From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
In situation where the user application keep a discovery session while
bonding with a device it may cause a delay, or even timeout, due to the
number of the inquiry responses that the controller has to process.
Since the discovery can be shared between many applications it may not be
possible to simple require to each application to stop their discovery
before trying to pair with a device, so to fix this bluetoothd now
suspends the discovery while bonding, resuming when completed.
---
src/adapter.c | 62 +++++++++++++++++++++++++++++++++++++++++++++-----------
src/adapter.h | 3 ++
src/device.c | 4 +++
3 files changed, 57 insertions(+), 12 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 173dfbe..25b0671 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -107,7 +107,7 @@ struct btd_adapter {
uint8_t global_mode; /* last valid global mode */
struct session_req *pending_mode;
int state; /* standard inq, periodic inq, name
- * resloving */
+ * resolving, suspended discovery */
GSList *found_devices;
GSList *oor_devices; /* out of range device list */
struct agent *agent; /* For the new API */
@@ -685,6 +685,27 @@ static uint8_t get_needed_mode(struct btd_adapter *adapter, uint8_t mode)
return mode;
}
+static void adapter_stop_inquiry(struct btd_adapter *adapter)
+{
+ pending_remote_name_cancel(adapter);
+
+ /* Clear out of range device list */
+ if (adapter->oor_devices) {
+ g_slist_free(adapter->oor_devices);
+ adapter->oor_devices = NULL;
+ }
+
+ /* Reset if suspended, otherwise remove timer (software scheduler)
+ or request inquiry to stop */
+ if (adapter->state & SUSPENDED_INQUIRY)
+ adapter->state &= ~SUSPENDED_INQUIRY;
+ else if (adapter->scheduler_id) {
+ g_source_remove(adapter->scheduler_id);
+ adapter->scheduler_id = 0;
+ } else
+ adapter_ops->stop_discovery(adapter->dev_id);
+}
+
static void session_remove(struct session_req *req)
{
struct btd_adapter *adapter = req->adapter;
@@ -719,19 +740,9 @@ static void session_remove(struct session_req *req)
DBG("Stopping discovery");
- pending_remote_name_cancel(adapter);
-
clear_found_devices_list(adapter);
- g_slist_free(adapter->oor_devices);
- adapter->oor_devices = NULL;
-
- if (adapter->scheduler_id) {
- g_source_remove(adapter->scheduler_id);
- adapter->scheduler_id = 0;
- }
-
- adapter_ops->stop_discovery(adapter->dev_id);
+ adapter_stop_inquiry(adapter);
}
}
@@ -1219,6 +1230,10 @@ static int adapter_start_inquiry(struct btd_adapter *adapter)
{
gboolean periodic = TRUE;
+ /* Do not start if suspended */
+ if (adapter->state & SUSPENDED_INQUIRY)
+ return 0;
+
if (main_opts.discov_interval)
periodic = FALSE;
@@ -3165,6 +3180,29 @@ gboolean adapter_has_discov_sessions(struct btd_adapter *adapter)
return TRUE;
}
+void adapter_suspend_discovery(struct btd_adapter *adapter)
+{
+ if (adapter->disc_sessions == NULL ||
+ adapter->state & SUSPENDED_INQUIRY)
+ return;
+
+ DBG("Suspending discovery");
+
+ adapter_stop_inquiry(adapter);
+ adapter->state |= SUSPENDED_INQUIRY;
+}
+
+void adapter_resume_discovery(struct btd_adapter *adapter)
+{
+ if (adapter->disc_sessions == NULL)
+ return;
+
+ DBG("Resuming discovery");
+
+ adapter->state &= ~SUSPENDED_INQUIRY;
+ adapter_start_inquiry(adapter);
+}
+
int btd_register_adapter_driver(struct btd_adapter_driver *driver)
{
GSList *adapters;
diff --git a/src/adapter.h b/src/adapter.h
index 5352731..fb52b34 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -33,6 +33,7 @@
#define DISCOVER_TYPE_NONE 0x00
#define STD_INQUIRY 0x01
#define PERIODIC_INQUIRY 0x02
+#define SUSPENDED_INQUIRY 0x04
/* Actions executed after inquiry complete */
#define RESOLVE_NAME 0x10
@@ -133,6 +134,8 @@ void adapter_add_connection(struct btd_adapter *adapter,
void adapter_remove_connection(struct btd_adapter *adapter,
struct btd_device *device, uint16_t handle);
gboolean adapter_has_discov_sessions(struct btd_adapter *adapter);
+void adapter_suspend_discovery(struct btd_adapter *adapter);
+void adapter_resume_discovery(struct btd_adapter *adapter);
struct btd_adapter *btd_adapter_ref(struct btd_adapter *adapter);
void btd_adapter_unref(struct btd_adapter *adapter);
diff --git a/src/device.c b/src/device.c
index 1129e85..9055eca 100644
--- a/src/device.c
+++ b/src/device.c
@@ -1813,6 +1813,8 @@ static void bonding_request_free(struct bonding_req *bonding)
device->bonding = NULL;
+ adapter_resume_discovery(device->adapter);
+
if (!device->agent)
return;
@@ -1879,6 +1881,8 @@ proceed:
bonding->conn = dbus_connection_ref(conn);
bonding->msg = dbus_message_ref(msg);
+ adapter_suspend_discovery(device->adapter);
+
return bonding;
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH] Make sure discovery don't interfere with bonding
From: Johan Hedberg @ 2010-09-02 14:43 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1283436253-9850-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Thu, Sep 02, 2010, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> In situation where the user application keep a discovery session while
> bonding with a device it may cause a delay, or even timeout, due to the
> number of the inquiry responses that the controller has to process.
>
> Since the discovery can be shared between many applications it may not be
> possible to simple require to each application to stop their discovery
> before trying to pair with a device, so to fix this bluetoothd now
> suspends the discovery while bonding, resuming when completed.
> ---
> src/adapter.c | 62 +++++++++++++++++++++++++++++++++++++++++++++-----------
> src/adapter.h | 3 ++
> src/device.c | 4 +++
> 3 files changed, 57 insertions(+), 12 deletions(-)
Thanks. The patch has been pushed upstream.
Johan
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Jiri Kosina @ 2010-09-02 15:25 UTC (permalink / raw)
To: Alan Ott, Marcel Holtmann
Cc: Stefan Achatz, Antonio Ospite, Alexey Dobriyan, Tejun Heo,
Alan Stern, Greg Kroah-Hartman, Stephane Chatty, Michael Poole,
David S. Miller, Bastien Nocera, Eric Dumazet, linux-input,
linux-kernel, linux-usb, linux-bluetooth, netdev
In-Reply-To: <alpine.LNX.2.00.1008231459370.1019@pobox.suse.cz>
On Mon, 23 Aug 2010, Jiri Kosina wrote:
> > This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
> >
> > Alan Ott (2):
> > HID: Add Support for Setting and Getting Feature Reports from hidraw
> > Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and
> > HIDIOCSFEATURE
> >
> > drivers/hid/hidraw.c | 105 ++++++++++++++++++++++++++++++++++++--
> > drivers/hid/usbhid/hid-core.c | 37 +++++++++++++-
> > include/linux/hid.h | 3 +
> > include/linux/hidraw.h | 3 +
> > net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++--
> > net/bluetooth/hidp/hidp.h | 8 +++
> > 6 files changed, 260 insertions(+), 10 deletions(-)
>
> Marcel, as per our previous discussion -- what is your word on this? I'd
> be glad taking it once you Ack the bluetooth bits (which, as far as I
> understood from your last mail, don't have strong objections against any
> more).
... Marcel?
I'd really like not to miss 2.6.37 merge window with this.
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* RE: [PATCH] BT_SECURITY_HIGH requires 16 digit pin code
From: Waldemar.Rymarkiewicz @ 2010-09-02 15:30 UTC (permalink / raw)
To: johan.hedberg
Cc: hadess, linux-bluetooth, par-gunnar.p.hjalmdahl, joakim.xj.ceder,
arunkr.singh
In-Reply-To: <20100902135108.GA30759@jh-x301>
Hi Johan,
>From: Johan Hedberg [mailto:johan.hedberg@gmail.com]
>Sent: Thursday, September 02, 2010 3:51 PM
>
>
>Thanks. However, the kernel patch and new ioctl will need
>comments at least from Marcel. Once we add an ioctl we're
>stuck with it for quite some time and have to maintain it, no
>matter what kind of newer/better kernel-userspace interfaces
>we come up with. So the choice of accepting a new ioctl isn't so easy.
Ok. Let's wait for Marcel's comment.
>One thing that you'd definitely need to fix in your patches is
>to keep at least the same level of support that the current
>BlueZ has with kernels that don't have the new ioctl. Right
>now your patch would make legacy pairing fail in such cases
>which is not acceptable. Only with a major version change
>(5.x) would it be possible to consider requiring a newer
>kernel version in order to have essential functionality in place.
Right. Will fix this.
/Waldek
^ permalink raw reply
* [PATCH] Fix Connected status when PS3 BD remote connects
From: Bastien Nocera @ 2010-09-02 15:59 UTC (permalink / raw)
To: BlueZ development
[-- Attachment #1: Type: text/plain, Size: 102 bytes --]
Hey,
This fixes a problem where the BD remote didn't appear as connected even
though it was.
Cheers
[-- Attachment #2: 0001-Fix-Connected-status-when-PS3-BD-remote-connects.patch --]
[-- Type: text/x-patch, Size: 1009 bytes --]
>From 5e636f5633c1af92880a249b50bf60f78a4350bb Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Thu, 2 Sep 2010 16:55:30 +0100
Subject: [PATCH] Fix Connected status when PS3 BD remote connects
The PS3 BD remote isn't connectable from the outside,
so the only way to use it with BlueZ is to make it connect. But
the code to create a new connection was never setting the
connected flags on the fake connection, so the remote wrongly
appeared as disconnected even though it was present.
---
input/device.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/input/device.c b/input/device.c
index 5187f41..0bcbbdb 100644
--- a/input/device.c
+++ b/input/device.c
@@ -640,6 +640,8 @@ static int hidp_add_connection(const struct input_device *idev,
fake->disconnect = fake_hid_disconnect;
fake->priv = fake_hid;
err = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
+ if (err == 0)
+ fake->flags |= FI_FLAG_CONNECTED;
goto cleanup;
}
--
1.7.0.1
^ permalink raw reply related
* Re: [PATCH] Fix Connected status when PS3 BD remote connects
From: Johan Hedberg @ 2010-09-02 16:09 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1283443172.2361.63.camel@localhost.localdomain>
Hi Bastien,
On Thu, Sep 02, 2010, Bastien Nocera wrote:
> This fixes a problem where the BD remote didn't appear as connected even
> though it was.
Thanks! The patch is now in the upstream tree.
Johan
^ permalink raw reply
* [PATCH] Remember fake devices for the daemon's lifetime
From: Bastien Nocera @ 2010-09-02 16:55 UTC (permalink / raw)
To: BlueZ development; +Cc: rufferson
[-- Attachment #1: Type: text/plain, Size: 358 bytes --]
Hello,
Here's a rework of Ruslan's patch. This should make PS3 BD remotes
faster to reconnect, by not having to setup uinput every time.
Next I'll look at implementing idle for that particular remote, as well
as being able to turn it off from the remote itself.
I won't make the keymap or the idle timeout configurable as in the
original patches.
Cheers
[-- Attachment #2: 0001-Remember-fake-devices-for-the-daemon-s-lifetime.patch --]
[-- Type: text/x-patch, Size: 4084 bytes --]
>From 67177f5fc4750960dde9af9ec57f5e50f2770581 Mon Sep 17 00:00:00 2001
From: Bastien Nocera <hadess@hadess.net>
Date: Thu, 2 Sep 2010 17:09:37 +0100
Subject: [PATCH] Remember fake devices for the daemon's lifetime
This would allow faster reconnection of already known devices,
so that no keypresses would be lost when reconnecting.
We only setup uinput the first time around, which will avoid
problems with devices not disappearing when disconnected.
Based on patch by Ruslan N. Marchenko <rufferson@gmail.com>
---
input/device.c | 8 ++++++--
input/device.h | 1 +
input/fakehid.c | 32 +++++++++++++++++++++++++++-----
input/fakehid.h | 3 ++-
4 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/input/device.c b/input/device.c
index 0bcbbdb..b2885c4 100644
--- a/input/device.c
+++ b/input/device.c
@@ -635,12 +635,16 @@ static int hidp_add_connection(const struct input_device *idev,
fake_hid = get_fake_hid(req->vendor, req->product);
if (fake_hid) {
+ err = 0;
fake = g_new0(struct fake_input, 1);
fake->connect = fake_hid_connect;
fake->disconnect = fake_hid_disconnect;
fake->priv = fake_hid;
- err = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
- if (err == 0)
+ fake->idev = idev;
+ fake = fake_hid_connadd(fake, iconn->intr_io, fake_hid);
+ if (fake == NULL)
+ err = -ENOMEM;
+ else
fake->flags |= FI_FLAG_CONNECTED;
goto cleanup;
}
diff --git a/input/device.h b/input/device.h
index 3390a0b..14c0f97 100644
--- a/input/device.h
+++ b/input/device.h
@@ -39,6 +39,7 @@ struct fake_input {
gboolean (*connect) (struct input_conn *iconn, GError **err);
int (*disconnect) (struct input_conn *iconn);
void *priv;
+ const struct input_device *idev;
};
int fake_input_register(DBusConnection *conn, struct btd_device *device,
diff --git a/input/fakehid.c b/input/fakehid.c
index ee1f77a..6346a3e 100644
--- a/input/fakehid.c
+++ b/input/fakehid.c
@@ -348,6 +348,7 @@ static struct fake_hid fake_hid_table[] = {
.disconnect = fake_hid_common_disconnect,
.event = ps3remote_event,
.setup_uinput = ps3remote_setup_uinput,
+ .devices = NULL,
},
{ },
@@ -370,12 +371,33 @@ struct fake_hid *get_fake_hid(uint16_t vendor, uint16_t product)
return NULL;
}
-int fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
+struct fake_input *fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
struct fake_hid *fake_hid)
{
- if (fake_hid->setup_uinput(fake, fake_hid)) {
- error("Error setting up uinput");
- return ENOMEM;
+ GList *l;
+ struct fake_input *old = NULL;
+
+ /* Look for an already setup device */
+ for (l = fake_hid->devices; l != NULL; l = l->next) {
+ old = l->data;
+ if (old->idev == fake->idev) {
+ g_free (fake);
+ fake = old;
+ fake_hid->connect(fake, NULL);
+ break;
+ }
+ old = NULL;
+ }
+
+ /* New device? Add it to the list of known devices,
+ * and create the uinput necessary */
+ if (old == NULL) {
+ if (fake_hid->setup_uinput(fake, fake_hid)) {
+ error("Error setting up uinput");
+ g_free(fake);
+ return NULL;
+ }
+ fake_hid->devices = g_list_append(fake_hid->devices, fake);
}
fake->io = g_io_channel_ref(intr_io);
@@ -383,5 +405,5 @@ int fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
g_io_add_watch(fake->io, G_IO_IN | G_IO_ERR | G_IO_HUP | G_IO_NVAL,
(GIOFunc) fake_hid->event, fake);
- return 0;
+ return fake;
}
diff --git a/input/fakehid.h b/input/fakehid.h
index 33b1e70..3a5d7c4 100644
--- a/input/fakehid.h
+++ b/input/fakehid.h
@@ -31,9 +31,10 @@ struct fake_hid {
int (*disconnect) (struct fake_input *fake_input);
gboolean (*event) (GIOChannel *chan, GIOCondition cond, gpointer data);
int (*setup_uinput) (struct fake_input *fake, struct fake_hid *fake_hid);
+ GList *devices;
};
struct fake_hid *get_fake_hid(uint16_t vendor, uint16_t product);
-int fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
+struct fake_input *fake_hid_connadd(struct fake_input *fake, GIOChannel *intr_io,
struct fake_hid *fake_hid);
--
1.7.0.1
^ permalink raw reply related
* CSP implementation for MCAP
From: Elvis Pfützenreuter @ 2010-09-02 18:58 UTC (permalink / raw)
To: johan.hedberg, linux-bluetooth
This is the repository for the CSP implementation, rebased over the recently accepted MCAP, for your appreciation:
git://gitorious.org/bluez-epx/bluez-epx.git csp
or
http://www.gitorious.org/bluez-epx/bluez-epx/commits/csp
^ permalink raw reply
* Re: [PATCH] Bluetooth: fix MTU L2CAP configuration parameter
From: Gustavo F. Padovan @ 2010-09-02 19:49 UTC (permalink / raw)
To: Emeltchenko Andrei; +Cc: linux-bluetooth
In-Reply-To: <1283343445-9328-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
* Emeltchenko Andrei <Andrei.Emeltchenko.news@gmail.com> [2010-09-01 15:17:25 +0300]:
> From: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
>
> When receiving L2CAP negative configuration response with respect
> to MTU parameter we modify wrong field. MTU here means proposed
> value of MTU that the remote device intends to transmit. So for local
> L2CAP socket it is pi->imtu.
>
> Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@nokia.com>
> ---
> net/bluetooth/l2cap.c | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
Acked-by: Gustavo F. Padovan <padovan@profusion.mobi>
--
Gustavo F. Padovan
ProFUSION embedded systems - http://profusion.mobi
^ permalink raw reply
* Re: [PATCH] Remember fake devices for the daemon's lifetime
From: Johan Hedberg @ 2010-09-02 20:16 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development, rufferson
In-Reply-To: <1283446547.2361.68.camel@localhost.localdomain>
Hi Bastien,
On Thu, Sep 02, 2010, Bastien Nocera wrote:
> Here's a rework of Ruslan's patch. This should make PS3 BD remotes
> faster to reconnect, by not having to setup uinput every time.
Thanks. This one has also been pushed upstream.
Johan
^ permalink raw reply
* Re: CSP implementation for MCAP
From: Johan Hedberg @ 2010-09-02 20:28 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <4A11989E-5448-43B7-887F-217C54977E22@epx.com.br>
Hi Elvis,
On Thu, Sep 02, 2010, Elvis Pfützenreuter wrote:
> This is the repository for the CSP implementation, rebased over the
> recently accepted MCAP, for your appreciation:
>
> git://gitorious.org/bluez-epx/bluez-epx.git csp
A couple of quick comments:
- Several of the commits in the tree have the author as
"epx <epx@xenicall.(none)>". That needs fixing.
- I'm not so happy about all the ifdefs in the code and the way that
they are used. So this may need some rethinking. Probably we could
have the code always compiled in and have a runtime variable to
disable its use.
Johan
^ permalink raw reply
* Re: CSP implementation for MCAP
From: Elvis Pfützenreuter @ 2010-09-02 20:36 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100902202806.GA8391@jh-x301>
On Sep 2, 2010, at 5:28 PM, Johan Hedberg wrote:
> Hi Elvis,
>
> On Thu, Sep 02, 2010, Elvis Pfützenreuter wrote:
>> This is the repository for the CSP implementation, rebased over the
>> recently accepted MCAP, for your appreciation:
>>
>> git://gitorious.org/bluez-epx/bluez-epx.git csp
>
> A couple of quick comments:
>
> - Several of the commits in the tree have the author as
> "epx <epx@xenicall.(none)>". That needs fixing.
Ouch :(
> - I'm not so happy about all the ifdefs in the code and the way that
> they are used. So this may need some rethinking. Probably we could
> have the code always compiled in and have a runtime variable to
> disable its use.
Such variable already exists, and starts turned off. So could I remove the --enable-mcap-csp flag altogether?
> Johan
^ permalink raw reply
* Re: CSP implementation for MCAP
From: Johan Hedberg @ 2010-09-02 20:40 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: linux-bluetooth
In-Reply-To: <FC6865EA-F6F4-459A-9962-7215F8B0509C@signove.com>
Hi Elvis,
On Thu, Sep 02, 2010, Elvis Pfützenreuter wrote:
> > - I'm not so happy about all the ifdefs in the code and the way that
> > they are used. So this may need some rethinking. Probably we could
> > have the code always compiled in and have a runtime variable to
> > disable its use.
>
> Such variable already exists, and starts turned off. So could I remove
> the --enable-mcap-csp flag altogether?
Yes, I think a single --enable-mcap that covers also csp should be
enough.
Johan
^ permalink raw reply
* Re: AVRCP future
From: Sander van Grieken @ 2010-09-02 21:18 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Luiz Augusto von Dentz
In-Reply-To: <AANLkTin8XEU2TQLSWYnP2SBrwXVe3Oj3YqX1nUBcfCn5@mail.gmail.com>
On Thursday 02 September 2010 14:56:10 you wrote:
> On Thu, Sep 2, 2010 at 11:20 AM, Sander van Grieken
> > I was more thinking of exposing a dbus interface that allows a player (or any TG) to
> > register itself as a TG, then acting on signals/sending events/responses.
>
> That could be done, actually this is a similar idea as we are planning
> to have[1] for replacing our audio ipc, but for things like progress
> we would really need to cache it since most device Ive seem keep
> polling this.
> Another possibility is to use MPRIS and PulseAudio
> together, but the spec of MPRIS need some work right now the player
> assume some name with a prefix e.g: org.freedesktop.MPRIS which is not
> that nice, perhaps making MPRIS a separate daemon would make more
> sense.
>
> This means that for freedesktop we have:
>
> BlueZ <-> PulseAudio <-> MPRIS
>
> For the rest:
>
> BlueZ <-> Player/whatever
>
> If that is done in PulseAudio we could probably associate the metadata
> directly with the stream using MPRIS, if it is up to the player then
> we don't care they can set this information directly via some D-Bus
> API that is yet to be defined, which wouldn't require player to
> implement MPRIS spec. Joao Paulo has something already so I guess we
> can start from there[2].
>
> [1] http://gitorious.org/~vudentz/bluez/vudentzs-clone/commits/endpoint
> [2] http://git.profusion.mobi/cgit.cgi/jprvita/bluez/log/?h=avrcp_metadata
Thanks Luiz,
I'm aware of João's work. In fact I've already merged his work into my branch, he exposed
much of the AVRCP controls.
I see the benefit of MPRIS+PulseAudio for AVRCP 1.3, but for 1.4 MPRIS is just too
limited. Also, it's only for audio players [1], while AVRCP also specifies (TV) menu
controls and such, so it exceeds the scope of MPRIS.
Your git looks interesting! Added to remotes :)
grtz,
Sander
[1] http://xmms2.org/wiki/Media_Player_Interfaces#Overview
^ permalink raw reply
* Re: [PATCH 12/22] Add some default values for configuration process
From: Mat Martineau @ 2010-09-02 21:29 UTC (permalink / raw)
To: haijun liu; +Cc: linux-bluetooth
In-Reply-To: <AANLkTikAZBO6dka+yN3tFTZekm9+1nzo3=OZEoxZ1Eab@mail.gmail.com>
On Thu, 26 Aug 2010, haijun liu wrote:
> From 2d21459fa52b754ce0f666ccefc0175bc7f04420 Mon Sep 17 00:00:00 2001
> From: haijun.liu <haijun.liu@atheros.com>
> Date: Sun, 22 Aug 2010 23:57:09 +0800
> Subject: [PATCH 12/22] Add some default values for configuration process.
>
> ---
> include/net/bluetooth/l2cap.h | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index fe411e2..d0ae9f5 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -36,6 +36,11 @@
> #define L2CAP_DEFAULT_MAX_PDU_SIZE 672
> #define L2CAP_DEFAULT_ACK_TO 200
> #define L2CAP_LOCAL_BUSY_TRIES 12
> +#define L2CAP_DEFAULT_MAX_SDU_SIZE 0xFFFF
> +#define L2CAP_DEFAULT_SDU_ARRIVAL_TIME 0xFFFFFFFF
> +#define L2CAP_DEFAULT_FLUSH_TIMEOUT 0xFFFFFFFF
> +#define L2CAP_DEFAULT_ACCESS_LATENCY 0xFFFFFFFF
> +#define L2CAP_DEFAULT_EXT_WINSIZE 1024
This seems like a large window size for a default - why 1024?
>
> #define L2CAP_CONN_TIMEOUT (40000) /* 40 seconds */
> #define L2CAP_CONFIG_TIMEOUT (40000) /* 40 seconds */
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 13/22] Add three new options for l2cap_options which used in setsockopt & getsockopt
From: Mat Martineau @ 2010-09-02 21:41 UTC (permalink / raw)
To: haijun liu; +Cc: linux-bluetooth
In-Reply-To: <AANLkTi=8xVks--xcLXEQ_=sHfP3fY+Wvyctu5K_kMDG-@mail.gmail.com>
On Thu, 26 Aug 2010, haijun liu wrote:
> From 897b281d14ba4cf9a5fbbf5ba65b84c85e688737 Mon Sep 17 00:00:00 2001
> From: haijun.liu <haijun.liu@atheros.com>
> Date: Mon, 23 Aug 2010 00:00:26 +0800
> Subject: [PATCH 13/22] Add three new options for l2cap_options which
> used in setsockopt & getsockopt.
>
> ---
> include/net/bluetooth/l2cap.h | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index d0ae9f5..4f87aec 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -65,6 +65,9 @@ struct l2cap_options {
> __u8 fcs;
> __u8 max_tx;
> __u16 txwin_size;
> + __u8 hschan_req;
> + __u8 guaranteed;
> + __u8 reconfig;
> };
>
> #define L2CAP_CONNINFO 0x02
How are each of these new options used?
Are any of the new options changeable after the socket is connected?
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: CSP implementation for MCAP
From: Elvis Pfützenreuter @ 2010-09-02 21:49 UTC (permalink / raw)
To: Johan Hedberg; +Cc: linux-bluetooth
In-Reply-To: <20100902204022.GA18957@jh-x301>
On Sep 2, 2010, at 5:40 PM, Johan Hedberg wrote:
> Hi Elvis,
>
> On Thu, Sep 02, 2010, Elvis Pfützenreuter wrote:
>>> - I'm not so happy about all the ifdefs in the code and the way that
>>> they are used. So this may need some rethinking. Probably we could
>>> have the code always compiled in and have a runtime variable to
>>> disable its use.
>>
>> Such variable already exists, and starts turned off. So could I remove
>> the --enable-mcap-csp flag altogether?
>
> Yes, I think a single --enable-mcap that covers also csp should be
> enough.
Ok, those first changes have been made and tested. Waiting for the next round.
^ permalink raw reply
* Re: [PATCH 16/22] Store new configuration values in l2cap_pinfo
From: Mat Martineau @ 2010-09-02 23:02 UTC (permalink / raw)
To: haijun liu; +Cc: linux-bluetooth
In-Reply-To: <AANLkTimnW0jk19cDG+r64Q+-HxdH2qdTBirTMB7ikr1W@mail.gmail.com>
On Thu, 26 Aug 2010, haijun liu wrote:
> From d093975dde6d85c824a5aaac943d676100810010 Mon Sep 17 00:00:00 2001
> From: haijun.liu <haijun.liu@atheros.com>
> Date: Mon, 23 Aug 2010 00:09:56 +0800
> Subject: [PATCH 16/22] Store new configuration values in l2cap_pinfo.
>
> ---
> include/net/bluetooth/l2cap.h | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
> index 2d864d4..f2dd65d 100644
> --- a/include/net/bluetooth/l2cap.h
> +++ b/include/net/bluetooth/l2cap.h
> @@ -406,6 +406,15 @@ struct l2cap_pinfo {
> __u16 remote_mps;
> __u16 mps;
>
> + __u8 ext_flowspec_enable;
> + struct ext_flow_spec loc_efs;
> + struct ext_flow_spec rem_efs;
> +
> + __u8 extwin_enable;
> + __u16 extwin_size;
> + __u8 rem_extwin_enable;
> + __u16 rem_extwin_size;
> +
> __le16 sport;
>
> struct timer_list retrans_timer;
Regarding the new "extwin" structure members, have you considered
changing the existing tx_win and remote_tx_win members to __u16 and
using them with both standard and extended window sizes?
The spec also requires that both directions of the link use the same
type of control field (standard or extended). After L2CAP
configuration is done, all the information required for the transmit
window is the control field type, tx_win, and remote_tx_win. The
control field would be set to 'extended' if a successful configuration
response is sent or received for the extended window size option.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 2/5] Bluetooth: Validate PSM values in calls to connect() and bind()
From: Mat Martineau @ 2010-09-02 23:53 UTC (permalink / raw)
To: linux-bluetooth; +Cc: marcel, gustavo, rshaffer
In-Reply-To: <1282689346-20371-3-git-send-email-mathewm@codeaurora.org>
On Tue, 24 Aug 2010, Mat Martineau wrote:
> Valid L2CAP PSMs are odd numbers, and the least significant bit of the
> most significant byte must be 0.
>
> Signed-off-by: Mat Martineau <mathewm@codeaurora.org>
> ---
> net/bluetooth/l2cap.c | 24 ++++++++++++++++++++----
> 1 files changed, 20 insertions(+), 4 deletions(-)
>
> diff --git a/net/bluetooth/l2cap.c b/net/bluetooth/l2cap.c
> index c784703..1f1fa3c 100644
> --- a/net/bluetooth/l2cap.c
> +++ b/net/bluetooth/l2cap.c
> @@ -1008,10 +1008,20 @@ static int l2cap_sock_bind(struct socket *sock, struct sockaddr *addr, int alen)
> goto done;
> }
>
> - if (la.l2_psm && __le16_to_cpu(la.l2_psm) < 0x1001 &&
> - !capable(CAP_NET_BIND_SERVICE)) {
> - err = -EACCES;
> - goto done;
> + if (la.l2_psm) {
> + __u16 psm = __le16_to_cpu(la.l2_psm);
> +
> + /* PSM must be odd and lsb of upper byte must be 0 */
> + if ((psm & 0x0101) != 0x0001) {
> + err = -EINVAL;
> + goto done;
> + }
> +
> + /* Restrict usage of well-known PSMs */
> + if (psm < 0x1001 && !capable(CAP_NET_BIND_SERVICE)) {
> + err = -EACCES;
> + goto done;
> + }
> }
>
> write_lock_bh(&l2cap_sk_list.lock);
> @@ -1190,6 +1200,12 @@ static int l2cap_sock_connect(struct socket *sock, struct sockaddr *addr, int al
> goto done;
> }
>
> + /* PSM must be odd and lsb of upper byte must be 0 */
> + if ((__le16_to_cpu(la.l2_psm) & 0x0101) != 0x0001) {
> + err = -EINVAL;
> + goto done;
> + }
> +
> /* Set destination address and psm */
> bacpy(&bt_sk(sk)->dst, &la.l2_bdaddr);
> l2cap_pi(sk)->psm = la.l2_psm;
This patch should not be merged - PSM 0 needs to be allowed when
connecting to SOCK_RAW sockets, so bonding works right.
--
Mat Martineau
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
^ permalink raw reply
* Re: [PATCH 13/22] Add three new options for l2cap_options which used in setsockopt & getsockopt
From: haijun liu @ 2010-09-03 1:19 UTC (permalink / raw)
To: Mat Martineau, linux-bluetooth
In-Reply-To: <alpine.DEB.2.00.1009021430120.17665@linux-sea-02>
On Fri, Sep 3, 2010 at 5:41 AM, Mat Martineau <mathewm@codeaurora.org> wrote:
>
> On Thu, 26 Aug 2010, haijun liu wrote:
>
>> From 897b281d14ba4cf9a5fbbf5ba65b84c85e688737 Mon Sep 17 00:00:00 2001
>> From: haijun.liu <haijun.liu@atheros.com>
>> Date: Mon, 23 Aug 2010 00:00:26 +0800
>> Subject: [PATCH 13/22] Add three new options for l2cap_options which
>> used in setsockopt & getsockopt.
>>
>> ---
>> include/net/bluetooth/l2cap.h | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
>> index d0ae9f5..4f87aec 100644
>> --- a/include/net/bluetooth/l2cap.h
>> +++ b/include/net/bluetooth/l2cap.h
>> @@ -65,6 +65,9 @@ struct l2cap_options {
>> __u8 fcs;
>> __u8 max_tx;
>> __u16 txwin_size;
>> + __u8 hschan_req;
>> + __u8 guaranteed;
>> + __u8 reconfig;
>> };
>>
>> #define L2CAP_CONNINFO 0x02
>
> How are each of these new options used?
>
> Are any of the new options changeable after the socket is connected?
>
> --
> Mat Martineau
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
>
>
I accept David suggestion, I am waiting your patch merged.
Yes, these are changeable.
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH] Make sure discovery don't interfere with bonding
From: Manuel Naranjo @ 2010-09-03 1:28 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1283436253-9850-1-git-send-email-luiz.dentz@gmail.com>
Luiz,
> In situation where the user application keep a discovery session while
> bonding with a device it may cause a delay, or even timeout, due to the
> number of the inquiry responses that the controller has to process.
>
> Since the discovery can be shared between many applications it may not be
> possible to simple require to each application to stop their discovery
> before trying to pair with a device, so to fix this bluetoothd now
> suspends the discovery while bonding, resuming when completed.
Stupid question but... Any way this is related to my seg faults during
sdp resolving problems? I haven't tried to fix it in a while, so far I'm
ok with a stupid cron rule which revives bluetoothd if it crashes, but I
would prefer a better solution.
Manuel
^ permalink raw reply
* Re: [PATCH 16/22] Store new configuration values in l2cap_pinfo
From: haijun liu @ 2010-09-03 1:30 UTC (permalink / raw)
To: Mat Martineau, linux-bluetooth
In-Reply-To: <alpine.DEB.2.00.1009021441390.17665@linux-sea-02>
On Fri, Sep 3, 2010 at 7:02 AM, Mat Martineau <mathewm@codeaurora.org> wrote:
>
> On Thu, 26 Aug 2010, haijun liu wrote:
>
>> From d093975dde6d85c824a5aaac943d676100810010 Mon Sep 17 00:00:00 2001
>> From: haijun.liu <haijun.liu@atheros.com>
>> Date: Mon, 23 Aug 2010 00:09:56 +0800
>> Subject: [PATCH 16/22] Store new configuration values in l2cap_pinfo.
>>
>> ---
>> include/net/bluetooth/l2cap.h | 9 +++++++++
>> 1 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/net/bluetooth/l2cap.h b/include/net/bluetooth/l2cap.h
>> index 2d864d4..f2dd65d 100644
>> --- a/include/net/bluetooth/l2cap.h
>> +++ b/include/net/bluetooth/l2cap.h
>> @@ -406,6 +406,15 @@ struct l2cap_pinfo {
>> __u16 remote_mps;
>> __u16 mps;
>>
>> + __u8 ext_flowspec_enable;
>> + struct ext_flow_spec loc_efs;
>> + struct ext_flow_spec rem_efs;
>> +
>> + __u8 extwin_enable;
>> + __u16 extwin_size;
>> + __u8 rem_extwin_enable;
>> + __u16 rem_extwin_size;
>> +
>> __le16 sport;
>>
>> struct timer_list retrans_timer;
>
> Regarding the new "extwin" structure members, have you considered changing
> the existing tx_win and remote_tx_win members to __u16 and using them with
> both standard and extended window sizes?
>
> The spec also requires that both directions of the link use the same type of
> control field (standard or extended). After L2CAP configuration is done,
> all the information required for the transmit window is the control field
> type, tx_win, and remote_tx_win. The control field would be set to
> 'extended' if a successful configuration response is sent or received for
> the extended window size option.
>
>
> --
> Mat Martineau
> Employee of Qualcomm Innovation Center, Inc.
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum
>
>
Yes, we do, please look into the patch, we use __u16 for extwin_size &
rem_extwin_size
+ __u8 extwin_enable;
+ __u16 extwin_size;
+ __u8 rem_extwin_enable;
+ __u16 rem_extwin_size;
You are exactly right, in our implementation, choosing standard or
extended window,
it depends whether successful configuration response contain the
extended window size option.
--
Haijun Liu
^ permalink raw reply
* Re: [PATCH] Make sure discovery don't interfere with bonding
From: Luiz Augusto von Dentz @ 2010-09-03 7:18 UTC (permalink / raw)
To: Manuel Naranjo; +Cc: linux-bluetooth
In-Reply-To: <4C804F5B.3010108@aircable.net>
Hi Manuel,
On Fri, Sep 3, 2010 at 4:28 AM, Manuel Naranjo <manuel@aircable.net> wrote:
> Luiz,
>>
>> In situation where the user application keep a discovery session while
>> bonding with a device it may cause a delay, or even timeout, due to the
>> number of the inquiry responses that the controller has to process.
>>
>> Since the discovery can be shared between many applications it may not be
>> possible to simple require to each application to stop their discovery
>> before trying to pair with a device, so to fix this bluetoothd now
>> suspends the discovery while bonding, resuming when completed.
>
> Stupid question but... Any way this is related to my seg faults during sdp
> resolving problems? I haven't tried to fix it in a while, so far I'm ok with
> a stupid cron rule which revives bluetoothd if it crashes, but I would
> prefer a better solution.
I don't think it fixes your problem, but you better check if
bluetoothd is still crashing as before, apparently nobody else is
having the same problem so it is quite tricky to resolve it.
Regards,
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [PATCH] Store new local name before writing it to HCI
From: Daniel Örstadius @ 2010-09-03 7:37 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <AANLkTi=KFGw_HQjUAb=s1Vf+tSW0BuFQWNwHrWBO7Wdq@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 247 bytes --]
On Mon, Aug 30, 2010 at 5:35 PM, Daniel Örstadius
<daniel.orstadius@gmail.com> wrote:
> Store new local name to the filesystem and emit property changed
> before actually writing the name to the chip.
Resending with amended commit message.
[-- Attachment #2: 0001-Store-new-local-name-before-writing-it-to-adapter.patch --]
[-- Type: text/x-patch, Size: 3247 bytes --]
From a10b5170f3ba69d880a8a9cd8737d0545e95b04b Mon Sep 17 00:00:00 2001
From: Daniel Orstadius <daniel.orstadius@nokia.com>
Date: Mon, 30 Aug 2010 16:54:09 +0300
Subject: [PATCH] Store new local name before writing it to adapter
Store new local name to the file system and emit property changed
before actually writing the name to the adapter.
The reason for the patch is the scenario were an application sets
the name and then immediately turns off the adapter. Previously the
requested name change might not have been properly applied in that
case. The new name was not written to storage until it had been
read from the adapter and the adapter could have been turned off
before the read command was completed.
Avoids writing the name twice by using a boolean variable in the
btd_adapter struct. The name may be changed by using for example
hciconfig and in that case the name needs to be updated to storage
after reading.
---
src/adapter.c | 35 ++++++++++++++++++++++-------------
1 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 377bacc..0dbb295 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -137,6 +137,8 @@ struct btd_adapter {
gint ref;
GSList *powered_callbacks;
+
+ gboolean name_stored;
};
static void adapter_set_pairable_timeout(struct btd_adapter *adapter,
@@ -950,17 +952,21 @@ void adapter_update_local_name(bdaddr_t *bdaddr, uint8_t status, void *ptr)
strncpy((char *) dev->name, (char *) rp.name, MAX_NAME_LENGTH);
- write_local_name(bdaddr, (char *) dev->name);
+ if (!adapter->name_stored) {
+ write_local_name(bdaddr, (char *) dev->name);
- update_ext_inquiry_response(adapter);
+ name = g_strdup((char *) dev->name);
- name = g_strdup((char *) dev->name);
+ if (connection)
+ emit_property_changed(connection, adapter->path,
+ ADAPTER_INTERFACE, "Name",
+ DBUS_TYPE_STRING, &name);
+ g_free(name);
+ }
- if (connection)
- emit_property_changed(connection, adapter->path,
- ADAPTER_INTERFACE, "Name",
- DBUS_TYPE_STRING, &name);
- g_free(name);
+ adapter->name_stored = FALSE;
+
+ update_ext_inquiry_response(adapter);
}
void adapter_setname_complete(bdaddr_t *local, uint8_t status)
@@ -998,16 +1004,18 @@ static DBusMessage *set_name(DBusConnection *conn, DBusMessage *msg,
if (strncmp(name, (char *) dev->name, MAX_NAME_LENGTH) == 0)
goto done;
- if (!adapter->up) {
- strncpy((char *) adapter->dev.name, name, MAX_NAME_LENGTH);
- write_local_name(&adapter->bdaddr, name);
- emit_property_changed(connection, adapter->path,
+ strncpy((char *) adapter->dev.name, name, MAX_NAME_LENGTH);
+ write_local_name(&adapter->bdaddr, name);
+ emit_property_changed(connection, adapter->path,
ADAPTER_INTERFACE, "Name",
DBUS_TYPE_STRING, &name);
- } else {
+
+ if (adapter->up) {
int err = adapter_ops->set_name(adapter->dev_id, name);
if (err < 0)
return failed_strerror(msg, err);
+
+ adapter->name_stored = TRUE;
}
done:
@@ -2504,6 +2512,7 @@ int adapter_stop(struct btd_adapter *adapter)
adapter->cache_enable = TRUE;
adapter->pending_cod = 0;
adapter->off_requested = FALSE;
+ adapter->name_stored = FALSE;
call_adapter_powered_callbacks(adapter, FALSE);
--
1.6.0.4
^ 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