org.bluez.Agent interface vs. org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent

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


I would like to test BT 2.1 and SSP, and have installed the updated kernel with patches onto my system.  To make the connection, I have to install or create an Agent that interacts with the BT daemon (currently, hcid), to deal with the pairing issues introduced by the SSSP (Secure "Supposedly Simple" Pairing).  However, it also appears that the DBus interfaces are in flux.
So, what is the future of these; is it the org.bluez.Agent, as described in bluez-utils-3.34/doc/agent-api.txt?  Or is it the old PasskeyAgent and AuthorizationAgent described in hcid/dbus-api.txt?
Also, the daemon/ directory used to contain sample code for a passkey agent and an authorization agent.  If as I assume these need to move over to the .Agent interface, are there plans to provide a design example for these (or a combined agent daemon)?
Has the gnome agent been modified to the "experimental" interface?
When starting the sample passkey agent, it is possible to provide a path that the agent uses as its object path (in function register_agent, with the call to dbus_connection_register_object_path).  I assume that this path is what we would pass to "Adapter.CreatePairedDevice" as the object path of the agent, with the capabilities string.  Am I correct?
Any constraints on what this object path contains (for example: "/com/frequency-one")?  I assume it must be unique and must not clash with the other paths under org.bluez.
Thanks in advance...
David Stockwell
Check out the new Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Bluez-devel mailing list

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

  Powered by Linux