* Re: [RFC 06/16] Change DiscoverSchedulerInterval default value
From: Luiz Augusto von Dentz @ 2011-05-02 7:48 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1304123252-14464-7-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
<andre.guedes@openbossa.org> wrote:
> This patch changes the default value of "DiscoverSchedulerInterval"
> from 0 to 30 seconds.
>
> Since Periodic Inquiry is not supported anymore, the option
> "DiscoverSchedulerInterval" in main.conf must be updated. As
> a first attempt, it was chosen a 30 seconds interval.
> ---
> src/main.conf | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/src/main.conf b/src/main.conf
> index c03f135..8cd132f 100644
> --- a/src/main.conf
> +++ b/src/main.conf
> @@ -27,8 +27,8 @@ PairableTimeout = 0
> PageTimeout = 8192
>
> # Discover scheduler interval used in Adapter.DiscoverDevices
> -# The value is in seconds. Defaults is 0 to use controller scheduler.
> -DiscoverSchedulerInterval = 0
> +# The value is in seconds. Defaults is 30.
> +DiscoverSchedulerInterval = 30
>
> # What value should be assumed for the adapter Powered property when
> # SetProperty(Powered, ...) hasn't been called yet. Defaults to true
Im not sure how you came up with 30 sec, IMO it is too long and
doesn't specify how long we inquiry/scan/resolve names.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: Status of MAP and AVRCP
From: Henrik Höglind @ 2011-05-02 7:51 UTC (permalink / raw)
To: linux-bluetooth
Hi David,
> I restarted work-in-earnest on an AVRCP layer a bit over two months ago
> [...]
> I will complete fairly extensive testing and begin submitting patches with
> major surgery to audio/control.c, supporting the API doc worked out in the
> Portland meeting, with a couple of minor extensions. This will bring BlueZ
>to AVRCP 1.3, figure by the end of this month.
Have you made any progress with the avrcp v1.3 implementation? Judging
from the messages on the list, there seems to be a lot of interest for
this update. We are also awaiting this, and would be happy to help if
there is something we can do.
Best regards,
Henrik
^ permalink raw reply
* [PATCH] Bluetooth: Double check sec req for pre 2.1 device
From: Waldemar Rymarkiewicz @ 2011-05-02 8:09 UTC (permalink / raw)
To: padovan, Johan Hedberg; +Cc: linux-bluetooth, Waldemar Rymarkiewicz
In case of pre v2.1 devices authentication request will return
success immediately if the link key already exists without any
authentication process.
That means, it's not possible to re-authenticate the link if you
already have combination key and for instance want to re-authenticate
to get the high security (use 16 digit pin).
Therefore, it's necessary to check security requirements on auth
complete event to prevent not enough secure connection.
Signed-off-by: Waldemar Rymarkiewicz <waldemar.rymarkiewicz@tieto.com>
---
include/net/bluetooth/hci_core.h | 4 +++-
net/bluetooth/hci_conn.c | 17 +++++++++++++++++
net/bluetooth/rfcomm/core.c | 2 +-
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index 14cc324..69ff0a4 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -420,9 +420,11 @@ 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);
-struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst, __u8 sec_level, __u8 auth_type);
+struct hci_conn *hci_connect(struct hci_dev *hdev, int type, bdaddr_t *dst,
+ __u8 sec_level, __u8 auth_type);
int hci_conn_check_link_mode(struct hci_conn *conn);
int hci_conn_security(struct hci_conn *conn, __u8 sec_level, __u8 auth_type);
+int hci_conn_accept_secure(struct hci_conn *conn, __u8 sec_level);
int hci_conn_change_link_key(struct hci_conn *conn);
int hci_conn_switch_role(struct hci_conn *conn, __u8 role);
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 7f5ad8a..b79d004 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -623,6 +623,23 @@ encrypt:
}
EXPORT_SYMBOL(hci_conn_security);
+/* Check secure link requirement */
+int hci_conn_accept_secure(struct hci_conn *conn, __u8 sec_level)
+{
+ BT_DBG("conn %p", conn);
+
+ if (sec_level != BT_SECURITY_HIGH)
+ return 1; /* Accept if non-secure is required */
+
+ if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
+ (conn->key_type == HCI_LK_COMBINATION &&
+ conn->pin_length == 16))
+ return 1;
+
+ return 0; /* Reject not secure link */
+}
+EXPORT_SYMBOL(hci_conn_accept_secure);
+
/* Change link key */
int hci_conn_change_link_key(struct hci_conn *conn)
{
diff --git a/net/bluetooth/rfcomm/core.c b/net/bluetooth/rfcomm/core.c
index 121a5c1..7de329c 100644
--- a/net/bluetooth/rfcomm/core.c
+++ b/net/bluetooth/rfcomm/core.c
@@ -2096,7 +2096,7 @@ static void rfcomm_security_cfm(struct hci_conn *conn, u8 status, u8 encrypt)
if (!test_and_clear_bit(RFCOMM_AUTH_PENDING, &d->flags))
continue;
- if (!status)
+ if (!status && hci_conn_accept_secure(conn, d->sec_level))
set_bit(RFCOMM_AUTH_ACCEPT, &d->flags);
else
set_bit(RFCOMM_AUTH_REJECT, &d->flags);
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] Bluetooth: Double check sec req for pre 2.1 device
From: Waldemar.Rymarkiewicz @ 2011-05-02 8:19 UTC (permalink / raw)
To: padovan, johan.hedberg; +Cc: linux-bluetooth
In-Reply-To: <1304323758-9668-1-git-send-email-waldemar.rymarkiewicz@tieto.com>
Hi,
>+int hci_conn_accept_secure(struct hci_conn *conn, __u8 sec_level) {
>+ BT_DBG("conn %p", conn);
>+
>+ if (sec_level != BT_SECURITY_HIGH)
>+ return 1; /* Accept if non-secure is required */
>+
>+ if (conn->key_type == HCI_LK_AUTH_COMBINATION ||
>+ (conn->key_type == HCI_LK_COMBINATION &&
>+ conn->pin_length == 16))
Checking againt conn->sec_level is tricky. This function is called indirectly by hci_auth_complete_evt which first sets sec_level to pending_sec_level even for pre-2.1 units. Thus, this always will return true while re-authentication of pre-2.1 devices because sec_level is already updated with the pending one.
I've tried to check, in hci_auth_complete_evt, if we deal with pre-2.1 dev and if a link key already exists and then set sec_level, but the link key in this point always exists.
Any suggestions how to solve this? A new flag in conn->pre21_reauth?
Thanks,
Waldek
^ permalink raw reply
* Re: [RFC 00/16] Discovery procedure refactoring
From: Luiz Augusto von Dentz @ 2011-05-02 8:39 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1304123252-14464-1-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
<andre.guedes@openbossa.org> wrote:
> Hi all,
>
> Today, discovery procedure is supported only in hciops. This refactoring has
> been done to provide easier implementation of discovery procedure in mgmtops.
> Lots of effort would be necessary to implement discovery procedure in mgmtops
> because its logic is spread out adapter layer and hciops layer.
>
> The approach this patchset follows is moving all logic related to discovery
> procedure from adapter layer to hciops layer.
>
> Future work will be:
> - full support for discovery procedure (BR/EDR, LE-Only, BR/EDR/LE
> devices) in kernel via management interface (today, only BR/EDR is
> supported).
> - name resolving support through mgmt interface (kernel + userspace)
>
> Thanks,
> Guedes.
>
> Anderson Briglia (1):
> Implement mgmt start and stop discovery
>
> Andre Guedes (15):
> Add discovery callbacks to btd_adapter_ops
> Replace inquiry/scanning calls by discovery calls
> Add 'discov_state' field to struct dev_info
> Code cleanup event.c
> Remove Periodic Inquiry support in hciops
> Change DiscoverSchedulerInterval default value
> Add 'timeout' param to start_scanning callback
> Refactoring adapter_set_state()
> Remove 'suspend' param from stop_discovery()
> Add extfeatures to struct dev_info
> Implement start_discovery hciops callback
> Remove obsolete code.
> Implement stop_discovery hciops callback
> Remove inquiry and scanning callbacks from btd_adapter_ops
> Remove 'periodic' param from hciops_start_inquiry()
>
> plugins/hciops.c | 373 ++++++++++++++++++++++++++++++++++++-----------------
> plugins/mgmtops.c | 35 ++----
> src/adapter.c | 217 ++++++++++---------------------
> src/adapter.h | 19 +--
> src/event.c | 48 +-------
> src/event.h | 1 -
> src/main.conf | 4 +-
> 7 files changed, 345 insertions(+), 352 deletions(-)
How do we solve the problem with command failing to restart
inquiring/scanning, with pinq we only need to send the command once
and if it fails we can signal the error back to the client, but if we
are sending commands every round they may fail (buggy hardware) and
currently we have no way to notify the client if discovery session
failed after it has been started.
Im afraid because of dual mode adapters we may need to change the
D-Bus API in the future and have the client to specify somehow on
StartDiscovery if LE only, BR/EDR only or both like connman does with
RequestScan, otherwise it may take too long (each cycle taking 20-30
seconds) to discover devices because it wasting time scanning or
resolving names in the wrong technology.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [RFC 09/16] Remove 'suspend' param from stop_discovery()
From: Luiz Augusto von Dentz @ 2011-05-02 8:42 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1304123252-14464-10-git-send-email-andre.guedes@openbossa.org>
Hi Andre,
On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
<andre.guedes@openbossa.org> wrote:
> This patch removes 'suspend' parameter from stop_discovery() in adapter.c.
>
> This parameter is useless since new a function (suspend_discovery) was
> created to suspend discovery sessions.
> ---
> src/adapter.c | 9 ++++-----
> 1 files changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/src/adapter.c b/src/adapter.c
> index 6a2a8c1..0279494 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -700,12 +700,11 @@ static GSList *remove_bredr(GSList *all)
> return le;
> }
>
> -static void stop_discovery(struct btd_adapter *adapter, gboolean suspend)
> +static void stop_discovery(struct btd_adapter *adapter)
> {
> pending_remote_name_cancel(adapter);
>
> - if (suspend == FALSE)
> - adapter->found_devices = remove_bredr(adapter->found_devices);
> + adapter->found_devices = remove_bredr(adapter->found_devices);
>
> if (adapter->oor_devices) {
> g_slist_free(adapter->oor_devices);
> @@ -762,7 +761,7 @@ static void session_remove(struct session_req *req)
>
> DBG("Stopping discovery");
>
> - stop_discovery(adapter, FALSE);
> + stop_discovery(adapter);
> }
> }
>
> @@ -2537,7 +2536,7 @@ int btd_adapter_stop(struct btd_adapter *adapter)
> /* check pending requests */
> reply_pending_requests(adapter);
>
> - stop_discovery(adapter, FALSE);
> + stop_discovery(adapter);
>
> if (adapter->disc_sessions) {
> g_slist_foreach(adapter->disc_sessions, (GFunc) session_free,
> --
What happened with stop_discovery called within suspend_discovery? We
need to avoid cleaning up the list of found devices otherwise we won't
be able to send DeviceDisappeared properly when discovery got resume.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* Re: [RFC 00/16] Discovery procedure refactoring
From: Anderson Lizardo @ 2011-05-02 14:01 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: Andre Guedes, linux-bluetooth
In-Reply-To: <BANLkTin7oCB9L0S0_kjESF6SfMfaqjwMtA@mail.gmail.com>
Hi Luiz,
On Mon, May 2, 2011 at 4:39 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Im afraid because of dual mode adapters we may need to change the
> D-Bus API in the future and have the client to specify somehow on
> StartDiscovery if LE only, BR/EDR only or both like connman does with
> RequestScan, otherwise it may take too long (each cycle taking 20-30
> seconds) to discover devices because it wasting time scanning or
> resolving names in the wrong technology.
On dual mode devices, there is a specific procedure (defined by the
Core spec) for discovery, called "interleaved discovery" where BR/EDR
and LE discovery procedures are alternated at specific times. It
cannot just do BR/EDR or LE, unless we want to "fake" a single mode
adapter.
In summary, if the adapter is to work as a compliant dual mode device,
it shall use the interleaved discovery procedure. BR/EDR only or LE
only discovery would only be acceptable for single mode adapters. We
could as well have configuration options to "simulate" single mode on
dual mode adapters.
HTH,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* RE: [PATCH 1/2] Add secure param to Mgmt PIN Code Request Event
From: Marcel Holtmann @ 2011-05-02 15:31 UTC (permalink / raw)
To: Waldemar.Rymarkiewicz; +Cc: linux-bluetooth, johan.hedberg
In-Reply-To: <99B09243E1A5DA4898CDD8B70011144816F29AF32A@EXMB04.eu.tieto.com>
Hi Waldemar,
> >> @@ -482,6 +482,7 @@ PIN Code Request Event
> >> Event Code 0x000E
> >> Controller Index: <controller id>
> >> Event Parameters Address (6 Octets)
> >> + Secure (1 Octet)
> >
> >we do need to document possible values and their meanings. Is
> >this a boolean or is this suppose to indicate the PIN code length?
>
> It's boolean.
> Do you mean something like this?
>
> Event Code 0x000E
> Controller Index: <controller id>
> Event Parameters Address (6 Octets)
> Secure (1 Octet)
>
> Secure: 0x01 16 digit PIN code required
> 0x00 16 digit PIN code not required
yes, we need these things documented.
Obviously now the question is why not expose this as min_pin_length
value?
Regards
Marcel
^ permalink raw reply
* Re: [PATCH] Move hid2hci to /lib/udev
From: Johan Hedberg @ 2011-05-02 16:26 UTC (permalink / raw)
To: Kay Sievers; +Cc: linux-bluetooth
In-Reply-To: <1304029945.27065.1.camel@zag>
Hi Kay,
On Fri, Apr 29, 2011, Kay Sievers wrote:
> ---
> Makefile.am | 2 +-
> Makefile.tools | 4 +++-
> acinclude.m4 | 10 ++++------
> 3 files changed, 8 insertions(+), 8 deletions(-)
The patch has been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix crash when calling finalize_setup_errno
From: Johan Hedberg @ 2011-05-02 17:24 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <1304074563-16865-1-git-send-email-luiz.dentz@gmail.com>
Hi Luiz,
On Fri, Apr 29, 2011, Luiz Augusto von Dentz wrote:
> From: Luiz Augusto von Dentz <luiz.dentz-von@nokia.com>
>
> finalize_setup_errno last parameter must be NULL otherwise it may access
> invalid memory.
> ---
> audio/a2dp.c | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Fix property type of Main Channel of Health plugin
From: Johan Hedberg @ 2011-05-02 17:24 UTC (permalink / raw)
To: Jaikumar Ganesh; +Cc: linux-bluetooth
In-Reply-To: <1304110863-26528-1-git-send-email-jaikumar@google.com>
Hi Jaikumar,
On Fri, Apr 29, 2011, Jaikumar Ganesh wrote:
> The property type must be DBUS_TYPE_OBJECT_PATH instead
> of DBUS_TYPE_STRING. This is in sync with the documentation
> and with the other places of usage such as the property change
> signal.
> ---
> health/hdp.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Remove btio.c compilation warning
From: anderson.briglia @ 2011-05-02 20:43 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Briglia
From: Anderson Briglia <anderson.briglia@openbossa.org>
This patch fixes a compilation warning regarding btio/btio.c
compilation.
---
btio/btio.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/btio/btio.c b/btio/btio.c
index 6d71b90..8f166cc 100644
--- a/btio/btio.c
+++ b/btio/btio.c
@@ -800,7 +800,7 @@ static gboolean l2cap_get(int sock, GError **err, BtIOOption opt1,
uint8_t dev_class[3];
uint16_t handle;
socklen_t len;
- gboolean flushable;
+ gboolean flushable = TRUE;
len = sizeof(l2o);
memset(&l2o, 0, len);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH] Remove btio.c compilation warning
From: Antonio Ospite @ 2011-05-02 20:56 UTC (permalink / raw)
To: anderson.briglia; +Cc: linux-bluetooth
In-Reply-To: <4dbf1776.0bd9650a.1733.7e99@mx.google.com>
[-- Attachment #1: Type: text/plain, Size: 895 bytes --]
On Mon, 2 May 2011 16:43:26 -0400
anderson.briglia@openbossa.org wrote:
> From: Anderson Briglia <anderson.briglia@openbossa.org>
>
> This patch fixes a compilation warning regarding btio/btio.c
> compilation.
Just a general observation, when fixing compilation warnings/errors it
is useful to put the actual message from the compiler in the commit log,
this helps reviewers validating the patch as they see exactly which
issue the fix addresses, but not only: there are chances the commit
message will be indexed by search engines and we'll be helping others
with similar issues searching for a solution on the web.
Regards,
Antonio
--
Antonio Ospite
http://ao2.it
PGP public key ID: 0x4553B001
A: Because it messes up the order in which people normally read text.
See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Johan Hedberg @ 2011-05-02 21:15 UTC (permalink / raw)
To: anderson.briglia; +Cc: linux-bluetooth
In-Reply-To: <4dbf1776.0bd9650a.1733.7e99@mx.google.com>
Hi Briglia,
On Mon, May 02, 2011, anderson.briglia@openbossa.org wrote:
> This patch fixes a compilation warning regarding btio/btio.c
> compilation.
> ---
> btio/btio.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/btio/btio.c b/btio/btio.c
> index 6d71b90..8f166cc 100644
> --- a/btio/btio.c
> +++ b/btio/btio.c
> @@ -800,7 +800,7 @@ static gboolean l2cap_get(int sock, GError **err, BtIOOption opt1,
> uint8_t dev_class[3];
> uint16_t handle;
> socklen_t len;
> - gboolean flushable;
> + gboolean flushable = TRUE;
>
> len = sizeof(l2o);
> memset(&l2o, 0, len);
I don't get the warning with my compiler, so in addition to the already
requested compiler logs please also mention the compiler version. Also,
the value should default to FALSE and not TRUE.
Johan
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Elvis Pfützenreuter @ 2011-05-02 21:23 UTC (permalink / raw)
To: Johan Hedberg; +Cc: anderson.briglia, linux-bluetooth
In-Reply-To: <20110502211537.GA17551@jh-x301>
On May 2, 2011, at 6:15 PM, Johan Hedberg wrote:
> Hi Briglia,
>
> On Mon, May 02, 2011, anderson.briglia@openbossa.org wrote:
>> This patch fixes a compilation warning regarding btio/btio.c
>> compilation.
>> ---
>> btio/btio.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/btio/btio.c b/btio/btio.c
>> index 6d71b90..8f166cc 100644
>> --- a/btio/btio.c
>> +++ b/btio/btio.c
>> @@ -800,7 +800,7 @@ static gboolean l2cap_get(int sock, GError **err, BtIOOption opt1,
>> uint8_t dev_class[3];
>> uint16_t handle;
>> socklen_t len;
>> - gboolean flushable;
>> + gboolean flushable = TRUE;
>>
>> len = sizeof(l2o);
>> memset(&l2o, 0, len);
>
> I don't get the warning with my compiler, so in addition to the already
> requested compiler logs please also mention the compiler version. Also,
> the value should default to FALSE and not TRUE.
It looks like a false alarm from gcc 4.5.2 (Ubuntu Natty), or at least I feel
like it (got it here, too). If you agree, a bug ticket could be submitted to them.
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Anderson Briglia @ 2011-05-02 21:33 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Johan Hedberg, linux-bluetooth
In-Reply-To: <0074C043-DBA7-4BE3-9D9E-9CEC1FFA4096@signove.com>
Hi all,
On Mon, May 2, 2011 at 6:23 PM, Elvis Pfützenreuter <epx@signove.com> wrote:
> On May 2, 2011, at 6:15 PM, Johan Hedberg wrote:
>
>> Hi Briglia,
>>
>> On Mon, May 02, 2011, anderson.briglia@openbossa.org wrote:
>>> This patch fixes a compilation warning regarding btio/btio.c
>>> compilation.
>>> ---
>>> btio/btio.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/btio/btio.c b/btio/btio.c
>>> index 6d71b90..8f166cc 100644
>>> --- a/btio/btio.c
>>> +++ b/btio/btio.c
>>> @@ -800,7 +800,7 @@ static gboolean l2cap_get(int sock, GError **err, BtIOOption opt1,
>>> uint8_t dev_class[3];
>>> uint16_t handle;
>>> socklen_t len;
>>> - gboolean flushable;
>>> + gboolean flushable = TRUE;
>>>
>>> len = sizeof(l2o);
>>> memset(&l2o, 0, len);
>>
>> I don't get the warning with my compiler, so in addition to the already
>> requested compiler logs please also mention the compiler version. Also,
>> the value should default to FALSE and not TRUE.
>
> It looks like a false alarm from gcc 4.5.2 (Ubuntu Natty), or at least I feel
> like it (got it here, too). If you agree, a bug ticket could be submitted to them.
It makes sense. This "fake" warning appears after I upgraded to Ubuntu
Natty. Anyway, you guys could make a quick test adding
--enable-maintainer-mode flag to configure.
--
INdT - Instituto Nokia de tecnologia
+55 2126 1122
http://techblog.briglia.net
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Gustavo F. Padovan @ 2011-05-02 21:47 UTC (permalink / raw)
To: Anderson Briglia; +Cc: Elvis Pfützenreuter, Johan Hedberg, linux-bluetooth
In-Reply-To: <BANLkTiknmT4JDXxbB0RQcraoAvo2ueY9ng@mail.gmail.com>
Hi Briglia,
* Anderson Briglia <anderson.briglia@openbossa.org> [2011-05-02 18:33:11 -0300]:
> Hi all,
>
> On Mon, May 2, 2011 at 6:23 PM, Elvis Pfützenreuter <epx@signove.com> wrote:
> > On May 2, 2011, at 6:15 PM, Johan Hedberg wrote:
> >
> >> Hi Briglia,
> >>
> >> On Mon, May 02, 2011, anderson.briglia@openbossa.org wrote:
> >>> This patch fixes a compilation warning regarding btio/btio.c
> >>> compilation.
> >>> ---
> >>> btio/btio.c | 2 +-
> >>> 1 files changed, 1 insertions(+), 1 deletions(-)
> >>>
> >>> diff --git a/btio/btio.c b/btio/btio.c
> >>> index 6d71b90..8f166cc 100644
> >>> --- a/btio/btio.c
> >>> +++ b/btio/btio.c
> >>> @@ -800,7 +800,7 @@ static gboolean l2cap_get(int sock, GError **err, BtIOOption opt1,
> >>> uint8_t dev_class[3];
> >>> uint16_t handle;
> >>> socklen_t len;
> >>> - gboolean flushable;
> >>> + gboolean flushable = TRUE;
> >>>
> >>> len = sizeof(l2o);
> >>> memset(&l2o, 0, len);
> >>
> >> I don't get the warning with my compiler, so in addition to the already
> >> requested compiler logs please also mention the compiler version. Also,
> >> the value should default to FALSE and not TRUE.
>
> >
> > It looks like a false alarm from gcc 4.5.2 (Ubuntu Natty), or at least I feel
> > like it (got it here, too). If you agree, a bug ticket could be submitted to them.
>
> It makes sense. This "fake" warning appears after I upgraded to Ubuntu
> Natty. Anyway, you guys could make a quick test adding
> --enable-maintainer-mode flag to configure.
We always have maintainer mode enabled and I can't see anything wrong here. It's
probably your ubuntu.
--
Gustavo F. Padovan
http://profusion.mobi
^ permalink raw reply
* [PATCH] Remove leftover of attrib plugin build
From: Claudio Takahasi @ 2011-05-02 22:23 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
Makefile.am | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 9703bf0..afc26f4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -385,7 +385,7 @@ pkgconfigdir = $(libdir)/pkgconfig
pkgconfig_DATA = bluez.pc
-DISTCHECK_CONFIGURE_FLAGS = --disable-udevrules --enable-attrib
+DISTCHECK_CONFIGURE_FLAGS = --disable-udevrules
DISTCLEANFILES = $(pkgconfig_DATA)
--
1.7.5.rc3
^ permalink raw reply related
* Re: [RFC 00/16] Discovery procedure refactoring
From: Andre Guedes @ 2011-05-02 22:32 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <BANLkTin7oCB9L0S0_kjESF6SfMfaqjwMtA@mail.gmail.com>
Hi Luiz,
On Mon, May 2, 2011 at 5:39 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Andre,
>
> On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
> <andre.guedes@openbossa.org> wrote:
>> Hi all,
>>
>> Today, discovery procedure is supported only in hciops. This refactoring has
>> been done to provide easier implementation of discovery procedure in mgmtops.
>> Lots of effort would be necessary to implement discovery procedure in mgmtops
>> because its logic is spread out adapter layer and hciops layer.
>>
>> The approach this patchset follows is moving all logic related to discovery
>> procedure from adapter layer to hciops layer.
>>
>> Future work will be:
>> - full support for discovery procedure (BR/EDR, LE-Only, BR/EDR/LE
>> devices) in kernel via management interface (today, only BR/EDR is
>> supported).
>> - name resolving support through mgmt interface (kernel + userspace)
>>
>> Thanks,
>> Guedes.
>>
>> Anderson Briglia (1):
>> Implement mgmt start and stop discovery
>>
>> Andre Guedes (15):
>> Add discovery callbacks to btd_adapter_ops
>> Replace inquiry/scanning calls by discovery calls
>> Add 'discov_state' field to struct dev_info
>> Code cleanup event.c
>> Remove Periodic Inquiry support in hciops
>> Change DiscoverSchedulerInterval default value
>> Add 'timeout' param to start_scanning callback
>> Refactoring adapter_set_state()
>> Remove 'suspend' param from stop_discovery()
>> Add extfeatures to struct dev_info
>> Implement start_discovery hciops callback
>> Remove obsolete code.
>> Implement stop_discovery hciops callback
>> Remove inquiry and scanning callbacks from btd_adapter_ops
>> Remove 'periodic' param from hciops_start_inquiry()
>>
>> plugins/hciops.c | 373 ++++++++++++++++++++++++++++++++++++-----------------
>> plugins/mgmtops.c | 35 ++----
>> src/adapter.c | 217 ++++++++++---------------------
>> src/adapter.h | 19 +--
>> src/event.c | 48 +-------
>> src/event.h | 1 -
>> src/main.conf | 4 +-
>> 7 files changed, 345 insertions(+), 352 deletions(-)
>
> How do we solve the problem with command failing to restart
> inquiring/scanning, with pinq we only need to send the command once
> and if it fails we can signal the error back to the client, but if we
> are sending commands every round they may fail (buggy hardware) and
> currently we have no way to notify the client if discovery session
> failed after it has been started.
>
I think this problem already exists if we change "DiscoverSchedulerInterval"
option to a value different from zero. So, there is no regression. The problem
you reported is masked by using PINQ as a default configuration in main.conf.
But anyway, you're right, we need to come up with some mechanism to
signal the client an error occurred during the discovery procedure.
> Im afraid because of dual mode adapters we may need to change the
> D-Bus API in the future and have the client to specify somehow on
> StartDiscovery if LE only, BR/EDR only or both like connman does with
> RequestScan, otherwise it may take too long (each cycle taking 20-30
> seconds) to discover devices because it wasting time scanning or
> resolving names in the wrong technology.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
The purpose of this patchset is refactoring discovery procedure related code.
It doesn't aim to fix known bugs.
--
Andre Guedes.
^ permalink raw reply
* Re: [RFC 05/16] Remove Periodic Inquiry support in hciops
From: Andre Guedes @ 2011-05-02 22:35 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <BANLkTinWERJyj2Gmm=ejQo4x0gqeBPtvXQ@mail.gmail.com>
Hi Luiz,
On Mon, May 2, 2011 at 4:38 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Andre,
>
> On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
> <andre.guedes@openbossa.org> wrote:
>> Periodic Inquiry is no longer supported in hciops since the discovery
>> procedure will use Standard Inquiry only.
>>
>> External tools which request Periodic Inquiry will not change the
>> adapter's state.
>> ---
>> plugins/hciops.c | 112 +++++++----------------------------------------------
>> src/event.c | 13 +------
>> 2 files changed, 16 insertions(+), 109 deletions(-)
>>
>> diff --git a/plugins/hciops.c b/plugins/hciops.c
>> index dfd00b1..81a0f29 100644
>> --- a/plugins/hciops.c
>> +++ b/plugins/hciops.c
>> @@ -507,24 +507,13 @@ static void start_adapter(int index)
>> static int hciops_stop_inquiry(int index)
>> {
>> struct dev_info *dev = &devs[index];
>> - struct hci_dev_info di;
>> - int err;
>>
>> DBG("hci%d", index);
>>
>> - if (hci_devinfo(index, &di) < 0)
>> + if (hci_send_cmd(dev->sk, OGF_LINK_CTL, OCF_INQUIRY_CANCEL, 0, 0) < 0)
>> return -errno;
>>
>> - if (hci_test_bit(HCI_INQUIRY, &di.flags))
>> - err = hci_send_cmd(dev->sk, OGF_LINK_CTL,
>> - OCF_INQUIRY_CANCEL, 0, 0);
>> - else
>> - err = hci_send_cmd(dev->sk, OGF_LINK_CTL,
>> - OCF_EXIT_PERIODIC_INQUIRY, 0, 0);
>> - if (err < 0)
>> - err = -errno;
>> -
>> - return err;
>> + return 0;
>> }
>>
>> static gboolean init_adapter(int index)
>> @@ -1306,56 +1295,6 @@ reject:
>> hci_send_cmd(dev->sk, OGF_LINK_CTL, OCF_PIN_CODE_NEG_REPLY, 6, dba);
>> }
>>
>> -static void start_inquiry(bdaddr_t *local, uint8_t status, gboolean periodic)
>> -{
>> - struct btd_adapter *adapter;
>> - int state;
>> -
>> - /* Don't send the signal if the cmd failed */
>> - if (status) {
>> - error("Inquiry Failed with status 0x%02x", status);
>> - return;
>> - }
>> -
>> - adapter = manager_find_adapter(local);
>> - if (!adapter) {
>> - error("Unable to find matching adapter");
>> - return;
>> - }
>> -
>> - state = adapter_get_state(adapter);
>> -
>> - if (periodic)
>> - state |= STATE_PINQ;
>> - else
>> - state |= STATE_STDINQ;
>> -
>> - adapter_set_state(adapter, state);
>> -}
>> -
>> -static void inquiry_complete(bdaddr_t *local, uint8_t status,
>> - gboolean periodic)
>> -{
>> - struct btd_adapter *adapter;
>> - int state;
>> -
>> - /* Don't send the signal if the cmd failed */
>> - if (status) {
>> - error("Inquiry Failed with status 0x%02x", status);
>> - return;
>> - }
>> -
>> - adapter = manager_find_adapter(local);
>> - if (!adapter) {
>> - error("Unable to find matching adapter");
>> - return;
>> - }
>> -
>> - state = adapter_get_state(adapter);
>> - state &= ~(STATE_STDINQ | STATE_PINQ);
>> - adapter_set_state(adapter, state);
>> -}
>> -
>> static inline void remote_features_notify(int index, void *ptr)
>> {
>> struct dev_info *dev = &devs[index];
>> @@ -1945,12 +1884,6 @@ static inline void cmd_complete(int index, void *ptr)
>> ptr += sizeof(evt_cmd_complete);
>> read_bd_addr_complete(index, ptr);
>> break;
>> - case cmd_opcode_pack(OGF_LINK_CTL, OCF_PERIODIC_INQUIRY):
>> - start_inquiry(&dev->bdaddr, status, TRUE);
>> - break;
>> - case cmd_opcode_pack(OGF_LINK_CTL, OCF_EXIT_PERIODIC_INQUIRY):
>> - inquiry_complete(&dev->bdaddr, status, TRUE);
>> - break;
>> case cmd_opcode_pack(OGF_LINK_CTL, OCF_INQUIRY_CANCEL):
>> cc_inquiry_cancel(index, status);
>> break;
>> @@ -2043,6 +1976,10 @@ static inline void inquiry_result(int index, int plen, void *ptr)
>> uint8_t num = *(uint8_t *) ptr++;
>> int i;
>>
>> + /* Skip if it is not in Inquiry state */
>> + if (get_state(index) != DISCOV_INQ)
>> + return;
>> +
>> for (i = 0; i < num; i++) {
>> inquiry_info *info = ptr;
>> uint32_t class = info->dev_class[0] |
>> @@ -3060,39 +2997,20 @@ static int hciops_start_inquiry(int index, uint8_t length, gboolean periodic)
>> {
>> struct dev_info *dev = &devs[index];
>> uint8_t lap[3] = { 0x33, 0x8b, 0x9e };
>> - int err;
>> + inquiry_cp inq_cp;
>>
>> DBG("hci%d length %u periodic %d", index, length, periodic);
>>
>> - if (periodic) {
>> - periodic_inquiry_cp cp;
>> -
>> - memset(&cp, 0, sizeof(cp));
>> - memcpy(&cp.lap, lap, 3);
>> - cp.max_period = htobs(24);
>> - cp.min_period = htobs(16);
>> - cp.length = length;
>> - cp.num_rsp = 0x00;
>> -
>> - err = hci_send_cmd(dev->sk, OGF_LINK_CTL,
>> - OCF_PERIODIC_INQUIRY,
>> - PERIODIC_INQUIRY_CP_SIZE, &cp);
>> - } else {
>> - inquiry_cp inq_cp;
>> -
>> - memset(&inq_cp, 0, sizeof(inq_cp));
>> - memcpy(&inq_cp.lap, lap, 3);
>> - inq_cp.length = length;
>> - inq_cp.num_rsp = 0x00;
>> + memset(&inq_cp, 0, sizeof(inq_cp));
>> + memcpy(&inq_cp.lap, lap, 3);
>> + inq_cp.length = length;
>> + inq_cp.num_rsp = 0x00;
>>
>> - err = hci_send_cmd(dev->sk, OGF_LINK_CTL,
>> - OCF_INQUIRY, INQUIRY_CP_SIZE, &inq_cp);
>> - }
>> -
>> - if (err < 0)
>> - err = -errno;
>> + if (hci_send_cmd(dev->sk, OGF_LINK_CTL,
>> + OCF_INQUIRY, INQUIRY_CP_SIZE, &inq_cp) < 0)
>> + return -errno;
>>
>> - return err;
>> + return 0;
>> }
>>
>> static int le_set_scan_enable(int index, uint8_t enable)
>> diff --git a/src/event.c b/src/event.c
>> index 7feec1f..b04220a 100644
>> --- a/src/event.c
>> +++ b/src/event.c
>> @@ -435,7 +435,7 @@ void btd_event_device_found(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
>> char local_addr[18], peer_addr[18], *alias, *name;
>> name_status_t name_status;
>> struct eir_data eir_data;
>> - int state, err;
>> + int err;
>> dbus_bool_t legacy;
>> unsigned char features[8];
>> const char *dev_name;
>> @@ -455,17 +455,6 @@ void btd_event_device_found(bdaddr_t *local, bdaddr_t *peer, uint32_t class,
>> if (data)
>> write_remote_eir(local, peer, data);
>>
>> - /*
>> - * Workaround to identify periodic inquiry: inquiry complete event is
>> - * sent after each window, however there isn't an event to indicate the
>> - * beginning of a new periodic inquiry window.
>> - */
>> - state = adapter_get_state(adapter);
>> - if (!(state & (STATE_STDINQ | STATE_LE_SCAN | STATE_PINQ))) {
>> - state |= STATE_PINQ;
>> - adapter_set_state(adapter, state);
>> - }
>> -
>> /* the inquiry result can be triggered by NON D-Bus client */
>> if (adapter_get_discover_type(adapter) & DISC_RESOLVNAME &&
>> adapter_has_discov_sessions(adapter))
>> --
>> 1.7.1
>>
>
> What exactly is reason to remove periodic inquiry? I see the point for
> dual mode devices, but for regular BD/EDR its very useful since the
> controller takes care of the scheduling and we don't have to send
> another command each round. Also we need to be able to detect if pinq
> was activate by the user somehow, since it may cause some bugs which
> will be very to debug since you are removing the state tracking.
>
The reason is, until now, we're not able to detect correctly when the controller
has started an periodic inquiry. What we had before was a workaround in inquiry
result event handler to set the adapter state to PINQ. This workaround is not
correct because the adapter may be carrying out a discovery procedure and its
state is IDLE. This situation occurs when there is no device in range (no
inquiry result event is generated, consequently, adapter's state will be not set
to PINQ).
So, due to that issue and the fact using periodic inquiry is not mandatory to
implement the discovery procedure described in Core spec, we decided to
remove the periodic inquiry support by now.
Additionally, as I said in the patch description, periodic inquiry commands sent
by the user somehow (and the events it generates) will not change the adapter
state since they are ignored by hciops.
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
--
Andre Guedes.
^ permalink raw reply
* Re: [RFC 06/16] Change DiscoverSchedulerInterval default value
From: Andre Guedes @ 2011-05-02 22:37 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <BANLkTinwg4B3dTsWtUzZ8ji5FqGPHjHPyg@mail.gmail.com>
Hi Luiz,
On Mon, May 2, 2011 at 4:48 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Andre,
>
> On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
> <andre.guedes@openbossa.org> wrote:
>> This patch changes the default value of "DiscoverSchedulerInterval"
>> from 0 to 30 seconds.
>>
>> Since Periodic Inquiry is not supported anymore, the option
>> "DiscoverSchedulerInterval" in main.conf must be updated. As
>> a first attempt, it was chosen a 30 seconds interval.
>> ---
>> src/main.conf | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/src/main.conf b/src/main.conf
>> index c03f135..8cd132f 100644
>> --- a/src/main.conf
>> +++ b/src/main.conf
>> @@ -27,8 +27,8 @@ PairableTimeout = 0
>> PageTimeout = 8192
>>
>> # Discover scheduler interval used in Adapter.DiscoverDevices
>> -# The value is in seconds. Defaults is 0 to use controller scheduler.
>> -DiscoverSchedulerInterval = 0
>> +# The value is in seconds. Defaults is 30.
>> +DiscoverSchedulerInterval = 30
>>
>> # What value should be assumed for the adapter Powered property when
>> # SetProperty(Powered, ...) hasn't been called yet. Defaults to true
>
> Im not sure how you came up with 30 sec, IMO it is too long and
> doesn't specify how long we inquiry/scan/resolve names.
>
30 sec was a reasonable time we firstly thought. But as I said, it is
just a first
attempt. How long you think it is a good interval value?
Yes. It doesn't specify how long the whole discovery process takes. It specifies
how long the adapter is gonna wait in IDLE state before trigger the a new
discovery procedure. We changed this behavior because it would become very
tricky to predict how long the name resolving is gonna take since it depends on
the number of devices found during discovery.
I think this is not clear in the patch description, so I rewrite it. Thanks.
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
--
Andre Guedes
^ permalink raw reply
* Re: [RFC 09/16] Remove 'suspend' param from stop_discovery()
From: Andre Guedes @ 2011-05-02 22:38 UTC (permalink / raw)
To: Luiz Augusto von Dentz; +Cc: linux-bluetooth
In-Reply-To: <BANLkTikv2fJoLJ+tpchWD7X6ugwjVcwoxg@mail.gmail.com>
Hi Luiz,
On Mon, May 2, 2011 at 5:42 AM, Luiz Augusto von Dentz
<luiz.dentz@gmail.com> wrote:
> Hi Andre,
>
> On Sat, Apr 30, 2011 at 3:27 AM, Andre Guedes
> <andre.guedes@openbossa.org> wrote:
>> This patch removes 'suspend' parameter from stop_discovery() in adapter.c.
>>
>> This parameter is useless since new a function (suspend_discovery) was
>> created to suspend discovery sessions.
>> ---
>> src/adapter.c | 9 ++++-----
>> 1 files changed, 4 insertions(+), 5 deletions(-)
>>
>> diff --git a/src/adapter.c b/src/adapter.c
>> index 6a2a8c1..0279494 100644
>> --- a/src/adapter.c
>> +++ b/src/adapter.c
>> @@ -700,12 +700,11 @@ static GSList *remove_bredr(GSList *all)
>> return le;
>> }
>>
>> -static void stop_discovery(struct btd_adapter *adapter, gboolean suspend)
>> +static void stop_discovery(struct btd_adapter *adapter)
>> {
>> pending_remote_name_cancel(adapter);
>>
>> - if (suspend == FALSE)
>> - adapter->found_devices = remove_bredr(adapter->found_devices);
>> + adapter->found_devices = remove_bredr(adapter->found_devices);
>>
>> if (adapter->oor_devices) {
>> g_slist_free(adapter->oor_devices);
>> @@ -762,7 +761,7 @@ static void session_remove(struct session_req *req)
>>
>> DBG("Stopping discovery");
>>
>> - stop_discovery(adapter, FALSE);
>> + stop_discovery(adapter);
>> }
>> }
>>
>> @@ -2537,7 +2536,7 @@ int btd_adapter_stop(struct btd_adapter *adapter)
>> /* check pending requests */
>> reply_pending_requests(adapter);
>>
>> - stop_discovery(adapter, FALSE);
>> + stop_discovery(adapter);
>>
>> if (adapter->disc_sessions) {
>> g_slist_foreach(adapter->disc_sessions, (GFunc) session_free,
>> --
>
> What happened with stop_discovery called within suspend_discovery? We
> need to avoid cleaning up the list of found devices otherwise we won't
> be able to send DeviceDisappeared properly when discovery got resume.
>
At patch 08/16 I create a new function to suspend the discovery procedure
(see suspend_discovery() in adapter.c). It was done because using the
same function to perform stop or suspend discovery started to get a little
bit confusing.
> --
> Luiz Augusto von Dentz
> Computer Engineer
>
--
Andre Guedes
^ permalink raw reply
* Re: [RFC][PATCH 0/4] Allow hexadecimal encoded pins
From: Bastien Nocera @ 2011-05-02 23:32 UTC (permalink / raw)
To: David Herrmann; +Cc: linux-bluetooth, johan.hedberg, dforsi
In-Reply-To: <1302455477-27664-1-git-send-email-dh.herrmann@googlemail.com>
On Sun, 2011-04-10 at 19:11 +0200, David Herrmann wrote:
<snip>
> Binary pin support is inspired by getting Nintendo Wiimote pairing support.
> To test wiimote pairing with this patch series, do the following:
> - assume the local bdaddr is: 01:23:45:67:89:ab
> and the wiimote bdaddr is: ba:98:76:54:32:10
> - Pairing with red-sync button, use pin: $ab8967452301 (host addr. backwards)
> - Pairing with 1+2 buttons, use pin: $1032547698ba (wiimote addr backwards)
> Automatic reconnection is only enabled in the wiimote when synced with the
> red-sync button. The 1+2 button method is only for temporary connections.
What are the necessary changes to be made in gnome-bluetooth?
I'm guessing that we should add a "WIIMOTE" type of special casing in
the pin database, and pass the adapter address as per the above when a
PIN is requested.
Is there any way to detect which "type" of pairing is made with the
Wiimote, eg. you say that button 1+2 will only work for temporary
connections. Can we detect this? Would pairing anyway work?
Cheers
^ permalink raw reply
* Re: [PATCH] Remove leftover of attrib plugin build
From: Johan Hedberg @ 2011-05-03 0:49 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1304375000-25686-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Mon, May 02, 2011, Claudio Takahasi wrote:
> ---
> Makefile.am | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* [PATCH] Check session->msg at sync_getphonebook_callback()
From: wu.zheng @ 2011-05-03 7:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: wu.zheng
Fix the issues of code style. Check session->msg at sync_getphonebook_callback()in client/sync.c. Otherwise, session->msg will be NULL and cause segmentation fault error. The reason is that the condition of transfer->fd > 0 && session->msg is ok and session->msg will be set to NULL in the func of session_notify_progress when sync profile is used.
---
client/sync.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/client/sync.c b/client/sync.c
index 3622a3d..184a284 100644
--- a/client/sync.c
+++ b/client/sync.c
@@ -78,6 +78,9 @@ static void sync_getphonebook_callback(struct session_data *session,
DBusMessage *reply;
char *buf = NULL;
+ if (session->msg == NULL)
+ goto done;
+
reply = dbus_message_new_method_return(session->msg);
if (transfer->filled > 0)
@@ -91,6 +94,9 @@ static void sync_getphonebook_callback(struct session_data *session,
g_dbus_send_message(session->conn, reply);
dbus_message_unref(session->msg);
session->msg = NULL;
+
+done:
+ transfer_unregister(transfer);
}
static DBusMessage *sync_getphonebook(DBusConnection *connection,
--
1.7.3.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