Bluetooth SDP - where is sdpd?

3
votes

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:

  1. I have installed (apt-get) every bluetooth or bluez package that seemed remotely relevant but still no sdpd.
  2. I tried to connect using the address of my Android phone (using the same code). That worked fine but, of course, is of no use.
  3. Did an exhaustive Google search on the problem but found no clear answers. A lot of talk about hcid, pand, etc. but no clear answers about how these are relevant.

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.

3
androidbluetoothdebiansdp

3 Answers

5
votes

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:

3
votes

[SOLVED] Apparently, sdpd is long gone. It's function has been subsumed by bluetoothd. To make it work, use the --compat flag, e.g.

bluetoothd --compat

This should be added to "/etc/init.d/bluetooth". With this, I can successfully connect and register my service.

I found a hint to this in a blog posting. Why the release notes or anything else on the planet never announced this, I have no idea.

1
votes

Not sure if this will help you, but it might be worth a try. I also had some problems with Debian 8 Bluetooth; I solved my problems by enabling Debian backports and downloading the newest backport version of blueman. To do that, first uninstall your current bluetooth packages (main ones, such as bluez), and then add this lines (or similar) to your /etc/apt/sources.list

deb http://ftp.debian.org/debian jessie-backports main contrib non-free
deb-src http://ftp.debian.org/debian jessie-backports main contrib non-free

Then run a apt-get update and install the backport version. I suggest using the following code to make sure that the configuration file is updated to the latest version:

apt-get update && DEBIAN_FRONTEND=noninteractive apt-get -qy -o DPkg::options::="--force-confnew" -t jessie-backports install blueman

Reboot your computer and see if it is working now. Note: enabling the backports on Debian will not install all backport versions of software available (nor would you want that). Only when you specifically request the backport version (like we did above) it will be installed. All other packages will be maintained as they are (stable). When updating, your backport packages will update with the latest backport version, and your stable packages will update with the latest stable version.

Edit: This answer was edited to add some enhancements and information.