0

I'm implementing Bluetooth on an embedded device and have a few questions about the BlueZ protocol stack. I'm using BlueZ-4.101 (do not have the option to upgrade to BlueZ-5), and do not have Python available.

Here are my questions after spending some time looking into BlueZ:

  1. Is bluetoothd needed in my situation? As in, is it just a daemon that handles Python dbus messages between user-space and the kernel, or is it more? I've looked through the source and can only find mostly dbus related calls
  2. How does one determine the value of DeviceID in /etc/bluetooth/main.conf? I found these instructions (section 3.4), but they are for a different platform using BlueZ 5

  3. Will sdptool work without setting the DeviceID value? I've tried the following command and receive timeouts every time (only for my local device):

    # sdptool browse local
Browsing FF:FF:FF:00:00:00 ...
Service Search failed: Connection timed out

  4. Is it viable to replace all of the python simple-agent scripts with libbluetooth instead, or do I need to try and port them over to a supported scripting language?

Any help would be greatly appreciated!!! If more logs are needed I can try and get them.

kaylum
  • 13,833
  • 2
  • 22
  • 31
zeus_masta_funk
  • 1,388
  • 2
  • 11
  • 34
  • bluetoothd implements the bluez DBUS API. Technically you can bypass it if you are able to reimplement what you need using low level HCI calls. But the DBUS APIs are the only officially supported APIs. The ones in `libbluetooth` are not. So you need to analyze your "situation" to understand whether libbluetooth does indeed provide all you need. Personally, I think it is a risky path if your are doing production work - risky both in how much time/effort it will require and also the possibility that you will not be able to achieve the functionality you need. – kaylum Mar 29 '16 at 22:12
  • On the other hand, bluez4 is no longer supported anyway. So I guess the "officially supported" considerations between DBUS APIs and libbluetooth are not that much different. Either way, if it does not do what you want then you are essentially on your own. – kaylum Mar 29 '16 at 22:16
  • By "officially suported", do you mean certified with the Bluetooth SIG, or do you mean maintained by the BlueZ community? I'm already using BlueZ4 which is now considered deprecated by BlueZ developers, but should save some testing as it has already been Bluetooth certified. In terms of my needs, I need pairing support (duh) and a few audio profiles. – zeus_masta_funk Mar 29 '16 at 22:20
  • I meant officially supported by the bluez devs. If you need pairing and profiles then I think you'll need the DBUS APIs. You may come to a different conclusion but when I looked at a similar path I came to the conclusion that using libbluetooth for anything more complex than basic rfcomm/l2cap socket connections is not really feasible without major development and testing. Regarding certification, I don't think saying that you are using bluez will really cut your certification time by much (been down that path). – kaylum Mar 29 '16 at 22:24
  • After looking into this a bit further, I agree, DBus will be needed in my situation. I am wondering however, do you know of any documentation/examples/tutorials using `libdbus` or `libdbus-glib` for BlueZ4? I can find some generic documentation about the API in the BlueZ repo, but as this is my first experience with DBus I would prefer something a bit more verbose. – zeus_masta_funk Mar 31 '16 at 19:44
  • 1
    Documentation is not the strong point of bluez. The best way to learn that I have found is to read their source code for the various client programs to see how they interact with dbus. FWIW, I wrote a simple example for another answer that does basic scanning and then collects the RSSI value for a given device. It may get you started on your journey of discovery: [bluez-rssi-example](https://bitbucket.org/kaylum/bluez-rssi-example/src) – kaylum Mar 31 '16 at 19:52

0 Answers0