bthcid(8) [netbsd man page]
BTHCID(8) BSD System Manager's Manual BTHCID(8) NAME
bthcid -- Bluetooth Link Key/PIN Code Manager SYNOPSIS
bthcid [-fn] [-d device] [-m mode] [-s socket_name] bthcid [-h] DESCRIPTION
The bthcid daemon handles Link Key and PIN code requests for Bluetooth devices. It opens a raw HCI socket and listens for the following HCI events. Link_Key_Request bthcid scans the /var/db/bthcid.keys file for a cached link key matching the remote device BD_ADDR and, if found, the Link_Key_Request_Reply will be sent back to the device, otherwise the Link_Key_Request_Negative_Reply will be sent. Link_Key_Notification When a new link key is created by the device, it will be cached for future use in the /var/db/bthcid.keys link keys file, which will be created if it does not already exist. PIN_Code_Request The bthcid daemon checks its PIN cache for a matching remote device entry. If no PIN is found, the bthcid daemon will send a message to any PIN clients that have registered, with the device details and a timeout value. When no clients are available or the timeout has expired, bthcid will send a PIN_Code_Request_Negative_Reply back to the device. When a PIN is found, or if a client responds within the timeout period, a PIN_Code_Request_Reply will be sent back to the device. PINs received from clients will be cached for 5 minutes until used, and may be added to the cache prior to pairing with the btpin(1) utility. Some of the functionality of bthcid can be handled by the Bluetooth controller directly, and cached Link Keys may be examined, deleted or moved to device storage using the btkey(1) program. The command line options are as follows: -d device Specify the local Bluetooth device address. The default is BDADDR_ANY. -f Run in foreground (do not detach). -h Display usage message and exit. -m Specify the file mode access bits for the PIN client socket. The default is to allow readwrite access to user and group (0660). -n Do not listen for PIN clients. -s socket_name Specify the socket name to listen on for PIN clients. The default path is /var/run/bthcid. FILES
/var/db/bthcid.keys /var/run/bthcid /var/run/bthcid.pid SEE ALSO
btkey(1), btpin(1), bluetooth(4), btconfig(8) HISTORY
The bthcid daemon first appeared in FreeBSD 5.3 as hcsecd. It was ported to NetBSD 4.0 with its present name and extended to support PIN clients by Iain Hibbert under the sponsorship of Itronix, Inc. AUTHORS
Maksim Yevmenkin <m_evmenkin@yahoo.com> Iain Hibbert BSD
September 29, 2006 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