1. Utilisation de BlueTooth
sous GNU Linux
GAYET Thierry – octobre 2005
Thierry.Gayet@yahoo.fr
REF. OSP003
2. Plan de la présentation
Historique
Bande de fréquence
Définition du protocole
Les services
Topologie
Présentation des profiles
La stack Bluetooth
Comparaison avec le modèle OSI
Format des paquets
Installation de la stack BlueZ
Fichiers importants
Utilisation
Autres outils
Programmation
Liens
3. Historique
Son nom est directement inspiré du roi danois Harald II surnommé Harald II Blåtand (« à la
dent bleue »), connu pour avoir réussi à unifier les états du Danemark, de Norvège et de
Suède. Le logo de Bluetooth est d'ailleurs composé des runes nordiques H et B.
1994 : Création par le fabriquant suédois Ericsson
1998 : Plusieurs grandes sociétés (Agere, IBM, Intel, Microsoft, Motorola, Nokia et Toshiba)
s'associent pour former le Bluetooth Special Interest Group (SIG)
juillet 1999 : Sortie de la spécification 1.0
4. Bande de Fréquence 1/3
Les bandes ISM (industriel, scientifique, et médical) sont des bandes de fréquences qui ne
sont pas soumises à des réglementations nationales et qui peuvent être utilisées librement
(gratuitement, et sans autorisation) pour des applications industrielles, scientifiques et
médicales.
Les seules obligations à observer sont :
• la puissance d'émission
• les excursions en fréquence, ou la perturbation de fréquences voisines.
Les champs d'application typiques sont les dispositifs Bluetooth et les réseaux sans fil (Wi-Fi et
WLAN).
La situation des bandes ISM n'est pas uniformément réglée dans le monde. Aux USA il y a
par exemple trois bandes ISM (902 - 928 MHz ; 2400 - 2483,5 MHz et 5800 MHz), mais seule
la bande des 2,4 GHz est libéré dans le monde entier.
Dans ces bandes, des téléphones sans-fil existent également. En Europe les téléphone sans-fil
au standard DECT fonctionnent toutefois dans une bande de fréquence propre, qui est
exclusivement disponible pour les appareils utilisant cette norme.
Les réseaux WLAN et les dispositifs Bluetooth émettent dans la bande des 2,4 GHz.
Il y a également des réseaux et dispositifs WLAN dans la bande des 5 GHz (plus précisément 5,15
- 5,725 GHz en Europe) et à une puissance d'émission différente.
6. Bande de Fréquence 3/3
En France:
En France, la bande ISM principale utilisée est la bande de fréquences de la gamme des UHF
allant de 2,4 à 2,4835 GHz (bande L).Cependant depuis peu des caméra sans fil fonctionnant
autour des 1.2 Ghz ont fait leur apparition sur le marché français avec le certificat quot;CEquot;. Cette
bande n'apparaît pas comme un spectre gratuit et ouvert ou public.
Outre le Wifi, elle est réservée à de nombreuses applications publiques et grand public sans fil,
les caméras de vidéo-surveillance professionnelles et domestiques, les webcams, les transmetteurs
(émetteur/récepteur) de salon audio-vidéo, tous ces appareils fonctionnant en vidéo composite PAL.
Puissance autorisée, PIRE 10 mW ou 10 dBm. Polarisation au choix, circulaire, linéaire. L'ISM est
partagée avec les radioamateurs jusqu'à 2450 MHz.
Nb : les appareils d'émission doivent comporter la mention « CE » (certificat de conformité
européeen) pour pouvoir être utilisés réglementairement à l'extérieur des bâtiments comme à
l'intérieur. (Voir : ART, Décision N° 02-1088 du 28.11.2002) Notons qu'en France metropolitaine il
n'existe plus de restrictions départemantales, non levées en outre-mer.
Dans les zones urbaines la cohabitation devient difficile entre les différents utilisateurs, wifistes d'un
côté et les usages domestiques utiles( video-surveillance) ou ludiques ( aérocam, astrocam,
météocam etc..), de l'autre.
http://www.art-telecom.fr/interactive/recherche/result.php?bandeau=/textes/avis/bandeau.htm&corps=
/textes/avis/02/02-1088.htm
7. Définition du protocole
La pile de protocoles
Afin d'assurer une compatibilité entre tous les périphériques Bluetooth, la majeure partie
de la pile de protocoles est définie dans la spécification.
Les éléments fondamentaux d'un produit Bluetooth sont définis dans les deux premières
couches protocolaires, la couche radio et la couche bande de base. Ces couches prennent
en charge les tâches matérielles comme le contrôle du saut de fréquence et la synchronisation
des horloges.
8. Définition du protocole
La couche radio (RF)
La couche radio (la couche la plus basse) est gérée au niveau matériel. C'est elle qui s'occupe de l'émission
et de la réception des ondes radio. Elle définit les caractéristiques telles que la bande de fréquence et
l'arrangement des canaux, les caractéristiques du transmetteur, de la modulation, du receveur, etc.
La technologie Bluetooth utilise l'une des bandes de fréquences ISM (Industrial, Scientific & Medical)
réservée pour l'industrie, la science et la médecine. La bande de fréquences utilisée est disponible au niveau
mondial et s'étend sur 83,5 MHz (de 2,4 à 2,4835 GHz).
Cette bande est divisée en 79 canaux séparés de 1 MHz.
Le codage de l'information se fait par sauts de fréquence.
La période est de 625µs ce qui permet 1600 sauts par seconde.
Il existe 3 classes de modules radio Bluetooth sur le marché ayant des puissances différentes et donc des
portées différentes :
Puissance Portée
Classe
1 100 mW (20 dBm) 100 mètres
2 2,5 mW (4d Bm) 15 à 20 mètres
3 1 mW (0 dBm) 10 mètres
La plupart des fabriquants d'appareils électroniques utilisent des modules de classe 3.
10. Définition du protocole
Bluetooth opère dans la bande non-officièle des 2.5GHz aussi appelée Industrial-Scientific-Medical
(ISM). Il y a déjà plusieurs type de devices dans cette bande de fréquence tel que les moniteurs
Pour surveiller les enfants ou les télécommande de portes de garages.
Pour évites les interférences, les devices Bluetooth envoient un faible signal (environ 1 milliwatt).
La limite de transmission ne dépasse pas 10 mètres. Il utilise aussi une technique de sauts de
fréquence en espérant, avec 79 sauts aléatoires de1 MHz et cela 1600 fois par secondes .
Chaque piconet est synchronisé avec un modèle de saut de fréquency fréquence, donc chaque
piconet différent n’interfère pas avec les autres. Un piconet peut être soit statique ou bien
Dynamique:
La modulation dans Bluetooth
est de type “Gaussian Frequency
Shift Keying (GFSK)”, avec un BT
Égal à 0.5 et un index de
modulation compris entre 0.25
et 0.35:
Bluetooth Modulation
11. Définition du protocole
La bande de base (baseband)
La bande de base (ou baseband en anglais) est également gérée au niveau matériel.
C'est au niveau de la bande de base que sont définies les adresses matérielles des périphériques
(équivalent à l'adresse MAC d'une carte réseau).
Cette adresse est nommée BD_ADDR (Bluetooth Device Address) et est codée sur 48 bits.
Ces adresses sont gérées par la IEEE Registration Authority.
C'est également la bande de base qui gère les différents types de communication entre les
appareils. Les connexions établies entre deux appareils Bluetooth peuvent être synchrones ou
asynchrones.
La bande de base peut donc gérer deux types de paquets:
• les paquets SCO
(Synchronous Connection-Orientated)
• les paquets ACL
(Asynchronous Connection-Less)
12. Définition du protocole
Réseau piconet
Un piconet est un mini réseau qui se crée de manière instantanée et automatique quand
plusieurs périphériques Bluetooth sont dans un même rayon.
Un piconet suit une topologie en étoile : 1 maître / plusieurs esclaves.
Un périphérique maître peut administrer jusqu'à :
• 7 esclaves actifs
• 255 esclaves en mode parked
La communication est directe entre le maître et un
esclave. Les esclaves ne peuvent pas communiquer
entre eux.
Tous les esclaves du piconet sont synchronisés sur
l'horloge du maître. C'est le maître qui détermine la
fréquence de saut pour tout le piconet.
13. Définition du protocole
Réseau scatternet
Les périphériques esclaves peuvent avoir plusieurs maîtres, les différents piconets peuvent
donc être reliés entre eux. Le réseau ainsi formé est appelé un scatternet (littéralement réseau
chaîné).
Bluetooth Scatternets and Piconets
Le contrôleur de liaisons (LC)
Cette couche gère la configuration et le contrôle de la liaison physique entre deux appareils.
14. Définition du protocole
Le gestionnaire de liaisons (LM)
Cette couche gère les liens entre les périphériques maîtres et esclaves ainsi que les types de
liaisons (synchrones ou asynchrones).
C'est le gestionnaire de liaisons qui implémente les mécanismes de sécurité comme :
• l'authentification,
• le pairage,
• la création et la modification des clés,
• et le cryptage.
L'interface de contrôle de l'hôte (HCI)
Cette couche fournit une méthode uniforme pour accéder aux couches matérielles.
Son rôle de séparation permet un développement indépendant du hardware et du software.
Les protocoles de transport suivants sont supportés :
• USB (Universal Serial Bus)
• PC-Card
• RS-232
• UART
16. Définition du protocole
La couche L2CAP
L2CAP signifie Logical Link Control
& Adaptation Protocol.
Multiplexage
Cette couche permet d'utiliser simultanément différents protocoles de niveaux supérieurs.
Un mécanisme permet d'identifier le protocole de chaque paquet envoyé pour permettre à
l'appareil distant de passer le paquet au bon protocole, une fois celui-ci récupéré.
Segmentation et réassemblage
La couche L2CAP gère également la ségmentation (et le réassemblage) des paquets de
protocoles de niveaux supérieurs en paquets de liaison de 64 Ko.
17. Les services
RFCOMM
RFCOMM est un service basé sur les spécifications RS-232, qui émule des liaisons séries.
Il peut notamment servir à faire passer une connexion IP par Bluetooth.
SDP
SDP siginifie Service Discovery Protocol.
Ce protocole permet à un appareil
Bluetooth de rechercher d'autres
appareils et d'identifier les services
disponibles.
Il s'agit d'un élément
particulièrement complexe de Bluetooth.
OBEX
OBEX siginifie Object Exchange. Ce service permet de transférer des données grâce à OBEX,
protocole d'échange de fichiers IrDA.
18. Topologie 1/2
A wireless local area network, also referred to as 802.11, uses high-frequency radio waves instead of wires to communicate between nodes in a network. A
wireless personal area network provides network connectivity without wires to devices (personal devices that are carried, worn, or located near the body) within a
personal operating space. Wireless personal area networks differ from wireless local area networks in several areas, including interaction, packet format, type of
devices, network build-out timeframe, relative cost, and general network architecture. The following table presents the comparison of WPAN and WLAN:
19. Topologie 2/2
802.15 WPAN Task Group 1
The 802.15 WPAN Task Group 1 (TG1) is using the Bluetooth v1.0 specifications to derive the
WPAN standard. The scope and focus of TG1 are to define PHY and MAC specifications for
wireless connectivity between devices that are either fixed or portable within the personal
operating space. The goal will be to allow low complexity, low power consumption wireless
connectivity to support data transfer to and from a WPAN device and an 802.11 device.
The proposed standard will take into account coexistence with all 802.11 devices.
802.15 WPAN Task Group 2
Task Group 2's (TG2) scope and focus is to address the coexistence of WPANs and WLANs.
TG2 is developing a coexistence model to quantify the mutual interference of a WLAN and a
WPAN. The Task Group is also developing a set of coexistence mechanisms to facilitate
coexistence of WLAN and WPAN devices.
802.15 WPAN Task Group 3
Task Group 3's (TG3) scope and focus is to publish a new standard for a high data rate, 20
Mbps or greater, for WPANs. TG3 will also be looking at providing a solution that is low power
and low cost, addressing the needs of digital imaging and multimedia applications. The new
standard will comply with the TG1 standard.
802.15 WPAN Task Group 4
Task Group 4's (TG4) scope and focus is to determine a solution with a low data rate and long
battery life, potentially months to years, with very low complexity. The solution determined
would need to operate within an unlicensed and global frequency band. The solution could
potentially be applied to sensors, remote controls, appliances, toys, etc.
20. Les profiles 1/6
Les profils
Un profil correspond à une spécification fonctionnelle d'un usage particulier.
Ils peuvent également correspondre à différents types de périphériques.
Les profils ont pour but d'assurer une interopérabilité entre tous les appareils Bluetooth.
Ils définissent :
• la manière d'implémenter un usage défini
• les protocoles spécifiques à utiliser
• les contraintes et les intervalles de valeurs de ces protocoles
• Les différents profils sont :
• GAP: Generic Access Profile
• SDAP: Service Discovery Application Profile
• SPP: Serial Port Profile
• HS Profile: Headset Profile
• DUN Profile: Dial-up Networking Profile
• LAN Access Profile
• Fax Profile
• GOEP: Generic Object Exchange Profile
• SP: Synchronization Profile
• OPP: Object Push Profile
• FTP: File Transfer Profile
• CTP: Cordless Telephony Profile
• IP: Intercom Profile
21. Les profiles 2/6
Le profil d'accès générique (GAP)
Le profil d'accès générique est le profil de base dont tous les autres profils héritent.
Il définit les procédures génériques de recherche d'appareils, de connexion et de sécurité.
22. HID
HID
EB
Average
Server
40-50m
3-10m
range
HCRP
HCRP
HCRP
1-5m
Client
Client
Client
ICP Terminal
Terminal
Terminal
BNEP TCS
70-100m
10-20m
1-10m
range
Gateway
Max
CTP
CTP
CTP Terminal
TCP/UDP
Network Access Point
PAN Group Ad-hoc N
Group Ad-hoc N
Group Ad-hoc N
Max Output
PAN User
PAN User
PAN User
IP
(20 dBm)
100 mW
(4 dBm)
(0 dBm)
2.5 mW
Power
1 mW
PPP
LAN Acc P
LAN
LAN
LAN Data Term
Gateway
DUN
DUN
DUN Data Terminal
Data Terminal
Data Terminal
Power
Class
Server
Server
Server
SAP
1
2
3
Client
Les profiles 3/6
Bluetooth overview
Terminal Eq. Unit
PAP
PAP
PAP Mobile Equipment
Audio Gateway
Audio Gateway
Audio Gateway
HFP Hands Free Unit
Hands Free Unit
Hands Free Unit
Audio Gateway
HS
HS
HS Headset
Gateway
RFCOMM
FAX
FAX
FAX
Rev < 0,95
Data Terminal
Data Terminal
Data Terminal
Rev < 1.0
Data exchange - 432.6 Kbips symétrique - 721 Kbips/57.6 Kbips asymétrique
L2CAP
Printer
Printer
Printer
BPP Sender
Sender
Sender
I Responder
BIP
BIP
BIP I Initiator
Server
Server
Server
OBEX
FTP
FTP
FTP Client
Client
ClientIrmC
IrMC S
IrMC S
IrMC S
SYNC IrMC C
Rev 0,95
Rev 1.0
P-Server
OPP
OPP
OPP P-Client
Server
Server
Server
SCO = Synchronous Connection Oriented
GOEP Client
Client
Client
ACL = Asynchronous Connection Less
Device B
SPP
SPP
SPP Device A
Voice exchange - 64 Kbips / canal
Gateway
VCP
VCP
VCP Data Terminal
Data Terminal
Data Terminal
Rev 1.1
Rev 1.1
CTP
AV-
Target
Target
Target
RCP Controller
Sink
VDP
VDP
VDP Source
AVDTP
Sink
Sink
Sink
A2DP Source
Source
Source
Acceptor
Protocols
GAVDP
GAVDP
GAVDP Initiator
Profiles
SDP
Rem Dev
SDAP
SDAP
SDAP Loc Dev
Loc Dev
Loc Dev
B-Party
B-Party
B-Party
GAP A-Party
A-Party
A-Party
23. Les profiles 4/6
Transfert de fichiers:
Le modèle de transfert de fichier The file transfer usage model
(cf file transfert profile) offre la capacité de transférer des objets
d’un device à un autre (e.g., PC, smart-phone, ou PDA).
Les types d’object peuvent être (mais n’y sont pas limités)
.xls, .ppt, .wav, .jpg, et .doc, contenu d’un répertoire, répertoire,
ou format en streaming.
Aussi, ce modèle offre la possibilité de consulter le contenu d’un
répertoire distant.
Dans le schéma donne une vue de cette stack mais ne
montre pas Les couches inférieures LMP, Baseband, et Radio. Stack pour les transferts de fichiers.
24. Les profiles 5/6
Synchronisation:
Le modèle synchronisation entre devices (téléphone, PDA,
ordinateurs, etc…) de toute information de type PIM
(personal Information management) : carnet d’adresses,
calendrier, messagecalendar, message, et note d’information.
La synchronisation requière des cartes de visites (business
card), calendriers (calendar), et tâches d’informations
(task information) à transférer et à traiter par les téléphones
Cellulaires et PDAs en utilisant des protoles et des formats
Communs.
Le schéma ci-contre donne une vue de ce model.
Stack pour la synchronisation
Le bloc « synchronization application » représente soit un
Client/Serveur IrMC.
25. Les profiles 5/6
Three-in-One téléphones:
Les handsets réalisés avec ce profile doivent se connecter
Avec 3 fournisseurs de services différents.
En premier, les téléphones doivent agir comme un
téléphone sans-fils connecté à un réseau public
(PSTN) à la maison ou au bureau. Ce scénario inclus une
base vocale de création d’appels en créant des appels
entre deux terminaux via la base et en accédant à des
services supplémentaires fournis par une réseau externe.
Après les téléphones peuvent se connecter à d’autres
téléphones en proposant des comportement tels que des
“walkie-talkie” ou des handsets.
En troisièmen le téléphone peut agir comme un téléphone
cellulaire en se connectant à une infrastructure GSM.
Stack pour les téléphones sans fils.
Le schéma ci-contre donne une vue de ce model.
Le flux audio se connecte directement à la couche Baseband
via ta couche L2CAP.
26. Les profiles 6/6
Ultimate Headset
Le modèle headset permet de connecter des devices
tel que des entrée & sortie audio avec des possibilités
d’actions. Il permet d’accroître les libertés de
Mouvements tout en garantissant la confidentialité.
Un exemple de scénario possible est un déport du son
et de la prise de l’appel d’un téléphone portable via un
Handset alors que l’on marche dans la rue ou que l’on
conduit un véhicule.
Le schéma ci-contre donne une vue de ce model.
Le flux audio en streaming est directement connecté à la
couche Baseband via L2CAP.
Stack des Headset.
Le headset doit être sapable d’envoyer des commandes
AT (commandes d’urgence) et de reçevoir des codes de
Retour. Cette capacité permet au headset de prendre des
appels et de les terminer sans avoir à communiquer physiquement
avec le téléphone.
31. Format des paquets 1/2
Les données dans un piconet sont encodées en paquets. En général ils ont la forme suivante:
Format des paquets bluetooth.
Code d’accès
Le code d’Accès est utilisé pour synchroniser, le décalage de compensation et d’identification:
Format d’un code d’accès d’un packet Bluetooth.
Il y a 3 genre de codes d’accès. Le canal destinés au code d’accès (Channel Access Code or CAC) est utilisé pour identifié un piconet. Tous les pquets
envoyés à travers le canal d’un piconet comprend l’adresse du device Master. Le code d’accès (Access Code ou DAC) est utilisé pour signaler des
procédures comme une demande de paging ou pour lire la réponse d’un paging. Un DAC pour un paging pour l’adresse de la page du device.
Chaque device Bluetooth possède une adresse unique appelée BD_ADDR. Elle est constituée en deux parties: Un ID constructeur unique à travers le
monde and un second ID lié au device lui aussi unique et correspondant au modèle du produit réalisé par le constructeur (comme une adresse MAC). La
partie “Sync”Word” du code d’accès est dérivée de l’adresse BD_ADDR en utilisant des blocs de (64,30) avec un PN de sequence de 64-bits.
La section “preamble”est simplement fixée à “0101” ou “1010” dépendant soit du LSB du “sync word” suivant. S’il n’y a pas d’entête suivant le code d’accès
ne contiendra pas de zone “trailer”.
Payload
Il y a deux types de payload: voice et data. Les paquets SCO ont un champs destinés uniquement pour la voix, tandis que les paquets ACL ont un champs
destinés uniquement aux données.
32. Format des paquets 2/2
L’entête:
L’entête fait partie du packet et est utilisé par le cannal logique de contrôle des liaisons (LC)
Format d’un Header d’un paquet Bluetooth.
AM_ADDR: adresse temporaire assignée à un membre actif du piconet. Elle est utilisée dans tous
Paquets envoyés et reçus entre le maître (master) et les adresses esclave (slave). Si AM_ADDR
Est entièrement assigné à zéro cela permet de communiquer en boadcast vers tous les escalves.
TYPE: type de paquet. Il y a 12 types de packets pour chaque liaison physique SCO et ACL, et
4 types de controle générique pour les deux.
FLOW: pour le contôle des flux
ARQN: pour les handshaking (ack).
SEQN: contient un numéro de séquence pour l’ordre des paquets.
HEC: vérification de l’intégrité.
33. Installer la stack BlueTooth
Sous GNU LinuX
Site officiel:
Sous GNU Debian, Ubuntu ou Kubuntu tout est si facilement
http://www.bluez.org/
installable en quelques minutes:
Lien de téléchargement: # apt-cache search bluez
http://www.bluez.org/download.html
bluez-cups - Bluetooth printer driver for CUPS
bluez-hcidump - Analyses Bluetooth HCI packets
bluez-pcmcia-support - PCMCIA support files for BlueZ 2.0 Bluetooth tools
Téléchargement des packages officiels: bluez-pin - Bluetooth PIN helper with D-BUS support
bluez-utils - Bluetooth tools and daemons
kernel-patch-2.4-bluez - Linux Bluetooth protocol stack kernel patches
• bluez-libs-2.21.tar.gz
kernel-patch-2.6-bluez - Linux Bluetooth protocol stack kernel patches
• bluez-utils-2.21.tar.gz
libbluetooth1 - Library to use the BlueZ Linux Bluetooth stack
• bluez-pin-0.26.tar.gz libbluetooth1-dev - Development files for using the BlueZ Linux Bluetooth library
• bluez-firmware-1.0.tar.gz libsdp2 - Dummy package for BlueZ SDP library.
• bluez-hcidump-1.25.tar.gz libsdp2-dev - Dummy package for BlueZ SDP library development files.
• bluez-hciemu-1.2.tar.gz
Installation:
•./configure
•make
•sudo make install ou su puis make install
34. Fichiers importants
Une fois les packages de la stack Bluez installés, tout est prêt à l'emploi : les fichiers de config dans
/etc/bluetooth, les binaires dans /bin et les devices dans /dev/rfcommx (avec x compris
Entre 0 et 9 au minimum).
Fichier de configuration du Démon HCI
/etc/bluetooth/hcid.conf
Configuration of RFCOMM bindings : associate MAC/Channel to a rfcomm dev
/etc/bluetooth/rfcomm.conf
Bluetooth PIN code used in the auto pairing mode (le code par défaut étant 1234)
/etc/bluetooth/pin
Detail the auto PIN code used for each Bluetooth device MAC address
/etc/bluetooth/pincode
Saved link key used for crypt data and communicate with paired devices
Il contient la liste des adresses MAC des devices apairés avec notre piconet. Pour relire ce
fichier (binaire) il faut utiliser la structure de fichier définie dans le header bluetooth.h
/etc/bluetooth/link_key
(file:/usr/src/linux/include/net/bluetooth) :
typedef struct { __u8 b[6]; } __attribute__((packed)) bdaddr_t;
35. Utilisation 1/4
Configure Bluetooth connections
HCI = Host Control Interface
/bin/hcitool
Usage ex. : hcitool scan
Control and interrogate SDP local and remote servers
SDP = Service Discovery Protocol
/bin/sdptool
Usage ex.: sdptool browse 00:80:98:64:A6:CD
sdptool add --channel=4 SP
RFCOMM configuration utility
RFCOMM = protocol providing emulation of serial ports (RS232) over the L2CAP protocol.
/bin/rfcomm
Usage ex. : rfcomm connect /dev/rfcomm0 00:80:98:64:A6:CD 4
rfcomm listen /dev/rfcomm0 4
nb: concernant l'utilisation des devices /dev/rfcomm, il est recommandé d'utiliser le
démon udev qui crée à la volée les devices en cas de besoin.
36. Utilisation 2/4
Sniff HCI data communication
/sbin/hcidump
/sbin/hciconfig Configure Bluetooth devices
Dial-Up network daemon : implement LAN access over PPP RFCOMM connection
/bin/dund
/bin/pand PAN network daemon : implement PAN profile with BNEP protocol
/sbin/hcid Bluetooth Host Controller Interface daemon
/sbin/hciattach Attach serial devices via UART HCI
/bin/bluepin Bluetooth pairing tool called for asking pin code in the not auto user mode
/sbin/hciemu HCI Emulator
L2CAP ping tool
/bin/l2ping
L2CAP = Logical Link Control and Adaptation Protocol
/bin/l2test L2CAP test tool
/bin/hstest HeadSet test tool
/bin/rctest RFCOMM test tool
SCO test tool
/bin/scotest
SCO = Synchronous Connection-Oriented packet (used in TCS)
37. Utilisation 3/4
sdptool browse 00:07:3A:05:D5:07 (1)
(Récupération de la liste des profiles sur un device)
Service Name: Network Access Point
Browsing 00:07:3A:05:D5:07 ... Service Name: OBEX Object Push
Service RecHandle: 0x10005fa0
Service RecHandle: 0x10005f90
Service Class ID List:
Service Class ID List:
Service Name: SDP Server quot;Network Access Pointquot; (0x1116)
quot;OBEX Object Pushquot; (0x1105)
Service Description: Bluetooth service discovery server Protocol Descriptor List:
Protocol Descriptor List:
Service Provider: BlueZ quot;L2CAPquot; (0x0100)
quot;L2CAPquot; (0x0100)
Service RecHandle: 0x0 PSM: 15
quot;RFCOMMquot; (0x0003)
Service Class ID List: quot;BNEPquot; (0x000f)
Channel: 4
quot;SDP Serverquot; (0x1000) Version: 0x0100
quot;OBEXquot; (0x0008)
Protocol Descriptor List: SEQ16: 800 806
Profile Descriptor List:
quot;L2CAPquot; (0x0100) Profile Descriptor List:
quot;OBEX Object Pushquot; (0x1105)
PSM: 1 quot;Network Access Pointquot; (0x1116)
Version: 0x0100
Version: 0x0001 Version: 0x0100
Service Name: Public Browse Group Root Service Name: LAN Access Point Service Name: Dial-Up Networking
Service Description: Root of public group hierarchy Service RecHandle: 0x10005fc0 Service RecHandle: 0x10005fb0
Service Provider: BlueZ Service Class ID List: Service Class ID List:
Service RecHandle: 0x10005000 quot;LAN Access Using PPPquot; (0x1102) quot;Dialup Networkingquot; (0x1103)
Service Class ID List: Protocol Descriptor List: quot;Generic Networkingquot; (0x1201)
quot;Browse Group Descriptorquot; (0x1001) quot;L2CAPquot; (0x0100) Protocol Descriptor List:
quot;RFCOMMquot; (0x0003) quot;L2CAPquot; (0x0100)
Service Name: Serial Port Channel: 1 quot;RFCOMMquot; (0x0003)
Service RecHandle: 0x10005f80 Profile Descriptor List: Channel: 1
Service Class ID List: quot;LAN Access Using PPPquot; (0x1102) Profile Descriptor List:
quot;Serial Portquot; (0x1101) Version: 0x0100 quot;Dialup Networkingquot; (0x1103)
Protocol Descriptor List: Version: 0x0100
quot;L2CAPquot; (0x0100)
quot;RFCOMMquot; (0x0003)
Channel: 1
Profile Descriptor List:
quot;Serial Portquot; (0x1101)
Version: 0x0100
(1) just change with the correct MAC address.
38. Utilisation4/4
1. Lister les devices disponibles :
Service Name: Public Browse Group
# hcitool scan
Root
Scanning ...
Service Description: Root of public browse
00:13:70:E1:DC:66 Nokia 6230
hierarchy
00:80:98:64:60:35 computer2-0
Service Provider: BlueZ
Service RecHandle: 0x804d008
2. Lister des profiles disponible sur un device :
Service Class ID List:
quot;Browse Group Descriptorquot; (0x1001)
# sdptool browse 00:80:98:64:60:35
Language Base Attr List:
Browsing 00:80:98:64:60:35 ...
code_ISO639: 0x656e
encoding: 0x6a
Service Name: SDP Server
base_offset: 0x100
Service Description: Bluetooth service 3. connexion avec le device trouvé (ce dernier doit
discovery server écouter sur le même canal) :
Service Provider: BlueZ
Service RecHandle: 0x0 # rfcomm connect /dev/rfcomm0 00:80:98:64:60:35 4
Service Class ID List: Connected /dev/rfcomm0 to 00:80:98:64:60:35 on
quot;SDP Serverquot; (0x1000) channel 4
Protocol Descriptor List: Press CTRL-C for hangup
quot;L2CAPquot; (0x0100)
PSM: 1 Le serveur écoutait avec la commande suivante :
Version: 0x0001
Language Base Attr List: # rfcomm listen /dev/rfcomm0 4
code_ISO639: 0x656e
encoding: 0x6a
base_offset: 0x100
39. Autres outils
Obextool : OBEX-OPP server.
Pairingd : Wifi/Bluetooth pairing authorization server management.
CTP server for TCS protocol connected with hphone H323 VoIP server.
Le deamon Bluetooth pour KDE (Kbluetooth).
http://www.xmailserver.org/ussp-push.html
http://rosko.net/osp/
http://rosko.net/osp/
http://www.geektown.de/devel/blue-cmd.pl
http://www.geektown.de/devel/
http://freshmeat.net/search/?q=bluetooth§ion=projects&Go.x=0&Go.y=0
40. Programmation 1/2
include <s t d i o . h>
#include <s t d l i b . h>
#include <uni s td . h>
#include <sys / s o c k e t . h>
#include <blue to o th / blue to o th . h>
Ce premier listing réserve les #include <blue to o th / hc i . h>
#include <blue to o th / h c i l i b . h>
ressources BlueTooth, puis effectue int main ( int argc , char argv )
{
i n q u i r y i n f o i i = NULL;
un scan des devices alentours en int max rsp , num rsp ;
int dev id , sock , len , f l a g s ;
affichant leurs noms. int i ;
char addr [ 1 9 ] = { 0 } ;
char name [ 2 4 8 ] = { 0 } ;
dev id = h c i g e t r o u t e (NULL) ;
typedef struct { sock = hc i open dev ( dev id ) ;
uint8tb[6]; i f ( dev id < 0 | | sock < 0) {
pe r r o r ( ” opening s o c k e t ” ) ;
} a t t r i b u t e ( ( packed ) ) exit(1);
bdaddr t ; }
l en = 8 ;
max rsp = 2 5 5 ;
f l a g s = IREQ CACHE FLUSH;
i i = ( i n q u i r y i n f o )mal loc (max rsp s
izeof ( i n q u i r y i n f o ) ) ;
num rsp = h c i i n q u i r y ( dev id , len , max rsp
, NULL, &i i , f l a g s ) ;
i f ( num rsp < 0 ) pe r r o r ( ” h c i i n q u i r y
”);
for ( i = 0 ; i < num rsp ; i++) {
ba 2 s t r (&( i i+i )−>bdaddr , addr ) ;
memset (name , 0 , s izeof (name ) ) ;
i f ( hc i r ead r emo t e name ( sock , &( i i+i
)−>bdaddr , s izeof (name ) ,
name , 0) < 0)
s t r cpy (name , ” [ unknown ] ” ) ;
p r i n t f ( ”%s %s n” , addr , name ) ;
42
}
free(ii);
c l o s e ( sock ) ;
return 0 ;
}
41. Programmation 2/2
#include <s t d i o . h>
#include <uni s td . h>
#include <sys / s o c k e t . h>
L'utilisation des connexions RFCOMM #include <blue to o th / blue to o th . h>
#include <blue to o th /rfcomm . h>
fonctionne sur le même principes que les int main ( int argc , char argv )
{
struct s o c k addr r c l o c addr = { 0 } , rem addr
sockets BSD. ={0};
char buf [ 1 0 2 4 ] = { 0 } ;
int s , c l i e n t , by t e s r e ad ;
int opt = s izeof ( rem addr ) ;
La seule différence est la structure // a l l o c a t e s oc k e t
s = s o c k e t (AF BLUETOOTH, SOCK STREAM,
d'adresse ; les fonctions de gestion du BTPROTORFCOMM) ;
// bind s oc k e t to por t 1 of the f i r s t a v a i
byte order sont toujours d'actualité. lable
// l o c a l b l u e t o o t h adapt e r
l o c addr . r c f ami l y = AF BLUETOOTH;
l o c addr . r c bdaddr = BDADDRANY;
l o c addr . r c channe l = ( u i n t 8 t ) 1 ;
L'exemple suivant montre comment bind ( s , ( struct sockaddr )&lo c addr , s izeof (
l o c addr ) ) ;
établir une connexion via une socket // put s oc k e t int o l i s t e n i n g mode
listen(s,1);
RFCOMM, en transférant des données // ac c ept one conne c t ion
c l i e n t = a c c ept ( s , ( struct sockaddr )&rem
et en se déconnectant. addr , &opt ) ;
ba 2 s t r ( &rem addr . rc bdaddr , buf ) ;
f p r i n t f ( s tde r r , ” accepted conne c t ion
from %s n” , buf ) ;
memset ( buf , 0 , s izeof ( buf ) ) ;
Pour simplifier le code source, l'adresse // read data from the c l i e n t
by t e s r e ad = read ( c l i e n t , buf , s izeof (
MAC du client a été hardcodé. buf ) ) ;
i f ( by t e s r e ad > 0 ) {
p r i n t f ( ” r e c e i v e d [%s ] n” , buf ) ;
}
// c l o s e conne c t ion
close(client);
close(s);
return 0 ;
}