<HTML > <HEAD> <META http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 11 (filtered medium)"> <style>  </style>  </HEAD> <BODY lang=EN-US link=blue vlink=purple> <DIV> <div class=Section1> For the benefit of others who may be trying to do the same thing, I *think* I have figured out how to use DBUS using TCP to provide a RPC-like mechanism. This post contains some of the documentation of the progress I have made to date.<o:p></o:p> <o:p> </o:p> Problem Description:<o:p></o:p> <o:p> </o:p> I am developing an embedded system running Linux and was originally attracted to DBUS as a general purpose IPC mechanism to communicate between various services (processes) that I write. Since this embedded box is equipped with an Ethernet port and there are several language bindings available for DBUS (including Python), I was hoping it would be simple to communicate with my services on the target from a Python script on a host (the embedded target will always reside behind the firewall/router so security is not an issue for me). This is a great way to test the target platform from the rich development environment of my host system.<o:p></o:p> <o:p> </o:p> For this example (and for testing purposes) I wanted to run another DBUS session bus that listened on a known TCP port. The first requirement is to rebuild dbus-daemon with the following change. In this example I'm using the sources from dbus-1.2.1. Looking in bus/bus.c:<o:p></o:p> <o:p> </o:p> Function: new_connection_callaback<o:p></o:p> <o:p> </o:p> I added the following call to dbus_connection_set_allow_anonymous() around line 188:<o:p></o:p> <o:p> </o:p> Before:<o:p></o:p> =====<o:p></o:p> <o:p> </o:p>   dbus_connection_set_max_received_size (new_connection, context->limits.max_incoming_bytes);<o:p></o:p>   dbus_connection_set_max_message_size (new_connection, context->limits.max_message_size);<o:p></o:p> /* on OOM, we won't have ref'd the connection so it will die. */<o:p></o:p> }<o:p></o:p> <o:p> </o:p> After:<o:p></o:p> ====<o:p></o:p> <o:p> </o:p> dbus_connection_set_max_received_size (new_connection, context->limits.max_incoming_bytes);<o:p></o:p> dbus_connection_set_max_message_size (new_connection, context->limits.max_message_size);<o:p></o:p> <o:p> </o:p> /* This allows anonymous connections */<o:p></o:p> dbus_connection_set_allow_anonymous(new_connection, TRUE);<o:p></o:p> <o:p> </o:p> /* on OOM, we won't have ref'd the connection so it will die. */<o:p></o:p> }<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Once that's compiled you now have a DBUS daemon that will support ANONYMOUS authentication over a TCP port.<o:p></o:p> <o:p> </o:p> The next step is to add a “session-local.conf” file to the same directory where session.conf is typically stored (/etc/dbus-1). This file (session-local.conf) will be automatically loaded in addition to the session.conf file. I this file we list the ports where the DBUS daemon should listen. Here's an example script:<o:p></o:p> <o:p> </o:p> <o:p></o:p> <o:p> </o:p> <!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd"><o:p></o:p> <o:p> </o:p> <busconfig><o:p></o:p> <o:p> </o:p> <o:p></o:p> <type>session</type><o:p></o:p> <o:p> </o:p> <o:p></o:p> <listen>tcp:host=localhost,bind=*,port=6666</listen><o:p></o:p> <o:p> </o:p> <o:p></o:p> <o:p> </o:p> <!—<o:p></o:p> <auth>EXTERNAL</auth><o:p></o:p> <auth>DBUS_COOKIE_SHA1</auth><o:p></o:p> <auth>ANONYMOUS</auth><o:p></o:p> --><o:p></o:p> <o:p> </o:p> </busconfig><o:p></o:p> <o:p> </o:p> Notice that I listen on ALL local interfaces on port 6666 (bind=* ensures this occurs). If you just use 'localhost' here then typically this will mean that only clients on the target itself will be able to connect to your daemon (on 127.0.0.1) over TCP while external clients (outside the target) will not. You can also explicitly specify the external IP address if you do not want the use “bind=*” to enforce binding to all local/external interfaces.<o:p></o:p> <o:p> </o:p> The DBUS documentation on authentication (<auth>) is a little sketchy when it comes to ANONYMOUS authentication. Originally, I specified every form of authentication I would allow. What I found out is that the order in which these are listed is VERY important (and contrary to what the dbus-daemon documentation seems to indicate). This was apparent when using a Python client on the host computer. If I reversed the order in which the ANONYMOUS authentication is specified from first to last (e.g. <auth>ANONYMOUS</auth> comes first before the others) my Python client could not authenticate successfully. Finally, I removed (by commenting it out) all the <auth></auth> entries and my Python client can still authenticates anonymously. Obviously, I am missing some subtle point here that perhaps someone can point out.<o:p></o:p> <o:p> </o:p> The final hurdle involved creating a client connection from my host computer using Python (on a Windows PC). Communicating over TCP using the Python DBUS client isn't obvious. Here is the gist of the script:<o:p></o:p> <o:p> </o:p> import dbus<o:p></o:p> import dbus.glib<o:p></o:p> from dbus.mainloop.glib import DbusGMainLoop<o:p></o:p> <o:p> </o:p> class TcpSessionBus(dbus.bus.BusConnection):<o:p></o:p>    <o:p></o:p>    def __new__(cls, addr, mainloop=None):<o:p></o:p>       from _dbus_bindings import BUS_SESSION<o:p></o:p>       bus = dbus.bus.BusConnection(addr, mainloop=mainloop)<o:p></o:p>       bus._bus_type = BUS_SESSION<o:p></o:p>       <o:p></o:p>       return bus<o:p></o:p>    <o:p></o:p>    def get_connection(self):<o:p></o:p>       return self<o:p></o:p>    <o:p></o:p>    _connection = property(get_connection, None, None,<o:p></o:p>                            """self._connection == self, for backwards<o:p></o:p>                            compatibility with earlier dbus-python versions<o:p></o:p>                            where Bus was not a subclass of Connection.""")<o:p></o:p>           <o:p></o:p> def main():<o:p></o:p>    addr = 'tcp:host=192.168.217.129,port=6666'<o:p></o:p>    bus = TcpSessionBus(addr, DbusGMainLoop())<o:p></o:p>    # Use the bus as normal to create an object and then retrieve the<o:p></o:p>    # interface.<o:p></o:p> <o:p> </o:p> if __name__ == '__main__':<o:p></o:p>    main()<o:p></o:p> <o:p> </o:p> This is a hack (particularly the TcpSessionBus) class and obviously could use some refinement. The default implementation of the Python SessionBus class does not allow you to specify a TCP address and required this work-around. Also, the “_connection” property of the TcpSessionBus class is important or the Python Dbus implementation will not wire up the bus class so that it can be used to receive signals/events from the service.<o:p></o:p> <o:p> </o:p> In an effort to be complete, I built and installed my “modified” dbus-daemon in a separate location from the default. The “configure” script was invoked as follows:<o:p></o:p> <o:p> </o:p> ./configure --prefix=/home/user/builds/dbus-1.2.1/publish --with-xml=expat --exec-prefix=/home/user/builds/dbus-1.2.1/publish –enable-verbose-mode<o:p></o:p> <o:p> </o:p> The “--enable-verbose-mode” is a helpful switch that will log debug information while the daemon is running.<o:p></o:p> <o:p> </o:p> After configuring it I did the “make install” step to build and install the dbus-daemon in a local directory.<o:p></o:p> <o:p> </o:p> Finally, I launched it like so:<o:p></o:p> <o:p> </o:p>  DBUS_VERBOSE=1 ./dbus-daemon --print-address –config-file=/home/user/builds/dbus-1.2.1/publish/etc/dbus-1/session.conf<o:p></o:p> <o:p> </o:p> <o:p> </o:p> I was able to communicate with a DBUS session service running on my target platform using the modified dbus-daemon. I am sure some of my steps or explanations can be improved by someone with a better understanding of the DBUS architecture. I am open to any corrections or improvements and I hope this helps someone contemplating a similar use for DBUS.<o:p></o:p> <o:p> </o:p> <o:p> </o:p> </div> </DIV> <DIV> </DIV> <DIV>******************************************* Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.   This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the contents in this e-mail is strictly forbidden. ******************************************* </DIV></BODY></HTML>