* Re: [PATCH] Remove btio.c compilation warning
From: Vinicius Costa Gomes @ 2011-05-05 14:05 UTC (permalink / raw)
To: Luiz Augusto von Dentz
Cc: Elvis Pfützenreuter, Anderson Briglia, linux-bluetooth
In-Reply-To: <BANLkTikLnb229tLvdeeWMnfqkqdSAva1bQ@mail.gmail.com>
Hi Luiz,
On 11:05 Thu 05 May, Luiz Augusto von Dentz wrote:
[snip]
>
> I don't see why it would be ubuntu specific, this seems to be some
> kind of regression/'feature' with gcc 4.5.
Yeah, I really believe this is the case. I have gcc 4.5.2 here, that
would be the version as in Natty, and I don't encounter that problem.
The only difference that I could find is that Ubuntu ships gcc with
a .diff.gz of 1.3MB ;-)
But back to the topic at hand, I agree that the patch should be applied,
Ubuntu is used by many developers and BlueZ should be kept clean of
warnings.
>
> --
> Luiz Augusto von Dentz
> Computer Engineer
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
^ permalink raw reply
* [PATCH v3] Add partial mas.c - messages-*.c API.
From: Slawomir Bochenski @ 2011-05-05 12:37 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Slawomir Bochenski
This adds stubs of functions needed for message browsing and retrieval.
---
Fixed documentation for messages_set_notification_registration().
plugins/messages-dummy.c | 71 ++++++++++++++
plugins/messages.h | 231 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 302 insertions(+), 0 deletions(-)
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index fd9679d..819f952 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -25,4 +25,75 @@
#include <config.h>
#endif
+#include <errno.h>
+
#include "messages.h"
+
+int messages_init(void)
+{
+ return 0;
+}
+
+void messages_exit(void)
+{
+}
+
+int messages_connect(void **session)
+{
+ *session = 0;
+ return 0;
+}
+
+void messages_disconnect(void *session)
+{
+}
+
+int messages_set_notification_registration(void *session,
+ void (*send_event)(void *session,
+ struct messages_event *event, void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+int messages_set_folder(void *session, const char *name, gboolean cdup)
+{
+ return -EINVAL;
+}
+
+int messages_get_folder_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset,
+ void (*callback)(void *session, int err, const char *name,
+ void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+int messages_get_messages_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset, struct messages_filter *filter,
+ uint16_t *size, gboolean *newmsg,
+ void (*callback)(void *session, int err,
+ const struct messages_message *message, void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+int messages_get_message(void *session,
+ const char *handle,
+ gboolean attachment, gboolean utf8,
+ gboolean fraction, gboolean next,
+ gboolean *fmore,
+ void (*callback)(void *session, int err, const char *chunk,
+ void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+void messages_abort(void *session)
+{
+}
diff --git a/plugins/messages.h b/plugins/messages.h
index c510244..ae6287b 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -20,3 +20,234 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
+
+#include <glib.h>
+#include <stdint.h>
+
+/* Those are used by backend to notify transport plugin which properties did it
+ * send.
+ */
+#define PMASK_SUBJECT 0x0001
+#define PMASK_DATETIME 0x0002
+#define PMASK_SENDER_NAME 0x0004
+#define PMASK_SENDER_ADDRESSING 0x0008
+#define PMASK_RECIPIENT_NAME 0x0010
+#define PMASK_RECIPIENT_ADDRESSING 0x0020
+#define PMASK_TYPE 0x0040
+#define PMASK_SIZE 0x0080
+#define PMASK_RECEPTION_STATUS 0x0100
+#define PMASK_TEXT 0x0200
+#define PMASK_ATTACHMENT_SIZE 0x0400
+#define PMASK_PRIORITY 0x0800
+#define PMASK_READ 0x1000
+#define PMASK_SENT 0x2000
+#define PMASK_PROTECTED 0x4000
+#define PMASK_REPLYTO_ADDRESSING 0x8000
+
+/* This one is used in a response to GetMessagesListing. Use PMASK_* values to
+ * notify the plugin which members are actually set. Backend shall not omit
+ * properties required by MAP specification (subject, datetime,
+ * recipient_addressing, type, size, reception_status, attachment_size) unless
+ * ordered by PARAMETERMASK. Boolean values should be probably
+ * always sent (need checking). Handle is mandatory. Plugin will filter out any
+ * properties that were not wanted by MCE.
+ *
+ * Handle shall be set to hexadecimal representation with upper-case letters. No
+ * prefix shall be appended and without no zeros. This corresponds to PTS
+ * behaviour described in comments to the MAP specification.
+ *
+ * The rest of char * fields shall be set according to the MAP specification
+ * rules.
+ */
+struct messages_message {
+ uint32_t mask;
+ char *handle;
+ char *subject;
+ char *datetime;
+ char *sender_name;
+ char *sender_addressing;
+ char *replyto_addressing;
+ char *recipient_name;
+ char *recipient_addressing;
+ char *type;
+ char *reception_status;
+ char *size;
+ char *attachment_size;
+ gboolean text;
+ gboolean read;
+ gboolean sent;
+ gboolean protect;
+ gboolean priority;
+};
+
+/* Type of message event to be delivered to MNS server */
+enum messages_event_type {
+ MET_NEW_MESSAGE,
+ MET_DELIVERY_SUCCESS,
+ MET_SENDING_SUCCESS,
+ MET_DELIVERY_FAILURE,
+ MET_SENDING_FAILURE,
+ MET_MEMORY_FULL,
+ MET_MEMORY_AVAILABLE,
+ MET_MESSAGE_DELETED,
+ MET_MESSAGE_SHIFT
+};
+
+/* Data for sending MNS notification. Handle shall be formatted as described in
+ * messages_message.
+ */
+struct messages_event {
+ enum messages_event_type type;
+ uint8_t instance_id;
+ char *handle;
+ char *folder;
+ char *old_folder;
+ char *msg_type;
+};
+
+/* parameter_mask: |-ed PMASK_* values
+ * See MAP specification for the rest.
+ */
+struct messages_filter {
+ uint32_t parameter_mask;
+ uint8_t type;
+ char *period_begin;
+ char *period_end;
+ uint8_t *read_status;
+ char *recipient;
+ char *originator;
+ uint8_t priority;
+};
+
+/* This is called once after server starts.
+ *
+ * Returns value less than zero if error. This will prevent MAP plugin from
+ * starting.
+ */
+int messages_init(void);
+
+/* This gets called right before server finishes
+ */
+void messages_exit(void);
+
+/* Starts a new MAP session.
+ *
+ * session: variable to store pointer to backend session data. This one shall be
+ * passed to all in-session calls.
+ *
+ * If session start succeeded, backend shall return 0. Otherwise the error value
+ * will be sent as a response to OBEX connect.
+ */
+int messages_connect(void **session);
+
+/* Closes a MAP session.
+ *
+ * This call should free buffer reserved by messages_connect.
+ */
+void messages_disconnect(void *session);
+
+/******************************************************************************
+ * NOTE on callbacks.
+ *
+ * All functions requiring callbacks have to call them asynchronously.
+ * 'user_data' is for passing arbitrary user data.
+ *
+ * If 'err' is negative it is used to send error to the
+ * OBEX request.
+ *
+ * The special case is err == -EAGAIN. This notifies transport
+ * plugin to not wake IO. This is especially useful to postpone sending
+ * application headers if backend did not set proper return values for
+ * parameters yet.
+ *
+ * In case of folder/message listing and get message, end of data is indicated
+ * by calling callback with parameter carrying data (e.g. chunk) set to NULL.
+ ******************************************************************************/
+
+/* Registers for messaging events notifications.
+ *
+ * session: Backend session.
+ * send_event: Function that will be called to indicate a new event.
+ *
+ * To unregister currently registered notifications, call this with send_event
+ * set to NULL.
+ */
+int messages_set_notification_registration(void *session,
+ void (*send_event)(void *session,
+ struct messages_event *event, void *user_data),
+ void *user_data);
+
+/* Changes current directory.
+ *
+ * session: Backend session.
+ * name: Subdirectory to go to. If empty or null and cdup is false, go to the
+ * root directory.
+ * cdup: If true, go up one level first.
+ */
+int messages_set_folder(void *session, const char *name, gboolean cdup);
+
+/* Retrieves subdirectories listing from a current directory.
+ *
+ * session: Backend session.
+ * name: Optional subdirectory name (not strictly required by MAP).
+ * max: Maximum number of entries to retrieve.
+ * offset: Offset of the first entry.
+ *
+ * Callback shall be called for every entry of the listing. 'name' is the
+ * subdirectory name.
+ */
+int messages_get_folder_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset,
+ void (*callback)(void *session, int err, const char *name,
+ void *user_data),
+ void *user_data);
+
+/* Retrieves messages listing from a current directory.
+ *
+ * session: Backend session.
+ * name: Optional subdirectory name.
+ * max: Maximum number of entries to retrieve.
+ * filter: Filter to apply on returned message listing.
+ * size: Pointer to return message listing size.
+ * newmsg: Pointer to return indicator of presence of unread messages.
+ *
+ * Callback shall be called for every entry of the listing, giving message data
+ * in 'message'.
+ */
+int messages_get_messages_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset, struct messages_filter *filter,
+ uint16_t *size, gboolean *newmsg,
+ void (*callback)(void *session, int err,
+ const struct messages_message *message, void *user_data),
+ void *user_data);
+
+/* Retrieves bMessage object (see MAP specification, ch. 3.1.3) of a given
+ * message.
+ *
+ * session: Backend session.
+ * handle: Handle of the message to retrieve.
+ * attachment: Selects whether or not attachments (if any) are to be included.
+ * utf8: If true, convert message to utf-8. Otherwise use native encoding.
+ * fraction: If true, deliver fractioned message.
+ * next: If fraction is true this indicates whether to retrieve first fraction
+ * or the next one.
+ * fmore: Pointer to return indicator of whether next fraction is available.
+ *
+ * Callback allows for returning bMessage in chunks.
+ */
+int messages_get_message(void *session,
+ const char *handle,
+ gboolean attachment, gboolean utf8,
+ gboolean fraction, gboolean next,
+ gboolean *fmore,
+ void (*callback)(void *session, int err, const char *chunk,
+ void *user_data),
+ void *user_data);
+
+/* Aborts currently pending request.
+ *
+ * session: Backend session.
+ */
+void messages_abort(void *session);
--
1.7.4.1
^ permalink raw reply related
* [PATCH v2] Add partial mas.c - messages-*.c API.
From: Slawomir Bochenski @ 2011-05-05 12:30 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Slawomir Bochenski
This adds stubs of functions needed for message browsing and retrieval.
---
Fixed typos pointed out by Daniele Forsi. Changes coming from
discussion on the IRC.
plugins/messages-dummy.c | 71 ++++++++++++++
plugins/messages.h | 229 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 300 insertions(+), 0 deletions(-)
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index fd9679d..819f952 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -25,4 +25,75 @@
#include <config.h>
#endif
+#include <errno.h>
+
#include "messages.h"
+
+int messages_init(void)
+{
+ return 0;
+}
+
+void messages_exit(void)
+{
+}
+
+int messages_connect(void **session)
+{
+ *session = 0;
+ return 0;
+}
+
+void messages_disconnect(void *session)
+{
+}
+
+int messages_set_notification_registration(void *session,
+ void (*send_event)(void *session,
+ struct messages_event *event, void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+int messages_set_folder(void *session, const char *name, gboolean cdup)
+{
+ return -EINVAL;
+}
+
+int messages_get_folder_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset,
+ void (*callback)(void *session, int err, const char *name,
+ void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+int messages_get_messages_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset, struct messages_filter *filter,
+ uint16_t *size, gboolean *newmsg,
+ void (*callback)(void *session, int err,
+ const struct messages_message *message, void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+int messages_get_message(void *session,
+ const char *handle,
+ gboolean attachment, gboolean utf8,
+ gboolean fraction, gboolean next,
+ gboolean *fmore,
+ void (*callback)(void *session, int err, const char *chunk,
+ void *user_data),
+ void *user_data)
+{
+ return -EINVAL;
+}
+
+void messages_abort(void *session)
+{
+}
diff --git a/plugins/messages.h b/plugins/messages.h
index c510244..1c4c9db 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -20,3 +20,232 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
+
+#include <glib.h>
+#include <stdint.h>
+
+/* Those are used by backend to notify transport plugin which properties did it
+ * send.
+ */
+#define PMASK_SUBJECT 0x0001
+#define PMASK_DATETIME 0x0002
+#define PMASK_SENDER_NAME 0x0004
+#define PMASK_SENDER_ADDRESSING 0x0008
+#define PMASK_RECIPIENT_NAME 0x0010
+#define PMASK_RECIPIENT_ADDRESSING 0x0020
+#define PMASK_TYPE 0x0040
+#define PMASK_SIZE 0x0080
+#define PMASK_RECEPTION_STATUS 0x0100
+#define PMASK_TEXT 0x0200
+#define PMASK_ATTACHMENT_SIZE 0x0400
+#define PMASK_PRIORITY 0x0800
+#define PMASK_READ 0x1000
+#define PMASK_SENT 0x2000
+#define PMASK_PROTECTED 0x4000
+#define PMASK_REPLYTO_ADDRESSING 0x8000
+
+/* This one is used in a response to GetMessagesListing. Use PMASK_* values to
+ * notify the plugin which members are actually set. Backend shall not omit
+ * properties required by MAP specification (subject, datetime,
+ * recipient_addressing, type, size, reception_status, attachment_size) unless
+ * ordered by PARAMETERMASK. Boolean values should be probably
+ * always sent (need checking). Handle is mandatory. Plugin will filter out any
+ * properties that were not wanted by MCE.
+ *
+ * Handle shall be set to hexadecimal representation with upper-case letters. No
+ * prefix shall be appended and without no zeros. This corresponds to PTS
+ * behaviour described in comments to the MAP specification.
+ *
+ * The rest of char * fields shall be set according to the MAP specification
+ * rules.
+ */
+struct messages_message {
+ uint32_t mask;
+ char *handle;
+ char *subject;
+ char *datetime;
+ char *sender_name;
+ char *sender_addressing;
+ char *replyto_addressing;
+ char *recipient_name;
+ char *recipient_addressing;
+ char *type;
+ char *reception_status;
+ char *size;
+ char *attachment_size;
+ gboolean text;
+ gboolean read;
+ gboolean sent;
+ gboolean protect;
+ gboolean priority;
+};
+
+/* Type of message event to be delivered to MNS server */
+enum messages_event_type {
+ MET_NEW_MESSAGE,
+ MET_DELIVERY_SUCCESS,
+ MET_SENDING_SUCCESS,
+ MET_DELIVERY_FAILURE,
+ MET_SENDING_FAILURE,
+ MET_MEMORY_FULL,
+ MET_MEMORY_AVAILABLE,
+ MET_MESSAGE_DELETED,
+ MET_MESSAGE_SHIFT
+};
+
+/* Data for sending MNS notification. Handle shall be formatted as described in
+ * messages_message.
+ */
+struct messages_event {
+ enum messages_event_type type;
+ uint8_t instance_id;
+ char *handle;
+ char *folder;
+ char *old_folder;
+ char *msg_type;
+};
+
+/* parameter_mask: |-ed PMASK_* values
+ * See MAP specification for the rest.
+ */
+struct messages_filter {
+ uint32_t parameter_mask;
+ uint8_t type;
+ char *period_begin;
+ char *period_end;
+ uint8_t *read_status;
+ char *recipient;
+ char *originator;
+ uint8_t priority;
+};
+
+/* This is called once after server starts.
+ *
+ * Returns value less than zero if error. This will prevent MAP plugin from
+ * starting.
+ */
+int messages_init(void);
+
+/* This gets called right before server finishes
+ */
+void messages_exit(void);
+
+/* Starts a new MAP session.
+ *
+ * session: variable to store pointer to backend session data. This one shall be
+ * passed to all in-session calls.
+ *
+ * If session start succeeded, backend shall return 0. Otherwise the error value
+ * will be sent as a response to OBEX connect.
+ */
+int messages_connect(void **session);
+
+/* Closes a MAP session.
+ *
+ * This call should free buffer reserved by messages_connect.
+ */
+void messages_disconnect(void *session);
+
+/******************************************************************************
+ * NOTE on callbacks.
+ *
+ * All functions requiring callbacks have to call them asynchronously.
+ * 'user_data' is for passing arbitrary user data.
+ *
+ * If 'err' is negative it is used to send error to the
+ * OBEX request.
+ *
+ * The special case is err == -EAGAIN. This notifies transport
+ * plugin to not wake IO. This is especially useful to postpone sending
+ * application headers if backend did not set proper return values for
+ * parameters yet.
+ *
+ * In case of folder/message listing and get message, end of data is indicated
+ * by calling callback with parameter carrying data (e.g. chunk) set to NULL.
+ ******************************************************************************/
+
+/* Registers for messaging events notifications.
+ *
+ * session: Backend session.
+ * enable: If true, register, otherwise unregister.
+ * send_event: Function that will be called to indicate a new event.
+ */
+int messages_set_notification_registration(void *session,
+ void (*send_event)(void *session,
+ struct messages_event *event, void *user_data),
+ void *user_data);
+
+/* Changes current directory.
+ *
+ * session: Backend session.
+ * name: Subdirectory to go to. If empty or null and cdup is false, go to the
+ * root directory.
+ * cdup: If true, go up one level first.
+ */
+int messages_set_folder(void *session, const char *name, gboolean cdup);
+
+/* Retrieves subdirectories listing from a current directory.
+ *
+ * session: Backend session.
+ * name: Optional subdirectory name (not strictly required by MAP).
+ * max: Maximum number of entries to retrieve.
+ * offset: Offset of the first entry.
+ *
+ * Callback shall be called for every entry of the listing. 'name' is the
+ * subdirectory name.
+ */
+int messages_get_folder_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset,
+ void (*callback)(void *session, int err, const char *name,
+ void *user_data),
+ void *user_data);
+
+/* Retrieves messages listing from a current directory.
+ *
+ * session: Backend session.
+ * name: Optional subdirectory name.
+ * max: Maximum number of entries to retrieve.
+ * filter: Filter to apply on returned message listing.
+ * size: Pointer to return message listing size.
+ * newmsg: Pointer to return indicator of presence of unread messages.
+ *
+ * Callback shall be called for every entry of the listing, giving message data
+ * in 'message'.
+ */
+int messages_get_messages_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset, struct messages_filter *filter,
+ uint16_t *size, gboolean *newmsg,
+ void (*callback)(void *session, int err,
+ const struct messages_message *message, void *user_data),
+ void *user_data);
+
+/* Retrieves bMessage object (see MAP specification, ch. 3.1.3) of a given
+ * message.
+ *
+ * session: Backend session.
+ * handle: Handle of the message to retrieve.
+ * attachment: Selects whether or not attachments (if any) are to be included.
+ * utf8: If true, convert message to utf-8. Otherwise use native encoding.
+ * fraction: If true, deliver fractioned message.
+ * next: If fraction is true this indicates whether to retrieve first fraction
+ * or the next one.
+ * fmore: Pointer to return indicator of whether next fraction is available.
+ *
+ * Callback allows for returning bMessage in chunks.
+ */
+int messages_get_message(void *session,
+ const char *handle,
+ gboolean attachment, gboolean utf8,
+ gboolean fraction, gboolean next,
+ gboolean *fmore,
+ void (*callback)(void *session, int err, const char *chunk,
+ void *user_data),
+ void *user_data);
+
+/* Aborts currently pending request.
+ *
+ * session: Backend session.
+ */
+void messages_abort(void *session);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH 1/3] Remove connectable checking when creating a device
From: Johan Hedberg @ 2011-05-05 9:16 UTC (permalink / raw)
To: Anderson Lizardo; +Cc: linux-bluetooth, Claudio Takahasi
In-Reply-To: <1304518429-8527-1-git-send-email-anderson.lizardo@openbossa.org>
Hi,
On Wed, May 04, 2011, Anderson Lizardo wrote:
> Kernel advertising cache will be used to infer the LE address type
> and if it is connectable. For kernels without cache patches, only
> LE public address is supported and if the remote is non-connectable,
> the connection will fail after the L2CAP timeout(~40s).
>
> Note: currently, CreateDevice misbehaves when LE Create Connection
> command times out for any reason (e.g. peer device left connectable
> mode). This is being investigated and will be fixed in a separate patch.
> ---
> src/adapter.c | 30 +++---------------------------
> 1 files changed, 3 insertions(+), 27 deletions(-)
All three patches have been pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH] Remove unused variable
From: Johan Hedberg @ 2011-05-05 9:14 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1304530367-18791-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Wed, May 04, 2011, Claudio Takahasi wrote:
> ---
> src/adapter.c | 5 -----
> 1 files changed, 0 insertions(+), 5 deletions(-)
Pushed upstream. Thanks.
Johan
^ permalink raw reply
* Re: [PATCH v2 00/13] Discovery Cleanup - Step 1
From: Johan Hedberg @ 2011-05-05 8:34 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1304458330-21499-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Tue, May 03, 2011, Claudio Takahasi wrote:
> This patch series is the first step to cleanup the device discovery
> procedure. The main changes are:
> - Unify advertising reports and inquiry results: mgmt sends
> one device found event
> - Logic improvement/cleanup: device found
> - Move EIR functions to a new file
> - Add BDADDR type constants: necessary L2CAP connections and bonding
>
>
>
> Bruna Moreira (3):
> Remove btd_event_advertising_report
> Replace EIR_DATA_LENGTH with HCI_MAX_EIR_LENGTH
> Drop variable EIR length
>
> Claudio Takahasi (10):
> Move EIR related functions to a new file
> Add Bluetooth address type definition
> Initial device found cleanup
> Move legacy verification to a new function
> Cleanup read name and alias from storage
> Don't resolve name if the name is in the storage
> Unify inquiry results and advertises
> Fix memory leak of EIR data
> Change the order to write/read the remote's name
> Cleanup inserting new device found entry
>
> Makefile.am | 2 +-
> lib/bluetooth.h | 4 +
> plugins/hciops.c | 202 +++++----------------------------
> plugins/mgmtops.c | 3 +-
> src/adapter.c | 182 +++++++++++++++++++-----------
> src/adapter.h | 9 +-
> src/eir.c | 328 +++++++++++++++++++++++++++++++++++++++++++++++++++++
> src/eir.h | 41 +++++++
> src/event.c | 224 +-----------------------------------
> src/event.h | 5 +-
> src/sdpd.h | 14 ---
> 11 files changed, 530 insertions(+), 484 deletions(-)
> create mode 100644 src/eir.c
> create mode 100644 src/eir.h
These patches don't seem to apply any more after I applied Andrés
patches. (also, I can't really try applying anything else except 1/13
since 2/13 is already the address type patch which is still being
discussed).
Johan
^ permalink raw reply
* Re: [RFC 00/16] Discovery procedure refactoring
From: Johan Hedberg @ 2011-05-05 8:26 UTC (permalink / raw)
To: Andre Guedes; +Cc: linux-bluetooth
In-Reply-To: <1304123252-14464-1-git-send-email-andre.guedes@openbossa.org>
Hi André,
On Fri, Apr 29, 2011, Andre Guedes 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(-)
All patches in this set have been pushed upstream. Thanks.
There seems to be at least one race condition that'd need fixing which I
can see with test-discovery: if the D-Bus client that requested
discovery exits like test-discovery does it can occur between sending
the HCI_Inquiry command but before the cmd_status or first inquiry event
arrives. In this case the adapter state doesn't seem to be yet updated
and so the ongoing inquiry doesn't get canceled even if it should. You
should be able to see this simply by running hcidump together with
test-discovery e.g. on your laptop.
Johan
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Luiz Augusto von Dentz @ 2011-05-05 8:05 UTC (permalink / raw)
To: Elvis Pfützenreuter; +Cc: Anderson Briglia, linux-bluetooth
In-Reply-To: <EE9AF3E8-0C89-4B05-93F1-D77B46A7BAF7@signove.com>
Hi,
On Thu, May 5, 2011 at 2:23 AM, Elvis Pfützenreuter <epx@signove.com> wrote:
> On 4 May 2011, at 20:09 , Anderson Briglia wrote:
>
>> Hi Johan,
>>
>> On Wed, May 4, 2011 at 5:39 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>>> Hi,
>>>
>>> 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);
>>>
>>> So are we going to get an updated patch for this (with the modifications
>>> that were requested)? It's quite clearly a false positive by the
>>> compiler (i.e. a compiler bug) but I still think that we should try to
>>> keep the BlueZ tree compilable with "./bootstrap-configure && make" for
>>> all major distributions.
>>
>> Elvis is going to open a bug in Ubuntu bug system regarding this false
>> positive. I believe it is worth to wait what Ubuntu developers will
>> say.
I don't see why it would be ubuntu specific, this seems to be some
kind of regression/'feature' with gcc 4.5.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* RE: BT 3.0 HS Support in BlueZ
From: Arun Kumar SINGH @ 2011-05-05 7:26 UTC (permalink / raw)
To: Gustavo F. Padovan, Anurag Gupta; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <20110419180425.GA2476@joana>
Hi Gustavo,
>> Does anybody know if
>bluetooth 3.0 HS spec is
>supported in BlueZ?
>> Is AMP supported in BlueZ?
>
>There is two different
>implementations, one by
>Atheros and another by QuIC.
>Both never reach upstream,
>if you look to the list logs
>you will find them.
Any hopes of getting this unified version upstream anytime in near future? I guess this has been on the cards for some time now given that merge process started last august.
I am trying to understand the options other folks may have, who may be interested in having 3.0 support in Bluez. Rewriting entire 3.0 support from scratch may be one thing that should be avoided as long as current upstreaming activity doesn't end up in a dead trail. Which I assume, it hadn't.
Thanks,
Arun
^ permalink raw reply
* Re: [PATCH v2 02/13] Add Bluetooth address type definition
From: Vinicius Costa Gomes @ 2011-05-05 0:31 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <20110504060357.GA3711@jh-x301>
Hi,
On 09:03 Wed 04 May, Johan Hedberg wrote:
> Hi Claudio,
>
> On Tue, May 03, 2011, Claudio Takahasi wrote:
> > Values defined to LE(public and random) are defined in the Bluetooth
> > Core Specification. For basic rate, there isn't address type concept.
> > The constants introduced by this commit will be used to identify the
> > remote address type, basically to distinguish LE/BR devices before
> > to request the L2CAP connection.
> > ---
> > lib/bluetooth.h | 4 ++++
> > 1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/lib/bluetooth.h b/lib/bluetooth.h
> > index 738e07a..98b8f1c 100644
> > --- a/lib/bluetooth.h
> > +++ b/lib/bluetooth.h
> > @@ -130,6 +130,10 @@ typedef struct {
> > #define BDADDR_ALL (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})
> > #define BDADDR_LOCAL (&(bdaddr_t) {{0, 0, 0, 0xff, 0xff, 0xff}})
> >
> > +#define BDADDR_TYPE_LE_PUBLIC 0x00
> > +#define BRADDR_TYPE_LE_RANDOM 0x01
> > +#define BDADDR_TYPE_BR 0xff
>
> Firstly this still needs Marcel's blessing (though I don't really see
> any other solution than an address type with three possible values).
> Secondly, if this is ever going to be added to the L2CAP socket address
> you'd have to have 0x00 as BDADDR_TYPE_BR for backwards compatibility.
>
As Claudio explained in an earlier email, we will need a way to get the
device type when the connection with that device starts
(MGMT_EV_DEVICE_CONNECTED), with hciops we can infer the type if we receive
the LE Meta Event.
My question is: should the event have a bdaddr_type field or a type field?
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers,
--
Vinicius
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Elvis Pfützenreuter @ 2011-05-04 23:23 UTC (permalink / raw)
To: Anderson Briglia; +Cc: linux-bluetooth
In-Reply-To: <BANLkTikbokOzYmnbPGcLGPVV_qJUCf3SkQ@mail.gmail.com>
On 4 May 2011, at 20:09 , Anderson Briglia wrote:
> Hi Johan,
>
> On Wed, May 4, 2011 at 5:39 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
>> Hi,
>>
>> 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);
>>
>> So are we going to get an updated patch for this (with the modifications
>> that were requested)? It's quite clearly a false positive by the
>> compiler (i.e. a compiler bug) but I still think that we should try to
>> keep the BlueZ tree compilable with "./bootstrap-configure && make" for
>> all major distributions.
>
> Elvis is going to open a bug in Ubuntu bug system regarding this false
> positive. I believe it is worth to wait what Ubuntu developers will
> say.
I have reported the bug yesterday
(https://bugs.launchpad.net/ubuntu/+source/gcc-defaults/+bug/776447),
but don't hold your breath while waiting for a response, you *will* die :)
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Anderson Briglia @ 2011-05-04 23:09 UTC (permalink / raw)
To: anderson.briglia, linux-bluetooth
In-Reply-To: <20110504213936.GA22493@jh-x301>
Hi Johan,
On Wed, May 4, 2011 at 5:39 PM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi,
>
> 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);
>
> So are we going to get an updated patch for this (with the modifications
> that were requested)? It's quite clearly a false positive by the
> compiler (i.e. a compiler bug) but I still think that we should try to
> keep the BlueZ tree compilable with "./bootstrap-configure && make" for
> all major distributions.
Elvis is going to open a bug in Ubuntu bug system regarding this false
positive. I believe it is worth to wait what Ubuntu developers will
say.
Briglia
>
> Johan
>
--
INdT - Instituto Nokia de tecnologia
+55 2126 1122
http://techblog.briglia.net
^ permalink raw reply
* Re: [PATCH] Remove btio.c compilation warning
From: Johan Hedberg @ 2011-05-04 21:39 UTC (permalink / raw)
To: anderson.briglia; +Cc: linux-bluetooth
In-Reply-To: <4dbf1776.0bd9650a.1733.7e99@mx.google.com>
Hi,
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);
So are we going to get an updated patch for this (with the modifications
that were requested)? It's quite clearly a false positive by the
compiler (i.e. a compiler bug) but I still think that we should try to
keep the BlueZ tree compilable with "./bootstrap-configure && make" for
all major distributions.
Johan
^ permalink raw reply
* [PATCH] Remove unused variable
From: Claudio Takahasi @ 2011-05-04 17:32 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
---
src/adapter.c | 5 -----
1 files changed, 0 insertions(+), 5 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 8dbd62c..426df15 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3255,8 +3255,6 @@ void adapter_add_connection(struct btd_adapter *adapter,
void adapter_remove_connection(struct btd_adapter *adapter,
struct btd_device *device)
{
- bdaddr_t bdaddr;
-
DBG("");
if (!g_slist_find(adapter->connections, device)) {
@@ -3268,9 +3266,6 @@ void adapter_remove_connection(struct btd_adapter *adapter,
adapter->connections = g_slist_remove(adapter->connections, device);
- /* clean pending HCI cmds */
- device_get_address(device, &bdaddr);
-
if (device_is_authenticating(device))
device_cancel_authentication(device, TRUE);
--
1.7.5.rc3
^ permalink raw reply related
* Re: [PATCH] bluetooth: Fix for security block issue.
From: Luiz Augusto von Dentz @ 2011-05-04 15:03 UTC (permalink / raw)
To: Lukasz.Rymanowski
Cc: mika.linnanoja, linux-bluetooth, ville.tervo, antti.julku, marcel,
linus.walleij, par-gunnar.p.hjalmdahl, padovan
In-Reply-To: <7D7F2FD3846CF6429ACEBDFB5A2DD86F07F33ED77A@EXMB01.eu.tieto.com>
Hi,
On Wed, May 4, 2011 at 10:53 AM, <Lukasz.Rymanowski@tieto.com> wrote:
> On Thu, Apr 28, 2011 at 12:39:37PM +0300, Antti Julku wrote:
>> It's easy to reproduce at least with these dongles:
>>
>> Alink BLUEUSB21 (BCM)
>> Belkin BT2.1 F8T017 (BCM)
>> DeLock 2.1 (CSR)
>> PTS 2.1 (CSR)
>>
>> So most of our BT 2.1 dongles seem to be buggy. It would be nice to
>> have a workaround since it happens with so many dongles.
>
> If there is so many buggy devices I think Gustavo and Marcel could consider to take this patch.
>
> On 04/28/2011 12:51 PM, ext Ville Tervo wrote:
>> Could the actual reason be some change in usb stack? Could it have
>> lower priority for event pipe than for data pipe? In that case event
>> for security change might arrive to bt stack too late.
>>
>> At lest I haven't seen this kind of behaviour with serial attached
>> chips. So I think this is something USB specific.
>
> I found the problem on serial attached chip.
> Before I received fix in the chip I used that patch for couple months without the problems.
I guess it worth checking if there is some priority inversion like
Ville suggested or it could be somehow related to RFCOMM, not long ago
I fixed a bug to the security level of the rfcomm socket to be applied
also to l2cap maybe it affects this.
Another thing that I noticed is that this check for psm 1 may be to
strict, there could be situation where an application want to
BT_SECURITY_SDP on some arbitrary/non-reserved psm, which currently is
possible with psm 3 (RFCOMM) since it only checks for sec.level >
BT_SECURITY_HIGH (see rfcomm_sock_setsockopt:710, bug?), but it can't
because of this security block will prevent any connection attempt.
--
Luiz Augusto von Dentz
Computer Engineer
^ permalink raw reply
* [PATCH 3/3] Remove flags2type() function
From: Anderson Lizardo @ 2011-05-04 14:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Anderson Lizardo
In-Reply-To: <1304518429-8527-1-git-send-email-anderson.lizardo@openbossa.org>
This function was only being used by create_device_internal(). It is
generating incorrect information when a single mode LE device has flags
0x02 (General Discoverable Mode), it was being "detected" as Dual Mode,
and thus the adapter was attempting to connect through BR/EDR.
This commit fixes CreateDevice() for these devices, but it is a partial
solution. In future, we should drop the "device type" enumeration, as
this information will come from kernel "device found" events.
Also note that the "DEVICE_TYPE_DUALMODE" enumeration is not really
being used, so it will probably disappear too.
---
src/adapter.c | 22 ++--------------------
1 files changed, 2 insertions(+), 20 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index aa8f5d4..609e3d5 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -1631,24 +1631,6 @@ static DBusMessage *cancel_device_creation(DBusConnection *conn,
return dbus_message_new_method_return(msg);
}
-static device_type_t flags2type(uint8_t flags)
-{
- /* Inferring the remote type based on the EIR Flags field */
-
- /* For LE only and dual mode the following flags must be zero */
- if (flags & (EIR_SIM_CONTROLLER | EIR_SIM_HOST))
- return DEVICE_TYPE_UNKNOWN;
-
- /* Limited or General discoverable mode bit must be enabled */
- if (!(flags & (EIR_LIM_DISC | EIR_GEN_DISC)))
- return DEVICE_TYPE_UNKNOWN;
-
- if (flags & EIR_BREDR_UNSUP)
- return DEVICE_TYPE_LE;
- else
- return DEVICE_TYPE_DUALMODE;
-}
-
static struct btd_device *create_device_internal(DBusConnection *conn,
struct btd_adapter *adapter,
const gchar *address, int *err)
@@ -1662,8 +1644,8 @@ static struct btd_device *create_device_internal(DBusConnection *conn,
match.name_status = NAME_ANY;
dev = adapter_search_found_devices(adapter, &match);
- if (dev && dev->flags)
- type = flags2type(dev->flags);
+ if (dev && dev->le)
+ type = DEVICE_TYPE_LE;
else
type = DEVICE_TYPE_BREDR;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/3] Remove advertise event type from adapter functions
From: Anderson Lizardo @ 2011-05-04 14:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
In-Reply-To: <1304518429-8527-1-git-send-email-anderson.lizardo@openbossa.org>
From: Claudio Takahasi <claudio.takahasi@openbossa.org>
---
src/adapter.c | 9 ++++-----
src/adapter.h | 5 ++---
src/event.c | 4 ++--
3 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 82002e7..aa8f5d4 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -3059,18 +3059,17 @@ static void dev_prepend_uuid(gpointer data, gpointer user_data)
void adapter_update_device_from_info(struct btd_adapter *adapter,
bdaddr_t bdaddr, int8_t rssi,
- uint8_t evt_type, const char *name,
- GSList *services, int flags)
+ const char *name, GSList *services,
+ int flags)
{
struct remote_dev_info *dev;
gboolean new_dev;
dev = get_found_dev(adapter, &bdaddr, &new_dev);
- if (new_dev) {
+ if (new_dev)
dev->le = TRUE;
- dev->evt_type = evt_type;
- } else if (dev->rssi == rssi)
+ else if (dev->rssi == rssi)
return;
dev->rssi = rssi;
diff --git a/src/adapter.h b/src/adapter.h
index 7cc7c02..a305fa7 100644
--- a/src/adapter.h
+++ b/src/adapter.h
@@ -84,7 +84,6 @@ struct remote_dev_info {
char **uuids;
size_t uuid_count;
GSList *services;
- uint8_t evt_type;
uint8_t bdaddr_type;
uint8_t flags;
};
@@ -120,8 +119,8 @@ struct remote_dev_info *adapter_search_found_devices(struct btd_adapter *adapter
struct remote_dev_info *match);
void adapter_update_device_from_info(struct btd_adapter *adapter,
bdaddr_t bdaddr, int8_t rssi,
- uint8_t evt_type, const char *name,
- GSList *services, int flags);
+ const char *name, GSList *services,
+ int flags);
void adapter_update_found_devices(struct btd_adapter *adapter, bdaddr_t *bdaddr,
int8_t rssi, uint32_t class, const char *name,
const char *alias, gboolean legacy,
diff --git a/src/event.c b/src/event.c
index 5373e33..c9d8d8c 100644
--- a/src/event.c
+++ b/src/event.c
@@ -399,8 +399,8 @@ void btd_event_advertising_report(bdaddr_t *local, le_advertising_info *info)
rssi = *(info->data + info->length);
adapter_update_device_from_info(adapter, info->bdaddr, rssi,
- info->evt_type, eir_data.name,
- eir_data.services, eir_data.flags);
+ eir_data.name, eir_data.services,
+ eir_data.flags);
free_eir_data(&eir_data);
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/3] Remove connectable checking when creating a device
From: Anderson Lizardo @ 2011-05-04 14:13 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Claudio Takahasi
From: Claudio Takahasi <claudio.takahasi@openbossa.org>
Kernel advertising cache will be used to infer the LE address type
and if it is connectable. For kernels without cache patches, only
LE public address is supported and if the remote is non-connectable,
the connection will fail after the L2CAP timeout(~40s).
Note: currently, CreateDevice misbehaves when LE Create Connection
command times out for any reason (e.g. peer device left connectable
mode). This is being investigated and will be fixed in a separate patch.
---
src/adapter.c | 30 +++---------------------------
1 files changed, 3 insertions(+), 27 deletions(-)
diff --git a/src/adapter.c b/src/adapter.c
index 8dbd62c..82002e7 100644
--- a/src/adapter.c
+++ b/src/adapter.c
@@ -71,9 +71,6 @@
#define EIR_SIM_HOST 0x10 /* Simultaneous LE and BR/EDR to Same
Device Capable (Host) */
-#define ADV_TYPE_IND 0x00
-#define ADV_TYPE_DIRECT_IND 0x01
-
#define IO_CAPABILITY_DISPLAYONLY 0x00
#define IO_CAPABILITY_DISPLAYYESNO 0x01
#define IO_CAPABILITY_KEYBOARDONLY 0x02
@@ -1652,21 +1649,9 @@ static device_type_t flags2type(uint8_t flags)
return DEVICE_TYPE_DUALMODE;
}
-static gboolean event_is_connectable(uint8_t type)
-{
- switch (type) {
- case ADV_TYPE_IND:
- case ADV_TYPE_DIRECT_IND:
- return TRUE;
- default:
- return FALSE;
- }
-}
-
static struct btd_device *create_device_internal(DBusConnection *conn,
struct btd_adapter *adapter,
- const gchar *address,
- gboolean force, int *err)
+ const gchar *address, int *err)
{
struct remote_dev_info *dev, match;
struct btd_device *device;
@@ -1682,14 +1667,6 @@ static struct btd_device *create_device_internal(DBusConnection *conn,
else
type = DEVICE_TYPE_BREDR;
- if (!force && type == DEVICE_TYPE_LE &&
- !event_is_connectable(dev->evt_type)) {
- if (err)
- *err = -ENOTCONN;
-
- return NULL;
- }
-
device = adapter_create_device(conn, adapter, address, type);
if (!device && err)
*err = -ENOMEM;
@@ -1721,7 +1698,7 @@ static DBusMessage *create_device(DBusConnection *conn,
DBG("%s", address);
- device = create_device_internal(conn, adapter, address, TRUE, &err);
+ device = create_device_internal(conn, adapter, address, &err);
if (!device)
goto failed;
@@ -1802,8 +1779,7 @@ static DBusMessage *create_paired_device(DBusConnection *conn,
device = adapter_find_device(adapter, address);
if (!device) {
- device = create_device_internal(conn, adapter, address,
- FALSE, &err);
+ device = create_device_internal(conn, adapter, address, &err);
if (!device)
return btd_error_failed(msg, strerror(-err));
}
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH v2 02/13] Add Bluetooth address type definition
From: Anderson Lizardo @ 2011-05-04 11:14 UTC (permalink / raw)
To: Claudio Takahasi, linux-bluetooth
In-Reply-To: <20110504060357.GA3711@jh-x301>
Hi Johan,
On Wed, May 4, 2011 at 2:03 AM, Johan Hedberg <johan.hedberg@gmail.com> wrote:
> Hi Claudio,
>
> On Tue, May 03, 2011, Claudio Takahasi wrote:
>> Values defined to LE(public and random) are defined in the Bluetooth
>> Core Specification. For basic rate, there isn't address type concept.
>> The constants introduced by this commit will be used to identify the
>> remote address type, basically to distinguish LE/BR devices before
>> to request the L2CAP connection.
>> ---
>> lib/bluetooth.h | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/lib/bluetooth.h b/lib/bluetooth.h
>> index 738e07a..98b8f1c 100644
>> --- a/lib/bluetooth.h
>> +++ b/lib/bluetooth.h
>> @@ -130,6 +130,10 @@ typedef struct {
>> #define BDADDR_ALL (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})
>> #define BDADDR_LOCAL (&(bdaddr_t) {{0, 0, 0, 0xff, 0xff, 0xff}})
>>
>> +#define BDADDR_TYPE_LE_PUBLIC 0x00
>> +#define BRADDR_TYPE_LE_RANDOM 0x01
>> +#define BDADDR_TYPE_BR 0xff
>
> Firstly this still needs Marcel's blessing (though I don't really see
> any other solution than an address type with three possible values).
> Secondly, if this is ever going to be added to the L2CAP socket address
> you'd have to have 0x00 as BDADDR_TYPE_BR for backwards compatibility.
The values for LE public/random were chosen to match the "address
type" field on HCI LE commands. We can of course use other values and
map to the HCI ones.
Also, as mentioned on the cover letter of the first version, we have
suggested using "BDADDR_TYPE_NON_LE" instead of "BDADDR_TYPE_BR", to
make it clear that value is more a "fallback" for non-LE addresses.
IIRC there is no current plan to put these types on the socket address
struct (the idea is to use, for instance, on device found events), but
if we go that path, I agree using 0x00 for BR/EDR makes more sense.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [PATCH] Add partial mas.c - messages-*.c API.
From: Daniele Forsi @ 2011-05-04 10:53 UTC (permalink / raw)
To: Slawomir Bochenski; +Cc: linux-bluetooth
In-Reply-To: <1304505628-21965-1-git-send-email-lkslawek@gmail.com>
2011/5/4 Slawomir Bochenski:
> diff --git a/plugins/messages.h b/plugins/messages.h
> + * ordered by PARAMETERMASK. Boolean values should be probably
> + * always send (need checking). Handle is mandatory. Plugin will filter out any
nitpicking: s/send/sent/
> + * If session start succeeded, backend shall return 0. Otherwise the error value
> + * will be send as a response to OBEX connect.
s/send/sent/
--
Daniele Forsi
^ permalink raw reply
* [PATCH] Add partial mas.c - messages-*.c API.
From: Slawomir Bochenski @ 2011-05-04 10:40 UTC (permalink / raw)
To: linux-bluetooth; +Cc: Slawomir Bochenski
This adds stubs of functions needed for message browsing and retrieval.
---
plugins/messages-dummy.c | 69 ++++++++++++++
plugins/messages.h | 226 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 295 insertions(+), 0 deletions(-)
diff --git a/plugins/messages-dummy.c b/plugins/messages-dummy.c
index fd9679d..d72ebe2 100644
--- a/plugins/messages-dummy.c
+++ b/plugins/messages-dummy.c
@@ -25,4 +25,73 @@
#include <config.h>
#endif
+#include <errno.h>
+
#include "messages.h"
+
+int messages_init(void)
+{
+ return 0;
+}
+
+void messages_exit(void)
+{
+}
+
+int messages_connect(void **session)
+{
+ *session = 0;
+ return 0;
+}
+
+void messages_disconnect(void *session)
+{
+}
+
+int messages_set_notification_registration(void *session,
+ gboolean enable,
+ void (*send_event)(void *data, struct messages_event_data *event),
+ void *data)
+{
+ return -EINVAL;
+}
+
+int messages_set_folder(void *session, const char *name, gboolean cdup)
+{
+ return -EINVAL;
+}
+
+int messages_get_folder_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset,
+ void (*callback)(void *data, int err, const char *name),
+ void *data)
+{
+ return -EINVAL;
+}
+
+int messages_get_messages_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset, struct messages_filter *filter,
+ uint16_t *size, gboolean *newmsg,
+ void (*callback)(void *data, int err,
+ const struct messages_mdata *message),
+ void *data)
+{
+ return -EINVAL;
+}
+
+int messages_get_message(void *session,
+ const char *handle,
+ gboolean attachment, gboolean utf8,
+ gboolean fraction, gboolean next,
+ gboolean *fmore,
+ void (*callback)(void *data, int err, const char *chunk),
+ void *data)
+{
+ return -EINVAL;
+}
+
+void messages_abort(void *session)
+{
+}
diff --git a/plugins/messages.h b/plugins/messages.h
index c510244..50a0392 100644
--- a/plugins/messages.h
+++ b/plugins/messages.h
@@ -20,3 +20,229 @@
* Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
*
*/
+
+#include <glib.h>
+#include <stdint.h>
+
+/* Those are used by backend to notify transport plugin which properties did it
+ * send.
+ */
+#define PMASK_SUBJECT 0x0001
+#define PMASK_DATETIME 0x0002
+#define PMASK_SENDER_NAME 0x0004
+#define PMASK_SENDER_ADDRESSING 0x0008
+#define PMASK_RECIPIENT_NAME 0x0010
+#define PMASK_RECIPIENT_ADDRESSING 0x0020
+#define PMASK_TYPE 0x0040
+#define PMASK_SIZE 0x0080
+#define PMASK_RECEPTION_STATUS 0x0100
+#define PMASK_TEXT 0x0200
+#define PMASK_ATTACHMENT_SIZE 0x0400
+#define PMASK_PRIORITY 0x0800
+#define PMASK_READ 0x1000
+#define PMASK_SENT 0x2000
+#define PMASK_PROTECTED 0x4000
+#define PMASK_REPLYTO_ADDRESSING 0x8000
+
+/* This one is used in a response to GetMessagesListing. Use PMASK_* values to
+ * notify the plugin which members are actually set. Backend shall not omit
+ * properties required by MAP specification (subject, datetime,
+ * recipient_addressing, type, size, reception_status, attachment_size) unless
+ * ordered by PARAMETERMASK. Boolean values should be probably
+ * always send (need checking). Handle is mandatory. Plugin will filter out any
+ * properties that were not wanted by MCE.
+ *
+ * Handle shall be set to hexadecimal representation with upper-case letters. No
+ * prefix shall be appended and without no zeros. This corresponds to PTS
+ * behaviour described in comments to the MAP specification.
+ *
+ * The rest of char * fields shall be set according to the MAP specification
+ * rules.
+ */
+struct messages_mdata {
+ uint32_t mask;
+ char *handle;
+ char *subject;
+ char *datetime;
+ char *sender_name;
+ char *sender_addressing;
+ char *replyto_addressing;
+ char *recipient_name;
+ char *recipient_addressing;
+ char *type;
+ char *reception_status;
+ char *size;
+ char *attachment_size;
+ gboolean text;
+ gboolean read;
+ gboolean sent;
+ gboolean protect;
+ gboolean priority;
+};
+
+/* Type of message event to be delivered to MNS server */
+enum messages_event_type {
+ MET_NEW_MESSAGE,
+ MET_DELIVERY_SUCCESS,
+ MET_SENDING_SUCCESS,
+ MET_DELIVERY_FAILURE,
+ MET_SENDING_FAILURE,
+ MET_MEMORY_FULL,
+ MET_MEMORY_AVAILABLE,
+ MET_MESSAGE_DELETED,
+ MET_MESSAGE_SHIFT
+};
+
+/* Data for sending MNS notification. Handle shall be formatted as described in
+ * messages_mdata.
+ */
+struct messages_event_data {
+ enum messages_event_type type;
+ uint8_t instance_id;
+ char *handle;
+ char *folder;
+ char *old_folder;
+ char *msg_type;
+};
+
+/* parameter_mask: |-ed PMASK_* values
+ * See MAP specification for the rest.
+ */
+struct messages_filter {
+ uint32_t parameter_mask;
+ uint8_t type;
+ char *period_begin;
+ char *period_end;
+ uint8_t *read_status;
+ char *recipient;
+ char *originator;
+ uint8_t priority;
+};
+
+/* This is called once after server starts.
+ *
+ * Returns value less than zero if error. This will prevent MAP plugin from
+ * starting.
+ */
+int messages_init(void);
+
+/* This gets called right before server finishes
+ */
+void messages_exit(void);
+
+/* Starts a new MAP session.
+ *
+ * session: variable to store pointer to backend session data. This one shall be
+ * passed to all in-session calls.
+ *
+ * If session start succeeded, backend shall return 0. Otherwise the error value
+ * will be send as a response to OBEX connect.
+ */
+int messages_connect(void **session);
+
+/* Closes a MAP session.
+ *
+ * This call should free buffer reserved by messages_connect.
+ */
+void messages_disconnect(void *session);
+
+/******************************************************************************
+ * NOTE on callbacks.
+ *
+ * All functions requiring callbacks have to call them asynchronously. 'data' is
+ * for passing user data.
+ *
+ * If 'err' is negative it is used to send error to the
+ * OBEX request.
+ *
+ * The special case is err == -EAGAIN. This notifies transport
+ * plugin to not wake IO. This is especially useful to postpone sending
+ * application headers if backend did not set proper return values for
+ * parameters yet.
+ *
+ * In case of folder/message listing and get message, end of data is indicated
+ * by calling callback with parameter carrying data (e.g. chunk) set to NULL.
+ ******************************************************************************/
+
+/* Registers for messaging events notifications.
+ *
+ * session: Backend session.
+ * enable: If true, register, otherwise unregister.
+ * send_event: Function that will be called to indicate a new event.
+ */
+int messages_set_notification_registration(void *session,
+ gboolean enable,
+ void (*send_event)(void *data, struct messages_event_data *event),
+ void *data);
+
+/* Changes current directory.
+ *
+ * session: Backend session.
+ * name: Subdirectory to go to. If empty or null and cdup is false, go to the
+ * root directory.
+ * cdup: If true, go up one level first.
+ */
+int messages_set_folder(void *session, const char *name, gboolean cdup);
+
+/* Retrieves subdirectories listing from a current directory.
+ *
+ * session: Backend session.
+ * name: Optional subdirectory name (not strictly required by MAP).
+ * max: Maximum number of entries to retrieve.
+ * offset: Offset of the first entry.
+ *
+ * Callback shall be called for every entry of the listing. 'name' is the
+ * subdirectory name.
+ */
+int messages_get_folder_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset,
+ void (*callback)(void *data, int err, const char *name),
+ void *data);
+
+/* Retrieves messages listing from a current directory.
+ *
+ * session: Backend session.
+ * name: Optional subdirectory name.
+ * max: Maximum number of entries to retrieve.
+ * filter: Filter to apply on returned message listing.
+ * size: Pointer to return message listing size.
+ * newmsg: Pointer to return indicator of presence of unread messages.
+ *
+ * Callback shall be called for every entry of the listing, giving message data
+ * in 'message'.
+ */
+int messages_get_messages_listing(void *session,
+ const char *name,
+ uint16_t max, uint16_t offset, struct messages_filter *filter,
+ uint16_t *size, gboolean *newmsg,
+ void (*callback)(void *data, int err,
+ const struct messages_mdata *message),
+ void *data);
+
+/* Retrieves bMessage object of given message.
+ *
+ * session: Backend session.
+ * handle: Handle of the message to retrieve.
+ * attachment: Selects whether or not attachments (if any) are to be included.
+ * utf8: If true, convert message to utf-8. Otherwise use native encoding.
+ * fraction: If true, deliver fractioned message.
+ * next: If fraction is true this indicates whether to retrieve first fraction
+ * or the next one.
+ * fmore: Pointer to return indicator of whether next fraction is available.
+ *
+ * Callback allows for returning bMessage in chunks.
+ */
+int messages_get_message(void *session,
+ const char *handle,
+ gboolean attachment, gboolean utf8,
+ gboolean fraction, gboolean next,
+ gboolean *fmore,
+ void (*callback)(void *data, int err, const char *chunk),
+ void *data);
+
+/* Aborts currently pending request.
+ *
+ * session: Backend session.
+ */
+void messages_abort(void *session);
--
1.7.4.1
^ permalink raw reply related
* [PATCH] Update params description of PIN Code Request
From: Waldemar Rymarkiewicz @ 2011-05-04 8:54 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, linux-bluetooth; +Cc: Waldemar Rymarkiewicz
---
doc/mgmt-api.txt | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/doc/mgmt-api.txt b/doc/mgmt-api.txt
index 45f6a64..353705e 100644
--- a/doc/mgmt-api.txt
+++ b/doc/mgmt-api.txt
@@ -484,6 +484,8 @@ Controller Index: <controller id>
Event Parameters Address (6 Octets)
Secure (1 Octet)
+ Secure: 0x01 secure PIN code required
+ 0x00 secure PIN code not required
User Confirmation Request Event
===============================
--
1.7.1
^ permalink raw reply related
* RE: [PATCH] bluetooth: Fix for security block issue.
From: Lukasz.Rymanowski @ 2011-05-04 7:53 UTC (permalink / raw)
To: mika.linnanoja, linux-bluetooth
Cc: ville.tervo, antti.julku, marcel, linus.walleij,
par-gunnar.p.hjalmdahl, padovan
In-Reply-To: <4DBA6D97.7050207@nokia.com>
On Thu, Apr 28, 2011 at 12:39:37PM +0300, Antti Julku wrote:
> It's easy to reproduce at least with these dongles:
>=20
> Alink BLUEUSB21 (BCM)
> Belkin BT2.1 F8T017 (BCM)
> DeLock 2.1 (CSR)
> PTS 2.1 (CSR)
>=20
> So most of our BT 2.1 dongles seem to be buggy. It would be nice to=20
> have a workaround since it happens with so many dongles.
If there is so many buggy devices I think Gustavo and Marcel could consider=
to take this patch.
On 04/28/2011 12:51 PM, ext Ville Tervo wrote:
> Could the actual reason be some change in usb stack? Could it have=20
> lower priority for event pipe than for data pipe? In that case event=20
> for security change might arrive to bt stack too late.
>
> At lest I haven't seen this kind of behaviour with serial attached=20
> chips. So I think this is something USB specific.
I found the problem on serial attached chip.
Before I received fix in the chip I used that patch for couple months witho=
ut the problems.
Br
Lukasz
^ permalink raw reply
* RE: [PATCH 1/2] Add secure param to Mgmt PIN Code Request Event
From: Waldemar.Rymarkiewicz @ 2011-05-04 7:52 UTC (permalink / raw)
To: marcel; +Cc: linux-bluetooth, johan.hedberg
In-Reply-To: <1304350260.15916.102.camel@aeonflux>
Hi Marcel,
>yes, we need these things documented.
>
>Obviously now the question is why not expose this as=20
>min_pin_length value?
>
Well, that's another approach, but for us it's only essential if the pin is=
16 digit or not. So, boolean it's enough in my opinion.
Moreover, if we go for min_pin_len a user should have a chance to set this =
value for instance an the socket. That means a new interface, obviously not=
appreciated. Otherwise, min_pin_len will be 16 or 0 (length not important)=
.
Thanks,
Waldek
^ permalink raw reply
* Re: [PATCH v2 02/13] Add Bluetooth address type definition
From: Johan Hedberg @ 2011-05-04 6:03 UTC (permalink / raw)
To: Claudio Takahasi; +Cc: linux-bluetooth
In-Reply-To: <1304458357-21571-1-git-send-email-claudio.takahasi@openbossa.org>
Hi Claudio,
On Tue, May 03, 2011, Claudio Takahasi wrote:
> Values defined to LE(public and random) are defined in the Bluetooth
> Core Specification. For basic rate, there isn't address type concept.
> The constants introduced by this commit will be used to identify the
> remote address type, basically to distinguish LE/BR devices before
> to request the L2CAP connection.
> ---
> lib/bluetooth.h | 4 ++++
> 1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/lib/bluetooth.h b/lib/bluetooth.h
> index 738e07a..98b8f1c 100644
> --- a/lib/bluetooth.h
> +++ b/lib/bluetooth.h
> @@ -130,6 +130,10 @@ typedef struct {
> #define BDADDR_ALL (&(bdaddr_t) {{0xff, 0xff, 0xff, 0xff, 0xff, 0xff}})
> #define BDADDR_LOCAL (&(bdaddr_t) {{0, 0, 0, 0xff, 0xff, 0xff}})
>
> +#define BDADDR_TYPE_LE_PUBLIC 0x00
> +#define BRADDR_TYPE_LE_RANDOM 0x01
> +#define BDADDR_TYPE_BR 0xff
Firstly this still needs Marcel's blessing (though I don't really see
any other solution than an address type with three possible values).
Secondly, if this is ever going to be added to the L2CAP socket address
you'd have to have 0x00 as BDADDR_TYPE_BR for backwards compatibility.
Johan
^ 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