Communication Models

Bluetooth Classic uses a hub and spoke communication model in which the hub (also known as the main) can communicate with up to seven spokes (also known as the follower). The main and followers can change roles based on agreement. Also, there is a Bluetooth mesh technology implementation which operates on a flood networking model (send the packet to all other peers except those who sent the packet to it). Bluetooth LE can operate in either of the models depending on the application profile. The device roles and negotiation can be tracked in the Wireshark Bluetooth captured packet type of HCI_CMD or HCI_EVT.

As seen in Figure 7-1, the laptop OS (host) sends instructions to the Bluetooth chip (controller) to connect to a pre-paired known headset with identifier Plantron_a3:7b:19. Also, the host specified in the command that the local device will be the master and won't accept a role switchover request.

A screenshot illustrates commands for Bluetooth device role negotiation. Command executed in steps, Bluetooth Sent command. Create Connection with subcommands, Opcode, packet type, Clock offset Valid Flag, and Allow Role Switch.

Radio and Data Transfer

The Bluetooth radios use an unlicensed but regulated spectrum at 2.40–2.483 GHz. Bluetooth Classic (BR/EDR) uses 79 channels 1 MHz each, which includes 32 channels for discovery purposes, whereas Bluetooth LE uses the same band with 40 channels, each 2 MHz wide with only 3 channels for discovery. This makes discovery quicker in LE as fewer channels to scan. The range, power output of the radios, modulation, and data rate vary between Bluetooth versions (1–5) and standards (Classic/LE).

Table 7-1 and Figure 7-2 show some summary comparisons between various specifications.

An image illustrates Bluetooth bandwidth and channel comparison for Bluetooth Classic Versus L E. Bluetooth Classic uses 79 channels, one Mega Hertz each, and Bluetooth L E uses 40 channels, two Mega Hertz each.

Table 7-1

Bluetooth Radio Specifications

	Bluetooth Classic	Bluetooth Low Energy
Radio class	Type 1: 10–100 mW Type 2: 1–2.5 mW Type 3: 0.01–1 mW	Mostly Type 3 Consumption range 0.01–0.5 mW
Frequency band	2.4–2.483 GHz	2.4–2.483 GHz
Number of channels	79 total including 32 for discovery	40 total including 3 for discovery
Channel width	1 MHz	2 MHz
Modulation	BR:   FSK/GFSK EDR2:  π/4-DQPSK EDR3:  8 DQPSK HDR4:  π/4-DQPSK HDR8:  π/4-DQPSK	FSK/GFSK
Data rate	BR:   1 Mbps EDR2:  2 Mbps EDR3:  3 Mbps HDR4:  4 Mbps HDR8:  8 Mbps	125 Kbps to 2 Mbps
Range	Up to 100m depends on radio, data rate, and modulation	Up to 100m depends on radio, data rate, and modulation
Encryption	56/128-bit physical and application	AES 128-bit physical and application

Bluetooth Protocol Stack

Bluetooth uses a completely different protocol stack specified and maintained by Bluetooth SIG standards. The protocols in the stack can be distributed across the hardware (controller) and software (host) portions of the device. The hardware or the Bluetooth chip is known as the controller and can be internal or external to the device. The software or OS is known as the host and runs the protocols that interact with the local controller and Bluetooth peer host.

Between the host and controller, there is a middle layer known as the Host Controller Interface (HCI) which provides a software interface to the host OS to interact with the controller hardware.

Figure 7-3 shows a summary view of the Bluetooth protocol placement. The following section will discuss in detail each of these layers.

A model indicates Bluetooth protocol stack. It has three layers. The host contains application layer protocols L 2 C A P. H C I has H C I protocol. Controller link manager and radio.

Controller Operations

The Bluetooth controller hardware normally takes care of the physical and data link layers of the communications. It has protocols running in the link manager and radio layers.

HCI

On a hostless system where HCI is absent, data and control packets are directly handed off by L2CAP to the link layer.

The HCI frames can be filtered through the display filter “hci_h4” or “hci_h1” depending on the host HCI type.

A screenshot of the H C I packet filter. The window has the option to check commands upon selection and indicates display filter H C I H four command.

Host Layer Operation

L2CAP

L2CAP (Logical Link Control and Adaptation Protocol) operates on the host and is part of the data link layer that works with the LMP which is the controller part of the data link layer. Some of the important functions of L2CAP are

• Multiplexing multiple applications over a single link

  • All upper layer application, control, or discovery protocols data passes through L2CAP

• Fragmentation and reassembly of data

• Handling one to many replications (hub and spoke topology)

• Quality of service (QoS)

All L2CAP types of packets can be filtered using a display filter “btl2cap”. Figure 7-5 shows SDP packets also as SDP is an upper layer protocol which hands over data to L2CAP to be sent on the link.

An image of L 2 C A P packet filter. It illustrates display filter B T L 2 C A P. It has sub commands; Information response which includes, Identifier Length, Information Type and Result; Fixed channel supported.

Application Profile–Specific Protocols

Bluetooth supports a wide variety of applications like telephony, audio/video, TCP/IP communication, medical or fitness equipment communication, computer I/O (mouse, keyboard, etc.), and many more. For every application, there is a standard protocol and parameter specifications defined by SIG, known as Bluetooth profiles.

The following are some of the protocols which run on top of L2CAP and help in application discovery and operation.

SDP

The Service Discovery Protocol (SDP) helps a Bluetooth-enabled device discover the service profile (the capabilities and services) offered by the peer device, for example, a Bluetooth-enabled mouse, keyboard, headset, etc. Also SDP specifies device-specific capabilities like, if it is an AV device, does it support an advanced audio distribution profile, or supports a hands-free profile or receiver-only profile, etc. After the connection is set up, SDP frames are exchanged between peer devices to agree on the profiles supported and what to use.

An image illustrates Session Discovery Protocol filter.The command indicates, Bluetooth S D P protocol has three sub commands, Service search request, Transaction ID and Parameter Length. Protocol type and information reflects at central pane.

Controller-to-Host Communication

Sometimes, the local Bluetooth host or controller (Bluetooth hardware) may misbehave. Also, if there are interoperability issues with an external controller, for example, a Bluetooth dongle connecting the host through a USB, then Wireshark can be used.

All host-to-controller communication happens through the HCI. Inspecting the HCI messages can help in this case. Filtering HCI was discussed in the previous section “HCI.”

An image of program illustrates communication between Host and controller. Program number 16 depicts; source, controller; Destination, host; Protocol, H C I underscore E V T; length, 10; Info, received command complete.

Pairing and Bonding

Pairing is used to authenticate a device and establish a bond by storing it as a known trusted device if the pairing is successful. Pairing normally requires a user to start the pairing process, but it can be done without user intervention also.

Once a device is paired and bonded, an authentication key is generated which is used to encrypt the communication data link. Once paired for subsequent attempts, no user intervention is required to connect two devices.

All these transactions can be tracked through Wireshark captures. This helps in detecting the failures in the pairing process. The following are some of the snapshots which show the steps mentioned earlier.

An image illustrates program locates presence of device by regular channel scan. It highlights code, page scan repetition, class of device and reflects Device Name colon P L T Focus.

An image illustrates S D P initiates an A C L link over L 2 C A P for Service discovery. Info row in program window indicates several commands to discover services.

An image illustrates Input and output capabilities and pair discovery. It has command window depicts, Command Opcode, Parameter total length, Display Yes or No, Authentication data not present.

Paired Device Discovery and Data Transfer

When the devices are already paired and come in range, a set of procedures must be completed before data is transferred:

• Devices do a link scan, signal strength measurement, etc.

• Initiate a role discovery and agree on the master. Exchange the link encryption keys generated during pairing (both sides must have the same key). The key is not encrypted and can be seen as clear text.

An image of program execution for link scan role discovery and key exchange. Steps reflects in info column; Role discovery; link supervision timeout changed; switch role; command status; Link key request; command complete. Two protocols involved; H C I underscore C M D; H C I underscore E V T.

• SDP initiates an ACL link over L2CAP for peer service profile and capability discovery.

An illustration of connection initiation between S D P and A C L. It consists of L 2 C A P protocol in four steps; Connection Request; Connection Response hyphen Pending; Connection Response hyphen Success; Configure Request.

A program window of S D P service profile discovery. It runs on Session Discovery Protocol and info column respond search requests, Handsfree Audio Gateway, Phonebook Access Server; Audio Source; A forward slash V Remote control Target, A forward slash V Remote control controller, Unknown.

• Based on the profile discovery required, upper layer protocols initiate additional connections for the exchange of configuration parameters.

• In our example, the Bluetooth headset is connected to a laptop. So we can see RFCOMM for the configuration setup and AVCTP and AVDTP protocol connections for audio control and data.

A program window of upper layer connection setup. It involves four protocols; H F P; H C I underscore E V T; R F C O M M; L 2 C A P. info column indicates; connection Request and response as pending and success; Configure response hyphen Success and Number of completed packets.

• After the upper layer connections are set up, actual data transfer can be seen. Here in our case, AVDTP is used to transport audio using aptX codec.

Data Transfer over Bluetooth. Program window represents five rows; Source; Destination; Protocol; Length; Info which indicates, Command hyphen start hyphen A C P S E I D, Number of completed packets, apt X.