D-Bus support

Hi Folks,

while thinking about the best management interface and API for the new Bluetooth library and utils I came to the conlusion that D-Bus is the right way to go. My problem is now that I don't wanna link the Bluetooth library itself with the D-Bus library. So what I was thinking of that we extend the hcid to be a multiplexer with a D-Bus interface. So we have the HCI raw socket and ioctl's for configuration and we can use the D-Bus interface for this and also advanced things like PIN management etc. My idea behind this is, that graphical interfaces like Gnome or KDE only have to use the D-Bus for their stuff.

Proposals and comments?

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

HI Marcel

Excellent choice, I believe so too. ;)

I have implemented this in hcid, DBus sockets, Gnome configuration interface and so on. Please look at: http://noring.nocrew.org/bluetooth/

Later tonight, I'll write you a detailed description on what's already implemented on the hcid DBus interfaces, new configuration options, the nametab and keytab files etc. I'd like to discuss these things so that we can agree on the API:s etc.

Here's the release notes for the Gnome Bluetooth Configuration tool 0.1.0, released today:

o All clickable buttons are actually working! This includes:

- Devices can be brought up and down by clicking on the Activate/Deactivate buttons.
- Device names can be set by typing in the Name field.
- Trusted devices pop up instantly below the "Trusted Devices" tab when paired, with both names and addresses.
- Trusted devices can be removed by clicking on the "Remove" button.
- Devices pop up automatically in the device list when inserted (USB etc.). Remove should work too.

o Installation target (--prefix) works with the glade file.

o A name cache is maintained by hcid in /etc/bluetooth/nametab. The location of this file may change in the future, and it will be configurable. The new "pair_name" option to hcid (default "yes") makes hcid save the names of remote devices when pairing.

Fredrik

Hi Fredrik,

I already looked at your stuff. Nice work btw. At the moment I am more concerned on how the D-Bus interface should look like than a real implementation. You now that an important part for me is the security. For example a user can see what devices a paired and it can delete a pairing, but it don't have to see the link key itself. This is the job of the daemon that provides this interface. The same applies for changing device settings and storing them on the harddisk.

Another point is that I want to use the system message bus for it.

My favourite storage is Berkeley DB.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

Thanks!

I will send you the interface proposal in another e-mail. It's largely implemented and used by the Gnome Bluetooth Configuration tool already, but it's possible to modify of course.

I agree. This is the way the new proposed hcid is implemented.

That's an interesting idea, you mentioned that before. Can you elaborate, please?

Here are some advantages of using textfiles (as default) for hcid storage:

1. Textfiles are intuitive to use and debug because they work with any tool (emacs, grep, awk, perl etc.)

2. Small to medium size storage files have always been text files in Unix/Linux (/etc/passwd, /etc/hosts etc.)

3. Textfile routines are very lightweight and efficient.

Please understand that although it does work, applications should use the DBus interface instead of manipulating these files directly.

Here's how it's implemented in the proposed hcid. The default location of these files is something to discuss. File layout:

   $ ls -l /etc/bluetooth/keytab*
   -rw-r--r-- 1 root root  98 Feb  8 18:29 /etc/bluetooth/keytab
   -rw-r--r-- 1 root root 147 Feb  8 16:56 /etc/bluetooth/keytab-
   -rw------- 1 root root 138 Feb  8 18:29 /etc/bluetooth/keytab.shadow
   -rw------- 1 root root 207 Feb  8 16:56 /etc/bluetooth/keytab.shadow-

   $ ls -l /etc/bluetooth/nametab*
   -rw-r--r-- 1 root root 115 Feb  8 16:00 /etc/bluetooth/nametab
   -rw-r--r-- 1 root root  86 Feb  8 15:02 /etc/bluetooth/nametab-

The dash files ("keytab-" etc.) are backup files. The "keytab" file is readable by all. The "keytab.shadow" is only r/w-able by root. Contents:

   $ cat /etc/bluetooth/keytab
   # sba              dba                type    create time
   00:03:C9:2A:C4:A8  00:07:E0:0C:1B:3F  0       1076252948
   00:10:DC:E9:EF:20  00:80:37:AA:7A:DA  0       1076253156

   $ cat /etc/bluetooth/keytab.shadow
   # sba              dba                key
   00:03:C9:2A:C4:A8  00:07:E0:0C:1B:3F  2f66d0364a1eea2fae680af948bb3299
   00:10:DC:E9:EF:20  00:80:37:AA:7A:DA  2855bdc30b49254902d5deebe24c24ce

   $ cat /etc/bluetooth/nametab
   # bdaddr                name
   00:00:08:04:DE:C8       Fuzz Buzz
   00:80:37:AA:7A:DA       Fredrik T39
   00:07:E0:0C:1B:3F       Fredrik TT

