[PATCH 2/2] dbus control interface, v2

[Dan Williams]

On Mon, 2006-04-24 at 09:34 -0700, Jouni Malinen wrote:
> On Thu, Apr 20, 2006 at 04:56:38PM -0400, Dan Williams wrote:
> 
> > This patch, along with the previous one, adds the minimum infrastructure
> > for a dbus control interface to wpa_supplicant.
> 
> Thanks! I applied this to the development branch with some coding style
> cleanup.
> 
> Do you have an example dbus configuration file (something in
> /etc/dbus-1/system.d directory)? I adapted one file I had there and that
> seemed to allow wpa_supplicant to register the connection. dbus-monitor
> shows something happening when wpa_supplicant is started with -u, but I
> did not figure out how to use dbus-send to do something useful. If you
> can send an example command that actually ends up sending something to
> wpa_supplicant, that would allow me to test this more easily.

Right, you probably adapted just about the same thing I've done.
Initially, I've the attached file.  That uses Fedora's "at_console"
facility (which is actually provided by pam_console which is not Fedora
specific) to allow any user at the console to control wpa_supplicant
too.

So the dbus control interface as sent doesn't actually _do_ anything
yet, but it at least bootstraps the interface to the point of being able
to send/receive messages.  In the next couple days I'll get another
patch that will start duplicating the functionality of the regular
control interface.

With DBus you have a service, objects, and interfaces.  Interfaces are
mostly like Java interfaces, in that more than one object can implement
a specified interface.  When you make a method call must pass the
service, the "object path", the interface, and the method, like so:

message = dbus_message_new_method_call (NM_DBUS_SERVICE, NM_DBUS_PATH, NM_DBUS_INTERFACE, "state")

In the wpa_supplicant case, we have only one service,
"fi.epitest.hostap.WPASupplicant".  And, since we're not complicated, we
support only one interface via this service, which (confusingly) looks
just like the service name: "fi.epitest.hostap.WPASupplicant".

The object path and the method name are the interesting bits.
Initially, we'll have one default object that's located at
"/fi/epitest/hostap/WPASupplicant", which is essentially the same as the
global control interface that exists right now.  When the user adds a
specific interface, by call the "addInterface" method, for example,
another object will be created at
"/fi/epitest/hostap/WPASupplicant/eth1".  _That_ object will be used for
operations like "scan" and so forth.  It is essentially like the
interface-specific control interfaces that one may create with the
global control interface.

Anyway, I hope this will all become clearer as I add functionality to
the dbus control interface and provide some examples of how to use it.

Dan



-------------- next part --------------
<!DOCTYPE busconfig PUBLIC
 "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
 "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
        <policy user="root">
                <allow own="fi.epitest.hostap.WPASupplicant"/>

                <allow send_destination="fi.epitest.hostap.WPASupplicant"/>
                <allow send_interface="fi.epitest.hostap.WPASupplicant"/>
        </policy>
        <policy at_console="true">
                <allow send_destination="fi.epitest.hostap.WPASupplicant"/>
                <allow send_interface="fi.epitest.hostap.WPASupplicant"/>
        </policy>
        <policy context="default">
                <deny own="fi.epitest.hostap.WPASupplicant"/>
                <deny send_destination="fi.epitest.hostap.WPASupplicant"/>
                <deny send_interface="fi.epitest.hostap.WPASupplicant"/>
        </policy>
</busconfig>