D-BUS fixes for hcid

Hi,

There are some problems with the current D-BUS pin-request handling in hcid. The attached patch tries to address those.

Also, the bluez-pin package will need to provide a D-BUS service file (bluez.service) so that the D-BUS daemon can activate it when needed. This file goes usually in /usr/lib/dbus-1.0/services and it's contents should be something like the following:

[D-BUS Service]
Name=org.bluez.PinAgent
Exec=/usr/bin/bluez-pin

You'll also need the following line in /etc/dbus-1/system.conf (at least the debian package of D-BUS doesn't have it):
<servicedir>/usr/lib/dbus-1.0/services</servicedir>

br,
Johan

@@ -75,7 +75,8 @@
 
 	message = dbus_pending_call_get_reply(call);
 
-	if (dbus_message_is_error(message, WRONG_ARGS_ERROR))
+	if (message == NULL ||
+	    dbus_message_get_type(message) == DBUS_MESSAGE_TYPE_ERROR)
 		goto error;
 
 	dbus_message_iter_init(message, &iter);

@@ -131,6 +132,8 @@
 	dbus_message_iter_append_byte_array(&iter,
 			(unsigned char *) &ci->bdaddr, sizeof(ci->bdaddr));
 
+	dbus_message_set_auto_activation(message, TRUE);
+
 	if (dbus_connection_send_with_reply(connection, message,
 						&pending, TIMEOUT) == FALSE) {
 		syslog(LOG_ERR, "D-BUS send failed");

Hi Johan,

since I don't know very much about D-Bus, please explain your changes to me. Why are they needed?

Don't get your point here, because it works perfect on my Debian Sid.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

The first part with the error handling is needed because dbus_pending_call_get_reply() may return NULL if a timeout occurs (a reply isn't received in time). Also, if new errors are added in the future it is probably better to check for the general case here:
dbus_message_get_type().

The second part (dbus_message_set_auto_activation) enables service activation if the PinAgent service isn't aquired by any process (i.e. the D-BUS daemon will execute the pin-helper program if needed).

Do you mean that without these changes, the pin-helper is automatically launched when a D-BUS message is sent by hcid to the service org.bluez.PinAgent? I could not get it working without the changes. What version of D-BUS are you using?

Johan

Actually you might even now get some DBUS_ERROR_* from dbus_pending_call_get_reply (for example DBUS_ERROR_NO_REPLY), so the dbus_message_get_type() == ERROR test is needed anyway.

Johan

Hi Johan,

ok, but the "message == NULL" must be moved into the D-Bus library. I checked their source code and actually they miss a

	_dbus_return_val_if_fail (message != NULL, ???);

in their function.

The hcid shouldn't execute the D-Bus PIN helper. In case of a failure with the D-Bus version it should fall back to the old one.

I use these tools:

Desired=Unknown/Install/Remove/Purge/Hold

| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name           Version        Description
+++-==============-==============-============================================
ii  bluez-hcidump  1.5-2          Analyses Bluetooth HCI packets
ii  bluez-pin      0.23-1         Bluetooth PIN helper with D-BUS support
ii  bluez-utils    2.7-4          Bluetooth tools and daemons

And I set this in hcid.conf:

# PIN helper
pin_helper /usr/bin/bluez-pin;

# D-Bus PIN helper
dbus_pin_helper;

fine.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel,

I must admit that I hadn't looked into how the bluez-pin program works in D-BUS mode. It seems it should be running all the time to be able to receive any D-BUS requests, correct?

The service activation feature of D-BUS which I have talked about is designed to solve the problem where some D-BUS service should be launched on-demand. I think the pin-helper falls exactly into this category, and would be IMHO more elegant if it wouldn't have to be running all the time but would be automatically launched by D-BUS daemon when needed.

Not hcid, but the D-BUS daemon.

Ok. But by using D-BUS service activation, you wouldn't need to do this.

Johan

Hi Johan,

if we change it this way, then how do the D-Bus PIN Helper get its information about the running X server?

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Good question ;-). One option is to hardcode DISPLAY=:0 to the pin-helper. Another one (probably better) is to start the D-BUS daemon with some default DISPLAY environment variable (which its child processes will inherit). How is this done with the old pin-helper design where hcid execs the pin-helper?

Johan

Hi Johan,

this was exactly the problem with old PIN helper and this is why the D-Bus version should be started from .xession user script.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Agreed.

On debian, dbus-1-utils installs a xsession startup script that checks for use-session-dbus in /etc/X11/Xsession.options Therefore dbus daemon knows the $DISPLAY.

Johan: When 2 xservers are running on vt7 as :0 and vt8 as :1
respectively. Do the 2 dbus daemons know which one is active?
(i.e. crt or lcd currently displays :0 or :1) Would be nice to get the pin helper window on :1 if one is working there instead of on :0 ;)

Achim

  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [email protected]

However, hcid uses the system D-BUS which knows nothing about the session (system D-BUS and session D-BUS are run as two separate processes). This is an interesting problem, because from a lowlevel (BT-stack) standpoint we want to use the system bus, but from a higher level (pin-code dialog) standpoint the session bus would be apropriate.

It would be nice to know how the D-BUS designers have thought about this kinds of problems.

No idea. But probably not.

Johan

Hi Johan,

feel free to come up with a solution for this.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Hi Marcel,

Unfortunately I don't have one. Would it still be possible to add the dbus_message_set_auto_activation function call to the code? This will not change the behaviour in any way if the service is already aquired (i.e. bluez-pin is running), but will allow more flexibility if someone decides that they want to use D-BUS activation (for example in an embeded system where you only have one display and don't want to have unecessary processes taking up memory all the time).

Johan

Hi Johan,

right now I don't see where this helps. If you work embedded, you don't need the D-Bus support. Use the old PIN helper stuff and write a shell script or program that handles the input of the PINs.

Regards

Marcel

-------------------------------------------------------
This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel

$DISPLAY is indeed in the enviroment when started by the debian x-session. But dbus doesn't (and shouldn't) care about it. There is nothing that says that a dbus session bus is connected to an X session (could be console only session just as well)..

From both standpoints you'll want to use the system bus. A bluetooth pin query is not linked to a specific users session, but to complete system.

The current sollution is correct imho, when a users wants to answer pin queries he/she should have something running that monitors the system bus for them. That something could be a gnome applet/notification icon, a kde thingie or a simple command line program that doesn't really matter.

The activation stuff could be nice for non-interactive pin handlers, but you can already use the ``old'' pin_helper option of hcid for that.

Sjoerd

Men love to wonder, and that is the seed of science.

As long is dbus does not delete DISPLAY it's okay ;) Child processes inherit DISPLAY (if available) and that's the important point. In hotplug scripts you have to hardcode :0 (almost always wrong when someone works in a second session on :1) or implement hack to find out the right display.

That does not scale well. Why does inetd exist? Just to not waste resources. Something similar for the desktop should exist! We have hotplug, on the one side and the desktop session on the other side. Maybe the design of dbus is too limited (or simply not designed
for it). But AFAIK dbus can start apps on demand. So

hotplug -> system dbus -> session dbus -> desktop tool/applet

was (one of) my expectation of dbus. Makes no sense that every app needs to know about dbus protocol, when all that's needed is just a 'desktop inetd' that start or notifies, e.g. via DCOP, an application off a certain hotplug event.

But this get's off really topic, I'll check the dbus mailing lists ...

Achim

  To me vi is Zen.  To use vi is to practice zen. Every command is
  a koan. Profound to the user, unintelligible to the uninitiated.
  You discover truth everytime you use it.
                                      -- [email protected]