HAL/Bluez integration
I've put a tarball up at
http://www.codon.org.uk/~mjg59/tmp/hal-bluetooth.tar.gz as a first attempt at some degree of integration. The current interface is basically:
1) Bluetooth HCIs support a "Scan" method. Calling this will populate the tree with any located bluetooth devices.
2) Bluetooth devices support "Pair" and "Browse" methods. Calling the first will attempt to initiate a pairing interaction - the second will populate the tree with any services found on the device via SDP.
So it's fairly simple at the moment. The obvious next step is to allow services to provide rfcomm-binding methods and the like, and to ensure that relevant pieces of service information are provided via sdp.
Now, there's a couple of issues:
1) I'm not sure about the pairing interface. Right now, calling the pair method prompts hcid to attempt to send a message to a registered pairing agent via bluetooth. This strikes me as a mild security problem, since there's no mechanism for ensuring that it's the current user who has registered a pairing agent. The best that can be done is to attempt to register an agent, notice that the registration has failed and then bail before attempting to make the connection (setting an appropriate error). This isn't entirely ideal. David, can you see any way that PolicyKit can help us here?
2) The SDP interface in bluez is currently labelled "experimental" and is fairly limited in functionality. I tried going back through the mailing list archives, but the sourceforge interface makes me cry - has there been discussion of what this interface should look like and the technical problems involved?
Obligatory screenshot - http://www.codon.org.uk/~mjg59/tmp/bluetooth.png
Signature · 7 lines
Matthew Garrett | [email protected] _______________________________________________ Bluez-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bluez-devel
Quoted 3 lines · Matthew Garrett
I've put a tarball up at
http://www.codon.org.uk/~mjg59/tmp/hal-bluetooth.tar.gz as a first attempt at some degree of integration.
Cool.
Quoted 8 lines
The current interface is
basically:1) Bluetooth HCIs support a "Scan" method. Calling this will populate the tree with any located bluetooth devices.
2) Bluetooth devices support "Pair" and "Browse" methods. Calling the first will attempt to initiate a pairing interaction - the second will populate the tree with any services found on the device via SDP.
Shouldn't Pair() take the pin?
Quoted 11 lines
So it's fairly simple at the moment. The obvious next step is to allow services to provide rfcomm-binding methods and the like, and to ensure that relevant pieces of service information are provided via sdp.
Now, there's a couple of issues:
1) I'm not sure about the pairing interface. Right now, calling the pair method prompts hcid to attempt to send a message to a registered pairing agent via bluetooth. This strikes me as a mild security problem, since there's no mechanism for ensuring that it's the current user who has registered a pairing agent.
Right.
Quoted 5 lines
The best that can be done is to attempt to
register an agent, notice that the registration has failed and then bail before attempting to make the connection (setting an appropriate error). This isn't entirely ideal. David, can you see any way that PolicyKit can help us here?
Not really, sorry.
It sounds like we want Pair() to take the pin and pass it on to hcid and propagate errors back as appropriate. Intermittently we might want to register a pairing agent with our hal stuff to pretend this just works. But CreateBonding() on org.bluez.Adapter really ought to (optionally) take the pincode too. Can Bluez be tweaked to support this?
Also, can we determine what devices are paired already? E.g. can we have useful properties on the hal device objects such as bluetooth_device.paired = TRUE|FALSE.
Quoted 5 lines
2) The SDP interface in bluez is currently labelled "experimental" and is fairly limited in functionality. I tried going back through the mailing list archives, but the sourceforge interface makes me cry - has there been discussion of what this interface should look like and the technical problems involved?
Some questions:
1. What other API do we need? I suspect that we want
1a. Some way of setting the device ID of an adapter (equiv to device {
name "foo"} in hcid.conf)
1b. Some way of setting the pin of the adapter
I guess both 1a and 1b falls under replacing hcid.conf (<insert rant about why text-based configuration files are bad>)
1c. A way to pair well-known devices that are not yet in your
vicinity?
This is just thinking out loud, I suspect you have a much better idea about this than I do. I guess it naturally falls out once one starts thinking about the UI.
2. We probably need a way to make hal device objects disappear when the parent disappears. Would setting info.reap_when_parent_dies=TRUE be sufficient? If so, I can quickly implement this.
3. Probably need to delete devices not being reported when doing a
Scan()
Quoted 1 line
Obligatory screenshot - http://www.codon.org.uk/~mjg59/tmp/bluetooth.png
Cool.
David
Marcel Holtmann
maintainerHi David,
Quoted 5 lines
Quoted 3 lines
2) Bluetooth devices support "Pair" and "Browse" methods. Calling the first will attempt to initiate a pairing interaction - the second will populate the tree with any services found on the device via SDP.
Shouldn't
Pair()take the pin?
be careful with this. The new Simple Pairing will come at some point and then alternate authentication methods like NFC and other OOB stuff might have to be considered.
The application should take by itself to register a passkey agent if the default one is not the preferred one. For example in case of a wizard.
Quoted 7 lines
Quoted 5 lines
1) I'm not sure about the pairing interface. Right now, calling the pair method prompts hcid to attempt to send a message to a registered pairing agent via bluetooth. This strikes me as a mild security problem, since there's no mechanism for ensuring that it's the current user who has registered a pairing agent.
Right.
We left out the multiple user interaction consideration out of it for now. The reason was to establish a usable API first. All user specific checks (and settings) should be done by hcid and they should be fully transparent for the actual user. For the next releases we need to integrate this kind of checking.
Quoted 5 lines
It sounds like we want
Pair()to take the pin and pass it on to hcid and propagate errors back as appropriate. Intermittently we might want to register a pairing agent with our hal stuff to pretend this just works. ButCreateBonding()on org.bluez.Adapter really ought to (optionally) take the pincode too. Can Bluez be tweaked to support this?
Because of upcoming Simple Pairing this is not an option. See comment above.
Quoted 11 lines
Some questions:
1. What other API do we need? I suspect that we want
1a. Some way of setting the device ID of an adapter (equiv to device {
name "foo"} in hcid.conf)1b. Some way of setting the pin of the adapter
I guess both 1a and 1b falls under replacing hcid.conf (<insert rant about why text-based configuration files are bad>)
It is possible to have a presistent storage for the device name. The value in hcid.conf is only the default value. It will be overwritten by the saved value. Set the name through the BlueZ D-Bus API and your device will use it next time.
Quoted 6 lines
1c. A way to pair well-known devices that are not yet in your
vicinity?This is just thinking out loud, I suspect you have a much better idea about this than I do. I guess it naturally falls out once one starts thinking about the UI.
Not a good idea. Pair them once needed. Otherwise don't even care.
Quoted 3 lines
2. We probably need a way to make hal device objects disappear when the parent disappears. Would setting info.reap_when_parent_dies=TRUE be sufficient? If so, I can quickly implement this.
Sounds enough too me.
Quoted 2 lines
3. Probably need to delete devices not being reported when doing a
Scan()
Not a good idea. A device can become invisible, but still in range. You need to keep track of last seen and last used. And paired or trusted device should always be available.
Regards
Marcel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Marcel Holtmann
maintainerHi Matthew,
Quoted 5 lines
2) The SDP interface in bluez is currently labelled "experimental" and is fairly limited in functionality. I tried going back through the mailing list archives, but the sourceforge interface makes me cry - has there been discussion of what this interface should look like and the technical problems involved?
we need to add an asynchronous SDP API to bluez-libs and integrate working caching of SDP objects. This is not a simple task and there was no enough time for it.
Regards
Marcel
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel