SDPCONTROL(8) BSD System Manager's Manual SDPCONTROL(8)NAME
sdpcontrol -- Bluetooth Service Discovery Protocol query utility
SYNOPSIS
sdpcontrol -h
sdpcontrol -a address command [parameters ...]
sdpcontrol -l [-c path] command [parameters ...]
DESCRIPTION
The sdpcontrol utility attempts to query the specified Service Discovery Protocol (SDP) server. Remote SDP servers are identified by their
address. Connection to the local SDP server is made via the control socket. The sdpcontrol utility uses Service Search Attribute Requests
and prints results to standard output and error messages to standard error.
The options are as follows:
-a address
Connect to the remote device with the specified address. The address can be specified as BD_ADDR or a name. If a name was speci-
fied, the sdpcontrol utility attempts to resolve the name via bt_gethostbyname(3).
-c path
Specify path to the control socket. The default path is /var/run/sdp.
-h Display usage message and exit.
-l Query the local SDP server via the control socket.
command
One of the supported commands (see below). The special command help can be used to obtain a list of all supported commands. To get
more information about a specific command, use help command.
parameters
One or more optional space separated command parameters.
COMMANDS
The currently supported node commands in sdpcontrol are:
Browse
Search
EXIT STATUS
The sdpcontrol utility exits 0 on success, and >0 if an error occurs.
SEE ALSO bluetooth(3), sdp(3)AUTHORS
Maksim Yevmenkin <m_evmenkin@yahoo.com>
CAVEATS
The sdpcontrol utility only implements client side functionality.
The sdpcontrol utility only requests the following attributes from the SDP server:
1. Service Record Handle
2. Service Class ID List
3. Protocol Descriptor List
4. Bluetooth Profile Descriptor List
BSD February 7, 2015 BSD
Check Out this Related Man Page
SDPD(8) BSD System Manager's Manual SDPD(8)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 creden-
tials 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 regis-
tering 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>.
BSD May 7, 2009 BSD