| SDPD(8) | System Manager's Manual | SDPD(8) | 
sdpd —
| sdpd | [ -dh] [-cpath] [-Ggroup] [-ggroup] [-uuser] | 
sdpd daemon keeps a database of Bluetooth Service
  Records registered on the host and responds to Service Discovery inquiries
  from remote Bluetooth devices.
In order to discover services, remote Bluetooth devices send
    Service Search and Service Attribute or Service Search Attribute requests
    over Bluetooth L2CAP connections on the SDP PSM (0x0001). The
    sdpd daemon will try to find matching Service
    Records in its Service Database and will return the requested record
    extracts for the remote device to interpret. The remote device will then
    make a separate connection in order to access the service.
Bluetooth applications, running on the host, are able to insert,
    remove and update Service Records with the sdpd
    daemon via the control socket. It is possible to query entire contents of
    the Service Database locally with
    sdpquery(1) using the
    -l option.
The command line options are as follows:
-c
    path-d-G
    groupsdpd Service Database.-g
    groupsdpd should run as after
      it initializes. The value specified may be either a group name or a
      numeric group ID. This only works if sdpd was
      started as root. The default group name is
      “_sdpd”.-h-u
    usersdpd should run as after it
      initializes. The value specified may be either a user name or a numeric
      user ID. This only works if sdpd was started as
      root. The default user name is
      “_sdpd”.The “Service Discovery Protocol” section of the Bluetooth Core specifications, available at http://www.bluetooth.com/
sdpd daemon first appeared in
  FreeBSD 5.3 and was imported into
  NetBSD 4.0 by Iain Hibbert
  under the sponsorship of Itronix, Inc. This version
  was rewritten by Iain Hibbert for
  NetBSD 6.0 in order to allow Bluetooth applications to
  fully specify service records.
sdpd daemon will listen for incoming L2CAP
  connections on a wildcard BD_ADDR.
In case of multiple Bluetooth controllers connected to the same host it is possible to limit visibility of Service Records according to the controller the connection is made through.
Requests to insert, remove or update service records can only be
    made via the control socket. The sdpd daemon will
    check the peer's credentials and will only accept the request when the peer
    is the superuser, of if the peer is a member of the group specified with the
    -G option.
The sdpd daemon does not check for
    duplicated Service Records and only performs minimal validation of the
    record data sent in the Insert/Update Record requests. It is assumed that
    application must obtain all required resources such as RFCOMM channels etc.,
    before registering the service.
sdpd only ever generates 16-bit sequence headers, so if
  a response was to grow over UINT16_MAX, the sequence
  header will be wrong.
There is no way for clients to discover the maximum packet size
    that sdpd will accept on the local socket. Currently
    this is SDP_LOCAL_MTU as defined in
    <bluetooth/sdp.h>.
| May 7, 2009 | NetBSD 10.1 |