* Re: [PATCH 2/2] adapter: Set default adapter id sooner
From: Marcel Holtmann @ 2013-02-06 7:57 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1360098656-12488-2-git-send-email-szymon@janc.net.pl>
Hi Szymon,
> When first adapter is registered set it as default before probing
> drivers or profiles as those might depend on that e.g. hostname.
>
> This fix hostname plugin setting default adapter name to 'foo #1'
> instead of 'foo' if pretty hostname was received before probing
> adapter drivers.
you find an issue that I meant to fix, but never got around so far. So I
do not like the magic default_adapter_id global variable.
I would prefer if we add a is_default or similar variable to btd_adapter
and make it change if one adapter goes away.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH 1/2] hostname: Fallback to static hostname if pretty hostname is not set
From: Marcel Holtmann @ 2013-02-06 7:44 UTC (permalink / raw)
To: Szymon Janc; +Cc: linux-bluetooth
In-Reply-To: <1360098656-12488-1-git-send-email-szymon@janc.net.pl>
Hi Szymon,
> If pretty hostname is not set fallback to static hostname (if it is
> set). If static or pretty hostname is not set appropriate properties
> are empty strings not NULLs. This behaviour is recomended by hostnamed.
>
> Also fix setting adapter name to empty string if pretty hostname was
> not set.
please do not squeeze to patches into one.
I am also not convinced that we should bother with the static hostname
at all. I left this out on purpose. My thinking here was that if we do
not have a pretty hostname, then why bother with trying to make
something useful out of the hostname, it would be ugly or wrong anyway.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH v0] core: Fix racy D-Bus service name request
From: Marcel Holtmann @ 2013-02-06 7:39 UTC (permalink / raw)
To: Mikel Astiz; +Cc: linux-bluetooth, Mikel Astiz
In-Reply-To: <1360076455-32716-1-git-send-email-mikel.astiz.oss@gmail.com>
Hi Mikel,
> The ObjectManager interface should already be ready by the time the
> D-Bus service name is owned. Hence, use g_dbus_request_name() explicitly
> once g_dbus_attach_object_manager() has finished.
>
> Without this patch, clients relying on the presence of the ObjectManager
> could potentially face a race condition.
I almost expected that someone sooner or later will run into this issue.
> ---
> src/main.c | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/src/main.c b/src/main.c
> index 1e40ebc..12ae3d9 100644
> --- a/src/main.c
> +++ b/src/main.c
> @@ -424,7 +424,7 @@ static int connect_dbus(void)
>
> dbus_error_init(&err);
>
> - conn = g_dbus_setup_bus(DBUS_BUS_SYSTEM, BLUEZ_NAME, &err);
> + conn = g_dbus_setup_bus(DBUS_BUS_SYSTEM, NULL, &err);
> if (!conn) {
> if (dbus_error_is_set(&err)) {
> g_printerr("D-Bus setup failed: %s\n", err.message);
> @@ -439,6 +439,12 @@ static int connect_dbus(void)
> g_dbus_set_disconnect_function(conn, disconnected_dbus, NULL, NULL);
> g_dbus_attach_object_manager(conn);
>
> + if (!g_dbus_request_name(conn, BLUEZ_NAME, &err)) {
> + g_printerr("D-Bus service name request failed: %s\n",
> + err.message);
> + return -EIO;
> + }
> +
The only thing that I do not really like here is that the request name
is actually a blocking call. If we are trying to fix this, then we might
actually really do this async.
Regards
Marcel
^ permalink raw reply
* RFC [PATCH] hci: Fix race between hidp_session and hci code
From: Karl Relton @ 2013-02-05 21:11 UTC (permalink / raw)
To: linux-bluetooth
From: Karl Relton <karllinuxtest.relton@ntlworld.com>
Fix race between hidp_session and hci code that can lead to
hci device being removed from sysfs before its children
devices. The removal is now delayed until the last
reference to it in the hci code is removed.
Signed-off-by: Karl Relton <karllinuxtest.relton@ntlworld.com>
---
include/net/bluetooth/hci_core.h | 10 +++-------
net/bluetooth/hci_core.c | 15 +++++++++++++--
2 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 90cf75a..47c9d30 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -198,6 +198,7 @@ struct hci_dev {
unsigned long quirks;
+ atomic_t ref_cnt;
atomic_t cmd_cnt;
unsigned int acl_cnt;
unsigned int sco_cnt;
@@ -646,19 +647,14 @@ static inline void hci_conn_put(struct hci_conn *conn)
}
/* ----- HCI Devices ----- */
-static inline void hci_dev_put(struct hci_dev *d)
-{
- BT_DBG("%s orig refcnt %d", d->name,
- atomic_read(&d->dev.kobj.kref.refcount));
-
- put_device(&d->dev);
-}
+void hci_dev_put(struct hci_dev *d);
static inline struct hci_dev *hci_dev_hold(struct hci_dev *d)
{
BT_DBG("%s orig refcnt %d", d->name,
atomic_read(&d->dev.kobj.kref.refcount));
+ atomic_inc(&d->ref_cnt);
get_device(&d->dev);
return d;
}
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 618ca1a..c187a84 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -891,6 +891,19 @@ int hci_dev_close(__u16 dev)
return err;
}
+void hci_dev_put(struct hci_dev *d)
+{
+ BT_DBG("%s orig refcnt %d", d->name,
+ atomic_read(&d->dev.kobj.kref.refcount));
+
+ if(atomic_dec_and_test(&d->ref_cnt)) {
+ hci_del_sysfs(d);
+ }
+ put_device(&d->dev);
+}
+EXPORT_SYMBOL(hci_dev_put);
+
+
int hci_dev_reset(__u16 dev)
{
struct hci_dev *hdev;
@@ -1884,8 +1897,6 @@ void hci_unregister_dev(struct hci_dev *hdev)
rfkill_destroy(hdev->rfkill);
}
- hci_del_sysfs(hdev);
-
destroy_workqueue(hdev->workqueue);
destroy_workqueue(hdev->req_workqueue);
--
1.7.9.5
^ permalink raw reply related
* [PATCH 2/2] adapter: Set default adapter id sooner
From: Szymon Janc @ 2013-02-05 21:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
In-Reply-To: <1360098656-12488-1-git-send-email-szymon@janc.net.pl>
When first adapter is registered set it as default before probing
drivers or profiles as those might depend on that e.g. hostname.
This fix hostname plugin setting default adapter name to 'foo #1'
instead of 'foo' if pretty hostname was received before probing
adapter drivers.
---
src/adapter.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 9ddd2fc..276d897 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -5492,6 +5492,9 @@ static int adapter_register(struct btd_adapter *adapter)
btd_adapter_gatt_server_start(adapter);
+ if (default_adapter_id < 0)
+ default_adapter_id = adapter->dev_id;
+
load_config(adapter);
fix_storage(adapter);
load_drivers(adapter);
@@ -5506,9 +5509,6 @@ static int adapter_register(struct btd_adapter *adapter)
adapter->initialized = TRUE;
- if (default_adapter_id < 0)
- default_adapter_id = adapter->dev_id;
-
if (main_opts.did_source)
set_did(adapter, main_opts.did_vendor, main_opts.did_product,
main_opts.did_version, main_opts.did_source);
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/2] hostname: Fallback to static hostname if pretty hostname is not set
From: Szymon Janc @ 2013-02-05 21:10 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Szymon Janc
If pretty hostname is not set fallback to static hostname (if it is
set). If static or pretty hostname is not set appropriate properties
are empty strings not NULLs. This behaviour is recomended by hostnamed.
Also fix setting adapter name to empty string if pretty hostname was
not set.
---
plugins/hostname.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
1 file changed, 44 insertions(+), 4 deletions(-)
diff --git a/plugins/hostname.c b/plugins/hostname.c
index 0b75fac..92a71e0 100644
--- a/plugins/hostname.c
+++ b/plugins/hostname.c
@@ -53,22 +53,43 @@ static uint8_t major_class = MAJOR_CLASS_MISCELLANEOUS;
static uint8_t minor_class = MINOR_CLASS_UNCATEGORIZED;
static char *pretty_hostname = NULL;
+static char *static_hostname = NULL;
+
+/*
+ * Fallback to static hostname only if empty pretty hostname was already
+ * received.
+ */
+static const char *get_hostname(void)
+{
+ if (pretty_hostname) {
+ if (g_str_equal(pretty_hostname, "") == FALSE)
+ return pretty_hostname;
+
+ if (static_hostname &&
+ g_str_equal(static_hostname, "") == FALSE)
+ return static_hostname;
+ }
+
+ return NULL;
+}
static void update_name(struct btd_adapter *adapter, gpointer user_data)
{
- if (pretty_hostname == NULL)
+ const char *hostname = get_hostname();
+
+ if (hostname == NULL)
return;
if (btd_adapter_is_default(adapter)) {
- DBG("name: %s", pretty_hostname);
+ DBG("name: %s", hostname);
- adapter_set_name(adapter, pretty_hostname);
+ adapter_set_name(adapter, hostname);
} else {
uint16_t index = btd_adapter_get_index(adapter);
char *str;
/* Avoid "some device #0" names, start at #1 */
- str = g_strdup_printf("%s #%u", pretty_hostname, index + 1);
+ str = g_strdup_printf("%s #%u", hostname, index + 1);
DBG("name: %s", str);
@@ -122,6 +143,24 @@ static void property_changed(GDBusProxy *proxy, const char *name,
adapter_foreach(update_name, NULL);
}
+ } else if (g_str_equal(name, "StaticHostname") == TRUE) {
+ if (iter == NULL) {
+ g_dbus_proxy_refresh_property(proxy, name);
+ return;
+ }
+
+ if (dbus_message_iter_get_arg_type(iter) == DBUS_TYPE_STRING) {
+ const char *str;
+
+ dbus_message_iter_get_basic(iter, &str);
+
+ DBG("static hostname: %s", str);
+
+ g_free(static_hostname);
+ static_hostname = g_strdup(str);
+
+ adapter_foreach(update_name, NULL);
+ }
} else if (g_str_equal(name, "Chassis") == TRUE) {
if (iter == NULL) {
g_dbus_proxy_refresh_property(proxy, name);
@@ -277,6 +316,7 @@ static void hostname_exit(void)
}
g_free(pretty_hostname);
+ g_free(static_hostname);
}
BLUETOOTH_PLUGIN_DEFINE(hostname, VERSION, BLUETOOTH_PLUGIN_PRIORITY_DEFAULT,
--
1.8.1.2
^ permalink raw reply related
* cross-compilation setup
From: Randy Yates @ 2013-02-05 18:03 UTC (permalink / raw)
To: linux-bluetooth
Hi,
I'm trying to ./configure, make, and make install bluez 5.2 into my
embedded linux project. I have a few questions on where things are
placed, which I would think are specified in the configure stage. Here
is my skeleton configure.mak with the specific questions.
So, apart from --sysconfdir, I don't see the options in README to
specify what I need. Can someone please help?
--Randy
# Author: Randy Yates
# Function: Bluez ./configure makefile
#
# this is my bluez configuration makefile. i wanted to have the
# configuration options recorded somewhere, and a makefile seemed to be
# a good choice. make -f configure.mak
#
# requires the following variables
#
# TARGET_ROOTFS
# DEVELOPMENT_ROOTFS
# 1. what output does "make" generate? what executables, shared libraries, etc?
#
# 2. how do you specify the cross-compiler to use in make?
#
# 3. what does "make install" install?
#
# a. the output in 1? to where? (needs to go into $(TARGET_ROOTFS)/usr/bin)
#
# b. the .h and other developer files? to where? (needs to go into $(DEVELOPMENT_ROOTFS)/inc, $(DEVELOPMENT_ROOTFS)/lib, etc.
#
# c. documentation (manpages, etc.)? to where? (needs to go to /dev/null)
#
# d. what else and to where?
#
-include Rules.make
.PHONY += configure
configure :
./configure --prefix=/usr --sysconfdir=$(TARGET_ROOTFS)/rootfs-partial/etc --localstatedir=/var --disable-cups
--
Randy Yates
Digital Signal Labs
http://www.digitalsignallabs.com
^ permalink raw reply
* [PATCH v0] core: Fix racy D-Bus service name request
From: Mikel Astiz @ 2013-02-05 15:00 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Mikel Astiz
From: Mikel Astiz <mikel.astiz@bmw-carit.de>
The ObjectManager interface should already be ready by the time the
D-Bus service name is owned. Hence, use g_dbus_request_name() explicitly
once g_dbus_attach_object_manager() has finished.
Without this patch, clients relying on the presence of the ObjectManager
could potentially face a race condition.
---
src/main.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/src/main.c b/src/main.c
index 1e40ebc..12ae3d9 100644
--- a/src/main.c
+++ b/src/main.c
@@ -424,7 +424,7 @@ static int connect_dbus(void)
dbus_error_init(&err);
- conn = g_dbus_setup_bus(DBUS_BUS_SYSTEM, BLUEZ_NAME, &err);
+ conn = g_dbus_setup_bus(DBUS_BUS_SYSTEM, NULL, &err);
if (!conn) {
if (dbus_error_is_set(&err)) {
g_printerr("D-Bus setup failed: %s\n", err.message);
@@ -439,6 +439,12 @@ static int connect_dbus(void)
g_dbus_set_disconnect_function(conn, disconnected_dbus, NULL, NULL);
g_dbus_attach_object_manager(conn);
+ if (!g_dbus_request_name(conn, BLUEZ_NAME, &err)) {
+ g_printerr("D-Bus service name request failed: %s\n",
+ err.message);
+ return -EIO;
+ }
+
return 0;
}
--
1.8.1
^ permalink raw reply related
* [PATCH BlueZ] core: Remove unused code from device_browse_sdp()
From: Anderson Lizardo @ 2013-02-05 0:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
The "search" parameter was always NULL, and therefore code depending on
it being non-NULL will never be reached.
---
src/device.c | 23 ++++++++---------------
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/src/device.c b/src/device.c
index 49f8957..dbf0744 100644
--- a/src/device.c
+++ b/src/device.c
@@ -215,7 +215,7 @@ static const uint16_t uuid_list[] = {
static int device_browse_primary(struct btd_device *device, DBusMessage *msg,
gboolean secure);
static int device_browse_sdp(struct btd_device *device, DBusMessage *msg,
- uuid_t *search, gboolean reverse);
+ gboolean reverse);
static gboolean store_device_info_cb(gpointer user_data)
{
@@ -1143,7 +1143,7 @@ void device_add_eir_uuids(struct btd_device *dev, GSList *uuids)
static int device_resolve_svc(struct btd_device *dev, DBusMessage *msg)
{
if (device_is_bredr(dev))
- return device_browse_sdp(dev, msg, NULL, FALSE);
+ return device_browse_sdp(dev, msg, FALSE);
else
return device_browse_primary(dev, msg, FALSE);
}
@@ -3374,11 +3374,10 @@ done:
}
static int device_browse_sdp(struct btd_device *device, DBusMessage *msg,
- uuid_t *search, gboolean reverse)
+ gboolean reverse)
{
struct btd_adapter *adapter = device->adapter;
struct browse_req *req;
- bt_callback_t cb;
uuid_t uuid;
int err;
@@ -3387,17 +3386,11 @@ static int device_browse_sdp(struct btd_device *device, DBusMessage *msg,
req = g_new0(struct browse_req, 1);
req->device = btd_device_ref(device);
- if (search) {
- memcpy(&uuid, search, sizeof(uuid_t));
- cb = search_cb;
- } else {
- sdp_uuid16_create(&uuid, uuid_list[req->search_uuid++]);
- init_browse(req, reverse);
- cb = browse_cb;
- }
+ sdp_uuid16_create(&uuid, uuid_list[req->search_uuid++]);
+ init_browse(req, reverse);
err = bt_search_service(adapter_get_address(adapter), &device->bdaddr,
- &uuid, cb, req, NULL);
+ &uuid, browse_cb, req, NULL);
if (err < 0) {
browse_request_free(req);
return err;
@@ -3554,7 +3547,7 @@ static gboolean start_discovery(gpointer user_data)
struct btd_device *device = user_data;
if (device_is_bredr(device))
- device_browse_sdp(device, NULL, NULL, TRUE);
+ device_browse_sdp(device, NULL, TRUE);
else
device_browse_primary(device, NULL, FALSE);
@@ -3624,7 +3617,7 @@ void device_bonding_complete(struct btd_device *device, uint8_t status)
}
if (device_is_bredr(device))
- device_browse_sdp(device, bonding->msg, NULL, FALSE);
+ device_browse_sdp(device, bonding->msg, FALSE);
else
device_browse_primary(device, bonding->msg, FALSE);
--
1.7.9.5
^ permalink raw reply related
* Re: pull request: bluetooth 2013-02-01
From: John W. Linville @ 2013-02-04 21:41 UTC (permalink / raw)
To: Gustavo Padovan, linux-wireless, linux-bluetooth, linux-kernel
In-Reply-To: <20130201173302.GC4733@joana>
On Fri, Feb 01, 2013 at 03:33:02PM -0200, Gustavo Padovan wrote:
> Hi John,
>
> Two simple fixes for 3.8. One of the patches fixes a situation where the
> connection wasn't terminated if a timeout ocurrs for LE an SCO connections.
> The other fixes prevent NULL dereference in the SMP code, it is a security fix
> as well.
>
> Please pull, or let me know of any problems!
>
> Gustavo
>
> ---
> The following changes since commit b7e98b5100aad9290d7f06fcb9d1e80f7f62f05f:
>
> Bluetooth: Check if the hci connection exists in SCO shutdown (2013-01-10 03:53:32 -0200)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth for-upstream
>
> for you to fetch changes up to 4c02e2d444595200d0b18b889994aac3611cd288:
>
> Bluetooth: Fix hci_conn timeout routine (2013-01-31 15:38:02 -0200)
Pulling now...
--
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
* HFP/HSP Telephony profile doesn't work with Bluetooth USB dongle
From: Jonathan Kamens @ 2013-02-04 19:39 UTC (permalink / raw)
To: linux-bluetooth
Greetings,
Using Fedora 18 x86_64, I've tested two different USB Bluetooth dongles
(cheap generic Cambridge Silicon and more expensive BlueRigger BTD-400)
and two different headsets (Motorola SF600, BrainyTrade BH-M20), in all
combinations, the A2DP High-Fidelity profile for audio output works, but
the HFP/HSP Telephony profile does not.
I contacted BlueRigger about this and they tested for themselves on
different hardware and got the same result. BlueRigger says the HFP/HSP
Telephony profile works fine with Ubuntu, which they say doesn't use Bluez.
I don't know if this problem is new in Fedora 18, because I didn't get
the dongles until after I upgraded from Fedora 17.
I've reported this in Red Hat bugzilla
<https://bugzilla.redhat.com/show_bug.cgi?id=905283> and emailed the
Fedora test list
<http://lists.fedoraproject.org/pipermail/test/2013-February/113598.html> about
it; there has been no response to either.
Any suggestions or insights into how to resolve this issue would be
appreciated.
Regards,
Jonathan Kamens
^ permalink raw reply
* [PATCH v3 5/5] Bluetooth: Fallback transparent SCO from T2 to T1
From: Frédéric Dalleau @ 2013-02-04 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1359986188-24432-1-git-send-email-frederic.dalleau@linux.intel.com>
When initiating a transparent eSCO connection, make use of T2 settings at
first try. T2 is the recommended settings from HFP 1.6 WideBand Speech. Upon
connection failure, try T1 settings.
To know which of T2 or T1 should be used, the connection attempt index is used.
T2 failure is detected if Synchronous Connection Complete Event fails with
error 0x0d. This error code has been found experimentally by sending a T2
request to a T1 only SCO listener. It means "Connection Rejected due to
Limited resource".
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
net/bluetooth/hci_conn.c | 11 ++++++++++-
net/bluetooth/hci_event.c | 1 +
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 504367e..a3f4e29 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -179,12 +179,21 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
cp.tx_bandwidth = __constant_cpu_to_le32(0x00001f40);
cp.rx_bandwidth = __constant_cpu_to_le32(0x00001f40);
- if (test_and_clear_bit(HCI_CONN_SCO_TRANSPARENT, &conn->flags)) {
+ if (conn->attempt == 1 &&
+ test_bit(HCI_CONN_SCO_TRANSPARENT, &conn->flags)) {
cp.pkt_type = __constant_cpu_to_le16(EDR_ESCO_MASK &
~ESCO_2EV3);
cp.max_latency = __constant_cpu_to_le16(0x000d);
cp.voice_setting = __constant_cpu_to_le16(0x0003);
cp.retrans_effort = 0x02;
+ } else if (conn->attempt == 2 &&
+ test_bit(HCI_CONN_SCO_TRANSPARENT, &conn->flags)) {
+ cp.pkt_type = __constant_cpu_to_le16(EDR_ESCO_MASK |
+ ESCO_EV3);
+ cp.max_latency = __constant_cpu_to_le16(0x0007);
+ cp.voice_setting = __constant_cpu_to_le16(0x0003);
+ cp.retrans_effort = 0x02;
+ clear_bit(HCI_CONN_SCO_TRANSPARENT, &conn->flags);
} else {
cp.pkt_type = cpu_to_le16(conn->pkt_type);
cp.max_latency = __constant_cpu_to_le16(0xffff);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 3fd0212..6c1aec9 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -3330,6 +3330,7 @@ static void hci_sync_conn_complete_evt(struct hci_dev *hdev,
hci_conn_add_sysfs(conn);
break;
+ case 0x0d: /* No resource available */
case 0x11: /* Unsupported Feature or Parameter Value */
case 0x1c: /* SCO interval rejected */
case 0x1a: /* Unsupported Remote Feature */
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 4/5] Bluetooth: Parameters for outgoing SCO connections
From: Frédéric Dalleau @ 2013-02-04 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1359986188-24432-1-git-send-email-frederic.dalleau@linux.intel.com>
In order to establish a transparent SCO connection, the correct settings must
be specified in the SetupSynchronousConnection request. For that, a bit is set
in ACL connection flags to set up the desired parameters. If this bit is not
set, a legacy SCO connection will be requested.
This patch uses T2 settings.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
include/net/bluetooth/hci_core.h | 3 +++
net/bluetooth/hci_conn.c | 29 +++++++++++++++++++----------
net/bluetooth/sco.c | 3 +--
3 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index f3be454..4a216e5 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -443,6 +443,7 @@ enum {
HCI_CONN_SSP_ENABLED,
HCI_CONN_POWER_SAVE,
HCI_CONN_REMOTE_OOB,
+ HCI_CONN_SCO_TRANSPARENT,
};
static inline bool hci_conn_ssp_enabled(struct hci_conn *conn)
@@ -590,6 +591,8 @@ struct hci_chan *hci_chan_lookup_handle(struct hci_dev *hdev, __u16 handle);
struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
__u8 dst_type, __u8 sec_level, __u8 auth_type);
+struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
+ u8 mode);
int hci_conn_check_link_mode(struct hci_conn *conn);
int hci_conn_check_secure(struct hci_conn *conn, __u8 sec_level);
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 25bfce0..504367e 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -175,13 +175,22 @@ void hci_setup_sync(struct hci_conn *conn, __u16 handle)
conn->attempt++;
cp.handle = cpu_to_le16(handle);
- cp.pkt_type = cpu_to_le16(conn->pkt_type);
cp.tx_bandwidth = __constant_cpu_to_le32(0x00001f40);
cp.rx_bandwidth = __constant_cpu_to_le32(0x00001f40);
- cp.max_latency = __constant_cpu_to_le16(0xffff);
- cp.voice_setting = cpu_to_le16(hdev->voice_setting);
- cp.retrans_effort = 0xff;
+
+ if (test_and_clear_bit(HCI_CONN_SCO_TRANSPARENT, &conn->flags)) {
+ cp.pkt_type = __constant_cpu_to_le16(EDR_ESCO_MASK &
+ ~ESCO_2EV3);
+ cp.max_latency = __constant_cpu_to_le16(0x000d);
+ cp.voice_setting = __constant_cpu_to_le16(0x0003);
+ cp.retrans_effort = 0x02;
+ } else {
+ cp.pkt_type = cpu_to_le16(conn->pkt_type);
+ cp.max_latency = __constant_cpu_to_le16(0xffff);
+ cp.voice_setting = cpu_to_le16(hdev->voice_setting);
+ cp.retrans_effort = 0xff;
+ }
hci_send_cmd(hdev, HCI_OP_SETUP_SYNC_CONN, sizeof(cp), &cp);
}
@@ -551,13 +560,13 @@ static struct hci_conn *hci_connect_acl(struct hci_dev *hdev, bdaddr_t *dst,
return acl;
}
-static struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type,
- bdaddr_t *dst, u8 sec_level, u8 auth_type)
+struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type, bdaddr_t *dst,
+ u8 mode)
{
struct hci_conn *acl;
struct hci_conn *sco;
- acl = hci_connect_acl(hdev, dst, sec_level, auth_type);
+ acl = hci_connect_acl(hdev, dst, BT_SECURITY_LOW, HCI_AT_NO_BONDING);
if (IS_ERR(acl))
return acl;
@@ -575,6 +584,9 @@ static struct hci_conn *hci_connect_sco(struct hci_dev *hdev, int type,
hci_conn_hold(sco);
+ if (mode)
+ set_bit(HCI_CONN_SCO_TRANSPARENT, &sco->flags);
+
if (acl->state == BT_CONNECTED &&
(sco->state == BT_OPEN || sco->state == BT_CLOSED)) {
set_bit(HCI_CONN_POWER_SAVE, &acl->flags);
@@ -603,9 +615,6 @@ struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
return hci_connect_le(hdev, dst, dst_type, sec_level, auth_type);
case ACL_LINK:
return hci_connect_acl(hdev, dst, sec_level, auth_type);
- case SCO_LINK:
- case ESCO_LINK:
- return hci_connect_sco(hdev, type, dst, sec_level, auth_type);
}
return ERR_PTR(-EINVAL);
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 7fbb4c4..1d79a2e 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -176,8 +176,7 @@ static int sco_connect(struct sock *sk)
else
type = SCO_LINK;
- hcon = hci_connect(hdev, type, dst, BDADDR_BREDR, BT_SECURITY_LOW,
- HCI_AT_NO_BONDING);
+ hcon = hci_connect_sco(hdev, type, dst, sco_pi(sk)->mode);
if (IS_ERR(hcon)) {
err = PTR_ERR(hcon);
goto done;
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 3/5] Bluetooth: Use mode to create SCO connection
From: Frédéric Dalleau @ 2013-02-04 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1359986188-24432-1-git-send-email-frederic.dalleau@linux.intel.com>
When an incoming SCO connection is requested, check the selected mode, and
reply appropriately. Mode should have been negotiated previously. For example,
in case of HFP, the codec is negotiated using AT commands on the RFCOMM
channel. This patch only changes replies for socket with defered setup enabled.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
net/bluetooth/sco.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 7d57af5..7fbb4c4 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -656,7 +656,7 @@ static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
return err;
}
-static void sco_conn_defer_accept(struct hci_conn *conn, int mask)
+static void sco_conn_defer_accept(struct hci_conn *conn, int mask, int mode)
{
struct hci_dev *hdev = conn->hdev;
@@ -683,9 +683,22 @@ static void sco_conn_defer_accept(struct hci_conn *conn, int mask)
cp.tx_bandwidth = __constant_cpu_to_le32(0x00001f40);
cp.rx_bandwidth = __constant_cpu_to_le32(0x00001f40);
- cp.max_latency = __constant_cpu_to_le16(0xffff);
- cp.content_format = cpu_to_le16(hdev->voice_setting);
- cp.retrans_effort = 0xff;
+
+ switch (mode) {
+ case SCO_MODE_CVSD:
+ cp.max_latency = __constant_cpu_to_le16(0xffff);
+ cp.content_format = cpu_to_le16(hdev->voice_setting);
+ cp.retrans_effort = 0xff;
+ break;
+ case SCO_MODE_TRANSPARENT:
+ if (conn->pkt_type & ESCO_2EV3)
+ cp.max_latency = __constant_cpu_to_le16(0x0008);
+ else
+ cp.max_latency = __constant_cpu_to_le16(0x000D);
+ cp.content_format = __constant_cpu_to_le16(0x0003);
+ cp.retrans_effort = 0x02;
+ break;
+ }
hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ,
sizeof(cp), &cp);
@@ -702,7 +715,7 @@ static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
if (sk->sk_state == BT_CONNECT2 &&
test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
- sco_conn_defer_accept(pi->conn->hcon, 0);
+ sco_conn_defer_accept(pi->conn->hcon, 0, pi->mode);
sk->sk_state = BT_CONFIG;
release_sock(sk);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 2/5] Bluetooth: Add option for SCO socket mode
From: Frédéric Dalleau @ 2013-02-04 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
In-Reply-To: <1359986188-24432-1-git-send-email-frederic.dalleau@linux.intel.com>
This patch extends the current SCO socket option to add a 'mode' field. This
field is intended to choose data type at runtime. Current modes are CVSD and
transparent SCO, but adding new modes could allow support for CSA2 and fine
tuning a sco connection, for example latency, bandwith, voice setting. Incoming
connections will be setup during defered setup. Outgoing connections have to
be setup before connect(). The selected type is stored in the sco socket info.
This patch declares needed members, modifies getsockopt() and implements
setsockopt(). Setting the mtu is not supported.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
include/net/bluetooth/sco.h | 7 +++++
net/bluetooth/sco.c | 59 +++++++++++++++++++++++++++++++++++++++++++
2 files changed, 66 insertions(+)
diff --git a/include/net/bluetooth/sco.h b/include/net/bluetooth/sco.h
index 1e35c43..4de67ef 100644
--- a/include/net/bluetooth/sco.h
+++ b/include/net/bluetooth/sco.h
@@ -41,8 +41,14 @@ struct sockaddr_sco {
/* SCO socket options */
#define SCO_OPTIONS 0x01
+
+#define SCO_MODE_CVSD 0x00
+#define SCO_MODE_TRANSPARENT 0x01
+#define SCO_MODE_MAX 0x01
+
struct sco_options {
__u16 mtu;
+ __u8 mode;
};
#define SCO_CONNINFO 0x02
@@ -73,6 +79,7 @@ struct sco_conn {
struct sco_pinfo {
struct bt_sock bt;
__u32 flags;
+ __u8 mode;
struct sco_conn *conn;
};
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 97177be6..7d57af5 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -418,6 +418,8 @@ static struct sock *sco_sock_alloc(struct net *net, struct socket *sock, int pro
sk->sk_protocol = proto;
sk->sk_state = BT_OPEN;
+ sco_pi(sk)->mode = SCO_MODE_CVSD;
+
setup_timer(&sk->sk_timer, sco_sock_timeout, (unsigned long)sk);
bt_sock_link(&sco_sk_list, sk);
@@ -712,6 +714,59 @@ static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
return bt_sock_recvmsg(iocb, sock, msg, len, flags);
}
+static int sco_sock_setsockopt_old(struct socket *sock, int optname,
+ char __user *optval, unsigned int optlen)
+{
+ struct sock *sk = sock->sk;
+ struct sco_options opts;
+ int len, err = 0;
+
+ BT_DBG("sk %p", sk);
+
+ lock_sock(sk);
+
+ switch (optname) {
+ case SCO_OPTIONS:
+ if (sk->sk_state != BT_OPEN &&
+ sk->sk_state != BT_BOUND &&
+ sk->sk_state != BT_CONNECT2) {
+ err = -EINVAL;
+ break;
+ }
+
+ opts.mtu = 0;
+ opts.mode = SCO_MODE_CVSD;
+
+ len = min_t(unsigned int, sizeof(opts), optlen);
+ if (copy_from_user((char *) &opts, optval, len)) {
+ err = -EFAULT;
+ break;
+ }
+
+ if (opts.mtu != 0) {
+ err = -EINVAL;
+ break;
+ }
+
+ BT_DBG("mode %d", opts.mode);
+
+ if (opts.mode > SCO_MODE_MAX) {
+ err = -EINVAL;
+ break;
+ }
+
+ sco_pi(sk)->mode = opts.mode;
+ break;
+
+ default:
+ err = -ENOPROTOOPT;
+ break;
+ }
+
+ release_sock(sk);
+ return err;
+}
+
static int sco_sock_setsockopt(struct socket *sock, int level, int optname, char __user *optval, unsigned int optlen)
{
struct sock *sk = sock->sk;
@@ -720,6 +775,9 @@ static int sco_sock_setsockopt(struct socket *sock, int level, int optname, char
BT_DBG("sk %p", sk);
+ if (level == SOL_SCO)
+ return sco_sock_setsockopt_old(sock, optname, optval, optlen);
+
lock_sock(sk);
switch (optname) {
@@ -772,6 +830,7 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname, char __user
}
opts.mtu = sco_pi(sk)->conn->mtu;
+ opts.mode = sco_pi(sk)->mode;
BT_DBG("mtu %d", opts.mtu);
--
1.7.9.5
^ permalink raw reply related
* [PATCH v3 1/5] Bluetooth: Move and rename hci_conn_accept
From: Frédéric Dalleau @ 2013-02-04 13:56 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Frédéric Dalleau
Since this function is only used by sco, move it from hci_event.c to
sco.c and rename to sco_conn_defer_accept.
Signed-off-by: Frédéric Dalleau <frederic.dalleau@linux.intel.com>
---
include/net/bluetooth/hci_core.h | 1 -
net/bluetooth/hci_event.c | 36 ------------------------------------
net/bluetooth/sco.c | 38 +++++++++++++++++++++++++++++++++++++-
3 files changed, 37 insertions(+), 38 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 90cf75a..f3be454 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -582,7 +582,6 @@ struct hci_conn *hci_conn_add(struct hci_dev *hdev, int type, bdaddr_t *dst);
int hci_conn_del(struct hci_conn *conn);
void hci_conn_hash_flush(struct hci_dev *hdev);
void hci_conn_check_pending(struct hci_dev *hdev);
-void hci_conn_accept(struct hci_conn *conn, int mask);
struct hci_chan *hci_chan_create(struct hci_conn *conn);
void hci_chan_del(struct hci_chan *chan);
diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index d4fcba6..3fd0212 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -2095,42 +2095,6 @@ unlock:
hci_conn_check_pending(hdev);
}
-void hci_conn_accept(struct hci_conn *conn, int mask)
-{
- struct hci_dev *hdev = conn->hdev;
-
- BT_DBG("conn %p", conn);
-
- conn->state = BT_CONFIG;
-
- if (!lmp_esco_capable(hdev)) {
- struct hci_cp_accept_conn_req cp;
-
- bacpy(&cp.bdaddr, &conn->dst);
-
- if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
- cp.role = 0x00; /* Become master */
- else
- cp.role = 0x01; /* Remain slave */
-
- hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp);
- } else /* lmp_esco_capable(hdev)) */ {
- struct hci_cp_accept_sync_conn_req cp;
-
- bacpy(&cp.bdaddr, &conn->dst);
- cp.pkt_type = cpu_to_le16(conn->pkt_type);
-
- cp.tx_bandwidth = __constant_cpu_to_le32(0x00001f40);
- cp.rx_bandwidth = __constant_cpu_to_le32(0x00001f40);
- cp.max_latency = __constant_cpu_to_le16(0xffff);
- cp.content_format = cpu_to_le16(hdev->voice_setting);
- cp.retrans_effort = 0xff;
-
- hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ,
- sizeof(cp), &cp);
- }
-}
-
static void hci_conn_request_evt(struct hci_dev *hdev, struct sk_buff *skb)
{
struct hci_ev_conn_request *ev = (void *) skb->data;
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index e435641..97177be6 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -654,6 +654,42 @@ static int sco_sock_sendmsg(struct kiocb *iocb, struct socket *sock,
return err;
}
+static void sco_conn_defer_accept(struct hci_conn *conn, int mask)
+{
+ struct hci_dev *hdev = conn->hdev;
+
+ BT_DBG("conn %p", conn);
+
+ conn->state = BT_CONFIG;
+
+ if (!lmp_esco_capable(hdev)) {
+ struct hci_cp_accept_conn_req cp;
+
+ bacpy(&cp.bdaddr, &conn->dst);
+
+ if (lmp_rswitch_capable(hdev) && (mask & HCI_LM_MASTER))
+ cp.role = 0x00; /* Become master */
+ else
+ cp.role = 0x01; /* Remain slave */
+
+ hci_send_cmd(hdev, HCI_OP_ACCEPT_CONN_REQ, sizeof(cp), &cp);
+ } else /* lmp_esco_capable(hdev)) */ {
+ struct hci_cp_accept_sync_conn_req cp;
+
+ bacpy(&cp.bdaddr, &conn->dst);
+ cp.pkt_type = cpu_to_le16(conn->pkt_type);
+
+ cp.tx_bandwidth = __constant_cpu_to_le32(0x00001f40);
+ cp.rx_bandwidth = __constant_cpu_to_le32(0x00001f40);
+ cp.max_latency = __constant_cpu_to_le16(0xffff);
+ cp.content_format = cpu_to_le16(hdev->voice_setting);
+ cp.retrans_effort = 0xff;
+
+ hci_send_cmd(hdev, HCI_OP_ACCEPT_SYNC_CONN_REQ,
+ sizeof(cp), &cp);
+ }
+}
+
static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
struct msghdr *msg, size_t len, int flags)
{
@@ -664,7 +700,7 @@ static int sco_sock_recvmsg(struct kiocb *iocb, struct socket *sock,
if (sk->sk_state == BT_CONNECT2 &&
test_bit(BT_SK_DEFER_SETUP, &bt_sk(sk)->flags)) {
- hci_conn_accept(pi->conn->hcon, 0);
+ sco_conn_defer_accept(pi->conn->hcon, 0);
sk->sk_state = BT_CONFIG;
release_sock(sk);
--
1.7.9.5
^ permalink raw reply related
* Re: Kernel Oops caused by high uart write loads
From: Thomas Gleixner @ 2013-02-04 11:44 UTC (permalink / raw)
To: Belser Florian
Cc: 'linux-rt-users@vger.kernel.org', linux-serial,
linux-bluetooth
In-Reply-To: <5EC8D4ACC923FE4D871AFFACC976127959E1C3@stwexdb.stww2k.local>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3080 bytes --]
On Wed, 30 Jan 2013, Belser Florian wrote:
> I'm running 3.4.17-rt28 on my mpc5200 based system. The complete
> system works pretty good until I select the "Fully Preemptible
> Kernel" option in the kernel settings. In that case, if I generate
> a high uart write load (sending a lot of stuff via Bluetooth) I get
> the following kernel Oops:
> # ------------[ cut here ]------------
> Kernel BUG at c03d1728 [verbose debug info unavailable]
I bet this is: BUG_ON(rt_mutex_owner(lock) == self);
> Oops: Exception in kernel mode, sig: 5 [#1]
> PREEMPT mpc5200-simple-platform
> Modules linked in:
> NIP: c03d1728 LR: c03d170c CTR: c01efc78
> REGS: c716fd30 TRAP: 0700 Not tainted (3.4.17-rt28/STW-V3.00r0+)
> MSR: 00029032 <EE,ME,IR,DR,RI> CR: 88002022 XER: 00000000
> TASK = c7125880[633] 'irq/129-mpc52xx' THREAD: c716e000
> GPR00: 00000001 c716fde0 c7125880 00000000 c7125880 00000000 00000001 00000000
> GPR08: c7125880 c7125880 c7125880 c7125881 88002022 fbfdffff 07fff000 00000004
> GPR16: 00000024 00000000 000000c0 00000000 c0537e70 00000004 00000000 00000004
> GPR24: c716ad5c c0537e8c c7a73000 00000000 c7bb2a00 c7125880 c78b9800 c0537e8c
> NIP [c03d1728] rt_spin_lock_slowlock+0x78/0x1e0
> LR [c03d170c] rt_spin_lock_slowlock+0x5c/0x1e0
> Call Trace:
> [c716fde0] [c03d170c] rt_spin_lock_slowlock+0x5c/0x1e0 (unreliable)
> [c716fe40] [c01efcd4] uart_write+0x5c/0x114
> [c716fe70] [c028f3f4] hci_uart_tx_wakeup+0xe0/0x1fc
> [c716fea0] [c01d3398] tty_wakeup+0x78/0xac
> [c716feb0] [c01ee9e0] uart_write_wakeup+0x24/0x34
> [c716fec0] [c01f1c38] mpc52xx_psc_handle_irq+0x3f8/0x4b0
> [c716ff20] [c01f13e4] mpc52xx_uart_int+0x38/0x60
> [c716ff30] [c005f660] irq_forced_thread_fn+0x38/0x9c
> [c716ff50] [c005f42c] irq_thread+0x13c/0x1c0
> [c716ff90] [c00391d4] kthread+0x8c/0x90
> [c716fff0] [c000dd4c] kernel_thread+0x4c/0x68
> Instruction dump:
> 7fe3fb78 7fa4eb78 38a00000 38c00001 4bc86591 2f830000 409e0134 801f0018
> 5400003c 7fa00278 7c000034 5400d97e <0f000000> 3bdd0418 3b810008 7fc3f378
> If I switch the preemption modelt o "Preemptible Kernel (Basic RT)"
> everything works fine.
By some definition of works. It works w/o RT_FULL because locks are
NOPs on uniprocessor, except you enable lock debugging.
This is a classic recursive dead lock. If you enable
CONFIG_PROVE_LOCKING, then you should see the same issue even on a
completely unpatched mainline kernel.
> Hope someone already had the same or similar problem and can help me solving it.
> Maybe a update to 3.4.27-rt39 helps?
No, wont help.
The problem is:
mpc52xx_uart_int()
lock(port->lock);
mpc52xx_psc_handle_irq()
mpc52xx_uart_int_tx_chars()
uart_write_wakeup()
tty_wakeup()
hci_uart_tx_wakeup()
len = tty->ops->write(tty, skb->data, skb->len);
The associated write function is uart_write
uart_write()
lock(port->lock) --> deadlock
I have no idea how that bluetooth "uart" gets connected to the
physical uart, but the backtrace is pretty obvious. What are you doing
to reproduce this?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH BlueZ] AVRCP: Handler player features as a byte array
From: Luiz Augusto von Dentz @ 2013-02-04 9:42 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <1359970052.6873.23.camel@aeonflux>
Hi Marcel,
On Mon, Feb 4, 2013 at 3:27 AM, Marcel Holtmann <marcel@holtmann.org> wrote:
> Hi Luiz,
>
>> >> --- a/profiles/audio/player.c
>> >> +++ b/profiles/audio/player.c
>> >> @@ -67,7 +67,7 @@ struct media_player {
>> >> char *name; /* Player name */
>> >> char *type; /* Player type */
>> >> char *subtype; /* Player subtype */
>> >> - uint64_t features[2]; /* Player features */
>> >> + uint8_t *features; /* Player features */
>> >
>> > Why not just have this as features[16] here as well so you don't need to
>> > do g_memdup and g_free?
>>
>> I was planning to have a NULL check if the features are valid.
>
> actually I like to decrease the number of extra memory allocations. So
> what benefit is the test for features giving you actually.
I would use it to differentiate players which can provide this
information from those who don't, for certain commands we can reject
based on the features but it has to be valid otherwise we just don't
know if it is supported and should send the command anyway.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ] AVRCP: Handler player features as a byte array
From: Marcel Holtmann @ 2013-02-04 9:27 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABBYNZ+u55P_TVMUEcfwJkc9KpT2GVnYjZzG6RuFVfWhReGpsg@mail.gmail.com>
Hi Luiz,
> >> --- a/profiles/audio/player.c
> >> +++ b/profiles/audio/player.c
> >> @@ -67,7 +67,7 @@ struct media_player {
> >> char *name; /* Player name */
> >> char *type; /* Player type */
> >> char *subtype; /* Player subtype */
> >> - uint64_t features[2]; /* Player features */
> >> + uint8_t *features; /* Player features */
> >
> > Why not just have this as features[16] here as well so you don't need to
> > do g_memdup and g_free?
>
> I was planning to have a NULL check if the features are valid.
actually I like to decrease the number of extra memory allocations. So
what benefit is the test for features giving you actually.
Regards
Marcel
^ permalink raw reply
* Re: [PATCH BlueZ] AVRCP: Handler player features as a byte array
From: Luiz Augusto von Dentz @ 2013-02-04 8:34 UTC (permalink / raw)
To: Luiz Augusto von Dentz, linux-bluetooth@vger.kernel.org
In-Reply-To: <20130204083030.GA1147@x220>
Hi Johan,
On Mon, Feb 4, 2013 at 2:30 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Luiz,
>
> On Sun, Feb 03, 2013, Luiz Augusto von Dentz wrote:
>> --- a/profiles/audio/player.c
>> +++ b/profiles/audio/player.c
>> @@ -67,7 +67,7 @@ struct media_player {
>> char *name; /* Player name */
>> char *type; /* Player type */
>> char *subtype; /* Player subtype */
>> - uint64_t features[2]; /* Player features */
>> + uint8_t *features; /* Player features */
>
> Why not just have this as features[16] here as well so you don't need to
> do g_memdup and g_free?
I was planning to have a NULL check if the features are valid.
--
Luiz Augusto von Dentz
^ permalink raw reply
* Re: [PATCH BlueZ] AVRCP: Handler player features as a byte array
From: Johan Hedberg @ 2013-02-04 8:30 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1359924910-27167-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Sun, Feb 03, 2013, Luiz Augusto von Dentz wrote:
> --- a/profiles/audio/player.c
> +++ b/profiles/audio/player.c
> @@ -67,7 +67,7 @@ struct media_player {
> char *name; /* Player name */
> char *type; /* Player type */
> char *subtype; /* Player subtype */
> - uint64_t features[2]; /* Player features */
> + uint8_t *features; /* Player features */
Why not just have this as features[16] here as well so you don't need to
do g_memdup and g_free?
Johan
^ permalink raw reply
* rfcomm connection reset by peer 104
From: Zheng, Wu @ 2013-02-04 3:25 UTC (permalink / raw)
To: linux-bluetooth@vger.kernel.org
Hi all,
I use bluez-4.101 and obexd-0.46 and Linux kernel is 2.6.35 on a device to implement OPP server.
Obexd runs well on the device.
When I send a file by obex-client to the device, the connection reset by peer 104 error is reported.
Client OPP:
obex-client[1109]: client/bluetooth.c: transport_connect() port 9
obex-client[1109]: client/bluetooth.c: transport_callback()
obex-client[1109]: client/session.c : transport_func()
obex-client[1109]: Connection reset by peer (104)
Server OPP:
Obexd: nothing info is printed
Can somebody provide some hints? Thanks
Best Regards
Zheng Wu
^ permalink raw reply
* [PATCH BlueZ 3/3] lib: Check if SDP buffer has enough data on partial responses
From: Anderson Lizardo @ 2013-02-04 1:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1359940845-14451-1-git-send-email-anderson.lizardo@openbossa.org>
Before manipulating data from previous partial responses, make sure the
buffer has enough data.
---
lib/sdp.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/lib/sdp.c b/lib/sdp.c
index e212c29..3855381 100644
--- a/lib/sdp.c
+++ b/lib/sdp.c
@@ -4144,7 +4144,7 @@ int sdp_process(sdp_session_t *session)
if (t->rsp_concat_buf.data_size == 0) {
/* first fragment */
rsp_count = sizeof(tsrc) + sizeof(csrc) + csrc * 4;
- } else {
+ } else if (t->rsp_concat_buf.data_size >= sizeof(uint16_t) * 2) {
/* point to the first csrc */
uint8_t *pcsrc = t->rsp_concat_buf.data + 2;
uint16_t tcsrc, tcsrc2;
@@ -4161,6 +4161,11 @@ int sdp_process(sdp_session_t *session)
pdata += sizeof(uint16_t); /* point to the first handle */
rsp_count = csrc * 4;
+ } else {
+ t->err = EPROTO;
+ SDPERR("Protocol error: invalid PDU size");
+ status = SDP_INVALID_PDU_SIZE;
+ goto end;
}
status = 0x0000;
break;
--
1.7.9.5
^ permalink raw reply related
* [PATCH BlueZ 2/3] lib: Add range check for SDP_SVC_ATTR_RSP/SDP_SVC_SEARCH_ATTR_RSP
From: Anderson Lizardo @ 2013-02-04 1:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1359940845-14451-1-git-send-email-anderson.lizardo@openbossa.org>
According to SDP spec, the byte count fields for these PDUs have a valid
range of 0x0002-0xFFFF.
---
lib/sdp.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/lib/sdp.c b/lib/sdp.c
index f3a0c17..e212c29 100644
--- a/lib/sdp.c
+++ b/lib/sdp.c
@@ -4169,6 +4169,14 @@ int sdp_process(sdp_session_t *session)
rsp_count = bt_get_be16(pdata);
SDPDBG("Attrlist byte count : %d\n", rsp_count);
+ /* Valid range for rsp_count is 0x0002-0xFFFF */
+ if (rsp_count < 0x0002) {
+ t->err = EPROTO;
+ SDPERR("Protocol error: invalid AttrList size");
+ status = SDP_INVALID_PDU_SIZE;
+ goto end;
+ }
+
/*
* Number of bytes in the AttributeLists parameter(without
* continuation state) + AttributeListsByteCount field size.
--
1.7.9.5
^ permalink raw reply related
* [PATCH BlueZ 1/3] lib: Fix buffer overflow when processing SDP response
From: Anderson Lizardo @ 2013-02-04 1:20 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1359940845-14451-1-git-send-email-anderson.lizardo@openbossa.org>
rsp_count is either read or calculated from untrusted input, and
therefore needs to be checked before being used as offset. The "plen"
variable is appropriate because it is calculated as the sum of fixed and
variable length fields, excluding the continuation state field, which
has at least 1 byte for its own length field.
---
lib/sdp.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/lib/sdp.c b/lib/sdp.c
index b87f392..f3a0c17 100644
--- a/lib/sdp.c
+++ b/lib/sdp.c
@@ -4189,6 +4189,17 @@ int sdp_process(sdp_session_t *session)
goto end;
}
+ /*
+ * Out of bound check before using rsp_count as offset for continuation
+ * state, which has at least a one byte size field.
+ */
+ if ((n - (int) sizeof(sdp_pdu_hdr_t)) < plen + 1) {
+ t->err = EPROTO;
+ SDPERR("Protocol error: invalid PDU size");
+ status = SDP_INVALID_PDU_SIZE;
+ goto end;
+ }
+
pcstate = (sdp_cstate_t *) (pdata + rsp_count);
SDPDBG("Cstate length : %d\n", pcstate->length);
--
1.7.9.5
^ 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