9/27/12

Features of BlueZ
Real hardware abstrac.on

The University of Rhode Island

Bluetooth Programming in C for Linux

Generic and vendor specic drivers

Over 150 supported Bluetooth adapters
Up to 16 host adapters at the same .me

Machine architecture independent

More features

LiAle and big endian

32 bit and 64 bit systems
SMP safe
Hyperthreading
Preempt ready

The BlueZ architecture

BSD sockets interface

HCI raw socket
L2CAP sequen.al packet and datagram
SCO sequen.al packet
RFCOMM stream

Complete modular design

Kernel code
User space programs and tools

Bluetooth library with user API

Handling of Bluetooth addresses and devices

Supported protocols and proles

Current protocols
HCI, L2CAP,
SDP,RFCOMM, OBEX,
BNEP, CMTP,HIDP,
HCRP,IrMC, SyncML

Future protocols
TCS-BIN, AVDTP,
AVCTP

Current proles
GAP, SDAP,SPP,
GOEP,DUN, FAX, LAN,
PUSH, SYNC,
FTP,PAN, CIP,HID,
HCR

Future proles
CTP, Intercom, BPP,
BIP,HSP, HFP, SAPP

Advantages of BlueZ
Full source code is available under the GPL
Socket based interfaces
Simple API for special HCI or SDP tasks
Access to all Bluetooth host layers
Big user and developer community
Very good interoperability with Bluetooth
devices

9/27/12

BlueZ host adapter setup

Ethernet device like congura.on
Linux Bluetooth stack specic se\ngs
Host controller related congura.on

Using the Bluetooth device

Simple command line tools
Scanning for devices in range
Get informa.on about devices and connec.ons
Link quality, RSSI, transmit power level etc.

BlueZ and HCI

Bluetooth user space library

From the user side

Handling of Bluetooth device addresses

The BlueZ HCI API is a raw socket

The internal protocol is H:4
Only one command/event per write/read
API for abstrac.ng HCI commands and events

New data type bdaddr_t

The special address BDADDR_ANY
The func.ons bacpy, baswap and bacmp
Address conversion with str2ba, ba2str, strtoba and batostr

The kernel side

Easy kernel API for wri.ng host drivers
Exis.ng drivers for H:2 (USB) and H:4 (UART)
Currently 8 dierent drivers
The Ax stack also uses the BlueZ host driver API

The Bluetooth sockets

Example program: rfcomm-server.c

Full socket interface

L2CAP
Connec.on-oriented (SOCK_SEQPACKET)
Connec.onless (SOCK_DGRAM)

RFCOMM
Data stream (SOCK_STREAM)
Sockets can be converted to a TTY device
Uses the L2CAP in-kernel socket interface

Complete abstrac.on from HCI

Crea.on and clearing of ACL connec.ons
Sending and receiving of data packets

9/27/12

rfcomm-server.c (Cont.)

Example program: rfcomm-client.c

Socket funcHon

Addressing structures

int socket(int domain, int type, int protocol);

For RFCOMM
AF_BLUETOOTH
species that it should be a Bluetooth socket

SOCK_STREAM
requests a socket with streams-based delivery seman.cs

BTPROTO_RFCOMM
specically requests an RFCOMM socket

socket function creates the RFCOMM socket and returns an

The
integer which is used as a handle to that socket

Establishing a connecHon
int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen);

sock should be the server socket created by connect. info should point to a struct
sockaddr_rc addressing structure lled in with the local Bluetooth adapter to use, and
which port number to use.
addrlen should always be sizeof( struct sockaddr_rc ).

int listen(int sockfd, int backlog);

the applica.on takes the bound socket and puts it into listening mode with the listen
func.on.
In between the .me an incoming Bluetooth connec.on is accepted by the opera.ng system
and the .me that the server applica.on actually takes control, the new connec.on is put into
a backlog queue. The backlog parameter species how big this queue should be. Usually, a
value of 1 or 2 is ne.

struct sockaddr_rc {
sa_family_t rc_family;
bdaddr_t
rc_bdaddr;
uint8_t
rc_channel;
};

The rc_family eld species the addressing family of the socket,

and will always be AF_BLUETOOTH.
For an outgoing connec.on, rc_bdaddr and rc_channel specify
the Bluetooth address and port number to connect to, respec.vely.
For a listening socket, rc_bdaddr species the address of the local
Bluetooth adapter to use and rc_channel species the port
number to listen on.
If you dont care which local Bluetooth adapter to use for the
listening socket, then you can use BDADDR_ANY to indicate that any

Establishing a connecHon (Cont.)

int accept(int sockfd, struct sockaddr *addr, socklen_t *addrlen);

The accept func.on waits for an incoming connec.on and returns a brand new
socket.
The returned socket represents the newly established connec.on with a client,
and is what the server applica.on should use to communicate with the client.
If client_info points to a valid struct sockaddr_rc structure, then it is
lled in with the clients informa.on.
Addi.onally, infolen will be set to sizeof(struct sockaddr_rc).
The server applica.on can then make another call to accept more connec.ons, or
it can close the server socket when nished.

9/27/12

Using a connected socket

ssize_t read (int fd, void *buf, size_t count);

ssize_t write (int fd, void *buf, size_t count);

The write func.on transmits data, the read func.on waits for and receives incoming data
Both func.ons take three parameter, the rst being a connected Bluetooth socket.

Close the socket

Once a program is nished with a connected
socket, calling close on the socket
disconnects and frees the system resources
used by that connec.on.

For write, the next two parameters should be a pointer to a buer containing the data to send, and the amount of
the buer to send, in bytes.
For read, the second two parameters should be a pointer to a buer into which incoming data will be copied, and an
upper limit on the amount of data to receive

write returns the number of bytes actually transmiAed, which may be less than the
amount requested. In that case, the program should just try again star.ng from where send
lej o.
read returns the number of bytes actually received, which may be less than the maximum
amount requested.
The special case where read returns 0 indicates that the connec.on is broken and no more
data can be transmiAed or received.