sdpd(8) [netbsd 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

SDP(3)							   BSD Library Functions Manual 						    SDP(3)

NAME

     sdp_open, sdp_open_local, sdp_close, sdp_service_search, sdp_service_attribute, sdp_service_search_attribute, sdp_record_insert,
     sdp_record_update, sdp_record_remove -- Service Discovery Protocol session routines

LIBRARY

     Bluetooth Library (libbluetooth, -lbluetooth)

SYNOPSIS

     #include <sdp.h>

     sdp_session_t
     sdp_open(const bdaddr_t *laddr, const bdaddr_t *raddr);

     sdp_session_t
     sdp_open_local(const char *control);

     void
     sdp_close(sdp_session_t ss);

     bool
     sdp_service_search(sdp_session_t ss, sdp_data_t *ssp, uint32_t *handlep, int *num);

     bool
     sdp_service_attribute(sdp_session_t ss, uint32_t handle, sdp_data_t *ail, sdp_data_t *response);

     bool
     sdp_service_search_attribute(sdp_session_t ss, sdp_data_t *ssp, sdp_data_t *ail, sdp_data_t *response);

     bool
     sdp_record_insert(sdp_session_t ss, bdaddr_t *bdaddr, uint32_t *handlep, sdp_data_t *record);

     bool
     sdp_record_update(sdp_session_t ss, uint32_t handle, sdp_data_t *record);

     bool
     sdp_record_remove(sdp_session_t ss, uint32_t handle);

DESCRIPTION

     The SDP library provides means for client programs to perform Bluetooth Service Discovery, and to advertise Service Records on the local
     host.

     The Service Discovery API reflects the Bluetooth SDP specification, providing access to complete ServiceSearch, ServiceAttribute or Service-
     SearchAttribute transactions and using SDP data element lists directly which can be constructed and parsed with the sdp_data(3) library func-
     tions.

     The ServiceSearchPattern is a list of UUID data elements.	The list must contain at least one UUID and the maximum number of UUIDs is 12.	A
     service record will be matched when all the UUIDs from the ServiceSearchPattern are contained in the record.

     The AttributeIDList is a list of data elements where each is either an attribute ID encoded as an unsigned 16-bit integer, or a range of
     attribute IDs encoded as an unsigned 32-bit integer where the high order 16-bits are the start of the range and the low order 16-bits are the
     end of the range (inclusive).  The AttributeIDList should be arranged in ascending order and there should be no duplicate attribute ID val-
     ues.  If NULL is passed, all attributes (0x0000-0xffff) will be requested.

     ServiceRecords to be registered with the local sdpd(8) server should consist of a list of attribute ID/value pairs, where the attribute ID is
     a 16-bit unsigned integer element, and the attribute value is any data element.  The attribute IDs should be in ascending order, and the
     first one must be SDP_ATTR_SERVICE_RECORD_HANDLE (0x0000), otherwise the server will reject the record.  For consistency, records should also
     contain a BrowseGroupList with the PublicBrowseGroup UUID, plus at least a ServiceName string in the native language with an associated Lan-
     guageBaseAttributeIDList although this is not currently enforced.

FUNCTIONS

     sdp_open(laddr, raddr)
	   Open a SDP session to a remote Bluetooth device.  laddr refers to the local bluetooth device address and may be NULL in which case it
	   will default to BDADDR_ANY.

     sdp_open_local(control)
	   Open a SDP session to a server using a local socket.  The control socket path may be given as NULL in which case the default control
	   path /var/run/sdp will be used.

     sdp_close(ss)
	   Close SDP session and release all resources.

     sdp_service_search(ss, ssp, handlep, num)
	   Perform a complete ServiceSearch transaction on the SDP session.  At most num service record handles matching the ServiceSearchPattern
	   ssp will be returned in the array pointed to by handlep.

     sdp_service_attribute(ss, handle, ail, response)
	   Perform a complete ServiceAttribute transaction on the SDP session.	The ServiceRecord with ServiceRecordHandle handle will be parsed
	   using the AttributeIDList ail.  If the transaction succeeds, the response data buffer will contain a validated data element list of
	   attribute ID/value pairs from the selected record.

     sdp_service_search_attribute(ss, ssp, ail, response)
	   Perform a complete ServiceSearchAttribute transaction on the SDP session.  All ServiceRecords matching the ServiceSearchPattern ssp
	   will be parsed using the AttributeIDList ail.  If the transaction succeeds, the response data buffer will contain a valid data element
	   list of sequences, where each sequence is the attribute ID/value list from a matched record.

     sdp_record_insert(ss, bdaddr, handlep, record)
	   Insert a ServiceRecord record.  If bdaddr is given, the service record will be restricted to clients connecting through the Bluetooth
	   controller with that BD_ADDR.  When the handlep pointer is non NULL, the resulting ServiceRecordHandle will be written to the address
	   given.  The record will be valid while the session is active and will be purged when the session is closed.

     sdp_record_update(ss, handle, record)
	   Update a ServiceRecord that is owned by this session.  handle is the identifier returned by the sdp_record_insert() call, and record is
	   the updated ServiceRecord as described above.

     sdp_record_remove(ss, handle)
	   Remove a ServiceRecord owned by this session.  handle is the identifier returned by the sdp_record_insert() call.

     A single response buffer is maintained for each session, so the results of a ServiceAttribute or ServiceSearchAttribute request will only be
     valid until another request is made or the session is closed.  The SDP specifications do not mandate a limit on the size of the response buf-
     fer but this implementation has a default limit of UINT16_MAX bytes.  This limit can be increased at runtime by setting the environment vari-
     able SDP_RESPONSE_MAX to a numeric value.

     Records are only allowed to be removed or updated by the session that inserted them, and records will be removed automatically when the ses-
     sion is closed.  Further, manipulating service records will normally only be possible for privileged users on a SDP session connected with a
     local socket.  See sdpd(8) and your local system administrator for details.

RETURN VALUES

     Session open routines will return a session handle on success and NULL on failure.  For service lookup and record manipulation routines, a
     boolean value is returned indicating success or failure.  On failure, errno will be set to indicate the error.

FILES

     /var/run/sdp

ERRORS

     In addition to errors returned by the standard C library IO functions, the following errors may be detected by libbluetooth:

	   [EINVAL]   A provided function argument was not valid.

	   [EIO]      A response from the remote server was not understood.

	   [ENOATTR]  The record handle did not exist on the server.

SEE ALSO

     sdpquery(1), bluetooth(3), sdp_data(3), sdpd(8)

     The "Service Discovery Protocol" section of the Bluetooth Core specifications, available at "http://www.bluetooth.com/"

HISTORY

     The first Service Discovery implementation was written for FreeBSD and was ported to NetBSD 4.0.  This, the second version API, was designed
     by Iain Hibbert for NetBSD 6.0 in order to simplify the sdpd(8) daemon and allow client code greater control over all aspects of the service
     records.  The original API is still available when SDP_COMPAT is defined but will eventually be removed.

BSD
								    May 7, 2009 							       BSD