[Bluez-devel] org.bluez.Agent interface vs. org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent

[Bluez-devel] org.bluez.Agent interface vs. org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent

[David Stockwell]

[-- Attachment #1.1: Type: text/plain, Size: 1477 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 2530 bytes --]

[-- Attachment #2: Type: text/plain, Size: 247 bytes --]

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

[-- Attachment #3: Type: text/plain, Size: 164 bytes --]

_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] org.bluez.Agent interface vs. org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent

[Johan Hedberg]

Hi David,

On Jun 27, 2008, at 23:07, David Stockwell wrote:
> 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?

org.bluez.Agent is the "future" as you put it. It gets enabled through  
the -x switch in 3.x versions. For 4.x the old PasskeyAgent and  
AuthorizationAgent will go away.

> 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)?

There already is one. Take a look at hcid/simple-agent

> Has the gnome agent been modified to the "experimental" interface?

This one I'll have to let Marcel answer since he's responsible for it.

> 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?

Yes. However in the CreatePairedDevice case the agent can't be  
implemented by anyone else except the caller (since hcid identifies  
the location of the agent by the unique name of the sender of  
CreatePairedDevice) so typically it would be a different  
implementation that the generic agent registered through RegisterAgent.

> 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.

There are no constraints as long as it's a valid object path. The  
agent's path resides in the agents object path hierarchy which is  
totally independent from hcid's object path hierarchy (since they  
reside withing two different processes).

Johan

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

Re: [Bluez-devel] org.bluez.Agent interface vs. org.bluez.PasskeyAgent and org.bluez.AuthorizationAgent

[Marcel Holtmann]

Hi David,

> > Has the gnome agent been modified to the "experimental" interface?
> 
> This one I'll have to let Marcel answer since he's responsible for it.

there is no support for the 4.x API in bluez-gnome.

Regards

Marcel



-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel