NAME
sdpd —
Bluetooth Service Discovery
Protocol daemon
SYNOPSIS
sdpd |
[-dh]
[-c path]
[-G group]
[-g group]
[-u
user] |
DESCRIPTION
The
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
- Specify path to the control socket. The default path is
/var/run/sdp.
-
-
- -d
- Do not detach from the controlling terminal.
-
-
- -G
group
- Grant permission to members of the
group to modify the sdpd Service
Database.
-
-
- -g
group
- Specifies the group the sdpd 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
- Display usage message and exit.
-
-
- -u
user
- Specifies the user the sdpd 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
”.
FILES
- /var/run/sdp
-
SEE ALSO
sdpquery(1),
sdp(3)
The “Service Discovery Protocol” section of the Bluetooth Core
specifications, available at
http://www.bluetooth.com/
HISTORY
The original
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.
AUTHORS
Maksim Yevmenkin
<
m_evmenkin@yahoo.com>
Iain Hibbert
CAVEATS
The
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.
BUGS
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>.