1HCID.CONF(5) System management commands HCID.CONF(5)
2
6 /etc/bluetooth/hcid.conf - Configuration file for the hcid Bluetooth
7 HCI daemon
8
11 /etc/bluetooth/hcid.conf contains all the options needed by the Blue‐
12 tooth Host Controller Interface daemon.
13 It consists of sections and parameters. A section begins with the name
15 of the section followed by optional specifiers and the parameters
16 inside curly brackets. Sections contain parameters of the form:
17 name value1, value2 ... ;
19 Any character after a hash ('#') character is ignored until newline.
22 Whitespace is also ignored.
23 The valid section names for hcid.conf are, at the moment:
26 options
29 contains generic options for hcid and the pairing policy.
30 device contains lower-level options for the hci devices connected to
32 the computer.
33
35 The following parameters may be present in an option section:
36 autoinit yes|no
40 Automatically initialize newly connected devices. The default is
42 no.
43 pairing none|multi|once
47 none means that pairing is disabled. multi allows pairing with
49 already paired devices. once allows pairing once and denies suc‐
50 cessive attempts. The default hcid configuration is shipped with
51 multi enabled
52 offmode noscan|devdown
55 noscan means that page and inquiry scans are disabled when you
57 call SetMode("off"). devdown sets the adapter into down state
58 (same what hciconfig hci0 down does).
59 passkey "pin"
62 The default PIN for incoming connections if security has been
64 set to auto.
65 security none|auto|user
68 none means the security manager is disabled. auto uses local
70 PIN, by default from pin_code, for incoming connections. user
71 always asks the user for a PIN.
72
75 Parameters within a device section with no specifier, the default
76 device section, will be applied to all devices and device sections
77 where these are unspecified. The following optional device specifiers
78 are supported:
79 nn:nn:nn:nn:nn:nn
82 Parameters specified within this section will be applied to the
84 device with this device bluetooth address. All other parameters
85 are applied from the default section.
86 hcin
89 Parameters specified within this section will be applied to the
91 device with this device interface, unless that device is matched
92 by a device address section. All other parameters are applied
93 from the default section.
94 Note: Most of the options supported in the device section are described
98 to some extent in the bluetooth specification version 1.2 Vol2, Part E
99 section 6. Please refer to it for technical details.
100 The following parameters may be present in a device section:
103 name "name"
106 The device name. %d inserts the device id. %h inserts the host
108 name.
109 class 0xSSDDdd (three bytes)
113 The Bluetooth Device Class is described in the Bluetooth Speci‐
115 fication section 1.2 ("Assigned Numbers - Bluetooth Baseband").
116 The default shipped with hcid is 0x000100 which simply stands
118 for "Computer".
119 The Bluetooth device class is a high-level description of the
121 bluetooth device, composed of three bytes: the "Major Service
122 Class" (byte "SS" above), the "Major Device Class" (byte "DD"
123 above) and the "Minor Device Class" (byte "dd" above). These
124 classes describe the high-level capabilities of the device, such
125 as "Networking Device", "Computer", etc. This information is
126 often used by clients who are looking for a certain type of ser‐
127 vice around them.
128 Where it becomes tricky is that another type of mechanism for
130 service discovery exists: "SDP", as in "Service Discovery Proto‐
131 col".
132 In practice, most Bluetooth clients scan their surroundings in
134 two successive steps: they first look for all bluetooth devices
135 around them and find out their "class". You can do this on Linux
136 with the hcitool scan command. Then, they use SDP in order to
137 check if a device in a given class offers the type of service
138 that they want.
139 This means that the hcid.conf "class" parameter needs to be set
141 up properly if particular services are running on the host, such
142 as "PAN", or "OBEX Obect Push", etc: in general a device looking
143 for a service such as "Network Access Point" will only scan for
144 this service on devices containing "Networking" in their major
145 service class.
146 Major service class byte allocation (from LSB to MSB):
150 Bit 1: Positioning (Location identification)
152 Bit 2: Networking (LAN, Ad hoc, ...)
154 Bit 3: Rendering (Printing, Speaker, ...)
156 Bit 4: Capturing (Scanner, Microphone, ...)
158 Bit 5: Object Transfer (v-Inbox, v-Folder, ...)
160 Bit 6: Audio (Speaker, Microphone, Headset service, ...)
162 Bit 7: Telephony (Cordless telephony, Modem, Headset service,
164 ...)
165 Bit 8: Information (WEB-server, WAP-server, ...)
167 Example: class 0x02hhhh : the device offers networking service
170 Major device class allocation:
174 0x00: Miscellaneous
176 0x01: Computer (desktop,notebook, PDA, organizers, .... )
178 0x02: Phone (cellular, cordless, payphone, modem, ...)
180 0x03: LAN /Network Access point
182 0x04: Audio/Video (headset,speaker,stereo, video display,
184 vcr.....
185 0x05: Peripheral (mouse, joystick, keyboards, ..... )
187 0x06: Imaging (printing, scanner, camera, display, ...)
189 Other values are not defined (refer to the Bluetooth specifica‐
191 tion for more details
192 Minor device class allocation: the meaning of this byte depends
195 on the major class allocation, please refer to the Bluetooth
196 specifications for more details).
197 Example: if PAND runs on your server, you need to set up at
200 least class 0x020100, which stands for "Service Class: Network‐
201 ing" and "Device Class: Computer, Uncategorized".
202 iscan enable|disable
206 pscan enable|disable
208 Bluetooth devices discover and connect to each other through the
210 use of two special Bluetooth channels, the Inquiry and Page
211 channels (described in the Bluetooth Spec Volume 1, Part A, Sec‐
212 tion 3.3.3, page 35). These two options enable the channels on
213 the bluetooth device.
214 iscan enable: makes the bluetooth device "discoverable" by
216 enabling it to answer "inquiries" from other nearby bluetooth
217 devices.
218 pscan enable: makes the bluetooth device "connectable to" by
220 enabling the use of the "page scan" channel.
221 lm none|accept,master
224 none means no specific policy. accept means always accept incom‐
226 ing connections. master means become master on incoming connec‐
227 tions and deny role switch on outgoing connections.
228 lp none|rswitch,hold,sniff,park
231 none means no specific policy. rswitch means allow role switch.
233 hold means allow hold mode. sniff means allow sniff mode. park
234 means allow park mode. Several options can be combined.
235 This option determines the various operational modes that are
237 allowed for this device when it participates to a piconet. Nor‐
238 mally hold and sniff should be enabled for standard operations.
239 hold: this mode is related to synchronous communications (SCO
241 voice channel for example).
242 sniff: when in this mode, a device is only present on the
244 piconet during determined slots of time, allowing it to do other
245 things when it is "absent", for example to scan for other blue‐
246 tooth devices.
247 park: this is a mode where the device is put on standby on the
249 piconet, for power-saving purposes for example.
250 rswitch: this is a mode that enables role-switch (master <->
252 slave) between two devices in a piconet. It is not clear whether
253 this needs to be enabled in order to make the "lm master" set‐
254 ting work properly or not.
255 pageto n
258 Page Timeout measured in number of baseband slots. Interval
260 length = N * 0.625 msec (1 baseband slot)
261 discovto n
264 The time in seconds that the device will stay in discoverable
266 mode. 0 disables this feature and forces the device to be always
267 discoverable.
268
271 /etc/bluetooth/hcid.conf
272 Default location of the global configuration file.
273
276 This manual page was written by Edouard Lafargue, Fredrik Noring, Maxim
277 Krasnyansky and Marcel Holtmann.
278hcid.conf - HCI daemon March 2004 HCID.CONF(5)