| SDPD(8) | System Manager's Manual | SDPD(8) |
sdpd —
sdpd |
[-dh] [-c
path] [-G
group] [-g
group] [-u
user] |
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 9.2 |