24.4. Bluetooth

24.4.1. Introduction

Bluetooth® est une technologie sans fil pour créer des réseaux personnels sans fils fonctionnant dans la bande 2.4 GHz ne nécessitant pas d'autorisation, avec une portée de 10 mètres. Les réseaux étant généralement composés de périphériques nomades comme les téléphones portables, les assistants personnels et les ordinateurs portables. Contrairement à l'autre technologie sans fil, Wi-Fi, Bluetooth offre un niveau plus élevé de profils de service, par exemple des serveurs de fichiers semblables à FTP, ``file pushing'', transport de la voix, émulation de lignes séries, et bien plus.

La pile Bluetooth sous FreeBSD utilise le système Netgraph (voir netgraph(4)). Une large gamme d'adaptateurs USB Bluetooth sont supportés par le pilote ng_ubt(4). Les périphériques Bluetooth basés sur le circuit Broadcom BCM2033 sont supportés par les pilotes ubtbcmfw(4) et ng_ubt(4). La carte 3Com Bluetooth PC Card 3CRWB60-A demande le pilote ng_bt3c(4). Les périphériques Bluetooth de type série et UART sont supportés via les pilotes sio(4), ng_h4(4) et hcseriald(8). Cette section décrit l'utilisation d'un adaptateur USB Bluetooth. Le support Bluetooth est disponible sur les systèmes 5.0 et suivants.

24.4.2. Branchement du périphérique

Par défaut les pilotes de périphériques Bluetooth sont disponibles sous la forme de modules du noyau. Avant de brancher le périphérique, vous devrez charger le pilote dans le noyau:

# kldload ng_ubt

Si le périphérique Bluetooth est présent au démarrage du système, chargez le module à partir de /boot/loader.conf:

ng_ubt_load="YES"

Branchez votre clé USB. Une sortie semblable à celle-ci devrait s'afficher sur la console (ou dans les journaux du système):

ubt0: vendor 0x0a12 product 0x0001, rev 1.10/5.25, addr 2
ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2
ubt0: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3,
      wMaxPacketSize=49, nframes=6, buffer size=294

Copiez /usr/share/examples/netgraph/bluetooth/rc.bluetooth à un emplacement adapté, comme /etc/rc.bluetooth. Cette procédure est utilisée pour démarrer et arrêter la pile Bluetooth. C'est une bonne idée d'arrêter la pile avant de débrancher le périphérique, mais ce n'est pas (généralement) fatal. Quand la pile démarre, vous devriez avoir des messages similaires aux suivants:

# /etc/rc.bluetooth start ubt0
BD_ADDR: 00:02:72:00:d4:1a
Features: 0xff 0xff 0xf 00 00 00 00 00
<3-Slot> <5-Slot> <Encryption> <Slot offset>
<Timing accuracy> <Switch> <Hold mode> <Sniff mode>
<Park mode> <RSSI> <Channel quality> <SCO link>
<HV2 packets> <HV3 packets> <u-law log> <A-law log> <CVSD>
<Paging scheme> <Power control> <Transparent SCO data>
Max. ACL packet size: 192 bytes
Number of ACL packets: 8
Max. SCO packet size: 64 bytes
Number of SCO packets: 8

24.4.3. Interface de contrôle de l'hôte (HCI)

L'interface de contrôle de l'hôte (HCI) fournit une interface de commande pour le contrôleur de la bande de base et le gestionnaire de liaisons, et l'accès à l'état du matériel et aux registres de contrôle. Cette interface offre une méthode uniforme d'accès aux fonctions de la bande de base Bluetooth. La couche HCI de l'hôte échange des données et des commandes avec le firmware HCI du matériel Bluetooth. Le pilote de la couche de transport du contrôleur d'hôte (i.e. le bus physique) fournit aux deux couches HCI la possibilité d'échanger des informations entre elles.

Un seul noeud Netgraph de type hci est créé pour un périphérique Bluetooth. Le noeud HCI est normalement connecté au noeud du pilote Bluetooth (flux descendant) et au noeud L2CAP (flux montant). Toutes les opérations HCI doivent être effectuées sur le noeud HCI et non pas sur le noeud du pilote de périphérique. Le nom par défaut pour le noeud HCI est ``devicehci''. Pour plus de détails consultez la page de manuel ng_hci(4).

Une des tâches les plus courantes est la recherche de périphériques Bluetooth dans le voisinage hertzien. Cette opération est appelée inquiry (enquête, recherche). Cette recherche et les autres opérations relatives à HCI sont effectuées par l'utilitaire hccontrol(8). L'exemple ci-dessous montre comment déterminer quels périphériques Bluetooth sont dans le voisinnage. Vous devriez obtenir une listes de périphériques au bout de quelques secondes. Notez qu'un périphérique distant ne répondra à la recherche que s'il est placé dans le mode discoverable.

% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
       BD_ADDR: 00:80:37:29:19:a4
       Page Scan Rep. Mode: 0x1
       Page Scan Period Mode: 00
       Page Scan Mode: 00
       Class: 52:02:04
       Clock offset: 0x78ef
Inquiry complete. Status: No error [00]

BD_ADDR est l'adresse unique d'un périphérique Bluetooth, similaire à l'adresse MAC d'une carte réseau. Cette adresse est nécessaire pour communiquer avec un périphérique. Il est possible d'assigner un nom humainement compréhensible à l'adresse BD_ADDR. Le fichier /etc/bluetooth/hosts contient des informations concernant les hôtes Bluetooth connus. L'exemple suivant montre comment obtenir le nom qui a été assigné au périphérique distant:

% hccontrol -n ubt0hci remote_name_request 00:80:37:29:19:a4
BD_ADDR: 00:80:37:29:19:a4
Name: Pav's T39

Si vous effectuez une recherche sur un périphérique Bluetooth distant, vous devriez trouver votre ordinateur en tant que ``votre.machine.nom (ubt0)''. Le nom affecté au périphérique local peut être modifié à tout moment.

Le système Bluetooth fournit une connexion point à point (seules deux matériels Bluetooth sont concernés), ou une connexion point à multipoints. Dans le cas d'une connexion point à multipoints, la connexion est partagés entre plusieurs périphériques Bluetooth. L'exemple suivant montre comment obtenir la liste des connexions en bande de base actives pour le périphérique local:

% hccontrol -n ubt0hci read_connection_list
Remote BD_ADDR    Handle Type Mode Role Encrypt Pending Queue State
00:80:37:29:19:a4     41  ACL    0 MAST    NONE       0     0 OPEN

Une manipulation de la connexion est utile quand la fin d'une connexion en bande de base est nécessaire. Notez qu'il n'est normalement pas nécessaire de le faire à la main. La pile mettra fin automatiquement aux connexions en bande de base inactives.

# hccontrol -n ubt0hci disconnect 41
Connection handle: 41
Reason: Connection terminated by local host [0x16]

Référez-vous à la commande hccontrol help pour une liste complète des commandes HCI disponibles. La plupart des commandes HCI ne nécessitent pas les privilèges du super-utilisateur.

24.4.4. Protocole d'adaptation et de contrôle de lien logique (L2CAP)

Le protocole d'adaptation et de contrôle de lien logique (L2CAP) fournit des services orientés connexion ou non aux protocoles de niveaux supérieurs, et cela avec des possibilités de multiplexage de protocoles, de segmentation et de réassemblage. L2CAP permet aux applications et aux protocoles de niveaux supérieurs de transmettre et recevoir des paquets L2CAP d'une taille allant jusqu'à 64 Ko.

L2CAP est basé sur le concept de canaux. Un canal est une connexion logique au sommet de la connexion en bande de base. Chaque canal est attaché à un protocole suivant le schéma plusieurs-vers-un. Plusieurs canaux peuvent être attachés au même protocole, mais un canal ne peut être attachés à plusieurs protocoles. Chaque paquet L2CAP reçu sur un canal est dirigé vers le protocole de niveau supérieur approprié. Plusieurs canaux peuvent partager la même connexion en bande de base.

Un seul noeud Netgraph de type l2cap est créé pour un périphérique Bluetooth. Le noeud L2CAP est normalement connecté au noeud HCI Bluetooth (flux descendant) et aux noeuds des ``sockets'' Bluetooth (flux montant). Le nom par défaut pour le noeud L2CAP est ``device2cap''. Pour plus de détails consultez la page de manuel ng_l2cap(4).

Une commande utile est l2ping(8), qui peut être utilisée pour ``pinguer'' les autres périphériques. Certaines implémentations de Bluetooth peuvent ne pas renvoyer toutes les données qui leur sont envoyées, aussi 0 bytes dans ce qui suit est normal.

# l2ping -a 00:80:37:29:19:a4
0 bytes from 0:80:37:29:19:a4 seq_no=0 time=48.633 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=1 time=37.551 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=2 time=28.324 ms result=0
0 bytes from 0:80:37:29:19:a4 seq_no=3 time=46.150 ms result=0

L'utilitaire l2control(8) est employé pour effectuer diverses opérations sur les noeuds L2CAP. Cet exemple montre comment obtenir la liste des connexions logiques (canaux) et la liste des connexions en bande de base pour le périphérique local:

% l2control -a 00:02:72:00:d4:1a read_channel_list
L2CAP channels:
Remote BD_ADDR     SCID/ DCID   PSM  IMTU/ OMTU State
00:07:e0:00:0b:ca    66/   64     3   132/  672 OPEN
% l2control -a 00:02:72:00:d4:1a read_connection_list
L2CAP connections:
Remote BD_ADDR    Handle Flags Pending State
00:07:e0:00:0b:ca     41 O           0 OPEN

Un autre outil de diagnostic est btsockstat(1). Il effectue un travail similaire à celui de netstat(1), mais relatif aux structures de données réseau Bluetooth. L'exemple ci-dessous montre la même connexion logique que l2control(8) ci-dessus.

% btsockstat
Active L2CAP sockets
PCB      Recv-Q Send-Q Local address/PSM       Foreign address   CID   State
c2afe900      0      0 00:02:72:00:d4:1a/3     00:07:e0:00:0b:ca 66    OPEN
Active RFCOMM sessions
L2PCB    PCB      Flag MTU   Out-Q DLCs State
c2afe900 c2b53380 1    127   0     Yes  OPEN
Active RFCOMM sockets
PCB      Recv-Q Send-Q Local address     Foreign address   Chan DLCI State
c2e8bc80      0    250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3    6    OPEN

24.4.5. Protocole RFCOMM

Le protocole RFCOMM permet l'émulation du port série au-dessus du protocole L2CAP. Le protocole est basé sur la norme ETSI TS 07.10. RFCOMM est un protocole de transport simple, avec les dispositions supplémentaires pour émuler les 9 circuits (signaux) d'un port série RS232 (EIATIA-232-E). Le protocole RFCOMM supporte jusqu'à 60 connexions simultanées (canaux RFCOMM) entre deux périphériques Bluetooth.

Dans le cas de RFCOMM, l'établissement d'une communication implique deux applications tournant sur des périphériques différents (les extrémités de la communication) avec un segment de communication entre eux. RFCOMM est prévu pour couvrir les applications faisant usage des ports séries des périphériques sur lesquels elles résident. Le segment de communication est une liaison Bluetooth d'un périphérique vers un autre (connexion directe).

RFCOMM est seulement concerné par la connexion entre périphériques dans le cas d'un raccordement direct, ou entre le périphérique et un modem dans le cas d'un réseau. RFCOMM peut supporter d'autres configurations, comme les modules qui communiquent par l'intermédiaire de la technologie sans fil Bluetooth d'un côté et utilise une interface câblée de l'autre côté.

Sous FreeBSD, le protocole RFCOMM est implémenté au niveau de la couche des ``sockets'' Bluetooth.

24.4.6. Couplage des périphériques

Par défaut, une communication Bluetooth n'est pas authentifiée, et n'importe quel périphérique peut parler avec n'importe quel autre périphérique. Un périphérique Bluetooth (par exemple un téléphone portable) peut choisir de demander une authentification pour fournir un service particulier (par exemple un service de connexion téléphonique). L'authentification Bluetooth est généralement effectuée avec des codes PIN. Un code PIN est une chaîne ASCII d'une longueur de 16 caractères. L'utilisateur doit entrer le même code PIN sur les deux périphériques. Une fois que l'utilisateur a entré le code PIN, les deux périphériques génèrent une clé de liaison (link key). Ensuite la clé peut être enregistrée soit dans les périphériques eux-mêmes ou sur un moyen de stockage non-volatile. La fois suivante les deux périphériques utiliseront la clé précédemment générée. La procédure décrite est appelée couplage. Si la clé de liaison est perdue par un des périphériques alors l'opération de couplage doit être répétée.

Le ``daemon'' hcsecd(8) est responsable de la gestion de toutes les requêtes d'authentification Bluetooth. Le fichier de configuration par défaut est /etc/bluetooth/hcsecd.conf. Un exemple de section pour un téléphone portable avec un code PIN arbitraire de ``1234'' est donné ci-dessous:

device {
        bdaddr  00:80:37:29:19:a4;
        name    "Pav's T39";
        key     nokey;
        pin     "1234";
      }

Il n'y pas de limitation sur les codes PIN (en dehors de la longueur). Certains périphériques (comme les casques-micro Bluetooth) peuvent avoir un code PIN définitivement fixé. Le paramètre -d force le ``daemon'' hcsecd(8) à rester en tâche de fond, il est donc aisé de voir ce qu'il se passe. Configurez le périphérique distant pour recevoir le couplage et initier la connexion Bluetooth vers le périphérique distant. Le périphérique distant devrait annoncer que le couplage a été accepté, et demander le code PIN. Entrez le même code PIN que celui que vous avez dand le fichier hcsecd.conf. Maintenant votre PC et le périphérique distant sont couplés. Alternativement, vous pouvez initier le couplage sur le périphérique distant. Ce qui suit est une partie de la sortie du ``daemon'' hcsecd:

hcsecd[16484]: Got Link_Key_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', link key doesn't exist
hcsecd[16484]: Sending Link_Key_Negative_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Got PIN_Code_Request event from 'ubt0hci', remote bdaddr 0:80:37:29:19:a4
hcsecd[16484]: Found matching entry, remote bdaddr 0:80:37:29:19:a4, name 'Pav's T39', PIN code exists
hcsecd[16484]: Sending PIN_Code_Reply to 'ubt0hci' for remote bdaddr 0:80:37:29:19:a4

24.4.7. Le protocole de découverte de service (SDP)

Le protocole de découverte de service (SDP) offre aux applications clientes les moyens de découvrir l'existence des services fournis par les applications serveurs ainsi que les propriétés (attributs) de ces services. Les attributs d'un service comprennent le type ou la classe du service offert et le mécanisme ou l'information sur le protocole nécessaire pour utiliser le service.

Le SDP implique la communication entre un serveur SDP et un client SDP. Le serveur maintient une liste d'enregistrements de services qui décrit les caractéristiques des services associés avec le serveur. Chaque enregistrement de service contient l'information sur un seul serveur. Un client peut récupérer l'information à partir d'un enregistrement de service maintenu par le serveur SDP en émettant une requête SDP. Si le client, ou une application associée avec le client, décide d'utiliser un service, il doit ouvrir une connexion séparée avec le fournisseur du service afin d'utiliser ce service. Le SDP fournit un mécanisme pour découvrir les services et leur attributs, mais n'offre pas de mécanisme pour utiliser ces services.

Généralement, un client SDP recherche les services sur la base de caractéristiques de services désirées. Cependant, il est parfois désirable de découvrir quel type de services sont décrits par les enregistrements de services d'un serveur SDP sans aucune information préalable sur les services. Ce processus de recherche des services offerts est appelé navigation (``browsing'').

Le serveur SDP Bluetooth sdpd(8) et le client en ligne de commande sdpcontrol(8) font partie de l'installation FreeBSD standard. L'exemple suivant montre comment effectuer un requête de navigation (``browse'') SDP:

% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
        Service Discovery Server (0x1000)
Protocol Descriptor List:
        L2CAP (0x0100)
                Protocol specific parameter #1: u/int/uuid16 1
                Protocol specific parameter #2: u/int/uuid16 1

Record Handle: 0x00000001
Service Class ID List:
        Browse Group Descriptor (0x1001)

Record Handle: 0x00000002
Service Class ID List:
        LAN Access Using PPP (0x1102)
Protocol Descriptor List:
        L2CAP (0x0100)
        RFCOMM (0x0003)
                Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
        LAN Access Using PPP (0x1102) ver. 1.0

... et ainsi de suite. Remarquez que chaque service a une liste d'attributs (canal RFCOMM par exemple). En fonction du service vous pourrez avoir besoin de prendre note de certains de ces attributs. Certaines implémentations Bluetooth ne supportent pas les requêtes de navigation et peuvent renvoyer une liste vide. Dans ce cas il est possible de chercher un service spécifique. L'exemple ci-dessous montre comment chercher le service OBEX Object Push (OPUSH):

% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH

Offrir des services sous FreeBSD aux clients Bluetooth se fait à l'aide du serveur sdpd(8):

# sdpd

L'application serveur locale qui désire offrir un service Bluetooth à des clients distants enregistrera le service auprès du ``daemon'' SDP local. Un exemple d'une telle application est rfcomm_pppd(8). Une fois démarré, il enregistrera un service de réseau local Bluetooth auprès du serveur SDP local.

La liste des services enregistrés auprès du serveur SDP local peut être obtenue en émettant une requête de navigation (``browse'') SDP par l'intermédiaire du canal de contrôle:

# sdpcontrol -l browse

24.4.8. Les profils Dial-Up Networking (DUN) et accès au réseau local avec PPP (LAN)

Le profil Dial-Up Networking (DUN) est principalement utilisé avec les modems et les téléphones portables. Les cas de figure couverts par ce profil sont les suivants:

• Utilisation d'un téléphone portable ou d'un modem par un ordinateur comme modem sans fil pour se connecter à un serveur d'accès Internet, ou pour l'utilisation de services accessibles par téléphone;

• Utilisation d'un téléphone portable ou d'un modem par un ordinateur pour recevoir des appels avec transmission de données.

Le profil d'accès au réseau local avec PPP (LAN) peut être utilisé dans les situations suivantes:

• Accès au réseau local pour un périphérique Bluetooth;

• Accès au réseau local pour plusieurs périphériques Bluetooth;

• Liaison PC à PC (en utilisant le protocole PPP sur une émulation de câble série).

Sous FreeBSD les deux profils sont implémentés par ppp(8) et rfcomm_pppd(8)--un ``wrapper'' convertit la connexion Bluetooth RFCOMM en quelque chose d'utilisable par PPP. Avant qu'un profil ne soit utilisable, un nouveau label doit être créé dans le fichier /etc/ppp/ppp.conf. Consultez la page de manuel rfcomm_pppd(8) pour des exemples.

Dans l'exemple suivant rfcomm_pppd(8) sera employé pour ouvrir un connexion RFCOMM avec le périphérique distant avec une adresse BD_ADDR 00:80:37:29:19:a4 sur un canal DUN RFCOMM. Le numéro de canal RFCOMM réel sera obtenu du périphérique distant par l'intermédiaire de SDP. Il est possible de préciser le canal RFCOMM à la main, dans ce cas rfcomm_pppd(8) n'émettra pas de requête SDP. Utilisez sdpcontrol(8) pour trouver le canal RFCOMM sur le périphérique distant.

# rfcomm_pppd -a 00:80:37:29:19:a4 -c -C dun -l rfcomm-dialup

Afin de fournir un service d'accès au réseau local avec PPP, le serveur sdpd(8) doit être en fonctionnement. Une nouvelle entrée pour les clients du réseau local doit être créée dans le fichier /etc/ppp/ppp.conf. Consultez la page de manuel rfcomm_pppd(8) pour des exemples. Enfin, lancez le serveur RFCOMM PPP sur un numéro de canal RFCOMM valide. Le serveur RFCOMM PPP enregistrera automatiquement un service Bluetooth LAN auprès du ``daemon'' SDP local. L'exemple ci-dessous montre comment démarrer le serveur RFCOMM PPP:

# rfcomm_pppd -s -C 7 -l rfcomm-server

24.4.9. Le profil OBEX Object Push (OPUSH)

OBEX (échange d'objets) est un protocole très largement utilisé pour les tranferts de fichiers entre périphériques mobiles. Son utilisation principale se trouve dans les communications par infrarouge, où il est utilisé pour le tranfert des fichiers entre ordinateurs portables ou PDAs, et pour envoyer des cartes de visite électronique ou des éléments d'agenda entre téléphones portables et d'autres périphériques disposant d'applications de gestion d'informations personnelles (PIM).

Le serveur et le client OBEX sont implémentés dans le logiciel tierce-partie obexapp, qui est disponible sous la forme du logiciel porté comms/obexapp.

Le client OBEX est employé pour ``pousser'' et/ou ``tirer'' des objets du serveur OBEX. Un objet peut être, par exemple, une carte de visite ou un rendez-vous. Le client OBEX peut obtenir un numéro de canal RFCOMM d'un périphérique distant par l'intermédiaire de SDP. Cela peut être fait en spécifiant le nom du service plutôt que le numéro du canal RFCOMM. Les noms de service supportés sont: IrMC, FTRN et OPUSH. Il est possible de préciser le canal RFCOMM par un nombre. Un exemple de session OBEX est présenté ci-dessous, où l'objet information du périphérique d'un téléphone portable est récupéré, et un nouvel objet (carte de visite) est envoyé dans le répertoire du téléphone.

% obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get telecom/devinfo.txt devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)

Afin de fournir le service OBEX Object Push, le serveur sdpd(8) doit tourner. Un dossier racine où tous les objets entrant seront stockés doit être créé. Le chemin d'accès par défaut du répertoire racine est /var/spool/obex. Le serveur OBEX enregistrera automatiquement le service OBEX Object Push auprès du ``daemon'' SDP local. L'exemple ci-dessous montre comment démarrer le serveur OBEX:

# obexapp -s -C 10

24.4.10. Le profil port série (SPP)

Le profil port série (SPP) permet aux périphériques Bluetooth d'émuler un câble série RS232 (ou similaire). Ce profil traite avec les applications classiques en utilisant Bluetooth comme un câble de remplacement, à travers une abstraction de port série virtuel.

L'utilitaire rfcomm_sppd(1) implémente le profil port série. Un pseudo terminal est utilisé comme abstraction de port série virtuel. L'exemple ci-dessous montre comment se connecter à un service port série d'un périphérique distant. Notez que vous n'avez pas besoin d'indiquer un canal RFCOMM -- rfcomm_sppd(1) peut l'obtenir auprès du périphérique distant via SDP. Si vous désirez forcer cela, spécifiez un canal RFCOMM sur la ligne de commande.

# rfcomm_sppd -a 00:07:E0:00:0B:CA -t /dev/ttyp6
rfcomm_sppd[94692]: Starting on /dev/ttyp6...

Une fois connecté, le pseudo-terminal peut être utilisé comme un port série:

# cu -l ttyp6

24.4.11. Dépannage

# hccontrol -n ubt0hci write_node_role_switch 0