Linux Wireless Networking
By Sreekrishnan Venkateswaran2005-05-04
Linux Bluetooth
|
|
Bluetooth, a short-range wireless technology designed to replace cables, supports speeds of 723 kbps (asymmetric) and 432 kbps (symmetric) and can transfer both data and voice. Bluetooth devices have a range of about 10 meters (30 feet). (See Resources for the Bluetooth specification.)
BlueZ, the official Linux Bluetooth stack, consists of the Host Control Interface (HCI) layer, the Bluetooth protocol core, the Logical Link Control and Adaptation Protocol (L2CAP), the SCO audio layer, other Bluetooth services, user space daemons, and configuration tools (see Resources).
The Bluetooth specification supports UART (Universal Asynchronous Receiver/Transmitter) and USB transport mechanisms for Bluetooth HCI packets. The BlueZ stack supports both of those transport mechanisms (drivers/Bluetooth/). BlueZ BNEP (Bluetooth Network Encapsulation Protocol) implements Ethernet emulation over Bluetooth, which lets TCP/IP run directly over Bluetooth. The BNEP module(net/bluetooth/bnep/) and the user mode pand daemon implement Bluetooth Personal Area Networking (PAN). BNEP registers itself with the Linux networking layer as an Ethernet device using register_netdev, and populates and passes sk_buffs to the protocol stack using netif_rx as described for WLAN drivers above. BlueZ RFCOMM (net/bluetooth/rfcomm/) provides serial emulation over Bluetooth that lets serial port applications like minicom and protocols like Point-to-Point Protocol (PPP) run unchanged over Bluetooth. The RFCOMM module and the user mode dund daemon implement Bluetooth dialup networking. The list below shows the BlueZ modules, utilities, daemons, and configuration files necessary to configure various protocol services over Bluetooth.
Next, consider the examples of a Bluetooth CF card, a Bluetooth USB adapter, a device with a built-in CSR Bluetooth chipset, and a Sony Bluetooth Headset to see how they work with Linux.
Sharp Bluetooth CF card
The Sharp Bluetooth CF card uses a UART transport to transfer HCI packets. The interaction of the Linux PCMCIA/CF layer with the rest of the OS for the Sharp card resembles the one explained for the Intersil WLAN CF card, except for the fact that serial_cs is the card services driver that interacts with the Linux PCMCIA core. The serial_cs driver (explained further in "Linux GPRS and Data over GSM" below) emulates a serial port over the Sharp CF card. The BlueZ hci_uart link driver talks with Bluetooth UART channels and connects the emulated serial port to the BlueZ stack.
The list below shows the modules that must be loaded when the card is inserted. Other Bluetooth CF cards, like the Pretec CompactBT card and the Socket Bluetooth card, have UART interfaces, but have their own card services drivers (drivers/bluetooth/bt950_cs.c and drivers/bluetooth/dtl1_cs.c, respectively). You'll find more information about Bluetooth UART transport later in the article.
An entry in /etc/pcmcia/config for the Sharp Bluetooth CF card:
card "SHARP Bluetooth Card"
version "SHARP", "Bluetooth Card"
bind "serial_cs"
The necessary kernel modules to be loaded:
• insmod serial_cs
• insmod bluez
• insmod l2cap
• insmod hci_uart
• insmod bnep (for pand)
• insmod rfcomm (for dund)
BlueZ user space daemons, utilities, and configuration files:
• hciattach ttySx any [baud_rate] [flow]
• hciconfig -a : Examine the HCI interface
• hcitool -a hci0 scan 'flush: Discover other devices
• hcidump: HCI Sniffer
• hcid: HCI Daemon
• /etc/bluetooth/hcid.conf: HCI daemon configuration file used by hcid that specifies link mode (master or slave), link policy, inquiry and scan mode, and so on
• /etc/bluetooth/pinDB: BlueZ PIN Database
• sdpd: Service Discovery Protocol Daemon
• pand: To run TCP/IP over Bluetooth (--listen for the server, --connect <bluetooth_address> for the client)
• /etc/bluetooth/pan/dev-up: pand invokes this script while bringing up TCP/IP. This script can contain a command like ifconfig bnep0 <ip_address> up to configure an IP address for the Bluetooth interface
• dund: To run PPP over Bluetooth RFCOMM (--listen for the server, --connect <bluetooth_address> for the client)
The Belkin Bluetooth USB Adapter
The Belkin Bluetooth USB adapter has a Bluetooth CSR chipset and uses USB transport for transferring HCI packets. Therefore, the Linux USB layer, the BlueZ USB transport driver, and the BlueZ protocol stack are the main kernel layers that get the device working. Now, you'll see how the three layers interact to get Linux networking applications running over this device.
The Linux USB subsystem (see Resources) resembles the PCMCIA subsystem in that both have host controller device drivers that talk to removable devices and both include a core layer that offers services to device drivers for the host controller and the individual devices. USB host controllers follow one of two standards: UHCI (Universal Host Controller Interface) or OHCI (Open Host Controller Interface). As with PCMCIA, the Linux device drivers for the individual USB devices do not depend on the host controller. Data transfers to and from a USB device fall into one of four categories (or pipes):
• Control
• Interrupt
• Bulk
• Isochronous
The first two are usually used for small messages while the latter two are used for larger messages.
When a USB device is plugged in, it is enumerated by the host controller driver using control pipes and assigned a device address (1 to 127). The device descriptor read by the host controller driver contains information about the device, such as class, subclass, and protocol. Linux's usbcore kernel module supports USB host controllers and USB devices. It contains functions and data structures that USB device drivers can use. USB drivers register two entry points, probe and disconnect, with usbcore, along with their class/subclass/protocol information (see struct usb_driver in include/linux/usb.h). When the corresponding USB device is attached, usbcore matches the registered class information with the one read from the device configuration descriptor during enumeration and binds the device with the corresponding driver. The core uses a data structure called USB Request Block, or URB (defined in include/linux/usb.h), to asynchronously manage data transfers between the host and the device. Device drivers use these routines to request various types of data transfers (control, interrupt, bulk, or isochronous). The core notifies the driver using previously registered callback functions after the transfer request is completed.
For Bluetooth USB devices, HCI commands are transported using Control pipes, HCI events using Interrupt pipes, Asynchronous (ACL) data using Bulk pipes, and Synchronous (SCO) audio data using Isochronous pipes. The Bluetooth specification defines a class/subclass/protocol code of 0xE/0x01/0x01 for Bluetooth USB devices. The BlueZ USB transport driver (drivers/bluetooth/hci_usb.c) registers this class/subclass/protocol information with the Linux USB core. When the Belkin USB adapter is plugged in, the host controller device driver enumerates it. Because the device descriptor read from the adapter during enumeration matches the information registered by the hci_usb driver with the USB core, this driver gets attached to the Belkin USB device. The HCI, ACL, and SCO data read by the hci_usb driver from the various endpoints described above are transparently passed on to the BlueZ protocol stack. Once this is done, Linux TCP/IP applications can run over BlueZ BNEP, and serial applications can run over BlueZ RFCOMM using the BlueZ services and tools described above.
A board with a built-in CSR Bluetooth chipset
Now, take a look at Bluetooth network data flow on a device with a built-in Bluetooth chipset. Consider a handheld with a built-in CSR Bluetooth chipset interfaced to the system using a UART interface. For UART interfaces, the available protocols to transport HCI packets between the Bluetooth device and the system are BlueCore Serial Protocol (BCSP), H4/UART, and H3/RS232. While H4 serves as the standard method to transmit Bluetooth data over UART as defined in the specifications, the proprietary BCSP protocol from CSR supports error checking and retransmission. BCSP is used on non-USB devices based on CSR BlueCore chips including PCMCIA and CF cards. BlueZ supports BCSP and H4.
The legacy serial driver that drives this board's UART channels can send and receive data from the BlueZ UART transport driver. If the CSR chip is programmed to encapsulate HCI packets using the BSCP protocol, you must inform the BlueZ link driver using hciattach (hciattach ttySx bcsp), where x is the UART channel number connected to the CSR chipset. hci_uart now talks to the CSR chip and passes on Bluetooth data to and from the BlueZ stack.
Sony HBH-30 Bluetooth Headset
The previous Bluetooth device examples showed network data flow. Now, consider the transfer of Bluetooth audio (SCO) data by looking at a Sony Ericsson Bluetooth headset. Before the headset can start communicating with a Linux device, it must be discovered by the Bluetooth link layer on the Linux device. Therefore, you must put the headset in a discover mode (by pressing a button on the headset). Additionally, you need to configure the headset's PIN with BlueZ on the Linux device. An application on the Linux Bluetooth device that uses BlueZ SCO APIs can now send audio data to the headset. The audio data should be in a format understood by the headset (for example, A-law PCM [Pulse Code Modulation] format for the Sony headset). There are public domain utilities for converting audio (and even text files) into various PCM formats.
Bluetooth chipsets have PCM interface pins in addition to the HCI transport interface. If a device supports, for instance, both GSM and Bluetooth, the PCM lines from the GSM chipset might be directly wired to the Bluetooth chip's PCM audio lines. You might then have to configure the Bluetooth chipset on the Linux device to receive and send SCO audio packets over the HCI transport interface rather than the PCM interface.
Tutorial Pages:
» A Look at WLAN, Bluetooth, GPRS, GSM, and Infrared Data on Linux
» Linux 802.11 WLAN
» Linux Bluetooth
» Linux GPRS and Data over GSM
» Linux Infrared Data
» Performance Issues
» Conclusion
» Resources
First published by IBM DeveloperWorks
|
