hcid D-Bus patch

Bluez-devel Claudio Takahasi 5 participants 27 messages Sep 16, 2005 – Oct 3, 2005 Bluetooth drivers

lore

Share & tools

lore

Claudio Takahasi

author

2005-09-16 14:42 UTC #0 lore raw

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.

hcid/Makefile.am +1 -1

@@ -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

hcid/dbus-internal.h +71 -0

71 lines not on this page · raw message

hcid/dbus.h +86 -0

86 lines not on this page · raw message

hcid/dbus.c +139 -9

198 lines not on this page · raw message

hcid/common.c +80 -0

80 lines not on this page · raw message

Claudio Takahasi

author

2005-09-19 14:31 UTC #1 lore raw

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

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;
}
...

Quoted 25 lines · Claudio Takahasi

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.

Marcel Holtmann

maintainer

2005-09-20 11:39 UTC #2 lore raw

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

Hi Claudio,

Quoted 5 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-21 08:51 UTC #3 lore raw

In reply to Claudio Takahasi

Hi Claudio,

Quoted 16 lines

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

Quoted 1 line

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

Claudio Takahasi

author

2005-09-21 12:49 UTC #4 lore raw

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.

Quoted 50 lines · Marcel Holtmann

Hi Claudio,
Quoted 16 lines
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
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

P. Durante

2005-09-21 13:19 UTC #5 lore raw

Hi,

Quoted 1 line

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...

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

Claudio Takahasi

author

2005-09-21 13:52 UTC #6 lore raw

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.

Quoted 38 lines · P. Durante

Hi,
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-22 14:13 UTC #7 lore raw

Hi Claudio,

Quoted 8 lines

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

Claudio Takahasi

author

2005-09-22 17:12 UTC #8 lore raw

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

Quoted 38 lines · Marcel Holtmann

Hi Claudio,
Quoted 8 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-22 14:17 UTC #9 lore raw

In reply to Claudio Takahasi

Hi Claudio,

Quoted 5 lines

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.

Quoted 12 lines

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

Quoted 1 line

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

Claudio Takahasi

author

2005-09-22 16:51 UTC #10 lore raw

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:

Quoted 1 line

Quoted 1 line
Quoted 1 line
Message Error Names:

org.bluez.EFailed
org.bluez.ENoMemory
/* open to more error names */

Quoted 1 line

Quoted 1 line
Quoted 1 line
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

Quoted 48 lines · Marcel Holtmann

Hi Claudio,
Quoted 5 lines
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.
Quoted 12 lines
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
Quoted 1 line
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-22 17:54 UTC #11 lore raw

Hi Claudio,

Quoted 11 lines

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

Quoted 4 lines

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.

Quoted 8 lines

After this discussion I would suggest the following structure:
Quoted 1 line
Quoted 1 line
Quoted 1 line
Message Error Names:
org.bluez.EFailed
org.bluez.ENoMemory
/* open to more error names */
Quoted 1 line
Quoted 1 line
Quoted 1 line
org.bluez.EFailed

Quoted 9 lines

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

Claudio Takahasi

author

2005-09-23 14:28 UTC #12 lore raw

Hi folks,

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

Suggestions and comments are welcome!

Regards,
Claudio

Quoted 1 line

Quoted 1 line
Quoted 1 line
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

Quoted 1 line

Quoted 1 line
Quoted 1 line
Configuration file

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

Quoted 1 line

Quoted 1 line
Quoted 1 line
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

hcid/dbus.h +153 -0

@@ -0,0 +1,153 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <[email protected]>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <[email protected]>
+ *
+ *
+ *  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__*/

hcid/dbus.c +578 ~~-12~~

662 lines not on this page · raw message

Claudio Takahasi

author

2005-09-23 17:15 UTC #13 lore raw

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.

Quoted 50 lines · Claudio Takahasi

Hi folks,
This patch implements inquiry, periodic inquiry, role switch and cancel periodic inquiry.
Suggestions and comments are welcome!
Regards,
Claudio
Quoted 1 line
Quoted 1 line
Quoted 1 line
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
Quoted 1 line
Quoted 1 line
Quoted 1 line
Configuration file
location: /etc/dbus-1/system.d/hcid.conf
The D-Bus configuration file is required for security policies.
Quoted 1 line
Quoted 1 line
Quoted 1 line
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

Quoted 10 lines

//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

hcid/dbus.h +153 -0

@@ -0,0 +1,153 @@
+/*
+ *
+ *  BlueZ - Bluetooth protocol stack for Linux
+ *
+ *  Copyright (C) 2000-2001  Qualcomm Incorporated
+ *  Copyright (C) 2002-2003  Maxim Krasnyansky <[email protected]>
+ *  Copyright (C) 2002-2005  Marcel Holtmann <[email protected]>
+ *
+ *
+ *  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__*/

hcid/dbus.c +574 -9

643 lines not on this page · raw message

Marcel Holtmann

maintainer

2005-09-25 10:33 UTC #14 lore raw

Hi Claudio,

Quoted 2 lines

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

Claudio Takahasi

author

2005-09-26 11:59 UTC #15 lore raw

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

Quoted 30 lines · Marcel Holtmann

Hi Claudio,
Quoted 2 lines
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel Holtmann

maintainer

2005-09-28 08:45 UTC #16 lore raw

Hi Claudio,

Quoted 12 lines

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

Quoted 7 lines

<======= 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.

Quoted 27 lines

<======= 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

Quoted 5 lines

/***** 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.

Quoted 3 lines

(#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?

Quoted 2 lines

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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Charles Majola

2005-09-28 09:08 UTC #17 lore raw

[Bluez-devel] help: HIDD and HID2HCI

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

Claudio Takahasi

author

2005-09-28 19:19 UTC #18 lore raw

In reply to Marcel Holtmann

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.

Quoted 1 line

Quoted 1 line
Quoted 1 line
Device PATH

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

Quoted 1 line

Quoted 1 line
Quoted 1 line
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.

Quoted 83 lines · Marcel Holtmann

Hi Claudio,
Quoted 12 lines
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
Quoted 7 lines
<======= 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.
Quoted 27 lines
<======= 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
Quoted 5 lines
/***** 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.
Quoted 3 lines
(#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?
Quoted 2 lines
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

Quoted 9 lines

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
[email protected]

Eduardo Rocha

2005-09-28 19:53 UTC #19 lore raw

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.

Quoted 182 lines · Claudio Takahasi

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.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Device PATH
permission: only bluez_admin group
path: /org/bluez/device
interface: org.bluez.device
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
Quoted 84 lines · Marcel Holtmann
Hi Claudio,
Quoted 13 lines
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
Quoted 7 lines
<======= 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.
Quoted 27 lines
<======= 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
Quoted 5 lines
/***** 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.
Quoted 3 lines
(#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?
Quoted 2 lines
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
Quoted 10 lines
-------------------------------------------------------
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 [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
[email protected]

Marcel Holtmann

maintainer

2005-09-29 16:25 UTC #20 lore raw

In reply to Claudio Takahasi

Hi Claudio,

Quoted 7 lines

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.

Quoted 7 lines

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

Quoted 6 lines

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.

Quoted 6 lines

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.

Quoted 11 lines

See below how I have want organize the service after your suggestions.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Device PATH
permission: only bluez_admin group
path: /org/bluez/device
interface: org.bluez.device
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.

Quoted 10 lines

* 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

Quoted 15 lines

* 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.

Quoted 7 lines

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

Claudio Takahasi

author

2005-09-29 19:26 UTC #21 lore raw

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.

Quoted 108 lines · Marcel Holtmann

Hi Claudio,
Quoted 7 lines
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.
Quoted 7 lines
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
Quoted 6 lines
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.
Quoted 6 lines
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.
Quoted 11 lines
See below how I have want organize the service after your suggestions.
Quoted 1 line
Quoted 1 line
Quoted 1 line
Device PATH
permission: only bluez_admin group
path: /org/bluez/device
interface: org.bluez.device
Quoted 1 line
Quoted 1 line
Quoted 1 line
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.
Quoted 10 lines
* 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
Quoted 15 lines
* 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.
Quoted 7 lines
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

Quoted 9 lines

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]

Marcel Holtmann

maintainer

2005-09-30 08:37 UTC #22 lore raw

Hi Claudio,

Quoted 4 lines

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.

Quoted 7 lines

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.

Quoted 5 lines

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.

Quoted 7 lines

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.

Quoted 55 lines

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);
..
}

Quoted 5 lines

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

Claudio Takahasi

author

2005-09-30 14:52 UTC #23 lore raw

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.

Quoted 116 lines · Marcel Holtmann

Hi Claudio,
Quoted 4 lines
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.
Quoted 7 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
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.
Quoted 55 lines
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);
..
}
Quoted 5 lines
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

Quoted 9 lines

-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]

Marcel Holtmann

maintainer

2005-09-30 15:03 UTC #24 lore raw

Hi Claudio,

Quoted 14 lines

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)."

Quoted 1 line

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.

Quoted 58 lines

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)

Quoted 7 lines

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

P. Durante

2005-10-02 11:52 UTC #25 lore raw

Quoted 3 lines

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

Marcel Holtmann

maintainer

2005-10-03 13:57 UTC #26 lore raw

Hi,

Quoted 10 lines

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?

Quoted 4 lines

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