[Bluez-devel] hcid D-Bus patch

[Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1.1: Type: text/plain, Size: 729 bytes --]

Hi Marcel,

I am sending the initial patch that implementing the skeleton
of the hcid D-Bus services.

Run hcid with a non-daemon option to see the output

Send the following messages to see the message handling.

dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
org.bluez.hci.PeriodicInqReq byte:1 byte:2 byte:3
dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
org.bluez.hci.CancelPeriodicInqReq
dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
org.bluez.hci.InquiryReq byte:1
dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
org.bluez.hci.RoleSwitchReq string:panu byte:1

Suggestions are welcome!

Regards,
Claudio.

[-- Attachment #1.2: Type: text/html, Size: 793 bytes --]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: hcid_dbus_0006.patch --]
[-- Type: text/x-patch; name="hcid_dbus_0006.patch", Size: 16047 bytes --]

--- bluez-utils-cvs.orig/hcid/Makefile.am	2005-09-14 08:51:58.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/Makefile.am	2005-09-15 17:03:22.000000000 -0300
@@ -13,7 +13,7 @@
 sbin_PROGRAMS = hcid
 
 if DBUS
-dbus_hcid_sources = dbus.c
+dbus_hcid_sources = common.c dbus.c
 dbus_hcid_libs    = @DBUS_LIBS@
 dbus_hcid_cflags  = -DENABLE_DBUS -DDBUS_API_SUBJECT_TO_CHANGE
 else
--- bluez-utils-cvs.orig/hcid/dbus-internal.h	1969-12-31 21:00:00.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus-internal.h	2005-09-16 11:33:09.049265392 -0300
@@ -0,0 +1,71 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <maxk@qualcomm.com>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <marcel@holtmann.org>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ *  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ *  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ *  CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES 
+ *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
+ *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
+ *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ *  ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS, 
+ *  COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS 
+ *  SOFTWARE IS DISCLAIMED.
+ *
+ *
+ *  $Id: dbus-internal.h,v 0.1 2005/09/16 08:00:00 holtmann Exp $
+ */
+ 
+#ifndef __H_BLUEZ_DBUS_INTERNAL_H__
+#define __H_BLUEZ_DBUS_INTERNAL_H__
+
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#include <stdint.h>
+#include <dbus/dbus.h>
+#include <errno.h>
+#include <signal.h>
+
+#include <sys/syslog.h>
+
+#include "dbus.h"
+
+typedef DBusMessage* (service_handler_func_t)(DBusMessage *, void *);
+
+typedef struct
+{
+	const char             *name;
+	service_handler_func_t *handler_func;
+	const char             *signature;
+}__attribute__((packed))service_table_t;
+
+typedef enum 
+{
+	RESULT_SUCCESS = 0,
+	RESULT_FAILED = 0x01,
+	RESULT_WRONG_PARAM = 0x02,
+	RESULT_BUSY = 0x04,
+	RESULT_ADAPTER_NOT_FOUND = 0x08,
+	RESULT_WRONG_SIG = 0x10,
+	RESULT_UNKNOWN_METHOD = 0x20,
+	RESULT_SVC_NOT_FOUND = 0x40,
+}__attribute__((packed)) EXEC_RESULT;
+
+
+DBusMessage *create_error_reply_message(DBusMessage *msg, const char *iface, EXEC_RESULT result);
+
+#endif /*__H_BLUEZ_DBUS_INTERNAL_H__*/
--- bluez-utils-cvs.orig/hcid/dbus.h	1969-12-31 21:00:00.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus.h	2005-09-16 11:33:38.448795984 -0300
@@ -0,0 +1,86 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <maxk@qualcomm.com>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <marcel@holtmann.org>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ *  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ *  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ *  CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES 
+ *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
+ *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
+ *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ *  ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS, 
+ *  COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS 
+ *  SOFTWARE IS DISCLAIMED.
+ *
+ *
+ *  $Id: dbus.h,v 0.1 2005/09/16 08:00:00 holtmann Exp $
+ */
+ 
+#ifndef __H_BLUEZ_DBUS_H__
+#define __H_BLUEZ_DBUS_H__
+
+#define __END_SIG__ DBUS_TYPE_INVALID_AS_STRING
+
+/* bluetoothd Bus name */
+#define BLUEZ_DBUS_NAME		"org.bluez"
+
+/* HCI definitions */
+#define BLUEZ_DBUS_HCI_PATH		"/org/bluez/hci"
+#define BLUEZ_DBUS_HCI_INTERFACE	BLUEZ_DBUS_NAME".hci"
+
+//HCI signals
+#define BLUEZ_DBUS_HCI_SIG_INQ_START		"InquiryStartSig"
+#define BLUEZ_DBUS_HCI_SIG_INQ_COMPLETE		"InquiryCompleteSig"
+#define BLUEZ_DBUS_HCI_SIG_INQ_RESULT		"InquiryResultSig"
+#define BLUEZ_DBUS_HCI_SIG_REMOTE_NAME		"RemoteNameSig"
+
+//HCI Provided services
+#define HCI_PERIODIC_INQ_REQ               "PeriodicInqReq"
+#define HCI_CANCEL_PERIODIC_INQ_REQ        "CancelPeriodicInqReq"
+#define HCI_INQ_REQ                        "InquiryReq"
+#define HCI_ROLE_SWITCH_REQ                "RoleSwitchReq"
+
+//HCI signatures
+#define HCI_PERIODIC_INQ_REQ_SIGNATURE		        DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+#define HCI_CANCEL_PERIODIC_INQ_REQ_SIGNATURE		__END_SIG__
+#define HCI_INQ_REQ_SIGNATURE                	    	DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+#define HCI_ROLE_SWITCH_REQ_SIGNATURE                   DBUS_TYPE_STRING_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+
+
+/* Common Error messages */
+#define ERR_UNKNOWN_METHOD      ".error.UnknowMethod"
+#define ERR_WRONG_SIGNATURE     ".error.WrongSignature"
+#define ERR_WRONG_PARAM         ".error.WrongParam"
+#define ERR_FAILED              ".error.Failed"
+#define ERR_REC_NOT_FOUND       ".error.RecordNotFound"
+#define ERR_BUSY                ".error.Busy"
+#define ERR_NO_DEV_FOUND                ".error.NoDevFound"
+
+#define ERR_MSG_INVALID_PARAMETERS     "Invalid parameters"
+#define ERR_MSG_NO_SVC_FOUND           "No service found"
+#define ERR_MSG_DEV_BUSY               "Device is busy"
+#define ERR_MSG_FAILED                 "Operation failed"
+#define ERR_MSG_NO_DEV_FOUND           "Active Bluetooth adapter not found"
+#define ERR_MSG_WRONG_SIG              "Wrong method signature"
+#define ERR_MSG_METHOD_NOT_FOUND       "Method not found on the interface"
+
+
+#endif /*__H_BLUEZ_DBUS_H__*/
--- bluez-utils-cvs.orig/hcid/dbus.c	2005-09-15 18:05:23.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus.c	2005-09-16 11:36:41.362988800 -0300
@@ -45,6 +45,7 @@
 #include "glib-ectomy.h"
 
 #include "hcid.h"
+#include "dbus-internal.h"
 
 static DBusConnection *connection;
 
@@ -62,6 +63,32 @@
 	bdaddr_t bda;
 };
 
+static DBusHandlerResult hci_msg_func(DBusConnection *conn, 
+				      DBusMessage *msg, void *data);
+
+static DBusMessage* handle_periodic_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_cancel_periodic_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_role_switch_req(DBusMessage *msg, void *data);
+
+				      
+static const DBusObjectPathVTable hci_vtable = {
+	NULL,
+	&hci_msg_func,
+	NULL,
+	NULL,
+	NULL,
+	NULL
+};
+
+static const service_table_t hci_services[] = {
+	{HCI_PERIODIC_INQ_REQ,        handle_periodic_inq_req,        HCI_PERIODIC_INQ_REQ_SIGNATURE},
+	{HCI_CANCEL_PERIODIC_INQ_REQ, handle_cancel_periodic_inq_req, HCI_CANCEL_PERIODIC_INQ_REQ_SIGNATURE},
+	{HCI_ROLE_SWITCH_REQ,         handle_role_switch_req,         HCI_ROLE_SWITCH_REQ_SIGNATURE},
+	{HCI_INQ_REQ,                 handle_inq_req,                 HCI_INQ_REQ_SIGNATURE},	
+	{NULL, NULL, NULL}
+};
+
 static void reply_handler_function(DBusPendingCall *call, void *user_data)
 {
 	struct pin_request *req = (struct pin_request *) user_data;
@@ -169,8 +196,9 @@
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryStart");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+					  BLUEZ_DBUS_HCI_INTERFACE, 
+					  BLUEZ_DBUS_HCI_SIG_INQ_START);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry start message");
 		goto failed;
@@ -203,8 +231,9 @@
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryComplete");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE, 
+				BLUEZ_DBUS_HCI_SIG_INQ_COMPLETE);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry complete message");
 		goto failed;
@@ -238,8 +267,9 @@
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryResult");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE, 
+				BLUEZ_DBUS_HCI_SIG_INQ_RESULT);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry result message");
 		goto failed;
@@ -277,8 +307,9 @@
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "RemoteName");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE,
+				BLUEZ_DBUS_HCI_SIG_REMOTE_NAME);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS remote name message");
 		goto failed;
@@ -388,15 +419,114 @@
 	dbus_error_init(&error);
 
 	connection = dbus_bus_get(DBUS_BUS_SYSTEM, &error);
+	
 	if (connection == NULL) {
 		fprintf(stderr, "Failed to open connection to system message bus: %s\n",
 			error.message);
 		dbus_error_free(&error);
 		return FALSE;
 	}
+	
+	dbus_bus_request_name(connection, BLUEZ_DBUS_NAME, 
+			      DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT, 
+			      &error);
+	
+	if (dbus_error_is_set (&error)) {
+		syslog(LOG_ERR,"D-Bus Error: %s\n", error.message);
+		dbus_error_free (&error);
+		return FALSE;
+	}
+	
+	if (!dbus_connection_register_object_path(connection, BLUEZ_DBUS_HCI_PATH, &hci_vtable, NULL)) {
+		syslog(LOG_ERR,"DBUS failed to register %s object", BLUEZ_DBUS_HCI_PATH);
+		return FALSE;
+	}
 
 	dbus_connection_set_watch_functions(connection,
 		add_watch, remove_watch, watch_toggled, NULL, NULL);
-
 	return TRUE;
 }
+
+/*****************************************************************
+ *  
+ *  Section reserved to D-Bus message handlers
+ *  
+ *****************************************************************/
+
+static DBusHandlerResult hci_msg_func(DBusConnection *conn, 
+				      DBusMessage *msg, void *data)
+{
+	const service_table_t *ptr_handlers =  hci_services;
+	DBusMessage *reply = NULL;
+	uint16_t type;
+	const char *iface;
+	const char *method;
+	const char *signature;
+	EXEC_RESULT result = RESULT_UNKNOWN_METHOD;
+	DBusHandlerResult ret = DBUS_HANDLER_RESULT_NOT_YET_HANDLED;;
+	
+	type = dbus_message_get_type(msg);
+	iface = dbus_message_get_interface(msg);
+	method = dbus_message_get_member (msg);
+	signature = dbus_message_get_signature(msg);
+	
+	syslog(LOG_INFO, "%s - type:%d, iface:%s, method:%s, sig:%s",__PRETTY_FUNCTION__, type, iface, method, signature);
+	
+	if ((type == DBUS_MESSAGE_TYPE_METHOD_CALL) && 
+		(strcmp(iface, BLUEZ_DBUS_HCI_INTERFACE) == 0) && 
+		(method != NULL)) {
+		
+		for (; ptr_handlers->name; ptr_handlers++) {
+			if (strcmp(method, ptr_handlers->name) == 0) {
+				/* resetting unknown method. It's possible handle method overload */
+				result = RESULT_WRONG_SIG; 
+				if (strcmp(ptr_handlers->signature, signature) == 0) {
+					reply = (ptr_handlers->handler_func)(msg, data);
+					result = 0; /* resetting wrong signature*/
+					break;
+				} 
+				
+			}
+		}
+		
+		if (result) {
+			reply = create_error_reply_message(msg, BLUEZ_DBUS_HCI_INTERFACE, result);
+		}
+		
+		/* send an error or the success reply*/
+		if (reply) {
+			if (!dbus_connection_send (conn, reply, NULL)) { 
+				syslog(LOG_ERR, "%s line:%d Can't send reply message!", \
+					__PRETTY_FUNCTION__, __LINE__) ;
+			}
+			dbus_message_unref (reply);
+		}
+		
+		ret = DBUS_HANDLER_RESULT_HANDLED;
+	}
+	return ret;
+}
+
+static DBusMessage* handle_periodic_inq_req(DBusMessage *msg, void *data) 
+{
+	syslog(LOG_INFO, "%s", __PRETTY_FUNCTION__);
+	return NULL;
+}
+
+static DBusMessage* handle_cancel_periodic_inq_req(DBusMessage *msg, void *data)
+{
+	syslog(LOG_INFO, "%s", __PRETTY_FUNCTION__);
+	return NULL;
+}
+
+static DBusMessage* handle_inq_req(DBusMessage *msg, void *data)
+{
+	syslog(LOG_INFO, "%s", __PRETTY_FUNCTION__);
+	return NULL;
+}
+
+static DBusMessage* handle_role_switch_req(DBusMessage *msg, void *data)
+{
+	syslog(LOG_INFO, "%s", __PRETTY_FUNCTION__);
+	return NULL;
+}
--- bluez-utils-cvs.orig/hcid/common.c	1969-12-31 21:00:00.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/common.c	2005-09-16 11:33:26.074677136 -0300
@@ -0,0 +1,80 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <maxk@qualcomm.com>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <marcel@holtmann.org>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ *  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ *  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ *  CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES 
+ *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
+ *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
+ *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ *  ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS, 
+ *  COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS 
+ *  SOFTWARE IS DISCLAIMED.
+ *
+ *
+ *  $Id: common.c ,v 0.1 2005/09/16 08:00:00 holtmann Exp $
+ */
+ 
+#include "dbus-internal.h"
+
+DBusMessage *create_error_reply_message(DBusMessage *msg, const char *iface, EXEC_RESULT result) 
+{
+	DBusMessage *reply = NULL;
+	const char *error_msg = NULL;
+	char perror_name[128];
+	
+	switch(result) {
+		case RESULT_FAILED:
+			sprintf(perror_name, "%s%s",iface, ERR_FAILED);
+			error_msg = ERR_MSG_FAILED;
+			break;
+		case RESULT_BUSY:
+			sprintf(perror_name, "%s%s",iface, ERR_BUSY);
+			error_msg = ERR_MSG_DEV_BUSY;
+			break;
+		case RESULT_WRONG_PARAM:
+			sprintf(perror_name, "%s%s",iface, ERR_WRONG_PARAM);
+			error_msg = ERR_MSG_INVALID_PARAMETERS;
+			break;
+		case RESULT_ADAPTER_NOT_FOUND:
+			sprintf(perror_name, "%s%s",iface, ERR_NO_DEV_FOUND);
+			error_msg = ERR_MSG_NO_DEV_FOUND;
+			break;
+		case RESULT_WRONG_SIG:
+			sprintf(perror_name, "%s%s",iface, ERR_WRONG_SIGNATURE);
+			error_msg = ERR_MSG_WRONG_SIG;
+			break;
+		case RESULT_UNKNOWN_METHOD:
+			sprintf(perror_name, "%s%s",iface, ERR_UNKNOWN_METHOD);
+			error_msg  = ERR_MSG_METHOD_NOT_FOUND;
+			break;
+		case RESULT_SVC_NOT_FOUND:
+			sprintf(perror_name, "%s%s",iface, ERR_REC_NOT_FOUND);
+			error_msg = ERR_MSG_NO_SVC_FOUND;
+			break;	
+		default:
+			error_msg = NULL;
+			break;
+	/* RESULT_SUCCESS: ignore, it must be created by the caller
+			break;
+	*/		
+	}
+	
+	syslog(LOG_INFO, "%s - error:%s", __PRETTY_FUNCTION__, perror_name);
+	reply = dbus_message_new_error(msg, (const char*)perror_name, error_msg);
+	
+	return reply;
+}

[Bluez-devel] Re: hcid D-Bus patch (RSSI question)

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 1833 bytes --]

Hi Marcel,

What are the requirements to use inquiry with rssi? My 
kernel version is 2.6.10 with bluez-utils.2.21.

Why it is not working? The periodic inquiry is working, but without
return an inquiry with rssi event.

Regards,
Claudio

if((dev_id = hci_get_route(NULL)) < 0) {
syslog(LOG_ERR, "Bluetooth device is not available");
result = RESULT_ADAPTER_NOT_FOUND;
goto cleanup;
}

if((sock = hci_open_dev(dev_id)) < 0) {
syslog(LOG_ERR, "HCI device open failed");
result = RESULT_ADAPTER_NOT_FOUND;
goto cleanup;
}

...

inq_mode.mode = 1; //INQUIRY_WITH_RSSI;

if (hci_send_cmd(sock, OGF_HOST_CTL, OCF_WRITE_INQUIRY_MODE,
WRITE_INQUIRY_MODE_CP_SIZE, &inq_mode) < 0) {
syslog(LOG_ERR, "Can't set inquiry mode:%s.", strerror(errno));
goto cleanup;
}

if (hci_send_cmd(sock, OGF_LINK_CTL, OCF_PERIODIC_INQUIRY,
PERIODIC_INQUIRY_CP_SIZE, &inq_param) < 0) {
syslog(LOG_ERR, "Can't send HCI commands:%s.", strerror(errno));
goto cleanup;
}
...



On 9/16/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
> 
> Hi Marcel,
> 
> I am sending the initial patch that implementing the skeleton
> of the hcid D-Bus services.
> 
> Run hcid with a non-daemon option to see the output
> 
> Send the following messages to see the message handling.
> 
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
> org.bluez.hci.PeriodicInqReq byte:1 byte:2 byte:3
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
> org.bluez.hci.CancelPeriodicInqReq
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
> org.bluez.hci.InquiryReq byte:1
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci 
> org.bluez.hci.RoleSwitchReq string:panu byte:1
> 
> Suggestions are welcome!
> 
> Regards,
> Claudio.
> 
>

[-- Attachment #2: Type: text/html, Size: 2728 bytes --]

Re: [Bluez-devel] Re: hcid D-Bus patch (RSSI question)

[Marcel Holtmann]

Hi Claudio,

> What are the requirements to use inquiry with rssi? My 
> kernel version is 2.6.10 with bluez-utils.2.21.
> 
> Why it is not working? The periodic inquiry is working, but without
> return an inquiry with rssi event.

you need a chip where "hciconfig hci0 features" shows support for
Inquiry with RSSI. A good choice seems to be the D-Link DBT-120 updated
with the Apple firmware or one of the EDR capable Cellink dongles.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> I am sending the initial patch that implementing the skeleton
> of the hcid D-Bus services.
> 
> Run hcid with a non-daemon option to see the output
> 
> Send the following messages to see the message handling.
> 
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> org.bluez.hci.PeriodicInqReq byte:1 byte:2 byte:3
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> org.bluez.hci.CancelPeriodicInqReq
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> org.bluez.hci.InquiryReq byte:1
> dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> org.bluez.hci.RoleSwitchReq string:panu byte:1
> 
> Suggestions are welcome!

I am not complete through all the changes yet, because the last week was
quite busy. However for what do we need a dbus-internal.h? I don't see
any need for it and it would be great if everything is inside dbus.h. If
we reach the level where stuff gets more generic and can also be reused
by pand etc. then we should think about moving it into the common/
toplevel directory. The same applies for common.c. For now simply put
into dbus.c and resend the patch.

I am not happy with EXEC_RESULT. We should simply use an uint32 for it
and then reuse the Bluetooth error codes and define some special ones
for us. The enum is the wrong choice here.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 2702 bytes --]

Hi Marcel,

I will analize our comments.

service_table_t and the function create_error_reply_message will be shared
by other profiles(pan, hid, rfcomm, ...)
this the reason to put in the dbus-internal.h file.
Regarding the Bluetooth error codes, we can add the code in the D-Bus error
messages as a argument. My proposal
is use a standard like this:

org.bluez.hci.error.UnknowMethod
org.bluez.hci.error.WrongSignature
org.bluez.hci.error.WrongParam
org.bluez.hci.error.Failed /* here we can add the bluetooth error code */
org.bluez.hci.error.Busy
org.bluez.hci.error.NoDevFound

 I will send a new path soon.

Regards,
Claudio.

On 9/21/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > I am sending the initial patch that implementing the skeleton
> > of the hcid D-Bus services.
> >
> > Run hcid with a non-daemon option to see the output
> >
> > Send the following messages to see the message handling.
> >
> > dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> > org.bluez.hci.PeriodicInqReq byte:1 byte:2 byte:3
> > dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> > org.bluez.hci.CancelPeriodicInqReq
> > dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> > org.bluez.hci.InquiryReq byte:1
> > dbus-send --system --type=method_call --dest=org.bluez /org/bluez/hci
> > org.bluez.hci.RoleSwitchReq string:panu byte:1
> >
> > Suggestions are welcome!
>
> I am not complete through all the changes yet, because the last week was
> quite busy. However for what do we need a dbus-internal.h? I don't see
> any need for it and it would be great if everything is inside dbus.h. If
> we reach the level where stuff gets more generic and can also be reused
> by pand etc. then we should think about moving it into the common/
> toplevel directory. The same applies for common.c. For now simply put
> into dbus.c and resend the patch.
>
> I am not happy with EXEC_RESULT. We should simply use an uint32 for it
> and then reuse the Bluetooth error codes and define some special ones
> for us. The enum is the wrong choice here.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 3599 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[P. Durante]

Hi,

>  org.bluez.hci.error.Failed  /* here we can add the bluetooth error code =
*/

Just an idea, keep it simple, if you give the clients just the
bluetooth error code they'll have to decode its meaning using
something like strerror( bt_error( error_code )) every time they make
a request, quite boring, even worse, bt_error is bluez-specific and if
the client wants to use something like that in a language which is not
C, they should grab the bluetooth specification write their own
function which tells what each error code means...

or

since dbus errors consist of error_name + error_message you could put
something meaningful in the error_message, and eventually append an
additional field with the error code to the message as well ( if the
application wants to treat some error codes in a particular way ) this
seems ok with the dbus specification which only says (if I remember
correctly) that if the first field in an error message is of type
'string' that string will be treated as the error message, and doesn't
say anything about additional fields.

regards


-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 2049 bytes --]

Hi Paul,

An ERROR may have any arguments, but if the first argument is a
STRING(error message). Therefore, the signature should be sq
(string+uint16).
In my opinion the error message string is not relevant, the client
applications
can use it or not. If we consider internationalization, this string will not
the useful.

Regards,
Claudio.

On 9/21/05, P. Durante <shackan@gmail.com> wrote:
>
> Hi,
>
> > org.bluez.hci.error.Failed /* here we can add the bluetooth error code
> */
>
> Just an idea, keep it simple, if you give the clients just the
> bluetooth error code they'll have to decode its meaning using
> something like strerror( bt_error( error_code )) every time they make
> a request, quite boring, even worse, bt_error is bluez-specific and if
> the client wants to use something like that in a language which is not
> C, they should grab the bluetooth specification write their own
> function which tells what each error code means...
>
> or
>
> since dbus errors consist of error_name + error_message you could put
> something meaningful in the error_message, and eventually append an
> additional field with the error code to the message as well ( if the
> application wants to treat some error codes in a particular way ) this
> seems ok with the dbus specification which only says (if I remember
> correctly) that if the first field in an error message is of type
> 'string' that string will be treated as the error message, and doesn't
> say anything about additional fields.
>
> regards
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 2586 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> An ERROR may have any arguments, but if the first argument is a 
> STRING(error message). Therefore, the signature should be sq (string
> +uint16).
> In my opinion the error message string is not relevant, the client
> applications
> can use it or not. If we consider internationalization, this string
> will not
> the useful.

the Bluetooth status is always uint8_t and I think it is a good idea to
map these error codes directly. We can define our own codes from 0xff
onwards if we use a uint16. However we should try to use the Bluetooth
defined errors whenever possible.

A string would be nice, but in generell these are useless. However for
application that doesn't consider internationalization it will be easy
for them to display the errors in clear text.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> I will analize our comments.
> 
> service_table_t and the function create_error_reply_message will be
> shared by other profiles(pan, hid, rfcomm, ...)
> this the reason to put in the dbus-internal.h file. 

if this is shared code then I like to have it in the common/ toplevel
directory. We should create the files dbus.[ch] and then use them from
there.

> Regarding the Bluetooth error codes, we can add the code in the D-Bus
> error messages as a argument. My proposal
> is use a standard like this:
> 
> org.bluez.hci.error.UnknowMethod
> org.bluez.hci.error.WrongSignature
> org.bluez.hci.error.WrongParam
> org.bluez.hci.error.Failed  /* here we can add the bluetooth error
> code */
> org.bluez.hci.error.Busy
> org.bluez.hci.error.NoDevFound
> 
> I will send a new path soon.

So a D-Bus error is always a method? I would simply use a general error
with an identifier number. Help me out here to understand what is the
best way to represent the errors.

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 4075 bytes --]

Hi Marcel,

Regarding the shared code I will analize the shared functions
and move to the common directory.


The D-Bus error is a message created based on a received message.
There are 4 message types:
1. method call message
2. method reply message
3. error message
4. signal

First of all you have to understand the difference bus name, path and
interface. Read http://dbus.freedesktop.org/doc/dbus-faq.html#id2778454
for more information. There is a FAQ with this topic.

In my opinion is better associate a "method" as a "service" this analogy
is more clear. They use method just to pass the idea of object oriented
programming. Where the object is the instance of a class that provides
several services and the method is just one service(function).

In a usage scenario, a client will request a service using a method
call message. The result (method reply or error message) will be
received only by the requestor because the reply or the error are
created based on the received message header infos.
It's possible send a method reply containing an argument with an error
code and ignore the usage of error messages. But this is not a good
programming practise because there are D-Bus functions to work with
error messages. These functions make possible compare the error NAME
without extract the other arguments embedded in the message.

After this discussion I would suggest the following structure:

>>> Message Error Names:
org.bluez.EFailed
org.bluez.ENoMemory
/* open to more error names */

>>>org.bluez.EFailed
This error message will have the signature(string+uint16+uint32).
Where the first argument is the error description. The second is
the error class and the third is the error code.
The error class can be system error, D-Bus error or HCI errors.
This structure mane possible return to the app clients any kind of
error. System error includes socket error, IO, ENODEV... D-Bus error
includes no service, no connection, security error and no method found.
HCI errors are listed in the bluetooth specification.

Maybe someone could ask why not bind the error to the profiles/bluez daemon
like org.bluez.hci.EFailed, org.bluez.sdp.EFailed, org.bluez.pan.EFailed.
Add an extra information(like the profile) in the message error
doesn't add relevant information because the error messages will be received
only by the requestor.

Regards,
Claudio


On 9/22/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > I will analize our comments.
> >
> > service_table_t and the function create_error_reply_message will be
> > shared by other profiles(pan, hid, rfcomm, ...)
> > this the reason to put in the dbus-internal.h file.
>
> if this is shared code then I like to have it in the common/ toplevel
> directory. We should create the files dbus.[ch] and then use them from
> there.
>
> > Regarding the Bluetooth error codes, we can add the code in the D-Bus
> > error messages as a argument. My proposal
> > is use a standard like this:
> >
> > org.bluez.hci.error.UnknowMethod
> > org.bluez.hci.error.WrongSignature
> > org.bluez.hci.error.WrongParam
> > org.bluez.hci.error.Failed /* here we can add the bluetooth error
> > code */
> > org.bluez.hci.error.Busy
> > org.bluez.hci.error.NoDevFound
> >
> > I will send a new path soon.
>
> So a D-Bus error is always a method? I would simply use a general error
> with an identifier number. Help me out here to understand what is the
> best way to represent the errors.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 4969 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 1914 bytes --]

Hi Marcel,

Sorry, I think have written an unclear text.

The first argument of an error message MUST be a string containing the
error description, this is a D-Bus definition. Regarding the error code
mapping I think my last email make more clear how I intend work
with system, D-Bus and HCI errors. Although I am defining a way to
report HCI error, I think it will not be possible catch this kind of error
without get the hci command complete event.


REgards,
Claudio

On 9/22/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > An ERROR may have any arguments, but if the first argument is a
> > STRING(error message). Therefore, the signature should be sq (string
> > +uint16).
> > In my opinion the error message string is not relevant, the client
> > applications
> > can use it or not. If we consider internationalization, this string
> > will not
> > the useful.
>
> the Bluetooth status is always uint8_t and I think it is a good idea to
> map these error codes directly. We can define our own codes from 0xff
> onwards if we use a uint16. However we should try to use the Bluetooth
> defined errors whenever possible.
>
> A string would be nice, but in generell these are useless. However for
> application that doesn't consider internationalization it will be easy
> for them to display the errors in clear text.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 2472 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> Regarding the shared code I will analize the shared functions
> and move to the common directory.
> 
> 
> The D-Bus error is a message created based on a received message.
> There are 4 message types:
> 1. method call message
> 2. method reply message
> 3. error message
> 4. signal
> 
> First of all you have to understand the difference bus name, path and 
> interface. Read
> http://dbus.freedesktop.org/doc/dbus-faq.html#id2778454
> for more information. There is a FAQ with this topic.

this is one of my basic problems with D-Bus and object oriented
programming in general. They try to abstract and solve everything and
this is not working. The reality is always different. We now need to
find a way to make it usable in a sane way.

> After this discussion I would suggest the following structure:
> 
> >>> Message Error Names:
> org.bluez.EFailed
> org.bluez.ENoMemory
> /* open to more error names */
> 
> >>>org.bluez.EFailed
> This error message will have the signature(string+uint16+uint32).
> Where the first argument is the error description. The second is
> the error class and the third is the error code.
> The error class can be system error, D-Bus error or HCI errors.
> This structure mane possible return to the app clients any kind of 
> error. System error includes socket error, IO, ENODEV... D-Bus error
> includes no service, no connection, security error and no method
> found.
> HCI errors are listed in the bluetooth specification.

We have three different categories of errors. The Bluetooth errors
defined in the specification. They are the same for the complete HCI.
Then we have the Unix/Linux error codes (errno) and we will have
additional codes defined by us. I don't like the idea of splitting the
errors into classes. This is confusing and not a nice API. We should
choose a base for the errors and these should be the Bluetooth error
codes defined in the HCI part specification. So for my point of view an
error org.bluez.error with string+uint16 is enough. The range 0x00-0xff
will be used by the Bluetooth errors and we define the rest for specific
errors that are currently not covered by the specification. This means
we have to match the Unix/Linux error codes somehow, but I don't see any
problems with that.

Regards

Marcel





-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1.1: Type: text/plain, Size: 1756 bytes --]

Hi folks,

This patch implements inquiry, periodic inquiry, role switch and cancel
periodic inquiry.

Suggestions and comments are welcome!

Regards,
Claudio


>>> Next action
1. move shared codes to common directory
2. fix the error code format for EFailed messages
3. handle multiple devices
4. develop other services

>>> Configuration file
location: /etc/dbus-1/system.d/hcid.conf
The D-Bus configuration file is required for security policies.

>>> How test
This is the easiest way to test the hcid D-Bus services. Another option is
develop a "c" client
or a python client.

//Sending Get Device Request
$dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
org.bluez.hci.GetDevReq

//Sending Inquiry Request
1o. param: length
2o. param: num response
3o. param: flags (0 or 1)
$dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
org.bluez.hci.InquiryReq byte:4 byte:10 uint16:0
comment: We have develop a client to extract the reply message arguments

//Sending Periodic Inquiry Request
1o. param: length
2o. param: min period
3o. param: max period
$dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
org.bluez.hci.PeriodicInquiryReq byte:4 byte:27 byte:49

//Sending Cancel Periodic Inquiry Request
$dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
org.bluez.hci.CancelPeriodicInqReq

//Sending Role Switch Request
1o. param: Remote device
2o. param: Role
$dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
org.bluez.hci.RoleSwitchReq string:00:20:E0:78:7F:7F byte:1
$dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
org.bluez.hci.RoleSwitchReq string:00:20:E0:78:7F:7F byte:0

[-- Attachment #1.2: Type: text/html, Size: 1995 bytes --]

[-- Attachment #2: hcid.conf --]
[-- Type: application/octet-stream, Size: 557 bytes --]

<!-- This configuration file specifies the required security policies
     for bluez-hcid to work. -->

<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>

  <!-- ../system.conf have denied everything, so we just punch some holes -->

  <policy context="default">
    <allow own="org.bluez"/>

    <allow send_destination="org.bluez.hci"/>
    <allow receive_sender="org.bluez.hci"/>

    <allow send_path="/org/bluez/hci"/>
  </policy>

</busconfig>

[-- Attachment #3: hcid_dbus_0007.patch --]
[-- Type: application/octet-stream, Size: 24948 bytes --]

--- bluez-utils-cvs.orig/hcid/dbus.h	1969-12-31 21:00:00.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus.h	2005-09-23 10:08:16.000000000 -0300
@@ -0,0 +1,153 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <maxk@qualcomm.com>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <marcel@holtmann.org>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ *  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ *  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ *  CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES 
+ *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
+ *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
+ *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ *  ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS, 
+ *  COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS 
+ *  SOFTWARE IS DISCLAIMED.
+ *
+ *
+ *  $Id: dbus.h,v 0.1 2005/09/16 08:00:00 holtmann Exp $
+ */
+ 
+#ifndef __H_BLUEZ_DBUS_H__
+#define __H_BLUEZ_DBUS_H__
+
+#define __END_SIG__ DBUS_TYPE_INVALID_AS_STRING
+
+/* bluetoothd Bus name */
+#define BLUEZ_DBUS_NAME		"org.bluez"
+
+
+/* ===== HCI definitions ===== */
+#define BLUEZ_DBUS_HCI_PATH		"/org/bluez/hci"
+#define BLUEZ_DBUS_HCI_INTERFACE	BLUEZ_DBUS_NAME".hci"
+
+//HCI signals
+#define BLUEZ_DBUS_HCI_SIG_INQ_START		"InquiryStartSig"
+#define BLUEZ_DBUS_HCI_SIG_INQ_COMPLETE		"InquiryCompleteSig"
+#define BLUEZ_DBUS_HCI_SIG_INQ_RESULT		"InquiryResultSig"
+#define BLUEZ_DBUS_HCI_SIG_REMOTE_NAME		"RemoteNameSig"
+
+//HCI Provided services
+#define HCI_GET_DEVICES_REQ			"GetDevReq"
+#define HCI_PERIODIC_INQ_REQ			"PeriodicInqReq"
+#define HCI_CANCEL_PERIODIC_INQ_REQ		"CancelPeriodicInqReq"
+#define HCI_INQ_REQ				"InquiryReq"
+#define HCI_ROLE_SWITCH_REQ			"RoleSwitchReq"
+
+//HCI signatures
+#define HCI_GET_DEVICES_REQ_SIGNATURE            	__END_SIG__
+
+#define HCI_PERIODIC_INQ_REQ_SIGNATURE		        DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+							
+#define HCI_CANCEL_PERIODIC_INQ_REQ_SIGNATURE		__END_SIG__
+
+#define HCI_INQ_REQ_SIGNATURE                	    	DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_UINT16_AS_STRING\
+							__END_SIG__
+							
+#define HCI_ROLE_SWITCH_REQ_SIGNATURE                   DBUS_TYPE_STRING_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+							
+#define HCI_DEVICE_STRUCT_SIGNATURE		DBUS_STRUCT_BEGIN_CHAR_AS_STRING\
+						DBUS_TYPE_STRING_AS_STRING\
+						DBUS_TYPE_STRING_AS_STRING\
+						DBUS_STRUCT_END_CHAR_AS_STRING
+/* yya(ss)*/
+#define HCI_GET_DEVICES_REPLY_SIGNATURE			DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_ARRAY_AS_STRING\
+							HCI_DEVICE_STRUCT_SIGNATURE\
+							__END_SIG__
+
+#define HCI_INQ_REPLY_SIGNATURE				DBUS_STRUCT_BEGIN_CHAR_AS_STRING\
+							DBUS_TYPE_STRING_AS_STRING\
+							DBUS_TYPE_UINT32_AS_STRING\
+							DBUS_TYPE_UINT16_AS_STRING\
+							DBUS_STRUCT_END_CHAR_AS_STRING\
+							__END_SIG__
+
+
+/* ===== HCICONFIG definitions ===== */
+//HCICONFIG signals
+//HCICONFIG Provided services
+//HCICONFIG signatures
+
+/* =====    SDP definitions    ===== */
+//SDP signals
+//SDP Provided services
+//SDP signatures
+
+
+/* =====   RFCOMM definitions  ===== */
+//RFCOMM signals
+//RFCOMM Provided services
+//RFCOMM signatures
+
+
+/* =====    PAN definitions    ===== */
+//PAN signals
+//PAN Provided services
+//PAN signatures
+
+/* =====    HID definitions    ===== */
+//HID signals
+//HID Provided services
+//HID signatures
+
+
+/* ===== Common Error messages of org.bluez. =====*/
+#define BLUEZ_DBUS_ERR_FAILED              BLUEZ_DBUS_NAME".EFailed"
+#define BLUEZ_DBUS_ERR_NO_MEMORY           BLUEZ_DBUS_NAME".ENoMemory"
+//TODO What are the other error types?
+
+
+/* BLUEZ_DBUS_ERR_FAILED
+ * EFailed error messages signature is : sni
+ * Where the first argument is a string(error message description),
+ * the second is a uint16 that contains the error class(system, dbus or hci).
+ * The last argument is a int32 that contains the error code(errno 
+ * for system errors, a dbus error code defined below or a hci error).
+ * For hci error see the bluetooth specification.
+ */
+ 
+/* first argument of the error msg */
+#define BLUEZ_ECLASS_SYSTEM   (0x01)
+#define BLUEZ_ECLASS_DBUS     (0x02)
+#define BLUEZ_ECLASS_HCI      (0x03) /* see Bluetooth error code */
+
+/* D-Bus error code (second argument of the error msg)*/
+#define BLUEZ_EDBUS_UNKNOWN_METHOD     (0x01)
+#define BLUEZ_EDBUS_WRONG_SIGNATURE    (0x02)
+#define BLUEZ_EDBUS_WRONG_PARAM        (0x03)
+#define BLUEZ_EDBUS_RECORD_NOT_FOUND   (0x04)
+
+/* BLUEZ_DBUS_ERR_NO_MEMORY */
+#define BLUEZ_DBUS_ERR_NO_MEMORY_STR	"No memory"
+
+
+#endif /*__H_BLUEZ_DBUS_H__*/
--- bluez-utils-cvs.orig/hcid/dbus.c	2005-09-15 18:05:23.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus.c	2005-09-23 11:19:09.000000000 -0300
@@ -33,8 +33,12 @@
 #endif
 
 #include <stdio.h>
+#include <errno.h>
+#include <unistd.h>
 #include <sys/socket.h>
 #include <sys/syslog.h>
+#include <sys/ioctl.h>
+
 
 #include <bluetooth/bluetooth.h>
 #include <bluetooth/hci.h>
@@ -45,23 +49,159 @@
 #include "glib-ectomy.h"
 
 #include "hcid.h"
+#include "dbus.h"
 
 static DBusConnection *connection;
 
 #define TIMEOUT (30 * 1000)		/* 30 seconds */
 
+#define BLUETOOTH_DEVICE_NAME_LEN    (18)
+#define BLUETOOTH_DEVICE_ADDR_LEN    (18)
+
 #define SERVICE_NAME "org.bluez.PinAgent"
 #define INTERFACE_NAME SERVICE_NAME
 #define REQUEST_NAME "PinRequest"
 #define PATH_NAME "/org/bluez/PinAgent"
 
-#define WRONG_ARGS_ERROR "org.bluez.Error.WrongArgs"
-
 struct pin_request {
 	int dev;
 	bdaddr_t bda;
 };
 
+/*
+ * This function should be moved to a common library
+ */
+int find_conn(int s, int dev_id, long arg)
+{
+	struct hci_conn_list_req *cl = NULL;
+	struct hci_conn_info *ci;
+	int i;
+	int result = 0;
+	
+	if (!(cl = malloc(10 * sizeof(*ci) + sizeof(*cl)))) {
+		syslog(LOG_ERR, "Can't allocate memory\n");
+		return 0;
+	}
+	
+	cl->dev_id   = dev_id;
+	cl->conn_num = 10;
+	ci           = cl->conn_info;
+
+	if (ioctl(s, HCIGETCONNLIST, (void *) cl)) {
+		syslog(LOG_ERR, "Can't get connection list\n");
+		return 0;
+	}
+
+	for (i = 0; i < cl->conn_num; i++, ci++) {
+		if (!bacmp((bdaddr_t *) arg, &ci->bdaddr)) {
+		result = 1;
+		goto cleanup;
+		}
+	}
+cleanup:
+	if(cl)
+		free(cl);
+	return result;
+}
+
+/*
+ * D-Bus error messages functions and declarations.
+ * This section should be moved to a common file 
+ * in the future
+ *
+ */
+typedef struct  {
+	uint8_t code;
+	const char *str;
+}bluez_error_t;
+
+static const bluez_error_t error_array[] = {
+	{ BLUEZ_EDBUS_UNKNOWN_METHOD,   "Method not found"},
+	{ BLUEZ_EDBUS_WRONG_SIGNATURE,  "Wrong method signature"},
+	{ BLUEZ_EDBUS_WRONG_PARAM,      "Invalid parameters"},
+	{ BLUEZ_EDBUS_RECORD_NOT_FOUND, "No record found"},
+	{ 0, NULL }
+};
+
+static const char *bluez_dbus_error_to_str(const uint16_t eclass, const int32_t ecode) 
+{
+	const bluez_error_t *ptr;
+	
+	if (eclass == BLUEZ_ECLASS_SYSTEM) {
+		return strerror(ecode);
+	} else { /* BLUEZ_ECLASS_DBUS */
+		
+		for (ptr = error_array; ptr->code; ptr++) {
+			if(ptr->code == ecode) {
+				return ptr->str;
+			}
+		}
+	}
+	return NULL;
+}
+
+DBusMessage *bluez_new_failure_msg(DBusMessage *msg, const uint16_t eclass, const int32_t ecode)
+{
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	const char *error_msg = NULL;
+	
+	error_msg = bluez_dbus_error_to_str(eclass, ecode);
+	
+	if (error_msg) {
+	
+		reply = dbus_message_new_error(msg, BLUEZ_DBUS_ERR_FAILED, error_msg);
+	
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_UINT16 ,&eclass);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_INT32 ,&ecode);
+	}
+	
+	return reply;
+}
+
+/*
+ * Message handler functions object table declaration
+ *
+ */
+ 
+typedef DBusMessage* (service_handler_func_t)(DBusMessage *, void *);
+
+typedef struct
+{
+	const char             *name;
+	service_handler_func_t *handler_func;
+	const char             *signature;
+}service_table_t;
+
+static DBusHandlerResult hci_msg_func(DBusConnection *conn, DBusMessage *msg, void *data);
+static DBusHandlerResult hci_signal_filter (DBusConnection *conn, DBusMessage *msg, void *data);
+
+static DBusMessage* handle_get_devices_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_periodic_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_cancel_periodic_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_role_switch_req(DBusMessage *msg, void *data);
+
+
+static const DBusObjectPathVTable hci_vtable = {
+	NULL,
+	&hci_msg_func,
+	NULL,
+	NULL,
+	NULL,
+	NULL
+};
+
+static const service_table_t hci_services[] = {
+	{HCI_GET_DEVICES_REQ,         handle_get_devices_req,         HCI_GET_DEVICES_REQ_SIGNATURE},
+	{HCI_PERIODIC_INQ_REQ,        handle_periodic_inq_req,        HCI_PERIODIC_INQ_REQ_SIGNATURE},
+	{HCI_CANCEL_PERIODIC_INQ_REQ, handle_cancel_periodic_inq_req, HCI_CANCEL_PERIODIC_INQ_REQ_SIGNATURE},
+	{HCI_ROLE_SWITCH_REQ,         handle_role_switch_req,         HCI_ROLE_SWITCH_REQ_SIGNATURE},
+	{HCI_INQ_REQ,                 handle_inq_req,                 HCI_INQ_REQ_SIGNATURE},	
+	{NULL, NULL, NULL}
+};
+
 static void reply_handler_function(DBusPendingCall *call, void *user_data)
 {
 	struct pin_request *req = (struct pin_request *) user_data;
@@ -169,8 +309,9 @@
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryStart");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+					  BLUEZ_DBUS_HCI_INTERFACE, 
+					  BLUEZ_DBUS_HCI_SIG_INQ_START);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry start message");
 		goto failed;
@@ -203,8 +344,9 @@
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryComplete");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE, 
+				BLUEZ_DBUS_HCI_SIG_INQ_COMPLETE);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry complete message");
 		goto failed;
@@ -238,8 +380,9 @@
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryResult");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE, 
+				BLUEZ_DBUS_HCI_SIG_INQ_RESULT);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry result message");
 		goto failed;
@@ -249,7 +392,7 @@
 					DBUS_TYPE_STRING, &local_addr,
 					DBUS_TYPE_STRING, &peer_addr,
 					DBUS_TYPE_UINT32, &class,
-					DBUS_TYPE_INT32, &rssi,
+					DBUS_TYPE_BYTE, &rssi,
 					DBUS_TYPE_INVALID);
 
 	if (dbus_connection_send(connection, message, NULL) == FALSE) {
@@ -277,8 +420,9 @@
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "RemoteName");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE,
+				BLUEZ_DBUS_HCI_SIG_REMOTE_NAME);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS remote name message");
 		goto failed;
@@ -388,6 +532,7 @@
 	dbus_error_init(&error);
 
 	connection = dbus_bus_get(DBUS_BUS_SYSTEM, &error);
+	
 	if (connection == NULL) {
 		fprintf(stderr, "Failed to open connection to system message bus: %s\n",
 			error.message);
@@ -395,8 +540,429 @@
 		return FALSE;
 	}
 
+	dbus_bus_request_name(connection, BLUEZ_DBUS_NAME, 
+			      DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT, 
+			      &error);
+	
+	if (dbus_error_is_set (&error)) {
+		syslog(LOG_ERR,"D-Bus Error: %s\n", error.message);
+		dbus_error_free (&error);
+		return FALSE;
+	}
+	
+	if (!dbus_connection_register_object_path(connection, BLUEZ_DBUS_HCI_PATH, &hci_vtable, NULL)) {
+		syslog(LOG_ERR,"DBUS failed to register %s object", BLUEZ_DBUS_HCI_PATH);
+		return FALSE;
+	}
+
+	if (!dbus_connection_add_filter (connection, hci_signal_filter, NULL, NULL)) {
+		syslog(LOG_ERR,"DBUS failed to add filter");
+		return FALSE;
+	}
+	
 	dbus_connection_set_watch_functions(connection,
 		add_watch, remove_watch, watch_toggled, NULL, NULL);
-
 	return TRUE;
 }
+
+/*****************************************************************
+ *  
+ *  Section reserved to D-Bus message handlers
+ *  
+ *****************************************************************/
+
+static DBusHandlerResult hci_signal_filter (DBusConnection *conn, DBusMessage *msg, void *data)
+{
+	DBusHandlerResult ret = DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+	const char *iface;
+	const char *method;
+
+	if (!msg || !conn)
+		return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+	
+	if (dbus_message_get_type (msg) != DBUS_MESSAGE_TYPE_SIGNAL)
+		return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+
+	iface = dbus_message_get_interface(msg);
+	method = dbus_message_get_member(msg);
+	
+	if (strcmp(iface, DBUS_INTERFACE_LOCAL) == 0) {
+		if (strcmp(method, "Disconnected") == 0){
+			ret = DBUS_HANDLER_RESULT_HANDLED;
+		}
+	} else	if (strcmp(iface, DBUS_INTERFACE_DBUS) == 0) {
+			if (strcmp(method, "NameOwnerChanged") == 0) {
+				ret = DBUS_HANDLER_RESULT_HANDLED;
+			}
+			if (strcmp(method, "NameAcquired") == 0) {
+				ret = DBUS_HANDLER_RESULT_HANDLED;
+			}
+	}
+	return ret;
+}
+static DBusHandlerResult hci_msg_func(DBusConnection *conn, 
+				      DBusMessage *msg, void *data)
+{
+	const service_table_t *ptr_handlers =  hci_services;
+	DBusMessage *reply = NULL;
+	uint16_t type;
+	const char *iface;
+	const char *method;
+	const char *signature;
+	uint8_t result = BLUEZ_EDBUS_UNKNOWN_METHOD;
+	DBusHandlerResult ret = DBUS_HANDLER_RESULT_NOT_YET_HANDLED;;
+	
+	type = dbus_message_get_type(msg);
+	iface = dbus_message_get_interface(msg);
+	method = dbus_message_get_member (msg);
+	signature = dbus_message_get_signature(msg);
+	
+	if ((type == DBUS_MESSAGE_TYPE_METHOD_CALL) && 
+		(strcmp(iface, BLUEZ_DBUS_HCI_INTERFACE) == 0) && 
+		(method != NULL)) {
+		
+		for (; ptr_handlers->name; ptr_handlers++) {
+			if (strcmp(method, ptr_handlers->name) == 0) {
+				/* resetting unknown method. It's possible handle method overload */
+				result = BLUEZ_EDBUS_WRONG_SIGNATURE; 
+				if (strcmp(ptr_handlers->signature, signature) == 0) {
+					reply = (ptr_handlers->handler_func)(msg, data);
+					result = 0; /* resetting wrong signature*/
+					break;
+				} 
+				
+			}
+		}
+		
+		if (result)
+			reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_DBUS, result);
+		
+		
+		/* send an error or the success reply*/
+		if (reply) {
+			if (!dbus_connection_send (conn, reply, NULL)) { 
+				syslog(LOG_ERR, "%s line:%d Can't send reply message!", \
+					__PRETTY_FUNCTION__, __LINE__) ;
+			}
+			dbus_message_unref (reply);
+		}
+		
+		ret = DBUS_HANDLER_RESULT_HANDLED;
+	}
+	return ret;
+}
+
+static DBusMessage* handle_get_devices_req(DBusMessage *msg, void *data)
+{
+	DBusMessageIter iter;
+	DBusMessageIter array_iter;
+	DBusMessageIter  struct_iter;
+	DBusMessage *reply = NULL;
+	
+	struct hci_dev_list_req *dl = NULL;
+	struct hci_dev_req *dr      = NULL;
+	struct hci_dev_info di;
+	int16_t i;
+	uint8_t up_dev = 0;
+	int32_t sock = -1;
+	
+	char aname[BLUETOOTH_DEVICE_NAME_LEN];
+	char aaddr[BLUETOOTH_DEVICE_ADDR_LEN];
+	char *paddr = aaddr;
+	char *pname = aname;
+	const char array_sig[] = HCI_DEVICE_STRUCT_SIGNATURE;
+
+        /* Create and bind HCI socket */
+        if ((sock = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI)) < 0) {
+                syslog(LOG_ERR, "Can't open HCI socket: %s (%d)",
+                	strerror(errno), errno);
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+        }
+
+
+	dl = malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl));
+	
+	if (!dl) {
+		syslog(LOG_ERR, "Can't allocate memory");
+		reply = dbus_message_new_error(msg, BLUEZ_DBUS_ERR_NO_MEMORY, BLUEZ_DBUS_ERR_NO_MEMORY_STR);
+		goto cleanup;
+	}
+
+	dl->dev_num = HCI_MAX_DEV;
+	dr = dl->dev_req;
+
+	if (ioctl(sock, HCIGETDEVLIST, (void *) dl) < 0) {
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+	}
+
+	
+	/* active bluetooth adapter found */
+	reply = dbus_message_new_method_return(msg);
+	dbus_message_iter_init_append(reply, &iter);
+	dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY, array_sig, &array_iter);
+	dr = dl->dev_req;
+	
+	for (i = 0; i < dl->dev_num; i++, dr++) {
+		if (hci_test_bit(HCI_UP, &dr->dev_opt)) {
+			up_dev++;
+			memset(&di, 0 , sizeof(struct hci_dev_info));
+			di.dev_id = dr->dev_id;
+				
+			if (!ioctl(sock, HCIGETDEVINFO, (void *) &di)) {
+				strcpy(aname, di.name);
+				ba2str(&di.bdaddr, aaddr);
+				dbus_message_iter_open_container(&array_iter, DBUS_TYPE_STRUCT, NULL,
+						&struct_iter);
+				dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_STRING ,&pname);
+				dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_STRING ,&paddr);
+				dbus_message_iter_close_container(&array_iter, &struct_iter);
+			}
+		}
+	}
+	dbus_message_iter_close_container(&iter, &array_iter);
+
+cleanup:
+	if (dl)
+		free(dl);
+	
+	if (sock > 0)
+		close (sock);
+	
+	return reply;
+}
+
+static DBusMessage* handle_periodic_inq_req(DBusMessage *msg, void *data) 
+{
+	write_inquiry_mode_cp inq_mode;
+	periodic_inquiry_cp inq_param;
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	uint8_t length;
+	uint8_t max_period;
+	uint8_t min_period;
+
+	int32_t sock = -1;
+	int32_t dev_id = -1;
+	
+	if ((dev_id = hci_get_route(NULL)) < 0) {
+		syslog(LOG_ERR, "Bluetooth device is not available");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+		
+	}
+	
+	if ((sock = hci_open_dev(dev_id)) < 0) {
+		syslog(LOG_ERR, "HCI device open failed");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+	
+	dbus_message_iter_init(msg, &iter);
+	dbus_message_iter_get_basic(&iter, &length);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &min_period);
+	dbus_message_iter_next(&iter);	
+	dbus_message_iter_get_basic(&iter, &max_period);
+	
+	if ((length >= min_period) || (min_period >= max_period)) {
+		  reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_DBUS, BLUEZ_EDBUS_WRONG_PARAM);
+		  goto cleanup;
+	}
+
+	inq_param.num_rsp = 100;
+	inq_param.length  = length;
+
+	inq_param.max_period = max_period;
+	inq_param.min_period = min_period;
+
+	/* General/Unlimited Inquiry Access Code (GIAC) */
+	inq_param.lap[0] = 0x33;
+	inq_param.lap[1] = 0x8b;
+	inq_param.lap[2] = 0x9e;
+
+	inq_mode.mode = 1; //INQUIRY_WITH_RSSI;
+	
+	if (hci_send_cmd(sock, OGF_HOST_CTL, OCF_WRITE_INQUIRY_MODE, 
+		WRITE_INQUIRY_MODE_CP_SIZE, &inq_mode) < 0) {
+		syslog(LOG_ERR, "Can't set inquiry mode:%s.", strerror(errno));
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+	}
+	
+	if (hci_send_cmd(sock, OGF_LINK_CTL, OCF_PERIODIC_INQUIRY, 
+		PERIODIC_INQUIRY_CP_SIZE, &inq_param) < 0) {
+		syslog(LOG_ERR, "Can't send HCI commands:%s.", strerror(errno));
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+	} else {
+	
+		uint8_t result = 0;
+		/* return TRUE to indicate that operation was completed */
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_BYTE ,&result);
+	}
+	
+cleanup:
+
+	if (sock > 0)
+		close(sock);
+	
+	return reply;
+}
+
+static DBusMessage* handle_cancel_periodic_inq_req(DBusMessage *msg, void *data)
+{
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	int32_t sock = -1;
+	int32_t dev_id = -1;
+	
+	if ((dev_id = hci_get_route(NULL)) < 0) {
+		syslog(LOG_ERR, "Bluetooth device is not available");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+		
+	}
+	
+	if ((sock = hci_open_dev(dev_id)) < 0) {
+		syslog(LOG_ERR, "HCI device open failed");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+	
+	if (hci_send_cmd(sock, OGF_LINK_CTL, OCF_EXIT_PERIODIC_INQUIRY, 0 , NULL) < 0) {
+		syslog(LOG_ERR, "Send hci command failed.");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+	} else  {
+		uint8_t result  = 0;
+		/* return TRUE to indicate that operation was completed */
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_BYTE ,&result);
+	}
+	
+cleanup:
+	if (sock > 0)
+		close(sock);
+	
+	return reply;
+}
+
+static DBusMessage* handle_inq_req(DBusMessage *msg, void *data)
+{
+	const char array_sig[] = HCI_INQ_REPLY_SIGNATURE;
+	DBusMessageIter iter;
+	DBusMessageIter array_iter;
+	DBusMessageIter  struct_iter;
+	DBusMessage *reply = NULL;
+	inquiry_info *info = NULL;
+	char addr[18];
+	const char *paddr = addr;
+	int32_t dev_id = -1;
+	uint32_t class = 0;
+	uint16_t clock_offset;
+	uint16_t flags;
+	int8_t length;
+	int8_t num_rsp;
+	int8_t i;
+
+	if ((dev_id = hci_get_route(NULL)) < 0) {
+		syslog(LOG_ERR, "Bluetooth device is not available");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+		
+	}
+	
+	dbus_message_iter_init(msg, &iter);
+	dbus_message_iter_get_basic(&iter, &length);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &num_rsp);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &flags);
+	
+	if ((length <= 0) || (num_rsp <= 0)) {
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_DBUS, BLUEZ_EDBUS_WRONG_PARAM);
+		goto cleanup;
+	}
+	
+	num_rsp = hci_inquiry(dev_id, length, num_rsp, NULL, &info, flags);
+	
+	if (num_rsp < 0) {
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+	} else {
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY, array_sig, &array_iter);
+		
+	        for (i = 0; i < num_rsp; i++) {
+			ba2str(&(info+i)->bdaddr, addr);
+
+			clock_offset = btohs((info+i)->clock_offset);
+                        /* only 3 bytes are used */
+			memcpy(&class, (info+i)->dev_class, 3);
+			
+			dbus_message_iter_open_container(&array_iter, DBUS_TYPE_STRUCT, NULL, &struct_iter);
+			dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_STRING , &paddr);
+			dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_UINT32 , &class);
+			dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_UINT16 , &clock_offset);
+			dbus_message_iter_close_container(&array_iter, &struct_iter);
+	}
+        	dbus_message_iter_close_container(&iter, &array_iter);
+        }
+
+cleanup:
+	if(info)
+		bt_free(info);
+	
+	return NULL;
+}
+
+static DBusMessage* handle_role_switch_req(DBusMessage *msg, void *data)
+{
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	char *str_bdaddr = NULL;
+	bdaddr_t bdaddr;
+	uint8_t role;
+	int32_t dev_id = -1, sock = -1;
+	
+	dbus_message_iter_init(msg, &iter);
+	dbus_message_iter_get_basic(&iter, &str_bdaddr);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &role);
+	
+	str2ba(str_bdaddr, &bdaddr);
+	
+	dev_id = hci_for_each_dev(HCI_UP, find_conn, (long) &bdaddr);
+	
+	if (dev_id < 0) {
+		syslog(LOG_ERR, "Bluetooth device failed\n");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+	
+	sock = hci_open_dev(dev_id);
+	
+	if (sock < 0) {
+		syslog(LOG_ERR, "HCI device open failed\n");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+
+	if (hci_switch_role(sock, &bdaddr, role, 10000) < 0) {
+		syslog(LOG_ERR, "Switch role request failed\n");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+	} else {
+		uint8_t result = 0;
+		/* return TRUE to indicate that operation was completed */
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_BYTE, &result);
+	}
+cleanup:
+	
+	return reply;
+}

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1.1: Type: text/plain, Size: 2088 bytes --]

Hi folks,

Sorry, but the last patch(hcid_dbus_0007.patch) was not
based on the latest CVS version.


This new one is correct.

Regards,
Claudio.


On 9/23/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
>
> Hi folks,
>
> This patch implements inquiry, periodic inquiry, role switch and cancel
> periodic inquiry.
>
> Suggestions and comments are welcome!
>
> Regards,
> Claudio
>
>
> >>> Next action
> 1. move shared codes to common directory
> 2. fix the error code format for EFailed messages
> 3. handle multiple devices
> 4. develop other services
>
> >>> Configuration file
> location: /etc/dbus-1/system.d/hcid.conf
> The D-Bus configuration file is required for security policies.
>
> >>> How test
> This is the easiest way to test the hcid D-Bus services. Another option is
> develop a "c" client
> or a python client.
>
> //Sending Get Device Request
> $dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
> org.bluez.hci.GetDevReq
>
> //Sending Inquiry Request
> 1o. param: length
> 2o. param: num response
> 3o. param: flags (0 or 1)
> $dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
> org.bluez.hci.InquiryReq byte:4 byte:10 uint16:0
> comment: We have develop a client to extract the reply message arguments
>
> //Sending Periodic Inquiry Request
> 1o. param: length
> 2o. param: min period
> 3o. param: max period
> $dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
> org.bluez.hci.PeriodicInquiryReq byte:4 byte:27 byte:49
>
> //Sending Cancel Periodic Inquiry Request
> $dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
> org.bluez.hci.CancelPeriodicInqReq
>
> //Sending Role Switch Request
> 1o. param: Remote device
> 2o. param: Role
> $dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
> org.bluez.hci.RoleSwitchReq string:00:20:E0:78:7F:7F byte:1
> $dbus-send --system --dest=org.bluez --type=method_call /org/bluez/hci
> org.bluez.hci.RoleSwitchReq string:00:20:E0:78:7F:7F byte:0
>
>
>

