Rediscovering Bluetooth
Software Compilation
If you wish to install everything yourself, you must use a specific version of bluez to avoid any dependency on DBus. Many parts of the Gnome desktop depend on DBus. It may not be a good idea to break it.
I recommend downloading bluez-libs-2.10, bluez-utils-2.10, bluez-hcidump-1.12, and bluez-hciemu-1.0, with the commands:
$ wget http://bluez.sf.net/download/bluez-libs-2.10.tar.gz
$ wget http://bluez.sf.net/download/bluez-utils-2.10.tar.gz
$ wget http://bluez.sf.net/download/bluez-hcidump-1.12.tar.gz
$ wget http://bluez.sf.net/download/bluez-hciemu-1.0.tar.gz
If you are not using i386-compatible hardware (for example, on handhelds with ARM or MIPS CPUs), please do a cross-compilation with the toolchain your architecture requires. Instructions to do that, along with this specific toolchain, may be available online on websites explaining how to hack your hardware (for example, Zaurus toolchain).
Compilation works the standard GNU way. I like to put everything into /opt/bluetooth so as not to conflict with your default install.
First, install the libraries, which everything else will use:
$ tar zxvf bluez-libs-2.10.tar.gz
$ cd bluez-libs-2.10
$ ./configure --prefix=/opt/bluetooth
$ make ; make install
$ echo "/opt/bluetooth/lib" >> /etc/ld.so.conf
$ ldconfig
Then, install the utilities:
$ tar zxvf bluez-utils-2.10.tar.gz
$ cd bluez-utils-2.10
$ ./configure --disable-debug --disable-dbus --disable-cups --disable-pcmcia \
--disable-initscripts --disable-bluepin --enable-hid2hci --enable-bcm203x \
--prefix=/opt/bluetooth
$ make ; make install
Finally, install the debug application:
$ tar zxvf bluez-hcidump-1.12.tar.gz
$ cd bluez-hcidump-1.12
$ ./configure --prefix=/opt/bluetooth
$ make ; make install
To use the newly installed binaries, type:
export PATH=$PATH:/opt/bluetooth/bin:/opt/bluetooth/sbin
or add it to your .bashrc or similar file. You are now ready to go!
Attaching a Serial Dongle
The first thing to do with a serial dongle is to attach it. The syntax is simple: specify the serial port name, the protocol, the initial speed, flow control, and a sustainable speed for normal use.
For example, if you have a serial dongle on the first serial port using BCSP, with a firmware configuration of 115200 baud, but you want to set it to work at 230400 baud, use:
$ hciattach /dev/ttyS0 bcsp 115200 noflow 230400
If you have a serial dongle, odds are you either have added it yourself, and therefore know the parameters because you set them manually with pskey, or that you have internal Bluetooth in your laptop, in which case you will find all the parameters on the same website where you found explanations to enable Bluetooth.
I strongly advise you against changing the initial speed with pskey. Keep that value to a safe default and let hciattach do the magic of switching to higher speeds. You can then try to go as high as 921600 if you want to, without taking any risks: a simple reset of the chip will take you back to 115200. On the other hand, setting the Bluetooth module to a default speed you can't reach will render it useless.
Starting Bluetooth and Talking to Another Device
Whether your device is serial or USB, you can start it with:
$ hciconfig hci0 up
hci0: Type: USB
BD Address: 00:80:C8:45:31:F8 ACL MTU: 192:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN AUTH ENCRYPT
RX bytes:2882377 acl:151624 sco:0 events:212 errors:0
TX bytes:2591 acl:184 sco:0 commands:20 errors:0
This means you have a USB device with an address of 00:80:C8:45:31:F8, running with the various options.
The address is unique and similar to a MAC address for an Ethernet card. It is unspoofable, unless you manage to get a development Bluetooth module that still has the "change address" feature enabled. In that case, you are one pskey command away from changing it. Therefore, I strongly advise you against using any Bluetooth address as a security token.
Now try to find neighboring Bluetooth devices:
$ hcitool scan
Scanning ...
00:A0:96:0A:D1:80 zaurus.guylhem.net
It found something!
The scan shows the other device's address and the device name. The owner has set the latter; it can be anything at all. However, I recommend you use a fully qualified domain name if you have your own domain--it makes it easier to find identify the device's owner with a simple whois.
Before you can go any further, start the hcid daemon and set up a PIN to protect the connection. Edit the hcid.conf file in /opt/bluetooth/etc/bluetooth to look like this:
options {
# automatically put new hciN devices up
autoinit yes;
# security mode
# none : security disabled
# auto : use local pin for incoming connections
# user : always ask a pin to the user
security auto;
pairing multi;
pin_helper /opt/bluetooth/bin/bluepin;
}
device {
# whatever you want
name "MyDevice.MyDomain.us";
# 0x100 is fine for a PC, 0x120112 is better for a PDA
class 0x100;
# enable inquiry scan
iscan enable;
# enable page scan
pscan enable;
# default link mode
# none : no policy
# accept : always accept incoming connections
# master : becomes the master on incoming connections
# and deny role switch on outgoing connections
lm accept;
# default link policy
# none : no policy
# rswitch : allow role switch
# hold : allow hold mode
# sniff : allow sniff mode
# park : allow park mode
lp rswitch,hold,sniff,park;
# enable authentication
auth enable;
# enable encryption
encrypt enable;
}
What Is All of This?
Bluetooth devices automatically organize themselves into piconets, with a master and slaves. There can only be one master per piconet. However, the master can be a slave in another piconet. The two piconets are, collectively, a scatternet.
What does it all mean? To avoid problems, enable role switch and let the devices manage themselves instead of forcing a master policy.
Another important option is page and inquiry scan. By default, Bluetooth devices are in standby mode and periodically try to listen for messages. With page scan, the device expects other devices to contact it by way of its code name. The remote device must know that name. Inquiry scan is the opposite; any device can call even if it does not know the proper code name. The class allows you to search for any type of device, when there are too many Bluetooth devices around you. If you want to hide your devices from other people, disable scans--either in hcid.conf, or manually after you have connected your devices:
$ hciconfig hci0 iscan disable
The most important option is certainly the security option.
To create a connection between two Bluetooth devices, they must both know the same PIN code. It can be as small as eight bits and as large as 128 bits, but ask you may have to type it on a cellphone keyboard, it usually is only four digits--"1234" by default in many embedded Bluetooth devices such as wireless headsets.
It works as a challenge, where one device creates a challenge by deriving a key from the PIN and sending it along with a random number. If the challenge is successful, a link key is created to secure this connection. This is why you should enable authentication and encryption as well: to prevent radio eavesdropping.
Regarding security, use auto and create an application that will give a PIN. Here's a simple one:
$ echo "
#!/bin/sh
echo -n PIN:
cat /opt/bluetooth/etc/pin
">/opt/bluetooth/bin/bluepin
$ echo "9874" > /opt/bluetooth/etc/pin
$ chmod +x /opt/bluetooth/bin/bluepin
This will display "PIN:9874" when it runs.
$ /opt/bluetooth/bin/bluepin PIN:9874
You can make it more complex, for example, by requesting the user to enter a specific password each time a new device attempts to connect. This is out of the scope of this article. Gnome and KDE already provide graphical bluepin applications. Feel free to improve them if you want.
Regarding modes, hold is when a master becomes silent, to save power or to do something else (perhaps to listen on another piconet, or to perform a scan). sniff is when a slave becomes deaf from time to time, to save power. park is when a slave leaves a piconet. You can still wake it up later by asking the master to unpark it.
Basically, you should enable all these modes if your hardware supports them all--and they now mostly do. You will save power and have more features. Ancient Bluetooth hardware like my old Socket CF+ Rev E (with a Nokia chipset, hci v 1.0b) may only support a subset of these options, and will fail to work if you still enable the unsupported options. (See a short introduction to the theoretical aspects behind a Bluetooth connection and hardware features.)
Now that you have set up a password and all the options, try a connection.
Start the hcid and sdpd daemons to allow communications (for example, giving a PIN or querying capabilities):
$ /opt/bluetooth/sbin/hcid -f /opt/bluetooth/etc/bluetooth/hcid.conf
$ /opt/bluetooth/sbin/sdpd
At the moment, there is no equivalent of /etc/hosts to map names to addresses, let alone a full-fledged DNS system. You must use the hardware address.
To test the connection:
$ l2ping 00:A0:96:0A:D1:80
You will know the device requires a password if you get:
Can't connect.: Connection timed out
Alternatively, if the device is off, you will get:
Can't connect.: Host is down
With some luck, everything will work fine:
# l2ping 00:A0:96:0A:D1:80
Ping: 00:A0:96:0A:D1:80 from 00:80:C8:45:31:F8 (data size 20) ...
20 bytes from 00:A0:96:0A:D1:80 id 200 time 64.76ms
20 bytes from 00:A0:96:0A:D1:80 id 201 time 45.80ms
20 bytes from 00:A0:96:0A:D1:80 id 202 time 38.89ms
20 bytes from 00:A0:96:0A:D1:80 id 203 time 95.60ms
20 bytes from 00:A0:96:0A:D1:80 id 204 time 43.26ms
20 bytes from 00:A0:96:0A:D1:80 id 205 time 53.72ms
20 bytes from 00:A0:96:0A:D1:80 id 206 time 39.92ms
20 bytes from 00:A0:96:0A:D1:80 id 207 time 28.68ms
8 sent, 8 received, 0% loss
Use Ctrl-C to stop this.
Now look at the syslog:
# tail /var/log/syslog
Aug 2 22:20:44 [hcid] link_key_request (sba=00:80:C8:45:31:F8,
dba=00:A0:96:0A:D1:80)_
Aug 2 22:20:44 [hcid] pin_code_request (sba=00:80:C8:45:31:F8,
dba=00:A0:96:0A:D1:80)_
Aug 2 22:20:44 [hcid] link_key_notify (sba=00:80:C8:45:31:F8)_
Aug 2 22:20:44 [hcid] Replacing link key 00:80:C8:45:31:F8 00:A0:96:0A:D1:80
Both devices shared the PIN to establish the connection.
Prev [1] [2] [3] Next
