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.4 |