* [PATCH 5/5] emulator/bthost: Check length of received RFCOMM UIH frames
From: Marcin Kraglak @ 2014-02-11 10:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392115862-19752-1-git-send-email-marcin.kraglak@tieto.com>
Add correct calculation of frame length. If frame is too short, ignore it.
---
emulator/bthost.c | 38 ++++++++++++++++++++++++++++++--------
1 file changed, 30 insertions(+), 8 deletions(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index ab90f4c..8447817 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -1760,17 +1760,30 @@ static void rfcomm_mcc_recv(struct bthost *bthost, struct btconn *conn,
struct l2conn *l2conn, const void *data, uint16_t len)
{
const struct rfcomm_mcc *mcc = data;
+ const struct rfcomm_msc *msc;
+ const struct rfcomm_pn *pn;
+
+ if (len < sizeof(*mcc))
+ return;
switch (RFCOMM_GET_MCC_TYPE(mcc->type)) {
case RFCOMM_MSC:
+ if (len - sizeof(*mcc) < sizeof(*msc))
+ break;
+
+ msc = data + sizeof(*mcc);
+
rfcomm_msc_recv(bthost, conn, l2conn,
- RFCOMM_TEST_CR(mcc->type) / 2,
- data + sizeof(*mcc));
+ RFCOMM_TEST_CR(mcc->type) / 2, msc);
break;
case RFCOMM_PN:
+ if (len - sizeof(*mcc) < sizeof(*pn))
+ break;
+
+ pn = data + sizeof(*mcc);
+
rfcomm_pn_recv(bthost, conn, l2conn,
- RFCOMM_TEST_CR(mcc->type) / 2,
- data + sizeof(*mcc));
+ RFCOMM_TEST_CR(mcc->type) / 2, pn);
break;
default:
break;
@@ -1781,18 +1794,27 @@ static void rfcomm_uih_recv(struct bthost *bthost, struct btconn *conn,
struct l2conn *l2conn, const void *data,
uint16_t len)
{
- const struct rfcomm_cmd *hdr = data;
+ const struct rfcomm_hdr *hdr = data;
+ uint16_t hdr_len;
const void *p;
+ if (len < sizeof(*hdr))
+ return;
+
if (RFCOMM_GET_DLCI(hdr->address))
return;
if (RFCOMM_TEST_EA(hdr->length))
- p = data + sizeof(struct rfcomm_hdr);
+ hdr_len = sizeof(*hdr);
else
- p = data + sizeof(struct rfcomm_hdr) + sizeof(uint8_t);
+ hdr_len = sizeof(*hdr) + sizeof(uint8_t);
+
+ if (len - hdr_len < 0)
+ return;
+
+ p = data + hdr_len;
- rfcomm_mcc_recv(bthost, conn, l2conn, p, p - data);
+ rfcomm_mcc_recv(bthost, conn, l2conn, p, len - hdr_len);
}
static void process_rfcomm(struct bthost *bthost, struct btconn *conn,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 4/5] emulator/bthost: Check length of received RFCOMM UA frames
From: Marcin Kraglak @ 2014-02-11 10:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392115862-19752-1-git-send-email-marcin.kraglak@tieto.com>
Check length of RFCOMM UA frames and ignore if frame is too short.
---
emulator/bthost.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index 33a0544..ab90f4c 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -1619,14 +1619,20 @@ static void rfcomm_ua_recv(struct bthost *bthost, struct btconn *conn,
uint16_t len)
{
const struct rfcomm_cmd *ua_hdr = data;
- uint8_t channel = RFCOMM_GET_CHANNEL(ua_hdr->address);
+ uint8_t channel;
struct rfcomm_connection_data *conn_data = bthost->rfcomm_conn_data;
- uint8_t type = RFCOMM_GET_TYPE(ua_hdr->control);
+ uint8_t type;
uint8_t buf[14];
struct rfcomm_hdr *hdr;
struct rfcomm_mcc *mcc;
struct rfcomm_pn *pn_cmd;
+ if (len < sizeof(*ua_hdr))
+ return;
+
+ channel = RFCOMM_GET_CHANNEL(ua_hdr->address);
+ type = RFCOMM_GET_TYPE(ua_hdr->control);
+
if (channel && conn_data && conn_data->channel == channel) {
if (conn_data->cb)
conn_data->cb(conn->handle, l2conn->scid,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 3/5] emulator/bthost: Check length of received RFCOMM DM frames
From: Marcin Kraglak @ 2014-02-11 10:51 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392115862-19752-1-git-send-email-marcin.kraglak@tieto.com>
Ignore too short received RFCOMM DM frames.
---
emulator/bthost.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index 2cd79bc..33a0544 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -1669,9 +1669,14 @@ static void rfcomm_dm_recv(struct bthost *bthost, struct btconn *conn,
uint16_t len)
{
const struct rfcomm_cmd *hdr = data;
- uint8_t channel = RFCOMM_GET_CHANNEL(hdr->address);
+ uint8_t channel;
struct rfcomm_connection_data *conn_data = bthost->rfcomm_conn_data;
+ if (len < sizeof(*hdr))
+ return;
+
+ channel = RFCOMM_GET_CHANNEL(hdr->address);
+
if (conn_data && conn_data->channel == channel) {
if (conn_data->cb)
conn_data->cb(conn->handle, l2conn->scid,
--
1.8.3.1
^ permalink raw reply related
* [PATCH 2/5] emulator/bthost: Check length of received RFCOMM DISC frame
From: Marcin Kraglak @ 2014-02-11 10:50 UTC (permalink / raw)
To: linux-bluetooth
In-Reply-To: <1392115862-19752-1-git-send-email-marcin.kraglak@tieto.com>
Don't access rfcomm_hdr struct and ignore if frame is too short.
---
emulator/bthost.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index f92b479..2cd79bc 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -1604,7 +1604,12 @@ static void rfcomm_disc_recv(struct bthost *bthost, struct btconn *conn,
uint16_t len)
{
const struct rfcomm_cmd *hdr = data;
- uint8_t dlci = RFCOMM_GET_DLCI(hdr->address);
+ uint8_t dlci;
+
+ if (len < sizeof(*hdr))
+ return;
+
+ dlci = RFCOMM_GET_DLCI(hdr->address);
rfcomm_ua_send(bthost, conn, l2conn, 0, dlci);
}
--
1.8.3.1
^ permalink raw reply related
* [PATCH 1/5] emulator/bthost: Check length of received RFCOMM SABM frame
From: Marcin Kraglak @ 2014-02-11 10:50 UTC (permalink / raw)
To: linux-bluetooth
This will check length of received SABM frame. Ignore frame if
it is too short.
---
emulator/bthost.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/emulator/bthost.c b/emulator/bthost.c
index 3ff2a36..f92b479 100644
--- a/emulator/bthost.c
+++ b/emulator/bthost.c
@@ -1578,9 +1578,15 @@ static void rfcomm_sabm_recv(struct bthost *bthost, struct btconn *conn,
uint16_t len)
{
const struct rfcomm_cmd *hdr = data;
- uint8_t dlci = RFCOMM_GET_DLCI(hdr->address);
+ uint8_t dlci;
struct rfcomm_conn_cb_data *cb;
- uint8_t chan = RFCOMM_GET_CHANNEL(hdr->address);
+ uint8_t chan;
+
+ if (len < sizeof(*hdr))
+ return;
+
+ chan = RFCOMM_GET_CHANNEL(hdr->address);
+ dlci = RFCOMM_GET_DLCI(hdr->address);
cb = bthost_find_rfcomm_cb_by_channel(bthost, chan);
if (!dlci || cb) {
--
1.8.3.1
^ permalink raw reply related
* [PATCH v2] android/README: Update with implementation status summary
From: Szymon Janc @ 2014-02-11 10:40 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
This will give a better overview of implemented features.
---
android/README | 38 +++++++++++++++++++++++++++++++++-----
1 file changed, 33 insertions(+), 5 deletions(-)
diff --git a/android/README b/android/README
index e3c314f..b987dc9 100644
--- a/android/README
+++ b/android/README
@@ -132,15 +132,43 @@ automatically on HAL library initialization. To deinitialize HAL library and
stop daemon type 'bluetooth cleanup'. Type 'help' for more information. Tab
completion is also supported.
+=====================
+Implementation status
+=====================
+
+Summary of HALs implementation status.
+
+complete - implementation is feature complete and Android Framework is able
+ to use it normally
+partial - implementation is in progress and not all required features are
+ present, Android Framework is able to use some of features
+initial - only initial implementations is present, Android Framework is
+ able to initialize but most likely not able to use it
+not started - no implementation, Android Framework is not able to initialize it
+
+Profile ID HAL header Status
+---------------------------------------
+core bluetooth.h complete
+a2dp bt_av.h complete
+gatt bt_gatt.h not started
+ bt_gatt_client.h not started
+ bt_gatt_server.h not started
+handsfree bt_hf.h initial
+hidhost bt_hh.h complete
+health bt_hl.h not started
+pan bt_pan.h complete
+avrcp bt_rc.h partial
+socket bt_sock.h partial
+
===========================
Implementation shortcomings
===========================
-It is possible that some of HAL functionality is missing implementation due to
-reasons like feature feasibility or necessity for latest Android Framework.
-This sections provides list of such deficiencies. Note that HAL library is
-always expected to fully implement HAL API so missing implementation might
-happen only in daemon.
+It is possible that some of HAL functionality (although being marked as
+complete) is missing implementation due to reasons like feature feasibility or
+necessity for latest Android Framework. This sections provides list of such
+deficiencies. Note that HAL library is always expected to fully implement HAL
+API so missing implementation might happen only in daemon.
HAL Bluetooth
=============
--
1.8.5.3
^ permalink raw reply related
* Re:
From: Andrei Emeltchenko @ 2014-02-11 7:13 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Viswanatham, RaviTeja,
bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <BE8107B5-0F83-47C5-ADC6-345CFD24BE21@holtmann.org>
Hi All,
On Mon, Feb 10, 2014 at 10:35:24AM -0800, Marcel Holtmann wrote:
> Hi Ravi,
>
> > I am working on Ubuntu 12.04 with a Bluetooth 3.0 +HS + wifi combo USB
> > dongle.
> >
> > I want to reach a data transfer speed of up to 24 Mbit/s.
> >
> > My Questions: Does Bluez support high speed data transfer rates up to
> > 24 Mbit/s (Bluetooth 3.0+HS) ?
> >
> > If it does, is there any user configuration involved to achieve that?
> > What other requirements need to be met? Does, Bluetooth enables AMP
> > function to communicate 802.11n channel to support high speed or it
> > has to be configure with any other drivers?
> >
> > I am new to Linux a detail explanation would be really appreciated.
> > Thank you in advance for your support.
>
> we do support Bluetooth HS operation. However your WiFi device needs to
> be exposed as AMP Controller. Most WiFi hardware needs a special driver
> to expose itself as AMP Controller. There is no generic driver for
> mac80211 subsystem in the kernel.
Some devices have AMP Controller implemented in firmware.
I was using Marvell SD8787, probably newer Marvell devices also works.
You may check drivers/bluetooth/btmrvl_main.c to see how HCI dev_type
HCI_AMP is assigned.
Best regards
Andrei Emeltchenko
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Peter Hurley @ 2014-02-10 23:00 UTC (permalink / raw)
To: Marcel Holtmann
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <3E0F3723-029F-4B12-8D77-9790FDBD3227@holtmann.org>
Hi Marcel,
On 02/10/2014 05:09 PM, Marcel Holtmann wrote:
> Hi Peter,
>
>> This patch series addresses a number of previously unknown issues
>> with the RFCOMM tty device implementation, in addition to
>> addressing the locking regression recently reported [1].
>>
>> As Gianluca suggested and I agree, this series first reverts
>> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
>
> so for 3.14 we should revert 3 patches. And then the other 21 are
> intended for 3.15 merge window.
Yep, this is probably best. At least 3.13 & 3.14 will behave the
same wrt rfcomm.
> I realize that we still have to deal with some breakage, but we
> do not want regressions and I clearly not going to take 24 patches
> for 3.14 at this point in time.
Yeah, I wasn't expecting you to.
> What I can do is take all 24 patches into bluetooth-next and let
> them sit for 1 week and have people test them. And then we go ahead
> with reverting 3 patches from 3.14. Does that make sense?
Yep, that's fine with me. Thanks.
Regards,
Peter Hurley
^ permalink raw reply
* Re: [PATCH 00/24] rfcomm fixes
From: Marcel Holtmann @ 2014-02-10 22:09 UTC (permalink / raw)
To: Peter Hurley
Cc: Gustavo F. Padovan, Johan Hedberg, Gianluca Anzolin,
Alexander Holler, Andrey Vihrov, Sander Eikelenboom,
bluez mailin list (linux-bluetooth@vger.kernel.org), linux-kernel
In-Reply-To: <1391997564-1805-1-git-send-email-peter@hurleysoftware.com>
Hi Peter,
> This patch series addresses a number of previously unknown issues
> with the RFCOMM tty device implementation, in addition to
> addressing the locking regression recently reported [1].
>
> As Gianluca suggested and I agree, this series first reverts
> 3 of the 4 patches of 3.14-rc1 for bluetooth/rfcomm/tty.c.
so for 3.14 we should revert 3 patches. And then the other 21 are intended for 3.15 merge window.
I realize that we still have to deal with some breakage, but we do not want regressions and I clearly not going to take 24 patches for 3.14 at this point in time.
What I can do is take all 24 patches into bluetooth-next and let them sit for 1 week and have people test them. And then we go ahead with reverting 3 patches from 3.14. Does that make sense?
Regards
Marcel
^ permalink raw reply
* Re: Some patches applied on Fedora that maybe should be considered for being applied upstream
From: Pacho Ramos @ 2014-02-10 20:01 UTC (permalink / raw)
To: Bastien Nocera; +Cc: BlueZ development
In-Reply-To: <1392039609.4417.14.camel@nuvo>
El lun, 10-02-2014 a las 14:40 +0100, Bastien Nocera escribió:
> On Sun, 2014-02-09 at 09:53 +0100, Pacho Ramos wrote:
> > Hello
> >
> > I was looking at bluez package and found some patches that maybe could
> > be upstreamed. Also, I would like to know the reasons for not accepting
> > them to ensure they are safe to be applied downstream by us too :)
> >
> > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch -> Does this cause any issues with systemd --user setups?
>
> Giovanni already posted this patch earlier. There's no distribution
> using systemd sessions, so this doesn't work yet.
>
> > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-obex-Use-GLib-helper-function-to-manipulate-paths.patch
> > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0002-autopair-Don-t-handle-the-iCade.patch
> > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0004-agent-Assert-possible-infinite-loop.patch
> > -> Any reason for not applying it upstream too?
>
> I've posted those patches to the list as well.
And, do you know why they weren't accepted? (it's for trying to get them
merged and not needing to carry them forever)
>
> > http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-work-around-Logitech-diNovo-Edge-keyboard-firmware-i.patch
> > -> Taking care this looks to be a really old issue, maybe using the
> > workaround would be the only option for now :/
>
> I have no hardware to test this on, I snatched it from Ubuntu's bluez 4
> package.
>
> Cheers
OK, thanks :)
^ permalink raw reply
* Re: [PATCH] android/README: Update with implementation status summary
From: Marcel Holtmann @ 2014-02-10 18:37 UTC (permalink / raw)
To: Szymon Janc; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <1392033059-3346-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
> This will give a better overview of implemented features.
> ---
> android/README | 37 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/android/README b/android/README
> index e3c314f..49536e2 100644
> --- a/android/README
> +++ b/android/README
> @@ -132,15 +132,42 @@ automatically on HAL library initialization. To deinitialize HAL library and
> stop daemon type 'bluetooth cleanup'. Type 'help' for more information. Tab
> completion is also supported.
>
> +=====================
> +Implementation status
> +=====================
> +
> +Summary of HALs implementation status.
> +
> +complete - implementation is feature complete and Android Framework is able
> + to use it normally
> +partial - implementation is in progress and not all required features are
> + present, Android Framework is able to use some of features
> +initial - only initial implementations is present, Android Framework is
> + able to initialize but most likely not able to use it
> +not started - no implementation, Android Framework is not able to initialize it
> +
> +profile ID HAL header status
use a ------ line here to separate header for content.
> +core bluetooth.h complete
> +a2dp bt_av.h complete
> +gatt bt_gatt.h not started
> + bt_gatt_client.h not started
> + bt_gatt_server.h not started
> +handsfree bt_hf.h initial
> +hidhost bt_hh.h complete
> +health bt_hl.h not started
> +pan bt_pan.h complete
> +avrcp bt_rc.h partial
> +socket bt_sock.h complete
> +
Regards
Marcel
^ permalink raw reply
* Re:
From: Marcel Holtmann @ 2014-02-10 18:35 UTC (permalink / raw)
To: Viswanatham, RaviTeja; +Cc: bluez mailin list (linux-bluetooth@vger.kernel.org)
In-Reply-To: <9BC883E0D59F6B4DBD525D460025714B08AE336F@deessmx03.dees.eberspaecher.com>
Hi Ravi,
> I am working on Ubuntu 12.04 with a Bluetooth 3.0 +HS + wifi combo USB dongle.
>
> I want to reach a data transfer speed of up to 24 Mbit/s.
>
> My Questions:
> Does Bluez support high speed data transfer rates up to 24 Mbit/s (Bluetooth 3.0+HS) ?
>
> If it does, is there any user configuration involved to achieve that? What other requirements need to be met?
> Does, Bluetooth enables AMP function to communicate 802.11n channel to support high speed or it has to be configure with any other drivers?
>
> I am new to Linux a detail explanation would be really appreciated. Thank you in advance for your support.
we do support Bluetooth HS operation. However your WiFi device needs to be exposed as AMP Controller. Most WiFi hardware needs a special driver to expose itself as AMP Controller. There is no generic driver for mac80211 subsystem in the kernel.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] btusb.c add IMC Networks id 13d3:3404 (bcm20702A0)
From: Marcel Holtmann @ 2014-02-10 18:33 UTC (permalink / raw)
To: Jurgen Kramer; +Cc: BlueZ development
In-Reply-To: <1392031617.5601.11.camel@develbox>
HI Jurgen,
> Attached patch adds support for IMC Networks (13d3:3404) to BCM20702A0
> in btusb.c. This device is used on the Asrock Z87E-ITX motherboard.
> Tested against 3.12.9.
>
> diff -uNrp
> linux-3.12.9-301.jk1.fc20.x86_64.orig/drivers/bluetooth/btusb.c
> linux-3.12.9-301.jk1.fc20.x86_64.new/drivers/bluetooth/btusb.c
> --- a/drivers/bluetooth/btusb.c 2014-02-10 11:35:08.976975562 +0100
> +++ b/drivers/bluetooth/btusb.c 2014-02-10 11:37:03.864921122 +0100
> @@ -106,6 +106,7 @@ static struct usb_device_id btusb_table[
> { USB_DEVICE(0x04ca, 0x2003) },
> { USB_DEVICE(0x0489, 0xe042) },
> { USB_DEVICE(0x413c, 0x8197) },
> + { USB_DEVICE(0x13d3, 0x3404) },
>
> /* Foxconn - Hon Hai */
> { USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01) },
>
> Signed-off-by: Jurgen Kramer <gtm.kramer@xs4all.nl>
>
> Jurgen
> <btusb-bcm20702a0-add-imc-networks.patch>
please send patches inline created from git-format-patch and include /sys/kernel/debug/usb/devices details for this device.
Regards
Marcel
^ permalink raw reply
* [PATCH BlueZ 3/3] unit: Fix memory leaks in test-gdbus-client
From: Anderson Lizardo @ 2014-02-10 17:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1392052498-9229-1-git-send-email-anderson.lizardo@openbossa.org>
---
unit/test-gdbus-client.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/unit/test-gdbus-client.c b/unit/test-gdbus-client.c
index 685729a..ee8a760 100644
--- a/unit/test-gdbus-client.c
+++ b/unit/test-gdbus-client.c
@@ -101,6 +101,7 @@ static void destroy_context(struct context *context)
dbus_connection_flush(context->dbus_conn);
dbus_connection_close(context->dbus_conn);
+ dbus_connection_unref(context->dbus_conn);
g_main_loop_unref(context->main_loop);
@@ -956,6 +957,10 @@ static void client_force_disconnect(void)
g_main_loop_run(context->main_loop);
+ g_dbus_unregister_interface(conn, SERVICE_PATH, SERVICE_NAME1);
+ g_dbus_detach_object_manager(conn);
+ dbus_connection_unref(conn);
+
destroy_context(context);
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH BlueZ 2/3] gdbus: Fix incorrect DBusConnection reference counting
From: Anderson Lizardo @ 2014-02-10 17:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1392052498-9229-1-git-send-email-anderson.lizardo@openbossa.org>
Commit abfc2b0dd5c3e33abfdf1a815b16d492c1751c06 attempted to fix a crash
related to improper reference counting, but the main issue was that the
reference was taken only during the function call (which is usually
unnecessary for single thread), but still passed a pointer to
DBusConnection to a function that is called by the mainloop. This left a
window where the DBusConnection can be destroyed.
---
gdbus/mainloop.c | 14 ++++----------
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/gdbus/mainloop.c b/gdbus/mainloop.c
index 099b67f..ec52554 100644
--- a/gdbus/mainloop.c
+++ b/gdbus/mainloop.c
@@ -70,8 +70,6 @@ static gboolean message_dispatch(void *data)
{
DBusConnection *conn = data;
- dbus_connection_ref(conn);
-
/* Dispatch messages */
while (dbus_connection_dispatch(conn) == DBUS_DISPATCH_DATA_REMAINS);
@@ -84,7 +82,8 @@ static inline void queue_dispatch(DBusConnection *conn,
DBusDispatchStatus status)
{
if (status == DBUS_DISPATCH_DATA_REMAINS)
- g_timeout_add(DISPATCH_TIMEOUT, message_dispatch, conn);
+ g_timeout_add(DISPATCH_TIMEOUT, message_dispatch,
+ dbus_connection_ref(conn));
}
static gboolean watch_func(GIOChannel *chan, GIOCondition cond, gpointer data)
@@ -92,9 +91,6 @@ static gboolean watch_func(GIOChannel *chan, GIOCondition cond, gpointer data)
struct watch_info *info = data;
unsigned int flags = 0;
DBusDispatchStatus status;
- DBusConnection *conn;
-
- conn = dbus_connection_ref(info->conn);
if (cond & G_IO_IN) flags |= DBUS_WATCH_READABLE;
if (cond & G_IO_OUT) flags |= DBUS_WATCH_WRITABLE;
@@ -103,10 +99,8 @@ static gboolean watch_func(GIOChannel *chan, GIOCondition cond, gpointer data)
dbus_watch_handle(info->watch, flags);
- status = dbus_connection_get_dispatch_status(conn);
- queue_dispatch(conn, status);
-
- dbus_connection_unref(conn);
+ status = dbus_connection_get_dispatch_status(info->conn);
+ queue_dispatch(info->conn, status);
return TRUE;
}
--
1.7.9.5
^ permalink raw reply related
* [PATCH BlueZ 1/3] gdbus: Fix memory leak
From: Anderson Lizardo @ 2014-02-10 17:14 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
data->conn and data->path must be destroyed before freeing "data".
---
gdbus/object.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gdbus/object.c b/gdbus/object.c
index b248cbb..13cf9a9 100644
--- a/gdbus/object.c
+++ b/gdbus/object.c
@@ -1253,6 +1253,8 @@ static struct generic_data *object_path_ref(DBusConnection *connection,
if (!dbus_connection_register_object_path(connection, path,
&generic_table, data)) {
+ dbus_connection_unref(data->conn);
+ g_free(data->path);
g_free(data->introspect);
g_free(data);
return NULL;
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] android/README: Update with implementation status summary
From: Szymon Janc @ 2014-02-10 14:53 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: linux-bluetooth
In-Reply-To: <CAF3PWx0fcUUQtdvm2c4m985vDNMdtOQKjKaFeg9L-LOZ+-dcxA@mail.gmail.com>
Hi Andrzej,
On Monday 10 of February 2014 15:35:15 Andrzej Kaczmarek wrote:
> Hi Szymon,
>
> On 10 February 2014 12:50, Szymon Janc <szymon.janc@tieto.com> wrote:
> > This will give a better overview of implemented features.
> > ---
> >
> > android/README | 37 ++++++++++++++++++++++++++++++++-----
> > 1 file changed, 32 insertions(+), 5 deletions(-)
> >
> > diff --git a/android/README b/android/README
> > index e3c314f..49536e2 100644
> > --- a/android/README
> > +++ b/android/README
> > @@ -132,15 +132,42 @@ automatically on HAL library initialization. To
> > deinitialize HAL library and>
> > stop daemon type 'bluetooth cleanup'. Type 'help' for more information.
> > Tab
> > completion is also supported.
> >
> > +=====================
> > +Implementation status
> > +=====================
> > +
> > +Summary of HALs implementation status.
> > +
> > +complete - implementation is feature complete and Android Framework is
> > able + to use it normally
> > +partial - implementation is in progress and not all required features
> > are + present, Android Framework is able to use some of
> > features +initial - only initial implementations is present, Android
> > Framework is + able to initialize but most likely not able
> > to use it +not started - no implementation, Android Framework is not able
> > to initialize it +
> > +profile ID HAL header status
> > +core bluetooth.h complete
> > +a2dp bt_av.h complete
> > +gatt bt_gatt.h not started
> > + bt_gatt_client.h not started
> > + bt_gatt_server.h not started
> > +handsfree bt_hf.h initial
> > +hidhost bt_hh.h complete
> > +health bt_hl.h not started
> > +pan bt_pan.h complete
> > +avrcp bt_rc.h partial
> > +socket bt_sock.h complete
>
> This should be 'partial' since you application cannot register server
> on custom UUID with channel being assigned dynamically
> (BluetoothAdapter::listenUsingRfcommWithServiceRecord). I have patches
> which add this support but need to fix other code first in order to
> make them work properly.
Right, I'll send V2 later (unless you manage to socket send fixes before me:))
--
BR
Szymon Janc
^ permalink raw reply
* (no subject)
From: Viswanatham, RaviTeja @ 2014-02-10 14:35 UTC (permalink / raw)
To: bluez mailin list (linux-bluetooth@vger.kernel.org)
Hello,
I am working on Ubuntu 12.04 with a Bluetooth 3.0 +HS + wifi combo USB dongle.
I want to reach a data transfer speed of up to 24 Mbit/s.
My Questions:
Does Bluez support high speed data transfer rates up to 24 Mbit/s (Bluetooth 3.0+HS) ?
If it does, is there any user configuration involved to achieve that? What other requirements need to be met?
Does, Bluetooth enables AMP function to communicate 802.11n channel to support high speed or it has to be configure with any other drivers?
I am new to Linux a detail explanation would be really appreciated. Thank you in advance for your support.
Best Regards,
Ravi Teja
^ permalink raw reply
* Re: [PATCH] android/README: Update with implementation status summary
From: Andrzej Kaczmarek @ 2014-02-10 14:35 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1392033059-3346-1-git-send-email-szymon.janc@tieto.com>
Hi Szymon,
On 10 February 2014 12:50, Szymon Janc <szymon.janc@tieto.com> wrote:
>
> This will give a better overview of implemented features.
> ---
> android/README | 37 ++++++++++++++++++++++++++++++++-----
> 1 file changed, 32 insertions(+), 5 deletions(-)
>
> diff --git a/android/README b/android/README
> index e3c314f..49536e2 100644
> --- a/android/README
> +++ b/android/README
> @@ -132,15 +132,42 @@ automatically on HAL library initialization. To deinitialize HAL library and
> stop daemon type 'bluetooth cleanup'. Type 'help' for more information. Tab
> completion is also supported.
>
> +=====================
> +Implementation status
> +=====================
> +
> +Summary of HALs implementation status.
> +
> +complete - implementation is feature complete and Android Framework is able
> + to use it normally
> +partial - implementation is in progress and not all required features are
> + present, Android Framework is able to use some of features
> +initial - only initial implementations is present, Android Framework is
> + able to initialize but most likely not able to use it
> +not started - no implementation, Android Framework is not able to initialize it
> +
> +profile ID HAL header status
> +core bluetooth.h complete
> +a2dp bt_av.h complete
> +gatt bt_gatt.h not started
> + bt_gatt_client.h not started
> + bt_gatt_server.h not started
> +handsfree bt_hf.h initial
> +hidhost bt_hh.h complete
> +health bt_hl.h not started
> +pan bt_pan.h complete
> +avrcp bt_rc.h partial
> +socket bt_sock.h complete
This should be 'partial' since you application cannot register server
on custom UUID with channel being assigned dynamically
(BluetoothAdapter::listenUsingRfcommWithServiceRecord). I have patches
which add this support but need to fix other code first in order to
make them work properly.
BR,
Andrzej
^ permalink raw reply
* Re: Some patches applied on Fedora that maybe should be considered for being applied upstream
From: Bastien Nocera @ 2014-02-10 13:40 UTC (permalink / raw)
To: Pacho Ramos; +Cc: BlueZ development
In-Reply-To: <1391935987.4666.5.camel@belkin5>
On Sun, 2014-02-09 at 09:53 +0100, Pacho Ramos wrote:
> Hello
>
> I was looking at bluez package and found some patches that maybe could
> be upstreamed. Also, I would like to know the reasons for not accepting
> them to ensure they are safe to be applied downstream by us too :)
>
> http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch -> Does this cause any issues with systemd --user setups?
Giovanni already posted this patch earlier. There's no distribution
using systemd sessions, so this doesn't work yet.
> http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-obex-Use-GLib-helper-function-to-manipulate-paths.patch
> http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0002-autopair-Don-t-handle-the-iCade.patch
> http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0004-agent-Assert-possible-infinite-loop.patch
> -> Any reason for not applying it upstream too?
I've posted those patches to the list as well.
> http://pkgs.fedoraproject.org/cgit/bluez.git/tree/0001-work-around-Logitech-diNovo-Edge-keyboard-firmware-i.patch
> -> Taking care this looks to be a really old issue, maybe using the
> workaround would be the only option for now :/
I have no hardware to test this on, I snatched it from Ubuntu's bluez 4
package.
Cheers
^ permalink raw reply
* Re: LE Connection Update Disallowed
From: Sandy Chapman @ 2014-02-10 12:30 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: BlueZ development
In-Reply-To: <CAPm3yA0m0AUyQd04J4H+mQ3NL7XjvkLX3M8R7cKhc8QGGG25hA@mail.gmail.com>
Hi All,
On Thu, Feb 6, 2014 at 12:21 PM, Sandy Chapman <schapman@lixar.com> wrote:
> Hi Anderson,
>
> On Wed, Feb 5, 2014 at 11:23 AM, Anderson Lizardo
> <anderson.lizardo@openbossa.org> wrote:
>> HI Sandy,
>>
>> On Wed, Feb 5, 2014 at 10:51 AM, Sandy Chapman <schapman@lixar.com> wrote:
>>>>> How do I initiate a Connection Update from the peripheral?
>>>>
>>>> I never tried this procedure myself, but my guess it that you are
>>>> using the incorrect mechanism on the slave role. Take a look at the
>>>> "Connection Parameters Update Request" on Vol 3, Part A, Section 4.20.
>>>> I believe this is the correct way to request from the slave (from what
>>>> I understand while reading the Linux kernel implementation of the
>>>> master side).
>>>>
>>>> Note that when Linux is the master, this command is issued
>>>> automatically by the kernel when requested by the slave.
>>>
>>> I've taken a look at that section and it appears that this is what is
>>> used to trigger the Connection Update. It states that the command
>>> shall only be issued from the slave to the master. I can confirm that
>>> my device is in the slave role using 'hcitool con'.
>>
>> I think you didn't notice that the section I mentioned is about a
>> L2CAP signalling packet, not an HCI command (which in this case is to
>> be used on the master side). I suggest you read a bit more on the
>> L2CAP section to understand how these signalling packets work. Then
>> you can try building such packet with "hcitool cmd" (unless there is
>> some support for it on the current kernel, which I didn't check)
>>
>
> Yes, you right, I missed that part. I've built out what my packet
> should look like, but I'm having troubles sending it to the
> controller. I really am stuck on issuing this packet. It appears that
> I need to send an HCI ACL Data Packet which holds a Signalling
> Command. This signalling command then holds the connection parameter
> update request as it's payload. It looks like 'hcitool cmd' can't send
> ACL packets though as the command requires an OGF and OCF which are
> part of the HCI Command Packet, not the HCI ACL Data Packet. From what
> I can tell, the best chance I'd have is to send it via the l2test tool
> over L2CAP, but attempting to use le_public address type doesn't work
> (which I believe will send the message over CID 0x0005 - the fixed LE
> channel). It fails on getsockopt/setsockopt for the SOL_BLUETOOTH
> type. From what I can tell, it requires a kernel with CoC (not sure
> what it means or if I have it). I'm really hoping I'm not going to
> have to compile the bluetooth kernel module myself to send this
> connection update packet.
>
>>>> You may want to take a look at the "GAP Peripheral Preferred
>>>> Connection Parameters" characteristic (see Vol 3, Part C, Section
>>>> 12.3). If iPhones reads this characteristic and honours the
>>>> parameters, it may help.
>>>
>>> Unfortunately, it appears Apple explicitly ignores this parameter
>>> (section 3.6 in this document
>>> https://developer.apple.com/hardwaredrivers/BluetoothDesignGuidelines.pdf).
>>
>> This is unfortunate. It would be the easiest way to pass custom
>> connection parameters IMHO.
>>
>>> I believe that 'hcitool lecup' is exactly supposed to initiate this
>>> process. I've also tried to use 'hcitool cmd' to issue direct commands
>>> to the controller (using Vol 3, Part A, Section 4.20 as a guide), but
>>> I am having no luck. It's stating that the command is disallowed (not
>>> that the parameters are invalid), so I'm guessing there's something
>>> else wrong. Since this is directly communicating with the controller,
>>> where would the problem be? In the kernel, itself? Could it be a
>>> problem with the Broadcom chipset in my MacBook?
>>
>> "hcitool lecup" is just a helper, it uses the same mechanism that
>> "hcitool cmd" uses (and both are just "raw" interfaces to the
>> Bluetooth controller). If you are getting an "Invalid Parameters" on
>> any of them, is either because you built the packet incorrectly on
>> "hcitool cmd" or given invalid values as per the spec.
>>
>> By the way, I suggest using "btmon" instead of "hcidump", as the
>> former has nicer output and is more up-to-date (although I'm not sure
>> it supports parsing "LE Connection Update" parameters).
>>
>
> You're right btmon is much nicer and does support recognition of the
> LE commands.
>
>> Best Regards,
>> --
>> Anderson Lizardo
>> http://www.indt.org/?lang=en
>> INdT - Manaus - Brazil
>
> I know what I'm doing might not be typical, but I really appreciate
> your help. If there's any direction you could point me in, I'd be
> really thankful. I don't really know what to try next.
>
> Thanks again,
>
> Sandy
Just wanted to post that I've got this working. However, I've had to
write code that will format the signalling packet properly and relay
it to the controller via hci (in a similar manner to how hcitool
current sends HCI commands). The approach I suggested in my previous
email worked (HCI ACL Data Packet containing a Signalling Command of
the type Connection Parameter Update Request). This required changes
to hci.c (to format and write the new packet to the hci device).
See Vol. 2, Part E, 4.1 for Host to Controller HCI flow.
See Vol. 2, Part E, 5.4.2 for HCI ACL Data Packet format.
See Vol. 3, Part A, 4 for Signalling Packet format.
See Vol. 3, Part A, 4.20 for Connection Parameter Update Request format.
Since I've got this working, I'm wondering if there is interest from
the bluez devs in supporting this going forward? If so, I can likely
clean up my code in such a way that it'll allow adding the other
signalling packet formats easily. Currently, I've got my specific
signalling packet exposed through hcitool (as a new command) as it was
convenient to piggyback on it. Since the ACL Data Packets are being
sent via HCI, this may be a decent place for this new functionality to
stay.
Anyway, I'm just wondering if there is any interest as I can likely do
some work to add this functionality and I don't think I'm going to be
the only one who wishes to be able to request the slave device to
renegotiate the connection parameters while a connection is open from
the command line. This would be useful in a case where a low energy
connection would require a burst of information to be sent (transfer
of a large log file, or an image from a sensor for examples).
Sandy
--
^ permalink raw reply
* Re: [PATCH 1/4] android/haltest: Remove unneeded assignment
From: Luiz Augusto von Dentz @ 2014-02-10 12:16 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1391775078-25010-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Fri, Feb 7, 2014 at 2:11 PM, Andrei Emeltchenko
<Andrei.Emeltchenko.news@gmail.com> wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> ---
> android/client/if-audio.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/android/client/if-audio.c b/android/client/if-audio.c
> index 8c640a1..5ab11a6 100644
> --- a/android/client/if-audio.c
> +++ b/android/client/if-audio.c
> @@ -225,10 +225,8 @@ static void *playback_thread(void *data)
> pthread_mutex_unlock(&outstream_mutex);
> } while (len && w_len > 0);
>
> - if (in) {
> + if (in)
> fclose(in);
> - in = NULL;
> - }
>
> pthread_cleanup_pop(1);
> return NULL;
> --
> 1.8.3.2
Pushed, note that I did move the changes from audio to android since
the audio code will be dropped as it is not unit tested.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] android/README: Update with implementation status summary
From: Szymon Janc @ 2014-02-10 11:50 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
This will give a better overview of implemented features.
---
android/README | 37 ++++++++++++++++++++++++++++++++-----
1 file changed, 32 insertions(+), 5 deletions(-)
diff --git a/android/README b/android/README
index e3c314f..49536e2 100644
--- a/android/README
+++ b/android/README
@@ -132,15 +132,42 @@ automatically on HAL library initialization. To deinitialize HAL library and
stop daemon type 'bluetooth cleanup'. Type 'help' for more information. Tab
completion is also supported.
+=====================
+Implementation status
+=====================
+
+Summary of HALs implementation status.
+
+complete - implementation is feature complete and Android Framework is able
+ to use it normally
+partial - implementation is in progress and not all required features are
+ present, Android Framework is able to use some of features
+initial - only initial implementations is present, Android Framework is
+ able to initialize but most likely not able to use it
+not started - no implementation, Android Framework is not able to initialize it
+
+profile ID HAL header status
+core bluetooth.h complete
+a2dp bt_av.h complete
+gatt bt_gatt.h not started
+ bt_gatt_client.h not started
+ bt_gatt_server.h not started
+handsfree bt_hf.h initial
+hidhost bt_hh.h complete
+health bt_hl.h not started
+pan bt_pan.h complete
+avrcp bt_rc.h partial
+socket bt_sock.h complete
+
===========================
Implementation shortcomings
===========================
-It is possible that some of HAL functionality is missing implementation due to
-reasons like feature feasibility or necessity for latest Android Framework.
-This sections provides list of such deficiencies. Note that HAL library is
-always expected to fully implement HAL API so missing implementation might
-happen only in daemon.
+It is possible that some of HAL functionality (although being marked as
+complete) is missing implementation due to reasons like feature feasibility or
+necessity for latest Android Framework. This sections provides list of such
+deficiencies. Note that HAL library is always expected to fully implement HAL
+API so missing implementation might happen only in daemon.
HAL Bluetooth
=============
--
1.8.5.3
^ permalink raw reply related
* Re: [PATCH v2 1/6] android/a2dp: Shutdown AVDTP gracefully
From: Luiz Augusto von Dentz @ 2014-02-10 11:36 UTC (permalink / raw)
To: Andrzej Kaczmarek; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1392029145-7954-1-git-send-email-andrzej.kaczmarek@tieto.com>
Hi Andrzej,
On Mon, Feb 10, 2014 at 12:45 PM, Andrzej Kaczmarek
<andrzej.kaczmarek@tieto.com> wrote:
> When shutting down AVDTP connection we first abort and wait for stream
> to go to idle state before disconnecting signalling channel.
> ---
> android/avdtp.c | 21 +++++++++++++++++----
> 1 file changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/android/avdtp.c b/android/avdtp.c
> index e26d6ec..2629e67 100644
> --- a/android/avdtp.c
> +++ b/android/avdtp.c
> @@ -398,6 +398,8 @@ struct avdtp {
> struct pending_req *req;
>
> GSList *disconnect;
> +
> + bool shutdown;
> };
>
> static GSList *lseps = NULL;
> @@ -913,6 +915,11 @@ static void avdtp_sep_set_state(struct avdtp *session,
> session->streams = g_slist_remove(session->streams, stream);
> stream_free(stream);
> }
> +
> + if (session->io && session->shutdown && session->streams == NULL) {
> + int sock = g_io_channel_unix_get_fd(session->io);
> + shutdown(sock, SHUT_RDWR);
> + }
> }
>
> static void finalize_discovery(struct avdtp *session, int err)
> @@ -2141,7 +2148,7 @@ gboolean avdtp_remove_disconnect_cb(struct avdtp *session, unsigned int id)
> void avdtp_shutdown(struct avdtp *session)
> {
> GSList *l;
> - int sock;
> + bool aborting = false;
>
> if (!session->io)
> return;
> @@ -2149,12 +2156,18 @@ void avdtp_shutdown(struct avdtp *session)
> for (l = session->streams; l; l = g_slist_next(l)) {
> struct avdtp_stream *stream = l->data;
>
> - avdtp_close(session, stream, TRUE);
> + if (stream->abort_int || avdtp_abort(session, stream) == 0)
> + aborting = true;
> }
>
> - sock = g_io_channel_unix_get_fd(session->io);
> + if (aborting) {
> + /* defer shutdown until all streams are aborted properly */
> + session->shutdown = true;
> + } else {
> + int sock = g_io_channel_unix_get_fd(session->io);
>
> - shutdown(sock, SHUT_RDWR);
> + shutdown(sock, SHUT_RDWR);
> + }
> }
>
> static void queue_request(struct avdtp *session, struct pending_req *req,
> --
> 1.8.5.3
Applied, thanks.
--
Luiz Augusto von Dentz
^ permalink raw reply
* [PATCH] btusb.c add IMC Networks id 13d3:3404 (bcm20702A0)
From: Jurgen Kramer @ 2014-02-10 11:26 UTC (permalink / raw)
To: linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Attached patch adds support for IMC Networks (13d3:3404) to BCM20702A0
in btusb.c. This device is used on the Asrock Z87E-ITX motherboard.
Tested against 3.12.9.
diff -uNrp
linux-3.12.9-301.jk1.fc20.x86_64.orig/drivers/bluetooth/btusb.c
linux-3.12.9-301.jk1.fc20.x86_64.new/drivers/bluetooth/btusb.c
--- a/drivers/bluetooth/btusb.c 2014-02-10 11:35:08.976975562 +0100
+++ b/drivers/bluetooth/btusb.c 2014-02-10 11:37:03.864921122 +0100
@@ -106,6 +106,7 @@ static struct usb_device_id btusb_table[
{ USB_DEVICE(0x04ca, 0x2003) },
{ USB_DEVICE(0x0489, 0xe042) },
{ USB_DEVICE(0x413c, 0x8197) },
+ { USB_DEVICE(0x13d3, 0x3404) },
/* Foxconn - Hon Hai */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01) },
Signed-off-by: Jurgen Kramer <gtm.kramer@xs4all.nl>
Jurgen
[-- Attachment #2: btusb-bcm20702a0-add-imc-networks.patch --]
[-- Type: text/x-patch, Size: 562 bytes --]
diff -uNrp linux-3.12.9-301.jk1.fc20.x86_64.orig/drivers/bluetooth/btusb.c linux-3.12.9-301.jk1.fc20.x86_64.new/drivers/bluetooth/btusb.c
--- a/drivers/bluetooth/btusb.c 2014-02-10 11:35:08.976975562 +0100
+++ b/drivers/bluetooth/btusb.c 2014-02-10 11:37:03.864921122 +0100
@@ -106,6 +106,7 @@ static struct usb_device_id btusb_table[
{ USB_DEVICE(0x04ca, 0x2003) },
{ USB_DEVICE(0x0489, 0xe042) },
{ USB_DEVICE(0x413c, 0x8197) },
+ { USB_DEVICE(0x13d3, 0x3404) },
/* Foxconn - Hon Hai */
{ USB_VENDOR_AND_INTERFACE_INFO(0x0489, 0xff, 0x01, 0x01) },
^ 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