It consists of sections and parameters. A section begins with the name of the section followed by optional specifiers and the parameters inside curly brackets. Sections contain parameters of the form:
Any character after a hash ('#') character is ignored until newline. Whitespace is also ignored.
The valid section names for hcid.conf are, at the moment:
Automatically initialize newly connected devices. The default is no.
none means that pairing is disabled. multi allows pairing with already paired devices. once allows pairing once and denies successive attempts. The default hcid configuration is shipped with multi enabled
The default PIN for incoming connections if security has been set to auto.
none means the security manager is disabled. auto uses local PIN, by default from pin_code, for incoming connections. user always asks the user for a PIN.
Parameters specified within this section will be applied to the device with this device bluetooth address. All other parameters are applied from the default section.
Parameters specified within this section will be applied to the device with this device interface, unless that device is matched by a device address section. All other parameters are applied from the default section.
Note: Most of the options supported in the device section are described to some extent in the bluetooth specification version 1.2 Vol2, Part E section 6. Please refer to it for technical details.
The following parameters may be present in a device section:
The device name. %d inserts the device id. %h inserts the host name.
The Bluetooth Device Class is described in the Bluetooth Specification section 1.2 ("Assigned Numbers - Bluetooth Baseband").
The default shipped with hcid is 0x000100 which simply stands for "Computer".
The Bluetooth device class is a high-level description of the bluetooth device, composed of three bytes: the "Major Service Class" (byte "SS" above), the "Major Device Class" (byte "DD" above) and the "Minor Device Class" (byte "dd" above). These classes describe the high-level capabilities of the device, such as "Networking Device", "Computer", etc. This information is often used by clients who are looking for a certain type of service around them.
Where it becomes tricky is that another type of mechanism for service discovery exists: "SDP", as in "Service Discovery Protocol".
In practice, most Bluetooth clients scan their surroundings in two successive steps: they first look for all bluetooth devices around them and find out their "class". You can do this on Linux with the hcitool scan command. Then, they use SDP in order to check if a device in a given class offers the type of service that they want.
This means that the hcid.conf "class" parameter needs to be set up properly if particular services are running on the host, such as "PAN", or "OBEX Obect Push", etc: in general a device looking for a service such as "Network Access Point" will only scan for this service on devices containing "Networking" in their major service class.
Bit 1: Positioning (Location identification)
Bit 2: Networking (LAN, Ad hoc, ...)
Bit 3: Rendering (Printing, Speaker, ...)
Bit 4: Capturing (Scanner, Microphone, ...)
Bit 5: Object Transfer (v-Inbox, v-Folder, ...)
Bit 6: Audio (Speaker, Microphone, Headset service, ...)
Bit 7: Telephony (Cordless telephony, Modem, Headset service, ...)
Bit 8: Information (WEB-server, WAP-server, ...)
0x01: Computer (desktop,notebook, PDA, organizers, .... )
0x02: Phone (cellular, cordless, payphone, modem, ...)
0x03: LAN /Network Access point
0x04: Audio/Video (headset,speaker,stereo, video display, vcr.....
0x05: Peripheral (mouse, joystick, keyboards, ..... )
0x06: Imaging (printing, scanner, camera, display, ...)
Other values are not defined (refer to the Bluetooth specification for more details
Bluetooth devices discover and connect to each other through the use of two special Bluetooth channels, the Inquiry and Page channels (described in the Bluetooth Spec Volume 1, Part A, Section 3.3.3, page 35). These two options enable the channels on the bluetooth device.
iscan enable: makes the bluetooth device "discoverable" by enabling it to answer "inquiries" from other nearby bluetooth devices.
pscan enable: makes the bluetooth device "connectable to" by enabling the use of the "page scan" channel.
none means no specific policy. accept means always accept incoming connections. master means become master on incoming connections and deny role switch on outgoing connections.
none means no specific policy. rswitch means allow role switch. hold means allow hold mode. sniff means allow sniff mode. park means allow park mode. Several options can be combined.
This option determines the various operational modes that are allowed for this device when it participates to a piconet. Normally hold and sniff should be enabled for standard operations.
hold: this mode is related to synchronous communications (SCO voice channel for example).
sniff: when in this mode, a device is only present on the piconet during determined slots of time, allowing it to do other things when it is "absent", for example to scan for other bluetooth devices.
park: this is a mode where the device is put on standby on the piconet, for power-saving purposes for example.
rswitch: this is a mode that enables role-switch (master <-> slave) between two devices in a piconet. It is not clear whether this needs to be enabled in order to make the "lm master" setting work properly or not.
Page Timeout measured in number of baseband slots. Interval length = N * 0.625 msec (1 baseband slot)
The time in seconds that the device will stay in discoverable mode. 0 disables this feature and forces the device to be always discoverable.