Where is the Bluetooth Service Discovery Protocol (SDP) Daemon?
I'm trying to register a bluetooth service on Debian V8.0 using bluez. I use example code at https://people.csail.mit.edu/albert/bluez-intro/. Everything goes well until I try
sdp_connect( BDADDR_ANY, BDADDR_LOCAL, 0 );
which fails. After some digging, I find that the sdp daemon (sdpd) (to which it needs to connect) is not running and in fact does not even exist on my system.
What I Tried:
My Goal:
I am trying to register my service on my Debian system, so that I can connect to it from another bluetooth device (in particular, my Android). The service runs just fine, it just can't be found without SDP registration.
I'd be satified to connect to it directly, using it's (known) channel number, but Android can only connect via a registered service UUID (i.e., using BluetoothDevice.createRfcommSocketToServiceRecord(uuid)
), but I see no API to connect to a channel.
Interestingly, I can connect to a service on the Android by channel number, but not the other way around. Me thinks maybe sdpd is obsolete - all references to it are several years old.
From the official bluez project site:
The BlueZ 5 D-Bus API contains significant changes compared to BlueZ 4. The bulk of the changes are due to the following features in BlueZ 5:
- Transformation to use standard D-Bus Properties and ObjectManager interfaces (available in the D-Bus specification document)
- Introduction of interface versions (e.g. org.bluez.Adapter1). When new versions are introduced we’ll try to keep supporting at least the two latest versions simultaneously.
- The simplification or removal of per-profile interfaces and the addition of a general org.bluez.Device1.Connect method to connect profiles.
- The removal of the org.bluez.Service interface (used for registering SDP records and authorization) and the introduction of a new org.bluez.Profile1 interface
- Dynamic device object creation during device discovery
- Introduction of an AgentManager1 interface
- Base path moved to “/org/bluez”. This shouldn’t make much difference though as the main entry point to any interaction through D-Bus is the ObjectManager.GetManagedObjects call.
In short, starting from Bluez5 you cannot use sdp_connect() like functions. You must use D-Bus. In the page linked above, you can also find the following:
BlueZ 5 introduces a new generic D-Bus interface for implementing external profiles. The profile (residing in a separate process) implements a org.bluez.Profile1 interface and registers an object implementing it through a new ProfileManager1 interface on the BlueZ side. In the RegisterProfile method (on the ProfileManager1 interface) the profile needs to at least provide the UUID for the profile to be registered. BlueZ has internally a table of defaults for common profiles so no other information is necessarily needed. However, if the profile desires to it can provide information such as the full SDP record (XML encoded), desired security level, enable/disable authorization, version, features, role, name, etc.
... and a lot of precious informations.
Please, don't use the compatibile mode (I mean the "--compat" option). You should use it only for testing and development:
commit 83b21cc152186f12f8bc76b7aec3107e220d5219
Author: Marcel Holtmann <[email protected]>
Date: Mon Dec 17 14:02:59 2012 +0100
core: Hide /var/run/sdp support behind command line option
By default /var/run/sdp support has been disabled from now on. It is not
the preferred way of handling SDP records. For testing and development
purposes it can be switched back on via --compat command line option.
Last but not least, here is a collection of useful links that could help the new users/developers working with Bluez5:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With