> Hi David,
Hello, Marcel...
>
>> 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).
>>
>> 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...
>
> this sounds like a bug in hcid. You can use CreateDevice on a
> Bluetooth
> 2.1 device and it will do just-works pairing.
When I CreatePairedDevice, the devices pair, but end up using legacy
pairing with a pin code. This makes me suspicious.
At the same time, CreateDevice does not appear to attempt to pair at
all.
I am investigating to see if somehow my remote device is not in SSP mode
(s/b default at this level of CSR's BlueLab SDK). Alternatively, I am
checking to see if the BT USB dongle is not quite capable of supporting
SSP, because of an older HCI stack.
>
> Or try to call CreatePairedDevice with a wrong agent path and it
> should
> gently fallback to the default one.
Thanks, now that my in-process Agent is working, I have verified that
this fallback works.
>
>> 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.
>
> This is total non-sense. Session bus and system are two separate
> things
> and nothing to do with each other.
Agreed, I was documenting my learning process...it would have been
better to post this to bluez-users, not to bluez-devel (after all, you
all know this in excruciating detail, right?)
>
>> 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.
>
> An agent has not to provide a well known name. Our whole design is
> based
> on the fact that an agent can connect to the system with a unique
> name.
> Meaning that we don't need a security config file for the agent.
Agree with the concern for a security config file, which should not be a
bluez issue in any event, but for the provider of the Agent. However,
if using a unique connection name, there is no way to pass that unique
name to RegisterAgent. Plus the issue of telling the
RegisterAgent-calling what that unique name is.
>
>> 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.
>
> That is how it is suppose to be. The :1.56 is the unique and it is
> unique for the life time of the system. It will never get re-assigned.
Yes, I know: again, better to send to bluez-users. Sorry.
>
>> 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.
>
> The object paths are per connection to the bus. So application A has
> its
> own namespace for the objects and application B has another one.
For CreatePairedDevice, a bad path (e.g., /x/y/zzy) is fine and causes
fall-back to the Register(ed)Agent if any. Maybe a little inelegant
(imho), but fine.
>
>
>> 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.
>
> Not a bug. We don't care. If calling the Agent object fails, then we
> fail the pairing process. That is perfectly fine.
I agree that failing pairing is OK; I am more concerned about
RegisterAgent not finding the Object Path and not telling anybody (even
the syslog).
>
>
> You know that there is a simple-agent Python script inside the
> bluez-utils source code :)
Yes, it was the basis for my work. Thanks. For perhaps irrational
reasons, I prefer to use C/C++ at this point, despite the extra work.
That said, except for the "bug" questions, this should have been posted
to bluez-users; I am sure there are others who may be struggling with
these interfaces (and what is coming down the pike), and my intent is to
save them a bit of struggle.
Best regards, David
>
> Regards
>
> Marcel
>
>
>
>
>
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Hi David,
> >> 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).
> >>
> >> 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...
> >
> > this sounds like a bug in hcid. You can use CreateDevice on a
> > Bluetooth
> > 2.1 device and it will do just-works pairing.
>
> When I CreatePairedDevice, the devices pair, but end up using legacy
> pairing with a pin code. This makes me suspicious.
you will need the kernel patches from my bluetooth-2.6 repository to
enable Simple Pairing.
> At the same time, CreateDevice does not appear to attempt to pair at
> all.
With Simple Pairing it is just-works model. Otherwise no pairing.
> >> 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.
> >
> > An agent has not to provide a well known name. Our whole design is
> > based
> > on the fact that an agent can connect to the system with a unique
> > name.
> > Meaning that we don't need a security config file for the agent.
>
> Agree with the concern for a security config file, which should not be a
> bluez issue in any event, but for the provider of the Agent. However,
> if using a unique connection name, there is no way to pass that unique
> name to RegisterAgent. Plus the issue of telling the
> RegisterAgent-calling what that unique name is.
The whole point is not to pass bus names around at all. We get the
unique name of the agent from the D-Bus message. This is all meant to be
this way so we can track the existence of an agent and if it dies
unexpectedly. Also you can only register yourself as an agent. You
should never mess around with other applications. It is on purpose
contained like this.
> >> 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.
> >
> > The object paths are per connection to the bus. So application A has
> > its
> > own namespace for the objects and application B has another one.
>
> For CreatePairedDevice, a bad path (e.g., /x/y/zzy) is fine and causes
> fall-back to the Register(ed)Agent if any. Maybe a little inelegant
> (imho), but fine.
The right way is to actually implement an agent if you wanna use
CreatePairedDevice. This fallback happens to work. Use it if you must,
but we are not encouraging people to do so. Also when writing real UI
application you do want a specific agent in this case anyway.
> >> 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.
> >
> > Not a bug. We don't care. If calling the Agent object fails, then we
> > fail the pairing process. That is perfectly fine.
>
> I agree that failing pairing is OK; I am more concerned about
> RegisterAgent not finding the Object Path and not telling anybody (even
> the syslog).
Again. That is up to the agent to implement this right. Doing any extra
checking for hcid side is wasted time. And we do syslog issues when
calling the agent fails.
> > You know that there is a simple-agent Python script inside the
> > bluez-utils source code :)
>
> Yes, it was the basis for my work. Thanks. For perhaps irrational
> reasons, I prefer to use C/C++ at this point, despite the extra work.
I have to fixup the passkey-agent.c example, but there was simply no
time.
> That said, except for the "bug" questions, this should have been posted
> to bluez-users; I am sure there are others who may be struggling with
> these interfaces (and what is coming down the pike), and my intent is to
> save them a bit of struggle.
I don't care. In a few month I will merge the mailing lists anyway.
Regards
Marcel
-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel