Creating a 4.x org.bluez.Agent (with BUG)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Over the last few days, I have developed an Agent to implement the
org.bluez.Agent interface, so that I can test the new BT2.1-compatible
Simple Secure Pairing (SSP).

I am developing in C/C++ with Glib and libgdbus, which provides the
functions and structures for method and signal definition and especially
provides for DBus introspection.  Also, I expected to develop this as a
separate process, much like the old passkey-agent.  I found that when I
did this, however, the new agent was never found by my application,
calling the Adapter.CreatePairedDevice method.  When I tested with the
hcid/simple-agent, that Python-based agent worked well.  I would like to
share the reasons for this...

1) When first testing the agent as a separate process, I figured I had
to tie that agent to the org.bluez well-known name.  The only way I
could find to do that was to connect to the Session bus (not the System
bus), and provide "org.bluez" as the name of the bus in the session.  I
used this to test the functioning of the agent with dbus-send.  However,
when I tried calling CreatePairedDevice from my application, it did not
find the agent; the error message in syslog indicated that Method
RequestPinCode with signature "o" was not found.

2) Knowing that hcid uses the System bus, I then tried to connect with
the System bus, referencing the "org.bluez" well-known connection name.
However, the connection was rejected because (as we all know) hcid owns
that name, and only one object can own a name at a time (and hcid was
not going to give it up!).

3) I connected the agent with the System bus leaving the service name
NULL, so the agent object was assigned a "unique connection name",
something like :1.56 (changes each time).  I was able to introspect the
object, and to invoke some of the methods using dbus-send, so long as I
addressed the System bus (--system) and set the destination with that
unique connection name (--dest =:1.56).  I also went down a path of
calling RegisterAgent from within the external Agent; this worked
properly in the sense that DBus was happy with it, the Agent was still
reachable from dbus-send, etc.

4) I attempted to connect with the registered Agent using
Adapter.CreatePairedDevice, the Agent was not connected to.  The reason
for this is that CreatePairedDevice explicitly uses its own "unique
connection name" to the System bus as the "bus name", and assumes that
the Object Path will be found on that bus name.  Which is only the case
if the Agent code is contained within the same process as the rest of
the application; the application calling CreatePairedDevice.

BUG-> If there is no object with that path for the unique connection
name, the code at hcid/agent.c agent_create (line 190) should throw an
error, perhaps .DoesNotExist...  What actually happens is that the code
just creates that path and attempts to call it during pairing; throwing
no error (except for the DBus error that shows up in the syslog).
Authentication then fails with no accurate indication as to why.

5) I attempted to register the Agent within the application using
Adapter.RegisterAgent.  However, again RegisterAgent assumes that the
bus name to be used is its own unique connection name; it does not
search for the object among other connections to the System bus, nor is
there any way to pass in a well-known name or a unique connection name.

BUG-> (actually, the same bug) As with CreatePairedDevice, if there is
no object with that path for the unique connection name, RegisterAgent
should throw an error.

6) Finally, I very slightly revamped my Agent code, changed the sub main
to a callable subroutine from my main application and integrated it into
the mainloop of the application.  All now works well, because the
application and the Agent are in the same process and share the same
connection to the System bus.

YOU MAY ASK, why did I not integrate the Agent code into the main
application in the first place?

The first reason is that it was not clear that this is what I needed to
do.  Although I did receive a hint about this from Johan Hedburg
(thanks!), I expected the agent should be a separate process, much like
the 3.x passkey-agent and auth-agent.

Second, depending on the application requirements, the agent may require
entry of a pincode or passkey (in my case, I am using SSP-JustWorks, so
human entry should not be needed).  Depending on the requirements, the
Agent should not hang up the main application waiting for human
interaction.  (That said, you could non-block the IO and multi-thread
the whole thing...).

Third, I just felt that putting the Agent in another process is a
somewhat more modular way to handle security, authorization and pairing.

Fourth, because it was there (the challenge of figuring this out,
learning more about DBus, GLib and the whole mess).

To that end, and in the interest of sharing, I am submitting my agent
code as a skeleton...  To react to RequestPinCode and RequestPasskey, I
have hardcoded values... I compile with C++ and use cout and string
because I am lazy (in this experimental phase); converting to standard
C, or to popping up a dialog, is trivial.  And I throw no errors (e.g.,
.Reject), nor do I really do anything with respect to actual
authorization, etc.  In other words,  it's just a start, designed to
allow me to see the interaction with the Agent during pairing,
especially with SSP.

Questions, comments?  Feel free...

David Stockwell
Frequency One

Attachment: bluez_agent.cpp
Description: Binary data

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
Bluez-devel mailing list
Bluez-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bluez-devel

[Index of Archives]     [Linux Bluetooth Devel]     [Linux USB Devel]     [Network Devel]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux