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.
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Nokia's Institute of Technology - INdT
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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 <[email protected]> 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
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/bluez-devel
> >
>
>
>
> --
> ---------------------------------------------------------
> Claudio Takahasi
> Instituto Nokia de Tecnologia - INdT
> [email protected]
>
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
--
---------------------------------------------------------
Claudio Takahasi
Instituto Nokia de Tecnologia - INdT
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
>
>
>
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
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/bluez-devel
>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
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 <[email protected]> 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.
>
>
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