[-- Attachment #1.2: Type: text/html, Size: 2550 bytes --]

[-- Attachment #2: hcid_dbus_0008.patch --]
[-- Type: application/octet-stream, Size: 24373 bytes --]

--- bluez-utils-cvs.orig/hcid/dbus.h	1969-12-31 21:00:00.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus.h	2005-09-23 10:08:16.000000000 -0300
@@ -0,0 +1,153 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <maxk@qualcomm.com>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <marcel@holtmann.org>
+ *
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation;
+ *
+ *  THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
+ *  OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ *  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OF THIRD PARTY RIGHTS.
+ *  IN NO EVENT SHALL THE COPYRIGHT HOLDER(S) AND AUTHOR(S) BE LIABLE FOR ANY
+ *  CLAIM, OR ANY SPECIAL INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES 
+ *  WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 
+ *  ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF 
+ *  OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ *  ALL LIABILITY, INCLUDING LIABILITY FOR INFRINGEMENT OF ANY PATENTS, 
+ *  COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS, RELATING TO USE OF THIS 
+ *  SOFTWARE IS DISCLAIMED.
+ *
+ *
+ *  $Id: dbus.h,v 0.1 2005/09/16 08:00:00 holtmann Exp $
+ */
+ 
+#ifndef __H_BLUEZ_DBUS_H__
+#define __H_BLUEZ_DBUS_H__
+
+#define __END_SIG__ DBUS_TYPE_INVALID_AS_STRING
+
+/* bluetoothd Bus name */
+#define BLUEZ_DBUS_NAME		"org.bluez"
+
+
+/* ===== HCI definitions ===== */
+#define BLUEZ_DBUS_HCI_PATH		"/org/bluez/hci"
+#define BLUEZ_DBUS_HCI_INTERFACE	BLUEZ_DBUS_NAME".hci"
+
+//HCI signals
+#define BLUEZ_DBUS_HCI_SIG_INQ_START		"InquiryStartSig"
+#define BLUEZ_DBUS_HCI_SIG_INQ_COMPLETE		"InquiryCompleteSig"
+#define BLUEZ_DBUS_HCI_SIG_INQ_RESULT		"InquiryResultSig"
+#define BLUEZ_DBUS_HCI_SIG_REMOTE_NAME		"RemoteNameSig"
+
+//HCI Provided services
+#define HCI_GET_DEVICES_REQ			"GetDevReq"
+#define HCI_PERIODIC_INQ_REQ			"PeriodicInqReq"
+#define HCI_CANCEL_PERIODIC_INQ_REQ		"CancelPeriodicInqReq"
+#define HCI_INQ_REQ				"InquiryReq"
+#define HCI_ROLE_SWITCH_REQ			"RoleSwitchReq"
+
+//HCI signatures
+#define HCI_GET_DEVICES_REQ_SIGNATURE            	__END_SIG__
+
+#define HCI_PERIODIC_INQ_REQ_SIGNATURE		        DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+							
+#define HCI_CANCEL_PERIODIC_INQ_REQ_SIGNATURE		__END_SIG__
+
+#define HCI_INQ_REQ_SIGNATURE                	    	DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_UINT16_AS_STRING\
+							__END_SIG__
+							
+#define HCI_ROLE_SWITCH_REQ_SIGNATURE                   DBUS_TYPE_STRING_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							__END_SIG__
+							
+#define HCI_DEVICE_STRUCT_SIGNATURE		DBUS_STRUCT_BEGIN_CHAR_AS_STRING\
+						DBUS_TYPE_STRING_AS_STRING\
+						DBUS_TYPE_STRING_AS_STRING\
+						DBUS_STRUCT_END_CHAR_AS_STRING
+/* yya(ss)*/
+#define HCI_GET_DEVICES_REPLY_SIGNATURE			DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_BYTE_AS_STRING\
+							DBUS_TYPE_ARRAY_AS_STRING\
+							HCI_DEVICE_STRUCT_SIGNATURE\
+							__END_SIG__
+
+#define HCI_INQ_REPLY_SIGNATURE				DBUS_STRUCT_BEGIN_CHAR_AS_STRING\
+							DBUS_TYPE_STRING_AS_STRING\
+							DBUS_TYPE_UINT32_AS_STRING\
+							DBUS_TYPE_UINT16_AS_STRING\
+							DBUS_STRUCT_END_CHAR_AS_STRING\
+							__END_SIG__
+
+
+/* ===== HCICONFIG definitions ===== */
+//HCICONFIG signals
+//HCICONFIG Provided services
+//HCICONFIG signatures
+
+/* =====    SDP definitions    ===== */
+//SDP signals
+//SDP Provided services
+//SDP signatures
+
+
+/* =====   RFCOMM definitions  ===== */
+//RFCOMM signals
+//RFCOMM Provided services
+//RFCOMM signatures
+
+
+/* =====    PAN definitions    ===== */
+//PAN signals
+//PAN Provided services
+//PAN signatures
+
+/* =====    HID definitions    ===== */
+//HID signals
+//HID Provided services
+//HID signatures
+
+
+/* ===== Common Error messages of org.bluez. =====*/
+#define BLUEZ_DBUS_ERR_FAILED              BLUEZ_DBUS_NAME".EFailed"
+#define BLUEZ_DBUS_ERR_NO_MEMORY           BLUEZ_DBUS_NAME".ENoMemory"
+//TODO What are the other error types?
+
+
+/* BLUEZ_DBUS_ERR_FAILED
+ * EFailed error messages signature is : sni
+ * Where the first argument is a string(error message description),
+ * the second is a uint16 that contains the error class(system, dbus or hci).
+ * The last argument is a int32 that contains the error code(errno 
+ * for system errors, a dbus error code defined below or a hci error).
+ * For hci error see the bluetooth specification.
+ */
+ 
+/* first argument of the error msg */
+#define BLUEZ_ECLASS_SYSTEM   (0x01)
+#define BLUEZ_ECLASS_DBUS     (0x02)
+#define BLUEZ_ECLASS_HCI      (0x03) /* see Bluetooth error code */
+
+/* D-Bus error code (second argument of the error msg)*/
+#define BLUEZ_EDBUS_UNKNOWN_METHOD     (0x01)
+#define BLUEZ_EDBUS_WRONG_SIGNATURE    (0x02)
+#define BLUEZ_EDBUS_WRONG_PARAM        (0x03)
+#define BLUEZ_EDBUS_RECORD_NOT_FOUND   (0x04)
+
+/* BLUEZ_DBUS_ERR_NO_MEMORY */
+#define BLUEZ_DBUS_ERR_NO_MEMORY_STR	"No memory"
+
+
+#endif /*__H_BLUEZ_DBUS_H__*/
--- bluez-utils-cvs.orig/hcid/dbus.c	2005-09-23 14:09:28.000000000 -0300
+++ bluez-utils-cvs-hcid-dbus/hcid/dbus.c	2005-09-23 14:00:51.000000000 -0300
@@ -33,6 +33,9 @@
 #endif
 
 #include <stdio.h>
+#include <errno.h>
+#include <unistd.h>
+#include <sys/ioctl.h>
 #include <sys/socket.h>
 #include <sys/syslog.h>
 
@@ -45,23 +48,159 @@
 #include "glib-ectomy.h"
 
 #include "hcid.h"
+#include "dbus.h"
 
 static DBusConnection *connection;
 
 #define TIMEOUT (30 * 1000)		/* 30 seconds */
+#define BLUETOOTH_DEVICE_NAME_LEN    (18)
+#define BLUETOOTH_DEVICE_ADDR_LEN    (18)
 
 #define SERVICE_NAME "org.bluez.PinAgent"
 #define INTERFACE_NAME SERVICE_NAME
 #define REQUEST_NAME "PinRequest"
 #define PATH_NAME "/org/bluez/PinAgent"
 
-#define WRONG_ARGS_ERROR "org.bluez.Error.WrongArgs"
 
 struct pin_request {
 	int dev;
 	bdaddr_t bda;
 };
 
+/*
+ * This function should be moved to a common library
+ */
+int find_conn(int s, int dev_id, long arg)
+{
+	struct hci_conn_list_req *cl = NULL;
+	struct hci_conn_info *ci;
+	int i;
+	int result = 0;
+	
+	if (!(cl = malloc(10 * sizeof(*ci) + sizeof(*cl)))) {
+		syslog(LOG_ERR, "Can't allocate memory\n");
+		return 0;
+	}
+	
+	cl->dev_id   = dev_id;
+	cl->conn_num = 10;
+	ci           = cl->conn_info;
+
+	if (ioctl(s, HCIGETCONNLIST, (void *) cl)) {
+		syslog(LOG_ERR, "Can't get connection list\n");
+		return 0;
+	}
+
+	for (i = 0; i < cl->conn_num; i++, ci++) {
+		if (!bacmp((bdaddr_t *) arg, &ci->bdaddr)) {
+		result = 1;
+		goto cleanup;
+		}
+	}
+cleanup:
+	if(cl)
+		free(cl);
+	return result;
+}
+
+/*
+ * D-Bus error messages functions and declarations.
+ * This section should be moved to a common file 
+ * in the future
+ *
+ */
+typedef struct  {
+	uint8_t code;
+	const char *str;
+}bluez_error_t;
+
+static const bluez_error_t error_array[] = {
+	{ BLUEZ_EDBUS_UNKNOWN_METHOD,   "Method not found"},
+	{ BLUEZ_EDBUS_WRONG_SIGNATURE,  "Wrong method signature"},
+	{ BLUEZ_EDBUS_WRONG_PARAM,      "Invalid parameters"},
+	{ BLUEZ_EDBUS_RECORD_NOT_FOUND, "No record found"},
+	{ 0, NULL }
+};
+
+static const char *bluez_dbus_error_to_str(const uint16_t eclass, const int32_t ecode) 
+{
+	const bluez_error_t *ptr;
+	
+	if (eclass == BLUEZ_ECLASS_SYSTEM) {
+		return strerror(ecode);
+	} else { /* BLUEZ_ECLASS_DBUS */
+		
+		for (ptr = error_array; ptr->code; ptr++) {
+			if(ptr->code == ecode) {
+				return ptr->str;
+			}
+		}
+	}
+	return NULL;
+}
+
+DBusMessage *bluez_new_failure_msg(DBusMessage *msg, const uint16_t eclass, const int32_t ecode)
+{
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	const char *error_msg = NULL;
+	
+	error_msg = bluez_dbus_error_to_str(eclass, ecode);
+	
+	if (error_msg) {
+	
+		reply = dbus_message_new_error(msg, BLUEZ_DBUS_ERR_FAILED, error_msg);
+	
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_UINT16 ,&eclass);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_INT32 ,&ecode);
+	}
+	
+	return reply;
+}
+
+/*
+ * Message handler functions object table declaration
+ *
+ */
+ 
+typedef DBusMessage* (service_handler_func_t)(DBusMessage *, void *);
+
+typedef struct
+{
+	const char             *name;
+	service_handler_func_t *handler_func;
+	const char             *signature;
+}service_table_t;
+
+static DBusHandlerResult hci_msg_func(DBusConnection *conn, DBusMessage *msg, void *data);
+static DBusHandlerResult hci_signal_filter (DBusConnection *conn, DBusMessage *msg, void *data);
+
+static DBusMessage* handle_get_devices_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_periodic_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_cancel_periodic_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_inq_req(DBusMessage *msg, void *data);
+static DBusMessage* handle_role_switch_req(DBusMessage *msg, void *data);
+
+
+static const DBusObjectPathVTable hci_vtable = {
+	NULL,
+	&hci_msg_func,
+	NULL,
+	NULL,
+	NULL,
+	NULL
+};
+
+static const service_table_t hci_services[] = {
+	{HCI_GET_DEVICES_REQ,         handle_get_devices_req,         HCI_GET_DEVICES_REQ_SIGNATURE},
+	{HCI_PERIODIC_INQ_REQ,        handle_periodic_inq_req,        HCI_PERIODIC_INQ_REQ_SIGNATURE},
+	{HCI_CANCEL_PERIODIC_INQ_REQ, handle_cancel_periodic_inq_req, HCI_CANCEL_PERIODIC_INQ_REQ_SIGNATURE},
+	{HCI_ROLE_SWITCH_REQ,         handle_role_switch_req,         HCI_ROLE_SWITCH_REQ_SIGNATURE},
+	{HCI_INQ_REQ,                 handle_inq_req,                 HCI_INQ_REQ_SIGNATURE},	
+	{NULL, NULL, NULL}
+};
+
 static void reply_handler_function(DBusPendingCall *call, void *user_data)
 {
 	struct pin_request *req = (struct pin_request *) user_data;
@@ -170,8 +309,9 @@
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryStart");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+					  BLUEZ_DBUS_HCI_INTERFACE, 
+					  BLUEZ_DBUS_HCI_SIG_INQ_START);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry start message");
 		goto failed;
@@ -204,8 +344,9 @@
 
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryComplete");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE, 
+				BLUEZ_DBUS_HCI_SIG_INQ_COMPLETE);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry complete message");
 		goto failed;
@@ -241,8 +382,9 @@
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "InquiryResult");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE, 
+				BLUEZ_DBUS_HCI_SIG_INQ_RESULT);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS inquiry result message");
 		goto failed;
@@ -280,8 +422,9 @@
 	baswap(&tmp, local); local_addr = batostr(&tmp);
 	baswap(&tmp, peer); peer_addr = batostr(&tmp);
 
-	message = dbus_message_new_signal("/org/bluez/DevAgent",
-				"org.bluez.DevAgent", "RemoteName");
+	message = dbus_message_new_signal(BLUEZ_DBUS_HCI_PATH,
+				BLUEZ_DBUS_HCI_INTERFACE,
+				BLUEZ_DBUS_HCI_SIG_REMOTE_NAME);
 	if (message == NULL) {
 		syslog(LOG_ERR, "Can't allocate D-BUS remote name message");
 		goto failed;
@@ -398,8 +541,430 @@
 		return FALSE;
 	}
 
+	dbus_bus_request_name(connection, BLUEZ_DBUS_NAME, 
+			      DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT, 
+			      &error);
+	
+	if (dbus_error_is_set (&error)) {
+		syslog(LOG_ERR,"D-Bus Error: %s\n", error.message);
+		dbus_error_free (&error);
+		return FALSE;
+	}
+	
+	if (!dbus_connection_register_object_path(connection, BLUEZ_DBUS_HCI_PATH, &hci_vtable, NULL)) {
+		syslog(LOG_ERR,"DBUS failed to register %s object", BLUEZ_DBUS_HCI_PATH);
+		return FALSE;
+	}
+
+	if (!dbus_connection_add_filter (connection, hci_signal_filter, NULL, NULL)) {
+		syslog(LOG_ERR,"DBUS failed to add filter");
+		return FALSE;
+	}
+	
 	dbus_connection_set_watch_functions(connection,
 		add_watch, remove_watch, watch_toggled, NULL, NULL);
 
 	return TRUE;
 }
+
+/*****************************************************************
+ *  
+ *  Section reserved to D-Bus message handlers
+ *  
+ *****************************************************************/
+
+static DBusHandlerResult hci_signal_filter (DBusConnection *conn, DBusMessage *msg, void *data)
+{
+	DBusHandlerResult ret = DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+	const char *iface;
+	const char *method;
+
+	if (!msg || !conn)
+		return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+	
+	if (dbus_message_get_type (msg) != DBUS_MESSAGE_TYPE_SIGNAL)
+		return DBUS_HANDLER_RESULT_NOT_YET_HANDLED;
+
+	iface = dbus_message_get_interface(msg);
+	method = dbus_message_get_member(msg);
+	
+	if (strcmp(iface, DBUS_INTERFACE_LOCAL) == 0) {
+		if (strcmp(method, "Disconnected") == 0){
+			ret = DBUS_HANDLER_RESULT_HANDLED;
+		}
+	} else	if (strcmp(iface, DBUS_INTERFACE_DBUS) == 0) {
+			if (strcmp(method, "NameOwnerChanged") == 0) {
+				ret = DBUS_HANDLER_RESULT_HANDLED;
+			}
+			if (strcmp(method, "NameAcquired") == 0) {
+				ret = DBUS_HANDLER_RESULT_HANDLED;
+			}
+	}
+	return ret;
+}
+static DBusHandlerResult hci_msg_func(DBusConnection *conn, 
+				      DBusMessage *msg, void *data)
+{
+	const service_table_t *ptr_handlers =  hci_services;
+	DBusMessage *reply = NULL;
+	uint16_t type;
+	const char *iface;
+	const char *method;
+	const char *signature;
+	uint8_t result = BLUEZ_EDBUS_UNKNOWN_METHOD;
+	DBusHandlerResult ret = DBUS_HANDLER_RESULT_NOT_YET_HANDLED;;
+	
+	type = dbus_message_get_type(msg);
+	iface = dbus_message_get_interface(msg);
+	method = dbus_message_get_member (msg);
+	signature = dbus_message_get_signature(msg);
+	
+	if ((type == DBUS_MESSAGE_TYPE_METHOD_CALL) && 
+		(strcmp(iface, BLUEZ_DBUS_HCI_INTERFACE) == 0) && 
+		(method != NULL)) {
+		
+		for (; ptr_handlers->name; ptr_handlers++) {
+			if (strcmp(method, ptr_handlers->name) == 0) {
+				/* resetting unknown method. It's possible handle method overload */
+				result = BLUEZ_EDBUS_WRONG_SIGNATURE; 
+				if (strcmp(ptr_handlers->signature, signature) == 0) {
+					reply = (ptr_handlers->handler_func)(msg, data);
+					result = 0; /* resetting wrong signature*/
+					break;
+				} 
+				
+			}
+		}
+		
+		if (result)
+			reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_DBUS, result);
+		
+		
+		/* send an error or the success reply*/
+		if (reply) {
+			if (!dbus_connection_send (conn, reply, NULL)) { 
+				syslog(LOG_ERR, "%s line:%d Can't send reply message!", \
+					__PRETTY_FUNCTION__, __LINE__) ;
+			}
+			dbus_message_unref (reply);
+		}
+		
+		ret = DBUS_HANDLER_RESULT_HANDLED;
+	}
+	return ret;
+}
+
+static DBusMessage* handle_get_devices_req(DBusMessage *msg, void *data)
+{
+	DBusMessageIter iter;
+	DBusMessageIter array_iter;
+	DBusMessageIter  struct_iter;
+	DBusMessage *reply = NULL;
+	
+	struct hci_dev_list_req *dl = NULL;
+	struct hci_dev_req *dr      = NULL;
+	struct hci_dev_info di;
+	int16_t i;
+	uint8_t up_dev = 0;
+	int32_t sock = -1;
+	
+	char aname[BLUETOOTH_DEVICE_NAME_LEN];
+	char aaddr[BLUETOOTH_DEVICE_ADDR_LEN];
+	char *paddr = aaddr;
+	char *pname = aname;
+	const char array_sig[] = HCI_DEVICE_STRUCT_SIGNATURE;
+
+        /* Create and bind HCI socket */
+        if ((sock = socket(AF_BLUETOOTH, SOCK_RAW, BTPROTO_HCI)) < 0) {
+                syslog(LOG_ERR, "Can't open HCI socket: %s (%d)",
+                	strerror(errno), errno);
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+        }
+
+
+	dl = malloc(HCI_MAX_DEV * sizeof(*dr) + sizeof(*dl));
+	
+	if (!dl) {
+		syslog(LOG_ERR, "Can't allocate memory");
+		reply = dbus_message_new_error(msg, BLUEZ_DBUS_ERR_NO_MEMORY, BLUEZ_DBUS_ERR_NO_MEMORY_STR);
+		goto cleanup;
+	}
+
+	dl->dev_num = HCI_MAX_DEV;
+	dr = dl->dev_req;
+
+	if (ioctl(sock, HCIGETDEVLIST, (void *) dl) < 0) {
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+	}
+
+	
+	/* active bluetooth adapter found */
+	reply = dbus_message_new_method_return(msg);
+	dbus_message_iter_init_append(reply, &iter);
+	dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY, array_sig, &array_iter);
+	dr = dl->dev_req;
+	
+	for (i = 0; i < dl->dev_num; i++, dr++) {
+		if (hci_test_bit(HCI_UP, &dr->dev_opt)) {
+			up_dev++;
+			memset(&di, 0 , sizeof(struct hci_dev_info));
+			di.dev_id = dr->dev_id;
+				
+			if (!ioctl(sock, HCIGETDEVINFO, (void *) &di)) {
+				strcpy(aname, di.name);
+				ba2str(&di.bdaddr, aaddr);
+				dbus_message_iter_open_container(&array_iter, DBUS_TYPE_STRUCT, NULL,
+						&struct_iter);
+				dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_STRING ,&pname);
+				dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_STRING ,&paddr);
+				dbus_message_iter_close_container(&array_iter, &struct_iter);
+			}
+		}
+	}
+	dbus_message_iter_close_container(&iter, &array_iter);
+
+cleanup:
+	if (dl)
+		free(dl);
+	
+	if (sock > 0)
+		close (sock);
+	
+	return reply;
+}
+
+static DBusMessage* handle_periodic_inq_req(DBusMessage *msg, void *data) 
+{
+	write_inquiry_mode_cp inq_mode;
+	periodic_inquiry_cp inq_param;
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	uint8_t length;
+	uint8_t max_period;
+	uint8_t min_period;
+
+	int32_t sock = -1;
+	int32_t dev_id = -1;
+	
+	if ((dev_id = hci_get_route(NULL)) < 0) {
+		syslog(LOG_ERR, "Bluetooth device is not available");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+		
+	}
+	
+	if ((sock = hci_open_dev(dev_id)) < 0) {
+		syslog(LOG_ERR, "HCI device open failed");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+	
+	dbus_message_iter_init(msg, &iter);
+	dbus_message_iter_get_basic(&iter, &length);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &min_period);
+	dbus_message_iter_next(&iter);	
+	dbus_message_iter_get_basic(&iter, &max_period);
+	
+	if ((length >= min_period) || (min_period >= max_period)) {
+		  reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_DBUS, BLUEZ_EDBUS_WRONG_PARAM);
+		  goto cleanup;
+	}
+
+	inq_param.num_rsp = 100;
+	inq_param.length  = length;
+
+	inq_param.max_period = max_period;
+	inq_param.min_period = min_period;
+
+	/* General/Unlimited Inquiry Access Code (GIAC) */
+	inq_param.lap[0] = 0x33;
+	inq_param.lap[1] = 0x8b;
+	inq_param.lap[2] = 0x9e;
+
+	inq_mode.mode = 1; //INQUIRY_WITH_RSSI;
+	
+	if (hci_send_cmd(sock, OGF_HOST_CTL, OCF_WRITE_INQUIRY_MODE, 
+		WRITE_INQUIRY_MODE_CP_SIZE, &inq_mode) < 0) {
+		syslog(LOG_ERR, "Can't set inquiry mode:%s.", strerror(errno));
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+	}
+	
+	if (hci_send_cmd(sock, OGF_LINK_CTL, OCF_PERIODIC_INQUIRY, 
+		PERIODIC_INQUIRY_CP_SIZE, &inq_param) < 0) {
+		syslog(LOG_ERR, "Can't send HCI commands:%s.", strerror(errno));
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+		goto cleanup;
+	} else {
+	
+		uint8_t result = 0;
+		/* return TRUE to indicate that operation was completed */
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_BYTE ,&result);
+	}
+	
+cleanup:
+
+	if (sock > 0)
+		close(sock);
+	
+	return reply;
+}
+
+static DBusMessage* handle_cancel_periodic_inq_req(DBusMessage *msg, void *data)
+{
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	int32_t sock = -1;
+	int32_t dev_id = -1;
+	
+	if ((dev_id = hci_get_route(NULL)) < 0) {
+		syslog(LOG_ERR, "Bluetooth device is not available");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+		
+	}
+	
+	if ((sock = hci_open_dev(dev_id)) < 0) {
+		syslog(LOG_ERR, "HCI device open failed");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+	
+	if (hci_send_cmd(sock, OGF_LINK_CTL, OCF_EXIT_PERIODIC_INQUIRY, 0 , NULL) < 0) {
+		syslog(LOG_ERR, "Send hci command failed.");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+	} else  {
+		uint8_t result  = 0;
+		/* return TRUE to indicate that operation was completed */
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_BYTE ,&result);
+	}
+	
+cleanup:
+	if (sock > 0)
+		close(sock);
+	
+	return reply;
+}
+
+static DBusMessage* handle_inq_req(DBusMessage *msg, void *data)
+{
+	const char array_sig[] = HCI_INQ_REPLY_SIGNATURE;
+	DBusMessageIter iter;
+	DBusMessageIter array_iter;
+	DBusMessageIter  struct_iter;
+	DBusMessage *reply = NULL;
+	inquiry_info *info = NULL;
+	char addr[18];
+	const char *paddr = addr;
+	int32_t dev_id = -1;
+	uint32_t class = 0;
+	uint16_t clock_offset;
+	uint16_t flags;
+	int8_t length;
+	int8_t num_rsp;
+	int8_t i;
+
+	if ((dev_id = hci_get_route(NULL)) < 0) {
+		syslog(LOG_ERR, "Bluetooth device is not available");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+		
+	}
+	
+	dbus_message_iter_init(msg, &iter);
+	dbus_message_iter_get_basic(&iter, &length);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &num_rsp);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &flags);
+	
+	if ((length <= 0) || (num_rsp <= 0)) {
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_DBUS, BLUEZ_EDBUS_WRONG_PARAM);
+		goto cleanup;
+	}
+	
+	num_rsp = hci_inquiry(dev_id, length, num_rsp, NULL, &info, flags);
+	
+	if (num_rsp < 0) {
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+	} else {
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY, array_sig, &array_iter);
+		
+	        for (i = 0; i < num_rsp; i++) {
+			ba2str(&(info+i)->bdaddr, addr);
+
+			clock_offset = btohs((info+i)->clock_offset);
+                        /* only 3 bytes are used */
+			memcpy(&class, (info+i)->dev_class, 3);
+			
+			dbus_message_iter_open_container(&array_iter, DBUS_TYPE_STRUCT, NULL, &struct_iter);
+			dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_STRING , &paddr);
+			dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_UINT32 , &class);
+			dbus_message_iter_append_basic(&struct_iter, DBUS_TYPE_UINT16 , &clock_offset);
+			dbus_message_iter_close_container(&array_iter, &struct_iter);
+	}
+        	dbus_message_iter_close_container(&iter, &array_iter);
+        }
+
+cleanup:
+	if(info)
+		bt_free(info);
+	
+	return NULL;
+}
+
+static DBusMessage* handle_role_switch_req(DBusMessage *msg, void *data)
+{
+	DBusMessageIter iter;
+	DBusMessage *reply = NULL;
+	char *str_bdaddr = NULL;
+	bdaddr_t bdaddr;
+	uint8_t role;
+	int32_t dev_id = -1, sock = -1;
+	
+	dbus_message_iter_init(msg, &iter);
+	dbus_message_iter_get_basic(&iter, &str_bdaddr);
+	dbus_message_iter_next(&iter);
+	dbus_message_iter_get_basic(&iter, &role);
+	
+	str2ba(str_bdaddr, &bdaddr);
+	
+	dev_id = hci_for_each_dev(HCI_UP, find_conn, (long) &bdaddr);
+	
+	if (dev_id < 0) {
+		syslog(LOG_ERR, "Bluetooth device failed\n");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+	
+	sock = hci_open_dev(dev_id);
+	
+	if (sock < 0) {
+		syslog(LOG_ERR, "HCI device open failed\n");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, ENODEV);
+		goto cleanup;
+	}
+
+	if (hci_switch_role(sock, &bdaddr, role, 10000) < 0) {
+		syslog(LOG_ERR, "Switch role request failed\n");
+		reply = bluez_new_failure_msg(msg, BLUEZ_ECLASS_SYSTEM, errno);
+	} else {
+		uint8_t result = 0;
+		/* return TRUE to indicate that operation was completed */
+		reply = dbus_message_new_method_return(msg);
+		dbus_message_iter_init_append(reply, &iter);
+		dbus_message_iter_append_basic(&iter, DBUS_TYPE_BYTE, &result);
+	}
+cleanup:
+	
+	return reply;
+}

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> Sorry, but the last patch(hcid_dbus_0007.patch) was not 
> based on the latest CVS version.

I realized that yesterday, but I am in Prague now for the UnPlugFest and
haven't had Internet access for two days. The patch looks good and I
think we now have a nice and clean base to start with. However there are
some names I like to change. For example using org.bluez.Device for all
device specific configuration, like name changes. And org.bluez.Manager
for Inquiry stuff etc. Do you think that makes sense?

Regards

Marcel




-------------------------------------------------------
SF.Net email is sponsored by:
Tame your development challenges with Apache's Geronimo App Server. 
Download it for free - -and be entered to win a 42" plasma tv or your very
own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 3339 bytes --]

Hi Marcel,

Define clear object paths and interfaces will make easier define rules in
the D-Bus configuration file. In this file it's possible specify the
permissions for send and receive messages based on the interfaces, paths and
users/groups.

Based on your comment I suggested the paths and interfaces. Defining this
structure it's possible allow only the "root" or a "bluez manager"
user/group change the adapter settings.


SERVICE BUS NAME: org.bluez

<======= Device ======>
description: device specific configuration services. eg: (#1)display local
devices, inqmode, inqtype, up, down, reset, auth, noauth, encrypt, ...

object path: /org/bluez/Device
interface: /org/bluez/Device

<======= Manager ======>
description: connection services. eg: inquiry, remote name, info,
master/slave role switch, active connecions and profile specific tasks.
Multiple local adapters scenario will be considered. The default object path
and the adapter specific paths will provide the same services.

/***** HCI ******/
default object path:/org/bluez/Manager/hci (will use the default device in
the kernel)
object path: /org/bluez/Manager/hci0/hci
object path: /org/bluez/Manager/hci1/hci
interface: org.bluez.Manager.hci

/***** SDP ******/
default object path:/org/bluez/Manager/sdp
object path: /org/bluez/Manager/hci0/sdp
object path: /org/bluez/Manager/hci1/sdp
interface: org.bluez.Manager.sdp

/***** PAN ******/
default object path:/org/bluez/Manager/pan
object path: /org/bluez/Manager/hci0/pan
object path: /org/bluez/Manager/hci1/pan
interface: org.bluez.Manager.pan

/***** RFCOMM ******/
default object path:/org/bluez/Manager/rfcomm
object path: /org/bluez/Manager/hci0/rfcomm
object path: /org/bluez/Manager/hci1/rfcomm
interface: org.bluez.Manager.rfcomm

...
(#1) Probably the display local devices should be moved to other path due
the permissions that I comment before. User applications should be able list
the local adapters to use in the pan, rfcomm, sdp ...


For me, your suggestion or my last suggestion are fine, both can address the
permissions. You have the decision in your hands! :)


Regards,
Claudio

On 9/25/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > Sorry, but the last patch(hcid_dbus_0007.patch) was not
> > based on the latest CVS version.
>
> I realized that yesterday, but I am in Prague now for the UnPlugFest and
> haven't had Internet access for two days. The patch looks good and I
> think we now have a nice and clean base to start with. However there are
> some names I like to change. For example using org.bluez.Device for all
> device specific configuration, like name changes. And org.bluez.Manager
> for Inquiry stuff etc. Do you think that makes sense?
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server.
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>

[-- Attachment #2: Type: text/html, Size: 4067 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> Define clear object paths and interfaces will make easier define rules
> in the D-Bus configuration file. In this file it's possible specify
> the permissions for send and receive messages based on the interfaces,
> paths and users/groups.
> 
> Based on your comment I suggested the paths and interfaces. Defining
> this structure it's possible allow only the "root" or a "bluez
> manager" user/group change the adapter settings.
> 
> 
> SERVICE BUS NAME: org.bluez
> 
> <======= Device ======>
> description: device specific configuration services. eg: (#1)display
> local devices, inqmode, inqtype, up, down, reset, auth, noauth,
> encrypt, ...
> 
> object path: /org/bluez/Device
> interface: /org/bluez/Device

this looks good to me.

> <======= Manager ======>
> description: connection services. eg: inquiry, remote name, info,
> master/slave role switch, active connecions and profile specific
> tasks.
> Multiple local adapters scenario will be considered. The default
> object path and the adapter specific paths will provide the same
> services.
> 
> /***** HCI ******/
> default object path:/org/bluez/Manager/hci (will use the default
> device in the kernel)
> object path: /org/bluez/Manager/hci0/hci
> object path: /org/bluez/Manager/hci1/hci
> interface: org.bluez.Manager.hci
> 
> /***** SDP ******/
> default object path:/org/bluez/Manager/sdp
> object path: /org/bluez/Manager/hci0/sdp
> object path: /org/bluez/Manager/hci1/sdp
> interface: org.bluez.Manager.sdp
> 
> /***** PAN ******/
> default object path:/org/bluez/Manager/pan
> object path: /org/bluez/Manager/hci0/pan
> object path: /org/bluez/Manager/hci1/pan
> interface: org.bluez.Manager.pan
> 
> /***** RFCOMM ******/
> default object path:/org/bluez/Manager/rfcomm
> object path: /org/bluez/Manager/hci0/rfcomm
> object path: /org/bluez/Manager/hci1/rfcomm
> interface: org.bluez.Manager.rfcomm

Actually my plan is to don't use names like hci, sdp, rfcomm etc. at
all. We should define logical function names. The user of the D-Bus API
shouldn't need any Bluetooth protocol knowledge at all. So the idea
would be call it discovery, network etc.

> (#1) Probably the display local devices should be moved to other path
> due the permissions that I comment before. User  applications should
> be able list the local adapters to use in the pan, rfcomm, sdp ...

We maybe make Manager.DeviceList accessable by everybody. Are such
things possible?
 
> For me, your suggestion or my last suggestion are fine, both can
> address the permissions. You have the decision in your hands! :)

I like to have feedback and serious comments about, because I am still
in the process to open my mind for D-Bus.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Bluez-devel] help: HIDD and HID2HCI

[Charles Majola]

Issint enabling hid2hci be accompanied with hidd being started? i say 
this becouse it seem hid2hci disconnection the hid devices. So hid 
should reconnect them?  please see : 
http://bugzilla.ubuntu.com/show_bug.cgi?id=16037

---
chmj


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 6599 bytes --]

Hi Marcel,

Regarding the DeviceList permission, It possible define rules for allow/deny
services based on interface name, path, user, groups, message type, service
name(member name), ...

Therefore, provide just one interface or path is not a good idea because we
will not be able to create permission rules and a clean API.

In my opinion, only a "bluez_admin" group should be able to use the service
under the "/org/bluez/Devices" path. These services are related to device
configuration(hciconfig). Application that don't have enough
privileges will receive the error message:
org.freedesktop.DBus.Error.AccessDenied

The other ordinary services under "org/bluez/Manager..." can be available
for everyone.

Currently we are not providing any kind of session control. All userspace
applications will be able to control connections and interfere in a
connection used by other application.

Another subject is the logical function names. If you want support multiple
adapters, it's necessary export one new path for each adapter. An adapter
identification must belongs to the object path. My suggestion is use
hci(default kernel device), hci0, hci1, ... We can suggest a more suitable
message member name, like you suggested for DeviceList, but for the object
path I don't see an easiest way.

See below how I have want organize the service after your suggestions.

>>> Device PATH
permission: only bluez_admin group
path: /org/bluez/device
interface: org.bluez.device

>>> Manager PATH
permission: everyone
path: /org/bluez/Manager
interface: org.bluez.manager

* Device Independent Service
path: "/org/bluez/manager"
interface: "org.bluez.manager" (signals and request)
comment: Always active
1. Init (version check)
2. DeviceList
3. ListServices (list available services)
4. Enable (Enable an service. eg: all pan related services)
5. Disable

* Device dependent Service
path: "/org/bluez/manager/hci/controller" (default HCI services)
path: "/org/bluez/manager/hci0/controller" (HCI services)
path: "/org/bluez/manager/hci1/controller" (HCI services)
path: "/org/bluez/manager/hci/pan" (default PAN services)
path: "/org/bluez/manager/hci0/pan" (PAN services)
path: "/org/bluez/manager/hci1/pan" (PAN services)
path: "/org/bluez/manager/hci/serial" (default RFCOMM services)
path: "/org/bluez/manager/hci0/serial" (RFCOMM services)
path: "/org/bluez/manager/hci1/serial" (RFCOMM services)
path: "/org/bluez/manager/hci/services" (default SDP publish/search)
path: "/org/bluez/manager/hci0/services" (services SDP publish/search)
path: "/org/bluez/manager/hci1/services" (services SDP publish/search)

interface: "org.bluez.manager" (signals and request) can be shared for all
manager services and signals.
comment: Available only when there is a device UP. The daemon must monitor
DEV_UP/DEV_DOWN events and register/unregister the path dynamically. Each
service will be accessible through the default path and the device dependent
path.

Regards,
Claudio.


On 9/28/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > Define clear object paths and interfaces will make easier define rules
> > in the D-Bus configuration file. In this file it's possible specify
> > the permissions for send and receive messages based on the interfaces,
> > paths and users/groups.
> >
> > Based on your comment I suggested the paths and interfaces. Defining
> > this structure it's possible allow only the "root" or a "bluez
> > manager" user/group change the adapter settings.
> >
> >
> > SERVICE BUS NAME: org.bluez
> >
> > <======= Device ======>
> > description: device specific configuration services. eg: (#1)display
> > local devices, inqmode, inqtype, up, down, reset, auth, noauth,
> > encrypt, ...
> >
> > object path: /org/bluez/Device
> > interface: /org/bluez/Device
>
> this looks good to me.
>
> > <======= Manager ======>
> > description: connection services. eg: inquiry, remote name, info,
> > master/slave role switch, active connecions and profile specific
> > tasks.
> > Multiple local adapters scenario will be considered. The default
> > object path and the adapter specific paths will provide the same
> > services.
> >
> > /***** HCI ******/
> > default object path:/org/bluez/Manager/hci (will use the default
> > device in the kernel)
> > object path: /org/bluez/Manager/hci0/hci
> > object path: /org/bluez/Manager/hci1/hci
> > interface: org.bluez.Manager.hci
> >
> > /***** SDP ******/
> > default object path:/org/bluez/Manager/sdp
> > object path: /org/bluez/Manager/hci0/sdp
> > object path: /org/bluez/Manager/hci1/sdp
> > interface: org.bluez.Manager.sdp
> >
> > /***** PAN ******/
> > default object path:/org/bluez/Manager/pan
> > object path: /org/bluez/Manager/hci0/pan
> > object path: /org/bluez/Manager/hci1/pan
> > interface: org.bluez.Manager.pan
> >
> > /***** RFCOMM ******/
> > default object path:/org/bluez/Manager/rfcomm
> > object path: /org/bluez/Manager/hci0/rfcomm
> > object path: /org/bluez/Manager/hci1/rfcomm
> > interface: org.bluez.Manager.rfcomm
>
> Actually my plan is to don't use names like hci, sdp, rfcomm etc. at
> all. We should define logical function names. The user of the D-Bus API
> shouldn't need any Bluetooth protocol knowledge at all. So the idea
> would be call it discovery, network etc.
>
> > (#1) Probably the display local devices should be moved to other path
> > due the permissions that I comment before. User applications should
> > be able list the local adapters to use in the pan, rfcomm, sdp ...
>
> We maybe make Manager.DeviceList accessable by everybody. Are such
> things possible?
>
> > For me, your suggestion or my last suggestion are fine, both can
> > address the permissions. You have the decision in your hands! :)
>
> I like to have feedback and serious comments about, because I am still
> in the process to open my mind for D-Bus.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>



--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
claudio.takahasi@indt.org.br

[-- Attachment #2: Type: text/html, Size: 8004 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Eduardo Rocha]

[-- Attachment #1: Type: text/plain, Size: 7395 bytes --]

Hi Claudio,

I'm new to the bluez world, but I'd like to make some questions. I've seen
in your last email that you are suggesting that "everyone" will be able to
call methods from Manager interface. Are you planning to make the Manager
interface provide only query style methods or will every one able to change
configurations (e.g pan configuration).

Br,
Eduardo.


On 9/28/05, Claudio Takahasi <cktakahasi@gmail.com> wrote:
>
> Hi Marcel,
>
> Regarding the DeviceList permission, It possible define rules for
> allow/deny services based on interface name, path, user, groups, message
> type, service name(member name), ...
>
> Therefore, provide just one interface or path is not a good idea because
> we will not be able to create permission rules and a clean API.
>
> In my opinion, only a "bluez_admin" group should be able to use the
> service under the "/org/bluez/Devices" path. These services are related to
> device configuration(hciconfig). Application that don't have enough
> privileges will receive the error message:
> org.freedesktop.DBus.Error.AccessDenied
>
> The other ordinary services under "org/bluez/Manager..." can be available
> for everyone.
>
> Currently we are not providing any kind of session control. All userspace
> applications will be able to control connections and interfere in a
> connection used by other application.
>
> Another subject is the logical function names. If you want support
> multiple adapters, it's necessary export one new path for each adapter. An
> adapter identification must belongs to the object path. My suggestion is use
> hci(default kernel device), hci0, hci1, ... We can suggest a more suitable
> message member name, like you suggested for DeviceList, but for the object
> path I don't see an easiest way.
>
> See below how I have want organize the service after your suggestions.
>
> >>> Device PATH
> permission: only bluez_admin group
> path: /org/bluez/device
> interface: org.bluez.device
>
> >>> Manager PATH
> permission: everyone
> path: /org/bluez/Manager
> interface: org.bluez.manager
>
> * Device Independent Service
> path: "/org/bluez/manager"
> interface: "org.bluez.manager" (signals and request)
> comment: Always active
> 1. Init (version check)
> 2. DeviceList
> 3. ListServices (list available services)
> 4. Enable (Enable an service. eg: all pan related services)
> 5. Disable
>
> * Device dependent Service
> path: "/org/bluez/manager/hci/controller" (default HCI services)
> path: "/org/bluez/manager/hci0/controller" (HCI services)
> path: "/org/bluez/manager/hci1/controller" (HCI services)
> path: "/org/bluez/manager/hci/pan" (default PAN services)
> path: "/org/bluez/manager/hci0/pan" (PAN services)
> path: "/org/bluez/manager/hci1/pan" (PAN services)
> path: "/org/bluez/manager/hci/serial" (default RFCOMM services)
> path: "/org/bluez/manager/hci0/serial" (RFCOMM services)
> path: "/org/bluez/manager/hci1/serial" (RFCOMM services)
> path: "/org/bluez/manager/hci/services" (default SDP publish/search)
> path: "/org/bluez/manager/hci0/services" (services SDP publish/search)
> path: "/org/bluez/manager/hci1/services" (services SDP publish/search)
>
> interface: "org.bluez.manager" (signals and request) can be shared for all
>
> manager services and signals.
> comment: Available only when there is a device UP. The daemon must monitor
> DEV_UP/DEV_DOWN events and register/unregister the path dynamically. Each
> service will be accessible through the default path and the device dependent
> path.
>
> Regards,
> Claudio.
>
>
> On 9/28/05, Marcel Holtmann <marcel@holtmann.org> wrote:
> >
> > Hi Claudio,
> >
> > > Define clear object paths and interfaces will make easier define rules
> > > in the D-Bus configuration file. In this file it's possible specify
> > > the permissions for send and receive messages based on the interfaces,
> >
> > > paths and users/groups.
> > >
> > > Based on your comment I suggested the paths and interfaces. Defining
> > > this structure it's possible allow only the "root" or a "bluez
> > > manager" user/group change the adapter settings.
> > >
> > >
> > > SERVICE BUS NAME: org.bluez
> > >
> > > <======= Device ======>
> > > description: device specific configuration services. eg: (#1)display
> > > local devices, inqmode, inqtype, up, down, reset, auth, noauth,
> > > encrypt, ...
> > >
> > > object path: /org/bluez/Device
> > > interface: /org/bluez/Device
> >
> > this looks good to me.
> >
> > > <======= Manager ======>
> > > description: connection services. eg: inquiry, remote name, info,
> > > master/slave role switch, active connecions and profile specific
> > > tasks.
> > > Multiple local adapters scenario will be considered. The default
> > > object path and the adapter specific paths will provide the same
> > > services.
> > >
> > > /***** HCI ******/
> > > default object path:/org/bluez/Manager/hci (will use the default
> > > device in the kernel)
> > > object path: /org/bluez/Manager/hci0/hci
> > > object path: /org/bluez/Manager/hci1/hci
> > > interface: org.bluez.Manager.hci
> > >
> > > /***** SDP ******/
> > > default object path:/org/bluez/Manager/sdp
> > > object path: /org/bluez/Manager/hci0/sdp
> > > object path: /org/bluez/Manager/hci1/sdp
> > > interface: org.bluez.Manager.sdp
> > >
> > > /***** PAN ******/
> > > default object path:/org/bluez/Manager/pan
> > > object path: /org/bluez/Manager/hci0/pan
> > > object path: /org/bluez/Manager/hci1/pan
> > > interface: org.bluez.Manager.pan
> > >
> > > /***** RFCOMM ******/
> > > default object path:/org/bluez/Manager/rfcomm
> > > object path: /org/bluez/Manager/hci0/rfcomm
> > > object path: /org/bluez/Manager/hci1/rfcomm
> > > interface: org.bluez.Manager.rfcomm
> >
> > Actually my plan is to don't use names like hci, sdp, rfcomm etc. at
> > all. We should define logical function names. The user of the D-Bus API
> > shouldn't need any Bluetooth protocol knowledge at all. So the idea
> > would be call it discovery, network etc.
> >
> > > (#1) Probably the display local devices should be moved to other path
> > > due the permissions that I comment before. User applications should
> > > be able list the local adapters to use in the pan, rfcomm, sdp ...
> >
> > We maybe make Manager.DeviceList accessable by everybody. Are such
> > things possible?
> >
> > > For me, your suggestion or my last suggestion are fine, both can
> > > address the permissions. You have the decision in your hands! :)
> >
> > I like to have feedback and serious comments about, because I am still
> > in the process to open my mind for D-Bus.
> >
> > Regards
> >
> > Marcel
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads,
> > discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Bluez-devel mailing list
> > Bluez-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
>
> --
> ---------------------------------------------------------
> Claudio Takahasi
> Instituto Nokia de Tecnologia - INdT
> claudio.takahasi@indt.org.br
>

[-- Attachment #2: Type: text/html, Size: 9224 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> Regarding the DeviceList permission, It possible define rules for
> allow/deny services based on interface name, path, user, groups,
> message type, service name(member name), ...
> 
> Therefore, provide just one interface or path is not a good idea
> because we will not be able to create permission rules and a clean
> API.

my hope is to make the permission of the BlueZ D-Bus API more flexible
and thus having a separate group "domain" for every group of access
sounds totally stupid to me. The permissions shouldn't have to do
anything with the logical structure of the API.

People with more D-Bus experience than me please comment on it.

> In my opinion, only a "bluez_admin" group should be able to use the
> service under the "/org/bluez/Devices" path. These services are
> related to device configuration(hciconfig). Application that don't
> have enough 
> privileges will receive the error message:
> org.freedesktop.DBus.Error.AccessDenied
> 
> The other ordinary services under "org/bluez/Manager..." can be
> available for everyone.
> 
> Currently we are not providing any kind of session control. All
> userspace applications will be able to control connections and
> interfere in a connection used by other application.

Maybe we should restrict this somehow, but I have no clue on how to do
it at the moment. I am fully open to proposals.

> Another subject is the logical function names. If you want support
> multiple adapters, it's necessary export one new path for each
> adapter. An adapter identification must belongs to the object path. My
> suggestion is use hci(default kernel device), hci0, hci1, ... We can
> suggest a more suitable message member name, like you suggested for
> DeviceList, but for the object path I don't see an easiest way.

We can always use the BD_ADDR instead and maybe also an alias that can
be set by bluetoothd/hcid.

> See below how I have want organize the service after your suggestions.
> 
> >>> Device PATH 
> permission: only bluez_admin group
> path: /org/bluez/device
> interface: org.bluez.device
> 
> >>> Manager PATH
> permission: everyone
> path: /org/bluez/Manager
> interface: org.bluez.manager

I think these are clear and they look good, but we should look at other
D-Bus services how they design their API.

> * Device Independent Service
>  path: "/org/bluez/manager" 
>  interface: "org.bluez.manager" (signals and request)
>  comment: Always active
>    1. Init (version check)
>    2. DeviceList
>    3. ListServices (list available services)
>    4. Enable (Enable an service. eg: all pan related services)
>    5. Disable 
> 
> * Device dependent Service
>  path: "/org/bluez/manager/hci/controller" (default HCI services)
>  path: "/org/bluez/manager/hci0/controller" (HCI services)
>  path: "/org/bluez/manager/hci1/controller" (HCI services)
>  path: "/org/bluez/manager/hci/pan" (default PAN services)
>  path: "/org/bluez/manager/hci0/pan" (PAN services)
>  path: "/org/bluez/manager/hci1/pan" (PAN services)
>  path: "/org/bluez/manager/hci/serial" (default RFCOMM services)
>  path: "/org/bluez/manager/hci0/serial" (RFCOMM services)
>  path: "/org/bluez/manager/hci1/serial" (RFCOMM services)
>  path: "/org/bluez/manager/hci/services" (default SDP publish/search)
>  path: "/org/bluez/manager/hci0/services" (services SDP
> publish/search)
>  path: "/org/bluez/manager/hci1/services" (services SDP
> publish/search)

I like to use the word "default" to select the default device/service
and "network" instead of "pan", because PAN is the way to go. The
fallback to LAP is optional.

>  interface: "org.bluez.manager" (signals and request) can be shared
> for all 
>  manager services and signals.
>  comment: Available only when there is a device UP. The daemon must
> monitor  DEV_UP/DEV_DOWN events and register/unregister the path
> dynamically. Each  service will be accessible through the default path
> and the device  dependent path.

Please check how HAL is handling the device register and unregister. I
think their current interface is quite good.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 8053 bytes --]

Hi Marcel,

I don't want define a group domain for evey group of access. I think you
didn't understand my idea. I defined fixed interfaces (org.bluez.manager or
org.bluez.devices) and path names based on device identification.

In the security policy file we can define rules according with our need. We
can define rules based on paths, interfaces, users, group ... or a
combination of these parameters. At first phase of bluetoothd development we
need only define clear interfaces and path to make possible define security
policy easily in the future. We don't need thinking on define a group domain
or rules at this momment.

The interfaces name will be shared by method call, method reply, errors and
signals. Remember that one path, can have a lot of interfaces. Interfaces is
just a way to group a set of methods(services). Therefore, if you apply one
rule for a path, this rule will be applied for all interfaces that belongs
to this path.

Regarding the device identification in the path name, I prefer use hci(for
default kernel device), hci1, hci2, ... It's easier use the device id of
"evt_si_device" event. You suggested use the bluetooth address, for this
approach we can define a the default device(000000000000), and use the
string representation of bdaddr_t for the others devices. eg:"A089BE880D00",
"E4A500461300" The final decision is yours.

I checked the libhal code, a similar approach is implemented. See how the
messages are created. The first argument of the dbus_message_new_method_call
function is the service bus name, the second is the path, the third is the
interface and
the last one is the member name(service). "udi" means unique device
identification.

LIBHAL side(client):

message = dbus_message_new_method_call ("org.freedesktop.Hal", udi,
"org.freedesktop.Hal.Device",
"GetAllProperties");
message = dbus_message_new_method_call ("org.freedesktop.Hal",
"/org/freedesktop/Hal/Manager",
"org.freedesktop.Hal.Manager",
"GetAllDevices");
message = dbus_message_new_method_call ("org.freedesktop.Hal", udi,
"org.freedesktop.Hal.Device",
"GetPropertyType");
message = dbus_message_new_method_call ("org.freedesktop.Hal", udi,
"org.freedesktop.Hal.Device",
"GetPropertyStringList");
message = dbus_message_new_method_call ("org.freedesktop.Hal", udi,
"org.freedesktop.Hal.Device",
"GetPropertyInteger");
message = dbus_message_new_method_call ("org.freedesktop.Hal", udi,
"org.freedesktop.Hal.Device",
"GetPropertyInteger");
message = dbus_message_new_method_call ("org.freedesktop.Hal", udi,
"org.freedesktop.Hal.Device",
"GetPropertyDouble");
In the server side - hald(daemon)
DBusHandlerResult
device_get_property (DBusConnection * connection, DBusMessage * message){
...
udi = dbus_message_get_path (message);
..
}

Basically, HAL has two interfaces, one for devices and another for the
manager. Each device has path registered in the system Bus, where the device
identification belongs to the path.

After this analysis I think we are following the right path.

Regards,
Claudio.

On 9/29/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > Regarding the DeviceList permission, It possible define rules for
> > allow/deny services based on interface name, path, user, groups,
> > message type, service name(member name), ...
> >
> > Therefore, provide just one interface or path is not a good idea
> > because we will not be able to create permission rules and a clean
> > API.
>
> my hope is to make the permission of the BlueZ D-Bus API more flexible
> and thus having a separate group "domain" for every group of access
> sounds totally stupid to me. The permissions shouldn't have to do
> anything with the logical structure of the API.
>
> People with more D-Bus experience than me please comment on it.
>
> > In my opinion, only a "bluez_admin" group should be able to use the
> > service under the "/org/bluez/Devices" path. These services are
> > related to device configuration(hciconfig). Application that don't
> > have enough
> > privileges will receive the error message:
> > org.freedesktop.DBus.Error.AccessDenied
> >
> > The other ordinary services under "org/bluez/Manager..." can be
> > available for everyone.
> >
> > Currently we are not providing any kind of session control. All
> > userspace applications will be able to control connections and
> > interfere in a connection used by other application.
>
> Maybe we should restrict this somehow, but I have no clue on how to do
> it at the moment. I am fully open to proposals.
>
> > Another subject is the logical function names. If you want support
> > multiple adapters, it's necessary export one new path for each
> > adapter. An adapter identification must belongs to the object path. My
> > suggestion is use hci(default kernel device), hci0, hci1, ... We can
> > suggest a more suitable message member name, like you suggested for
> > DeviceList, but for the object path I don't see an easiest way.
>
> We can always use the BD_ADDR instead and maybe also an alias that can
> be set by bluetoothd/hcid.
>
> > See below how I have want organize the service after your suggestions.
> >
> > >>> Device PATH
> > permission: only bluez_admin group
> > path: /org/bluez/device
> > interface: org.bluez.device
> >
> > >>> Manager PATH
> > permission: everyone
> > path: /org/bluez/Manager
> > interface: org.bluez.manager
>
> I think these are clear and they look good, but we should look at other
> D-Bus services how they design their API.
>
> > * Device Independent Service
> > path: "/org/bluez/manager"
> > interface: "org.bluez.manager" (signals and request)
> > comment: Always active
> > 1. Init (version check)
> > 2. DeviceList
> > 3. ListServices (list available services)
> > 4. Enable (Enable an service. eg: all pan related services)
> > 5. Disable
> >
> > * Device dependent Service
> > path: "/org/bluez/manager/hci/controller" (default HCI services)
> > path: "/org/bluez/manager/hci0/controller" (HCI services)
> > path: "/org/bluez/manager/hci1/controller" (HCI services)
> > path: "/org/bluez/manager/hci/pan" (default PAN services)
> > path: "/org/bluez/manager/hci0/pan" (PAN services)
> > path: "/org/bluez/manager/hci1/pan" (PAN services)
> > path: "/org/bluez/manager/hci/serial" (default RFCOMM services)
> > path: "/org/bluez/manager/hci0/serial" (RFCOMM services)
> > path: "/org/bluez/manager/hci1/serial" (RFCOMM services)
> > path: "/org/bluez/manager/hci/services" (default SDP publish/search)
> > path: "/org/bluez/manager/hci0/services" (services SDP
> > publish/search)
> > path: "/org/bluez/manager/hci1/services" (services SDP
> > publish/search)
>
> I like to use the word "default" to select the default device/service
> and "network" instead of "pan", because PAN is the way to go. The
> fallback to LAP is optional.
>
> > interface: "org.bluez.manager" (signals and request) can be shared
> > for all
> > manager services and signals.
> > comment: Available only when there is a device UP. The daemon must
> > monitor DEV_UP/DEV_DOWN events and register/unregister the path
> > dynamically. Each service will be accessible through the default path
> > and the device dependent path.
>
> Please check how HAL is handling the device register and unregister. I
> think their current interface is quite good.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>



--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
claudio.takahasi@indt.org.br

[-- Attachment #2: Type: text/html, Size: 14477 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> I don't want define a group domain for evey group of access. I think
> you didn't understand my idea. I defined fixed interfaces
> (org.bluez.manager or org.bluez.devices) and path names based on
> device identification. 

this might be true, because I am a total newbie when it comes to D-Bus
security. I have to rely on other peoples investigation here.

> In the security policy file we can define rules according with our
> need.  We can define rules based on paths, interfaces, users,
> group ... or a combination of these parameters. At first phase of
> bluetoothd development we need only define clear interfaces and path
> to make possible define security policy easily in the future. We don't
> need thinking on define a group domain or rules at this momment.
> 
> The interfaces name will be shared by method call, method reply,
> errors and signals. Remember that one path, can have a lot of
> interfaces.  Interfaces is just a way to group a set of
> methods(services). Therefore, if you apply one rule for a path, this
> rule will be applied for all interfaces that belongs to this path.

This means we will have a generell restricted policy and we create some
holes to make specific calls available for normal users.

> Regarding the device identification in the path name, I prefer use
> hci(for default kernel device), hci1, hci2, ... It's easier use the
> device id of "evt_si_device" event. You suggested use the bluetooth
> address, for this approach we can define a the default
> device(000000000000), and use the string  representation of bdaddr_t
> for the others devices. eg:"A089BE880D00", "E4A500461300" The final
> decision is yours.

I will go with "default", because at some point I might make the HCI
device identifier strings changeable, like we can do for Ethernet. The
BDADDR_ANY is not needed, but we can do this. However this means that I
have to implement a possibility to define a default device inside the
kernel. Otherwise BDADDR_ANY in D-Bus and inside the kernel might end up
in two different devices. For the address representation I will use the
string representation "00:11:22:33:44:55", because this is how normal
users will see the address and there is no need to obfuscate the address
for it.
 
> I checked the libhal code, a similar approach is implemented. See how
> the messages are created. The first argument of the
> dbus_message_new_method_call function is the service bus name, the
> second is the path, the third is the interface and 
> the last one is the member name(service). "udi" means unique device
> identification.
> 
> LIBHAL side(client):
> 
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> udi,
> 
> "org.freedesktop.Hal.Device",
>                                                 "GetAllProperties");
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> 
> "/org/freedesktop/Hal/Manager",
> 
> "org.freedesktop.Hal.Manager",
>                                                 "GetAllDevices");
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> udi,
> 
> "org.freedesktop.Hal.Device",
>                                                 "GetPropertyType");
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> udi,
> 
> "org.freedesktop.Hal.Device",
> 
> "GetPropertyStringList");
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> udi,
> 
> "org.freedesktop.Hal.Device",
>                                                 "GetPropertyInteger");
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> udi,
> 
> "org.freedesktop.Hal.Device",
>                                                 "GetPropertyInteger");
>         message = dbus_message_new_method_call ("org.freedesktop.Hal",
> udi,
> 
> "org.freedesktop.Hal.Device",
>                                                 "GetPropertyDouble");
> In the server side - hald(daemon)
> DBusHandlerResult
> device_get_property (DBusConnection * connection, DBusMessage *
> message){
> ...
> udi = dbus_message_get_path (message);
> ..
> }
> 
> Basically, HAL has two interfaces, one for devices and another for the
> manager. Each device has path registered in the system Bus, where the
> device identification belongs to the path.
> 
> After this analysis I think we are following the right path.

I think so, too. Please send in a new patch. We need something to get
started and as you, I like it step by step.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Claudio Takahasi]

[-- Attachment #1: Type: text/plain, Size: 8203 bytes --]

Hi Marcel,

We CAN'T use the full string representation of the bluetooth address.
According with D-Bus specification the path name is restricted to
"[A-Z][a-z][0-9]_". The character ":" is not allowed. See the rules:
"* The path may be of any length.
* The path must begin with an ASCII '/' (integer 47) character, and must
consist of elements separated by slash characters.
* Each element must only contain the ASCII characters "[A-Z][a-z][0-9]_"
* No element may be the empty string.
* Multiple '/' characters cannot occur in sequence.
* A trailing '/' character is not allowed unless the path is the root path
(a single '/' character)."


Which approach do you want now ? :)




More inforamtion how D-Bus paths works:
This is just to explain to you how DBus paths works and try pass an useful
information. If we analize HAL API deeply you will notice a small
difference, HAL provide a Manager interface used to recover the
devices(including paths) information. The Device interface is used by
clients that want change/get ONE DEVICE property.

Interfaces:
org.freedesktop.Hal.Manager
org.freedesktop.Hal.Device

Manager interface services:
- GetAllDevices
- DeviceExists
- FindDeviceByCapability
....

Device interface services:
- GetProperty
- SetProperty
- Lock
- Unlock
...

Path example:
/org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0 (iface
org.freedesktop.Hal.Device)

One path represents a unique identification to where a message is sent. In
the code that I am developing there is only one D-Bus message handler, the
path will be the primary element to know which local adapter use. Remember
that each path will provide a set of services, and each path can has more
than one interface.

We are using the path "/org/bluez/Manager" to provide to userspace
application services to list ACTIVE devices and enable/disable services. The
path "/org/bluez/Devices" will be restricted to device setup. Therefore, the
message format used in "/org/bluez/Devices" path should contains one
arguments to indicate the device identification, like hciconfig uses. For
the messages send under the path "/org/bluez/Manager/BDADDR/..." is not
necessary send this argument because the path already contains the device
identification.

The prefix "/org/bluez/Manager" used before device based path is not realy
necessary. It is used only to make easier find services under this
hierarchy.

HAL DOESN'T provide an extra path as we are doing for device setup
"/org/bluez/Devices" all paths are device based. If you want copy exactly
HAL paths principle, we should have:
/org/bluez/Manager
/org/bluez/Devices/BDADDR/Hciconfig (always active)
/org/bluez/Devices/BDADDR/Hciconfig (always active)
/org/bluez/Devices/BDADDR/Controller (if dev is UP)
/org/bluez/Devices/default/Controller (if dev is UP)
/org/bluez/Devices/BDADDR/Net (if dev is UP)
/org/bluez/Devices/default/Net (if dev is UP)

And use two interfaces:
org.bluez.Manager
org.bluez.Devices



I will send a new patch in the next email.

Regards,
Claudio.


On 9/30/05, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Claudio,
>
> > I don't want define a group domain for evey group of access. I think
> > you didn't understand my idea. I defined fixed interfaces
> > (org.bluez.manager or org.bluez.devices) and path names based on
> > device identification.
>
> this might be true, because I am a total newbie when it comes to D-Bus
> security. I have to rely on other peoples investigation here.
>
> > In the security policy file we can define rules according with our
> > need. We can define rules based on paths, interfaces, users,
> > group ... or a combination of these parameters. At first phase of
> > bluetoothd development we need only define clear interfaces and path
> > to make possible define security policy easily in the future. We don't
> > need thinking on define a group domain or rules at this momment.
> >
> > The interfaces name will be shared by method call, method reply,
> > errors and signals. Remember that one path, can have a lot of
> > interfaces. Interfaces is just a way to group a set of
> > methods(services). Therefore, if you apply one rule for a path, this
> > rule will be applied for all interfaces that belongs to this path.
>
> This means we will have a generell restricted policy and we create some
> holes to make specific calls available for normal users.
>
> > Regarding the device identification in the path name, I prefer use
> > hci(for default kernel device), hci1, hci2, ... It's easier use the
> > device id of "evt_si_device" event. You suggested use the bluetooth
> > address, for this approach we can define a the default
> > device(000000000000), and use the string representation of bdaddr_t
> > for the others devices. eg:"A089BE880D00", "E4A500461300" The final
> > decision is yours.
>
> I will go with "default", because at some point I might make the HCI
> device identifier strings changeable, like we can do for Ethernet. The
> BDADDR_ANY is not needed, but we can do this. However this means that I
> have to implement a possibility to define a default device inside the
> kernel. Otherwise BDADDR_ANY in D-Bus and inside the kernel might end up
> in two different devices. For the address representation I will use the
> string representation "00:11:22:33:44:55", because this is how normal
> users will see the address and there is no need to obfuscate the address
> for it.
>
> > I checked the libhal code, a similar approach is implemented. See how
> > the messages are created. The first argument of the
> > dbus_message_new_method_call function is the service bus name, the
> > second is the path, the third is the interface and
> > the last one is the member name(service). "udi" means unique device
> > identification.
> >
> > LIBHAL side(client):
> >
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> > udi,
> >
> > "org.freedesktop.Hal.Device",
> > "GetAllProperties");
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> >
> > "/org/freedesktop/Hal/Manager",
> >
> > "org.freedesktop.Hal.Manager",
> > "GetAllDevices");
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> > udi,
> >
> > "org.freedesktop.Hal.Device",
> > "GetPropertyType");
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> > udi,
> >
> > "org.freedesktop.Hal.Device",
> >
> > "GetPropertyStringList");
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> > udi,
> >
> > "org.freedesktop.Hal.Device",
> > "GetPropertyInteger");
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> > udi,
> >
> > "org.freedesktop.Hal.Device",
> > "GetPropertyInteger");
> > message = dbus_message_new_method_call ("org.freedesktop.Hal",
> > udi,
> >
> > "org.freedesktop.Hal.Device",
> > "GetPropertyDouble");
> > In the server side - hald(daemon)
> > DBusHandlerResult
> > device_get_property (DBusConnection * connection, DBusMessage *
> > message){
> > ...
> > udi = dbus_message_get_path (message);
> > ..
> > }
> >
> > Basically, HAL has two interfaces, one for devices and another for the
> > manager. Each device has path registered in the system Bus, where the
> > device identification belongs to the path.
> >
> > After this analysis I think we are following the right path.
>
> I think so, too. Please send in a new patch. We need something to get
> started and as you, I like it step by step.
>
> Regards
>
> Marcel
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by:
> Power Architecture Resource Center: Free content, downloads, discussions,
> and more. http://solutions.newsforge.com/ibmarch.tmpl
> _______________________________________________
> Bluez-devel mailing list
> Bluez-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>



--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
claudio.takahasi@indt.org.br

[-- Attachment #2: Type: text/html, Size: 11896 bytes --]

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi Claudio,

> We CAN'T use the full string representation of the bluetooth address.
> According with D-Bus specification the path name is restricted to
> "[A-Z][a-z][0-9]_".  The character ":" is not allowed. See the rules:
>     "* The path may be of any length.
>     * The path must begin with an ASCII '/' (integer 47) character,
> and must consist of elements separated by slash characters.
>     * Each element must only contain the ASCII characters
> "[A-Z][a-z][0-9]_"
>     * No element may be the empty string.
>     * Multiple '/' characters cannot occur in sequence.
>     * A trailing '/' character is not allowed unless the path is the
> root path (a single '/' character)."
> 
> 
> Which approach do you want now ? :)

can you ask J5 (or D-Bus mailing list) about the ":" character, because
I don't see any problem with it.

> More inforamtion how D-Bus paths works:
> This is just to explain to you how DBus paths works and try pass an
> useful information. If we analize HAL API deeply you will notice a
> small difference, HAL provide a Manager interface used to recover the
> devices(including paths) information. The Device interface is used by
> clients that want change/get ONE DEVICE property.
> 
> Interfaces:
> org.freedesktop.Hal.Manager
> org.freedesktop.Hal.Device
> 
> Manager interface services:
> - GetAllDevices
> - DeviceExists
> - FindDeviceByCapability
> ....
> 
> Device interface services:
> - GetProperty
> - SetProperty
> - Lock
> - Unlock
> ...
> 
> Path example:
> /org/freedesktop/Hal/devices/usb_device_a12_1_noserial_if0 (iface
> org.freedesktop.Hal.Device)
> 
> One path represents a unique identification to where a message is
> sent. In the code that I am developing there is only one D-Bus message
> handler, the path will be the primary element to know which local
> adapter use. Remember that each path will provide a set of services,
> and each path can has more than one interface. 
> 
> We are using the path "/org/bluez/Manager" to provide to userspace
> application services to list ACTIVE devices and enable/disable
> services. The path "/org/bluez/Devices" will be restricted to device
> setup. Therefore, the message format used in "/org/bluez/Devices" path
> should contains one arguments to indicate the device identification,
> like hciconfig uses. For the messages send under the path
> "/org/bluez/Manager/BDADDR/..." is not necessary send this argument
> because the path already contains the device identification. 
> 
> The prefix "/org/bluez/Manager" used before device based path is not
> realy necessary. It is used only to make easier find services under
> this hierarchy.
> 
> HAL DOESN'T provide an extra path as we are doing for device setup
> "/org/bluez/Devices" all paths are device based. If you want copy
> exactly HAL paths principle, we should have:
> /org/bluez/Manager
> /org/bluez/Devices/BDADDR/Hciconfig (always active)
> /org/bluez/Devices/BDADDR/Hciconfig (always active)
> /org/bluez/Devices/BDADDR/Controller (if dev is UP)
> /org/bluez/Devices/default/Controller (if dev is UP)
> /org/bluez/Devices/BDADDR/Net (if dev is UP)
> /org/bluez/Devices/default/Net (if dev is UP)
> 
> And use two interfaces:
> org.bluez.Manager
> org.bluez.Devices
> 
> 
> 
> I will send a new patch in the next email.

Cool. Please don't try to include everything. Lets make small steps. I
am ready to do a new release in the next few days and I like to have
some preliminary D-Bus support in it for testing.

Will someone provide Python based graphical applications that are using
this new D-Bus interface?

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[P. Durante]

> Will someone provide Python based graphical applications that are using
> this new D-Bus interface?
>

Hi,
I'm not new here, as I've already mentioned in other posts, this
summer I've written both a dbus daemon (from scratch) and some python
gui eye-candy stuff, since you seem interested in the latter, take a
look  here :)

http://shackan.altervista.org/bluetools.png

it's still under heavy development, unfortunately university started
last week and I don't have much time now, anyway I'll keep you
informed if you want.

ps: the problem is my dbus interface is different from yours, I might
consider making it compatible if I have time to, but I'm going to
redesign my api anyway so I might "rip" a good amount of suggestions
from the way you and Claudio are doing it.

regards


-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] hcid D-Bus patch

[Marcel Holtmann]

Hi,

> I'm not new here, as I've already mentioned in other posts, this
> summer I've written both a dbus daemon (from scratch) and some python
> gui eye-candy stuff, since you seem interested in the latter, take a
> look  here :)
> 
> http://shackan.altervista.org/bluetools.png
> 
> it's still under heavy development, unfortunately university started
> last week and I don't have much time now, anyway I'll keep you
> informed if you want.

I like to have you on the time for bluetoothd and our D-Bus interface.
It seems also that you might be the one that will do the nice graphical
integration of Bluetooth into the GNOME Desktop. Please keep doing this,
because we need a lot more nice looking GUIs in the future. What do you
think if I create a bluez-gnome package in the CVS and you start working
there?

> ps: the problem is my dbus interface is different from yours, I might
> consider making it compatible if I have time to, but I'm going to
> redesign my api anyway so I might "rip" a good amount of suggestions
> from the way you and Claudio are doing it.

The design makes good progress and I am waiting for the first patches
from Claudio that I am going to include. This will help a lot. The next
release might have some inquiry interface over D-Bus.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel