> 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 Bluez-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.sourceforge.net/lists/listinfo/bluez-devel