Fredrik

Hi Fredrik,

This is my favourite and we should make it easy to substitute is with another storage backend. So the handheld or embedded people can use what they thing fits better.

If we have a D-Bus interface, these files (databases) should only be modified by the hcid. It is easier to use the Berkeley DB, because you don't have to write everything by yourself. The database code includes locking stuff for free.

My idea is to have a plain text file for default configuration and a database file with dynamic configuration.

/etc/bluetooth/hcid.conf
/etc/bluetooth/hcid.db

The "hcid.db" will store different databases in the same file, for example link keys or devices names.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

I don't want to complain about your favourite DB, but isn't a binary database engine like Berkely DB over engineering for storing a handful of keys and device names? I mean, we're talking about maybe 50 entries max for all common cases.

Textfiles can easily handle 1000+ entries of Bluetooth key pairs and device names without problems.

Text based storage is easy I'd say, and a proof of concept is already implemented too in typically less than 200 lines of code each. :) For the common cases Berkely DB is heavier, less accessible, and more difficult to maintain and debug.

That's why I think Berekely DB should be an option, if required, but not default storage.

Fredrik

Marcel,

Here's an initial draft proposal for hcid DBus interfaces (as currently implemented in hcid 2.4-fn8):

	service:   "org.bluez.hcid",
	path:      "/org/bluez/hcid/device
	interface: "org.bluez.hcid.device

           // Returns a dictionary with hci devices
           // as keys. The values are dictionaries with
           // the configuration parameters. Example:
           //    
           //   { "hci0" : { "type"         : "USB",
           //                "addr"         : "00:00:00:00:00:00",
           //                "status"       : "up",
           //                "name"         : "Fuzz",
           //                "manufacturer" : "Company" },
           //     "hci1" : { "type"         : ... } }
           method: dict(string:dict(string:string)) list(void)

           // Returns a specific configuration dict with the
           // parameters as above.
           method: dict(string:string) get_conf(string hci_dev)

           // Activates an hci device.
           method: void up(string hci_dev)
  
           // Deactivates an hci device.
           method: void down(string hci_dev)

           // Deactivates an hci device.
           method: void set_name(string hci_dev, string name)

	service:   "org.bluez.hcid",
	path:      "/org/bluez/hcid/keytab
	interface: "org.bluez.hcid.keytab

           // Returns an array with key pairs as a dictionaries.
           // Example:
           //    
           //   [ { "sba" : "00:00:00:00:00:00",
           //       "dba" : "00:00:00:00:00:00" },
           //     { "sba" : "00:00:00:00:00:00",
           //       "dba" : "00:00:00:00:00:00" },
           //     ... ]
           method: array(dict(string:string)) list(void|string hci_dev)

           // Deletes a link pair
           method: void delete(string sba, string dba)

	service:   "org.bluez.hcid",
	path:      "/org/bluez/hcid/nametab
	interface: "org.bluez.hcid.nametab

           // Returns a device name or void
           method: void|string delete(string bdaddr)

	path:      "/org/bluez/hcid
	interface: "org.bluez.hcid

           // Notifies applications that device configuration
           // has changed.
           signal: void device(void)

           // Notifies applications that trusted key configuration
           // has changed.
           signal: void keytab(void)

Fredrik

Hi Fredrik,

I think of a more generic interface. Not everything is Linux or BlueZ related ;)

service: "org.bluetooth.hci"

It is Bluetooth we are talking about, so use "bluetooth.org" even if we don't own the domain. I don't care, because it is only a name ;)

The interface is about access to a specific service or protocol, so I want to use "hci". The hcid is only the implementation of it. For the future I also think about having D-Bus interfaces for "sdp", "hid" etc.

Why not a list of devices and then an extra method for every element? I want to make this interface as open and as extendable as possible.

Of course, this is obvious. What format do we use for the parameter. You show it as string. This means "hci0" or "11:22:33:44:55:66" or both?

And I prefer also to have get_name. See comment above.

We must also have something for remote names, so set_local_name, get_remote_name etc. would maybe better.

I don't wanna use the name "keytab". Maybe "pairing_list".

Something like "is_paired(src, dst)" would also be nice.

Yes, but "delete" is too generic.

As said above. "get_remote_name" and so "del_remote_name".

Now you see that I don't really like the object oriented stuff. I see no need for "keytab", "nametab" etc. I see this interface more as somekind of multiplexing for HCI.

Can these signal also give us the new values? Like the HCI events. For example local_name_changed().

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

Well, please look at the names Freedeskop uses in DBus for generic things like disconnect signals. They actually use the "freedesktop" interface. :)

OK.

The reason is efficiency and ease of use. It's much more efficient to get everything in one batch when this is what's needed anyway. The dictionaries make this method call extremely extendable. We can also add complementary method calls if needed.

I think both should be allowed. Currently only "hciX" is implemented.

OK. Adding new methods is no problem.

Agreed, but these should not be implemented in the "device" interface because this isn't a device property.

OK.

Not in a "key pair" context, I think.

This isn't about objects. It's about modularisation. The new hcid implementation is much more modular than the previous version, made to enable plugin modules/services. It's really a very good idea to keep conceptually different things like "key pairs" and "name lookups" apart, using different interfaces.

Yes, signals can carry arguments.

Fredrik

Hi Fredrik,

please be more specific. What files are you talking about?

What stuff do UI interfaces need to get with one call?

Agreed. This makes it easy to come from socket programming to the D-Bus interface, because you can use the BD_ADDR you are also using for the socket.

Do we need a special datatype for the BD_ADDR or is string the best?

This is about objects. It is an object oriented interface. You have objects like "device", "nametab", keytab" etc. with their methods. What we don't have is instances like "hci0", so we have to carry the device as an parameter.

Do we really need this? What are the advantages of objects? I prefer differencing with the method names. For example like "get_local_name" and "get_remote_name".

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

I'm talking about the DBus specification. See:
http://freedesktop.org/Software/dbus/doc/dbus-specification.html

Excerpt: "Before an application is able to send messages to other applications it must send the org.freedesktop.DBus.Hello message to
the message bus service." ^^^^^^^^^^^^^^^^^^^^^^^^^^

I.e. the name is more about who implemented it than what it tries to implement.

The device listning on for example the main window in the Gnome Bluetooth Configuration tool.

When using DBus, I think it's a good idea to stay with generic types like int, string, dictionary and array. Makes it easier to use a wide range of languages too.

But objects carry contexts. These modular interfaces carry no contexts, and therefore cannot possibly be objects. Modular interfaces is about keeping name spaces apart.

Modules is the way to extend applications. Say someday somebody decides to do loadable modules in hcid, implementing completely new services. Naturally, these modules ought to have their own name spaces. That's what these interfaces are used for.

Mixing it makes a mess. :)

Fredrik

Hi Fredrik,

We try to implement Bluetooth so "org.bluetooth" is ok ;)

Do you mean contexts or contents?

I am not really convinced about your argument, because I prefer to have more in common with the HCI specification. But the HCI don't have any namespace. Let me think about.

Lets talk about the namespaces you are thinking of. What makes sense to separate?

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Well.. :)

I mean context as in "state" and "handle". A file descriptor is an example of handle that is a reference to a state or object. The hcid interface as proposed does not have any contexts/states/handles. It's just name space separation (modularity) for a bunch of functions.

We can perhaps have alteranative interfaces for different purposes, if the difference in semantics is large enough. For example a "standard" HCI interface with all such methods. (I'm not familiar with HCI myself.)

For example: org.bluez.hci

For stuff that doesn't fit within HCI, or becomes very akward, we can have other complementary interfaces. GUI applications have other needs than for example server applications, I suspect. Having several interfaces for the same things isn't ideal though, but some overlap for the sake of the HCI standard is perhaps a good idea?

Some ideas:

- Name services: including local device, paired and scanned names. Preferably using the same "lookup" function, because when searching for a name, applications don't want to bother where (local/remote/cache/whatever) the name comes from. Given a device address, simply return the name if it's readily available.

Note that since initiating a scan is expensive, this ought to be a separate method call.

Example: org.bluez.name

- Key/pairing services: including requesting/receiving a pairing procedure, link key and PIN management.

Example: org.bluez.link

- (Local) device configuration services: activate/deactivate devices etc. Link modes? Classes? Or maybe org.bluez.hci will be enough for this?

Example: org.bluez.device

Fredrik

Hi Fredrik,

not this way. I want to seperate the running services/profiles. The hcid must serve "org.bluetooth.hci" as its base.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

What would the Apache webserver use? "org.w3c.http"? Something like "org.apache.httpd" fits better for a DBus interface. Similarly hcid ought to use "org.bluez.hcid", I think.

Fredrik

Hi Fredrik,

this actually depends on what you provide. The httpd provides the implementation of the HTTP. We will provide a general and extend interface to the HCI functions, so we call it "hci". The hcid is the implementation of these functions on the server side.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

mån 2004-02-09 klockan 11.06 skrev Marcel Holtmann:

For example saving/loading the hcid configuration file (hcid.conf) isn't about HCI functions, is it? To include such out-of-HCI-scope functions, hcid should probably export interfaces beyond the HCI space:

org.bluetooth.hci, org.bluez.hci or org.bluez.hcid.hci org.bluez.hcid.conf
org.bluez.hcid.fuzz
org.bluez.hcid.*

Can I ask you to provide a list of all the standard HCI functions? Is the syntax/parameters/semantics defined so that exactly one HCI interface implementation makes sense?

Many thanks,
Fredrik

Hi Fredrik,

I don't wanna support this. The hcid.conf file is a configuration file for a default configuration and don't needs to read or stored through the D-Bus interface. All modifications done through the D-Bus must be stored in another file/database.

The goal is to have an interface that can be used by Gnome, KDE etc. without any proper knowledge of the running implementations and its configuration files. So this is not about hcid, this is about what do the UI applications need.

The HCI is well defined in the Bluetooth specification and you can of course look at libs2. The source contains all defined HCI commands and events for Bluetoth 1.2.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel,

mån 2004-02-09 klockan 11.38 skrev Marcel Holtmann:

This doesn't make sense. What happens when a user edits hcid.conf manually? It's simpler and straight forward to have exactly one config file which also can be edited manually if required. Please note that Gnome will most likely not expose _all_ HCI configuration features and that manual editing will be required to use these.

OK, thanks.

Fredrik

Hi Fredrik,

I don't wanna support a config file which is intend to be editable by a user and changable by a program. This is always a mess.

The hcid.conf will provide the default settings for new devices or special settings that are not in the database. If a setting is in the database, this one will be used. The hcid.conf can also contain features which we don't provide over a D-Bus interface. I don't have any problems if the Gnome utility don't provide support for all HCI config stuff. We need to write a command line utility with full support anyway, because the interface must be tested.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

mån 2004-02-09 klockan 12.03 skrev Marcel Holtmann:

That's actually the way many other configuration tools in Linux works... Like it or not, it's the simplest and most robust way to have it working because you will have to trust the administrator of the system for certain things anyway.

If the administrator decides to edit a system file, it's very likely because something really needs to be done. Hiding the real configuration files behind special binary databases is a true nightmare when stuff simply isn't working.

Emacs/grep/awk/perl et. al. are much more powerful than most special tools. The user interfaces, DBus interfaces and tools only need to support the common cases when plain text files are used. This shouldn't stop anyone from actually implementing _all_ configuration features in some tool, but the advanced stuff can be also be left to the administrator.

Fredrik

Hi Fredrik,

this is only true if the plain file itself is designed in somekind of database format like /etc/passwd, but for hcid.conf that is not acceptable. The format of hcid.conf is more flexible and if a user has to edit this file, I don't wanna allow a program do edit it as well and introduce its own format style.

So we have to separate some settings.

If we want a clean interface for the configuration stuff that is not covered by the HCI specification (like name cache etc.) we must go through these interface in all cases, because the hcid implementation is replaceable and the storage format also.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

mån 2004-02-09 klockan 14.01 skrev Marcel Holtmann:

Why is the formating style a problem?

Is the formating style issue the main reason for introducing a binary database instead of plain text?

It would be great to have file storage documented and part of the interface as well. Forcing specialized tools isn't flexible and user/admin friendly.

Fredrik

Hi Fredrik,

ask yourself what's the indentation of hcid.conf and how should a computer program know about it. Of course this is possible to handle, but it is always a mess.

No. This is the reason against letting hcid modify the hcid.conf. If the settings are stored like in /etc/passwd or in a per-line basis I have no problems with plain text files for this case.

No. If we use a uniform storage, there is no need for a D-Bus interface, because the application can modify the storage directly. One of the main ideas is to abstract from the storage of the information. We provide an interface to access and modify them and that must be enough.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

mån 2004-02-09 klockan 16.46 skrev Marcel Holtmann:

hcid can have some standard indentation style but it can also support the "--marcel-style" flag for your personal formating preferences. ;)

"Plain text files" and "DBus interface" do not exclude each other. It would be great to have them both, because they serve different pruposes:

Plain text files are great for admins, debugging, diagnostics etc.

DBus is great for system tools, Gnome, KDE etc. Besides, the DBus interfaces provide a lot more services than just maintaining files.

Agreed. But storage abstraction does not implicate storage obfuscation, does it? :)

Fredrik

Hi Fredrik,

you don't got my point here. If a system administrator modifies some settings in complex files like hcid.conf, everyone uses its own identation and style to make it best readable for themself. And nobody likes if a program changes a value and introduces some odd styles.

Config files like hcid.conf are build this way, because they can contain complex configuration. Only the administrator should edit such files.

No they don't, but with an D-Bus interface we don't need to have knowledge about these files, because this is the job of the program that provides us with this D-Bus interface.

I was never talking about D-Bus for file maintaining. I talked about a general interface for different tasks. If it comes to link keys or name caches, of couse these must be stored somewhere. But you can also store them on a SQL database in another country. Who cares? That is beyond the interface and its the job of the program that provides this interface.

As already said, I have no problem with plain text files. But hcid.conf is a configuration file and should only read once at startup. All other modification have to stored in a configuration storage. If we have stuff that overlaps, we must find a solution for it.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

mån 2004-02-09 klockan 17.30 skrev Marcel Holtmann:

Well, I don't agree with you on this.

Having two configuration files, where one is non-editable, with some kind of conflict management scheme between them does not make sense, in my opinion.

hcid.conf isn't too complex to handle by hcid as well as being editable and personal formating preferences simply isn't so important that hcid shouldn't modify this file, I think.

Besides, if you don't use the Gnome/KDE tools for hcid, the config file will not be modified anyway because the common DBus interfaces which use name caches etc. have other files like the nametab/keytab files.

Fredrik

Marcel,

mån 2004-02-09 klockan 11.38 skrev Marcel Holtmann:

This looks good but many HCI functions are perhaps a bit low level? These are probably OK:

org.bluetooth.hci.devup
org.bluetooth.hci.devdown
org.bluetooth.hci.devreset
org.bluetooth.hci.devinfo
org.bluetooth.hci.set_pkt_type
org.bluetooth.hci.set_link_policy
org.bluetooth.hci.set_link_mode
org.bluetooth.hci.write_local_name
org.bluetooth.hci.read_local_name
etc.

But these do not appear to be suited for a DBus interface because they deal with low level things like sockets:

hci_open
hci_close
hci_recv
hci_send_command
hci_send_request
hci_errno
etc.

Do you mean an extended subset of HCI? I'm not sure I understand, please explain. What will be omitted and what will be extended?

Thanks,
Fredrik

Hi Fredrik,

we don't have to use the HCI names for it. We can choose names that fit a little bit more better.

These are not needed in the D-Bus interface. The first parameter of a D-Bus method will be "string device" and can be "hci0" or a BD_ADDR and this is enough to identify the device and open the needed socket.

The HCI don't defines anything on PIN or link key management, but a D-Bus interface should provide functions for it.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

ons 2004-02-11 klockan 14.32 skrev Marcel Holtmann:

Agreed. For configuration management, the difference in reference is very important:

When using "hci0", the setting will be permanently stored and used for all devices that become "hci0". When using "00:00:00:00:00:00", the device with that address will have that setting, regardless of the interface (hci0, hci1 or otherwise). Configurations based on addresses should have higher priority than those based on interfaces.

The applications will have to be careful on how to use the references, unless we decide that configurations only will be stored on addresses regardless of the type reference used by the application.

Agreed.

Fredrik

Hi Fredrik,

do we really need to store configurations based on the device id? I think we should store them all based on the device address only.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

My opinion is that we can drop support for the "device hci0 { ... }" syntax since it's a bit confusing - Bluetooth devices are very address oriented so "device { ... }" and "device 00:00:00:00:00:00 { ... }" are enough. This would also simplify the configuration code in hcid, i.e. less risk for bugs.

Hi Fredrik,

I like to keep it, because it can be useful for embedded devices where you have two or more Bluetooth dongles. However I started using it on one of my test machines that have many dongles attached.

For the D-Bus interface and the Gnome or KDE frontend we should use BD_ADDR based settings only.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

That's OK with me.

Fredrik

Marcel,

mån 2004-02-09 klockan 11.38 skrev Marcel Holtmann:

It's important for the Gnome applications to be able to do both configuration and device management. These are two separate things.

Configuration management is about the persistent configurations (past and present), basically those configrations stored in hcid.conf. The Gnome applications must be able to list, add, remove and modify such configurations.

There may exist configurations for devices that are not attached, and there may also be devices attached that do not have any specific configuration. The Gnome applications must be able to deal with these kinds of situations intelligently.

Device management is about the devices currently attached, basically a light version of the HCI functionality in the Bluetooth lib. The Gnome applications should be able to list, probe and control such devices, but probably only at a very basic/high level through DBus.

Your idea of having device managment in "org.bluetooth.hci" is good, I think. However, we will have to decide on what that interface looks like, because as noted in my previous e-mail, the HCI is not straight forward for a DBus interface. Many things are too low-level.

The configuration management is probably better suited for another interface, possibly "org.bluetooth.conf".

Name caches, pairing etc. also have several requirements to address. For example, requesting a pairing procedure is a typical device management task. But managing paired devices (listing, removing etc.) is typically a configuration management kind of thing.

Comments?

Fredrik

Hi Fredrik,

for the real device management on HCI level we don't need any other interface. All that we need is in the Bluetooth library and the new version of the library brings full 1.2 support.

What I expect from a D-Bus interface is that it hides the HCI low level tasks and combines it with storing of settings etc. for later use. The setting of the local device is a good example. You can do this with the HCI API, but it will only set the name and after a reboot it is gone and have done again. If you set the local name through the D-Bus interface than this name will be stored in somekind of database and the low level HCI API will be used to set it. On reboot the hcid will retrieve these setting and set the local name.

The other important part is the trusted devices management, which is not defined in any part of the Bluetooth specification. From the low level stuff it is easy, because we have to store the link keys and send them on requests. For the UI level the link key itself is unimportant, but the trusted devices must be manageable.

I think we should summarise what tasks an UI have to do and then design a D-Bus interface from it.

Regards

Marcel

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

ons 2004-02-11 klockan 14.28 skrev Marcel Holtmann:

Here are some basic requirements, I think, for a Gnome Bluetooth Configuration tool:

1. List devices currently attached.
2. Get info on devices currently attached (address, name, manufacturer, type etc.)
3. Permanently configure device status (up/down).
4. Permanently configure device name.
5. Permanently configure device discoverability (Iscan? Pscan? Which?)
6. Permanently configure pair mode (allow/disallow).
7. List permanently stored configurations.
8. Remove permanently stored configurations.
9. List devices which are paired.
10. Remove devices which are paired.
11. Request the name for a device address, if available in the name cache.
12. Perform av device scan (this will also update the name cache).
13. Perform a pairing procedure (will update the name cache too).
14. Provide a one-time PIN during a pairing procedure.

(1) and (2) can possibly be solved without DBus, but the rest will require it.

Fredrik

Hi Fredrik,

Agreed.

But I also think that we should make is possible to list and configure previous attached devices. So they can change settings and attach the device later.

Agreed. Put "reset" to this list.

Maybe a flag for auto-up on/off per device would be nice.

Agreed.

I don't think that we need that. The pairing mode from hcid can go away and we should use multi every time.

If a specific service like PAN requests a pairing or not is out of scope for the current interface. These a service specific settings.

What do you mean by permanently stored configurations?

Agreed.

Agreed.

But we also need a method to set an alias name for a remote device.

We need something, but I am not sure how to do this. Let's put it at the bottom of the list.

Don't worry about the name cache. That is a very easy task for hcid.

The pairing procedure should work in background and if a PIN is needed a PIN helper window should be opened. Maybe you should look at the bluez-pin program on the internet and the D-Bus extensions for hcid.

The one-time PIN method is what I really want to have. So an application can provide a previous entered PIN and send it to hcid. The hcid will use this for the next PIN request (and don't call a PIN helper) and then forget the PIN.

It is possible, but we won't have it. D-Bus for everything ;)

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

Agreed. This is the intention of (4) - (10), see below.

Uhu? Permanent reset? ;)

What do you mean?

The intention was that when a device is permanently configured "down", it will be kept down regardless of reboots etc. It will only go up after using the other option, configuring it permanently "up". Then it will be kept up by hcid, after reboot etc. This is equivalent with having the "autoinit" option available per device, i.e. in the "device" parameter section.

I agree with the once/multi thing. But isn't it useful to be able to disable/enable pairing, i.e. deny/accept all pairing requests?

I mean what you asked above: Make it possible to list and configure previous attached devices. :) A "permanent configuration" is equivalent to having a configuration like "device 00:00:00:00:00:00 { ... }" in hcid.conf. (I know you want to have this in another database, but it would still be "equivalent" with this.)

Agreed, see (6) below.

Something is needed when a user wants to request a pairing procedure through DBus. I suspect the user would like to select a device to pair with first, i.e. do a scan.

What do you mean? I suppose an application DBus callback would be needed to handle PIN requests.

This sounds a bit strange. Isn't the PIN an on-demand thing? I mean, the user expects to enter the PIN which will be used for the current pairing procedure?

Here's an updated list:

1. List devices currently attached.
2. Get info on devices currently attached (address, name, manufacturer, type etc.)
3. Reset a device.
4. Permanently configure device status (up/down).
5. Permanently configure device name.
6. Permanently configure remote device name (alias).
7. Permanently configure device discoverability.
8. Permanently configure pair mode (accept multi, or deny all).
9. List permanently stored configurations.
10. Remove permanently stored configurations.
11. List devices which are paired.
12. Remove devices which are paired.
13. Request the name for a device address, if available in the name cache.
14. Perform a pairing procedure (will update the name cache too).
15. Provide a one-time PIN during a pairing procedure.
16. Perform av device scan (this will also update the name cache).

Fredrik

Hi Fredrik,

I tought you meant up/down as real actions.

Why? If you want to deny a paring, you can click cancel on the PIN request. And of course you can mark your device as non-inquiryable and non-pageable.

Remember these are client options. If we come to the service options we can think about once/multi/deny thing againg, but for the client it makes no sense.

So lets combine these with (1) and (2). How to present it, is a problem of the UI.

The pairing procedure should be run automaticly on the fist connect, so we shouldn't care about it.

Yes. Please look at the code that RedHat already ships.

It sounds somekind weird, but it will help in some cases.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

Yes, that too. Set the device up/down as well as keep it up/down. That's what the user expects from the GUI buttons up/down.

Well, you might want to avoid DOS PIN attacks by evil neighbours.

(1) and (2) is about current devices, that may or may not be configured. This is about list/remove configurations, that may or may not have devices attached. It's not the same thing, really.

Uh? You do need a scan to find other devices, don't you?

Sure.

I don't understand why. :)

Fredrik

Hi Fredrik,

this is more service specific. Maybe we add this later.

I don't think so, because instead of (1) and (2) we need only a method that returns the current attached devices.

	hci0 -> 11:22:33:44:55:66
	hci2 -> aa:bb:cc:dd:ee:ff

With this mapping the UI can do the rest.

Yes, but let's talk about this later and concentrate on the device configuration at the moment.

Let's think about a HID keyboard at boot time. You can't input your PIN, but the screen can display it. So you tell hcid about a one-time PIN and try to connect to keyboard in range.

Another point is that some application may want to ask for the PIN before the connect to the device.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

But device info like manufacturer isn't stored in the configuration, so you'll need the actual device for this. That's why both (1) and (2) are needed. (1) provides the list you gave above. (2) provides device info which isn't configurable. Yes?

Fredrik

Hi Fredrik,

No, we can store manufacturer, version, features etc. along with all other device information. It is very easy to keep track of these. The only difference with such informations is that they are read-only.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Marcel,

I see. Yes, that would be better. When the device is reattached, this info may need to be updated in case something has changed though. But it's great to have it available "off-line" as read-only device metadata.

Fredrik

Hi Fredrik,

don't care about the update, because this is so easy :)

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

I can only speak from my experience with dcop, but I would try to use standard types whereever it's possible. In case that there exists a d-bus counterpart to the dcop command line utility (dbus-send maybe?), it would make the bluez interface more accessible for scripts.
This (besides flexibility issues) is also the reason why I agree with Marcel that "simple" return values, but more methods are better than one method that returns all the information at once, using nested dictionaries or whatever.

greetings
Fred

-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Yes, agreed. In my experiments with D-BUS and BlueZ so far, I've been using a simple byte array for the address. Encoding it as an ASCII string would be another possibility, but this would generally make the marshalling/unmarshalling process more expensive, and doesn't really gain you anything.

p.

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Phil,

btw I tried to integrate the D-Bus patch for the PIN-Helper, but got compilation errors with the libraries from Debian Sid. Has anyone used this patch on Debian Sid?

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Ah, yeah, you need an updated version to work with D-BUS 0.20. I think
http://handhelds.org/~pb/bluez-utils-2.3-dbus-20040119.diff
is the right file. The version of bluez-pin in Sid is already updated. Let me know if you still have trouble.

p.

Hi Phil,

I included your patch with a massive coding style change. Any other outstanding stuff before I prepare a new release?

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel

Ah, cool. Nothing else from me.

p.

Hi Philip,

before I forget it. This must be changed

	#define SERVICE_NAME "org.handhelds.gpe.bluez"
	#define INTERFACE_NAME SERVICE_NAME ".PinAgent"
	#define REQUEST_NAME "PinRequest"
	#define PATH_NAME "/org/handhelds/gpe/bluez/PinAgent"

I prefer something like "org.bluetooth.pin.request".

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

I don't think it'd be a good idea to use "org.bluetooth", unless you can get the bluetooth SIG to endorse the interface. But we could certainly use "org.bluez".

p.

Hi Philip,

actually I don't care about the Bluetooth SIG. This interface is not really BlueZ and Linux specific, because the FreeBSD stack can also make use of it.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Right, but BlueZ is the group defining the interface. Linux and FreeBSD are not the only Bluetooth vendors, so I don't think it is appropriate to use the bluetooth.org namespace.

Do you think that the FreeBSD people will have a problem using an interface that has "bluez" in the name?

p.

Hi Philip,

for me this is only a name and the technology behind it is Bluetooth, so I prefer to use org.bluetooth. That's it.

Personally I don't like this reversed domain stuff I have seen first with the introduction of Java.

I don't know, but I like to have a pseudo standard interface that can be used across free unix operating systems.

Regards

Marcel

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

I agree that it's just a name, but I don't think it's necessarily appropriate for us to use the Bluetooth name just because that's the underlying technology. The reason for having the domain identifier is to ensure unique naming, not to indicate the provenance of the interface. Any other group that wanted to invent D-BUS bindings for Bluetooth would be just as entitled as us to use the "org.bluetooth" namespace. Not that I think this is especially likely to happen, but it still seems like bad form to usurp those identifiers.

We can still have that within the org.bluez namespace.

p.

Hi Philip

ons 2004-02-18 klockan 01.29 skrev Philip Blundell:

I too had this discussion with Marcel on this list a week ago and I agree with you: "org.bluez" appears to be the proper D-Bus prefix.

Fredrik

Hi Marcel

tis 2004-02-17 klockan 23.59 skrev Marcel Holtmann:

I have a bunch of patches that extends hcid with D-Bus interfaces and so on (see http://noring.nocrew.org/bluetooth/) which would be very useful for the Gnome Bluetooth Configuration utility:

1. The "keytab" file for link keys
2. The "nametab" file for cached names
3. The D-Bus interface
4. The use of "hcid.conf" for configuration storage

Everything except (4) is implemented.

Fredrik

Hi Phil

mån 2004-02-16 klockan 15.46 skrev Phil Blundell:

Marshalling of text addresses is probably negligible in a DBus context. It can potentially make the interface more accessible to text based tools such as Perl as configurarions, user input etc. are based on text addresses.

Fredrik

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Fredrik

I don't think this is really an issue: text-based tools are probably going to be using dbus-send, which can take care of converting to binary representation from some convenient textual format. Or, for languages which have their own D-BUS bindings, it would be handled at that level. So we may as well use the D-BUS type system, rather than manually converting everything to and from text strings.

p.

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Phil,

tor 2004-02-19 klockan 17.48 skrev Phil Blundell:

This would require applications to convert Bluetooth addresses to/from an artificial byte array representation which in most cases doesn't have any meaning nor usefulness for the applications anyway. This is not only unneeded work, it's also harmful because it restricts the address format at the application layer instead of the at proper protocol layer.

Consider the same address issue with ipv4: It's better for high-level applications to use text addresses (e.g. "127.0.0.1") instead of four byte arrays. It's not only more convenient, it also works when the address format is extended with ipv6.

Fredrik

-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Bluez-devel mailing list [email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel