====== Faites communiquer votre téléphone mobile avec votre Linux sous KDE ======

Cet article est paru dans le magazine [[http://www.lpmagazine.org/|Linux+ DVD]] (11/2007)

Merci encore à Joanna Bonka (j'espère que j'écris bien son nom :) ), rédactrice en chef du magazine Linux+ DVD, qui a accepté que je reproduise l'article pour le [[http://wiki.alionet.org/doku.php|Wiki d'Alionet]] et également pour [[http://www.linuxpedia.fr|Linuxpedia]]
\\
\\
===== Introduction =====

Dans notre société actuelle, nous sommes de plus en plus constamment connectés avec le reste du monde. Téléphones, PC, assistants personnels (PDA), tous ces équipements font que nous sommes en permanence en contact avec notre famille, nos amis, nos collègues de travail, mais également avec le monde entier. Et pour cause, Internet, les messageries électroniques et instantanées, les SMS/MMS... sont autant de moyens que nous avons avec nous pour communiquer. Mais nous ne sommes pas les seuls à pouvoir communiquer. Tous nos appareils électroniques peuvent communiquer entre eux. Nos téléphones mobiles ou PDA peuvent « dialoguer » avec nos PC, et inversement.

Les téléphones mobiles actuels disposent de nombreuses fonctionnalités autres que la simple émission/réception d'appels. Agenda, appareil photo numérique (APN) ou encore lecteur MP3 sont autant de fonctions qui équipent nos téléphones mobiles. Mais les capacités de stockage des téléphones restent limitées bien qu'il soit possible de les étendre avec des cartes mémoires de type MMC ou MicroSD par exemple. Ainsi, il nous sera difficile de conserver un grand nombre de photos (ou vidéos) et de fichiers musicaux (obtenus légalement bien sûr ;) ) sur notre téléphone. Il nous faut donc pouvoir les stocker là où il y a de la place. Une solution serait de changer la carte mémoire une fois pleine, mais disposer d'une multitude de cartes mémoires à échanger en fonction de ses besoins n'est pas très pratique. Où disposons-nous de suffisamment d'espace de stockage pour pouvoir conserver photos, vidéos, musiques... ? La réponse est simple : nos ordinateurs. Les disques durs de nos PC ont en effet des capacités pouvant aller jusqu'à 1 To (terra-octet), nous offrant ainsi suffisamment de place pour y conserver nos fichiers. 
En règle générale, lorsque l'on achète un téléphone mobile de dernière génération, celui-ci est livré avec un logiciel permettant de pouvoir réaliser les différentes tâches présentées précédemment. Mais, parce qu'il faut bien un mais (le monde n'étant pas parfait), ces logiciels sont des logiciels Windows. Heureusement pour nous, utilisateurs de Linux, notre système d'exploitation dispose de tous les outils adéquats.
Mais qu'en est-il de la connexion entre le téléphone mobile et le PC ? La solution du câble USB reliant les deux équipements est tout à fait possible. Mais, bien qu'offrant des débits importants, ce n'est pas la solution la plus pratique à mettre en oeuvre, ni même la plus esthétique – les câbles étant souvent source de contraintes. Qui aime voir se balader un câble dans une pièce, ou encore qui aime brancher/débrancher le cordon sur le téléphone à chaque fois que l'on en a besoin. Les technologies sans fil permettent de pallier ces contraintes. Et par technologies sans fil, nous parlons ici du Bluetooth qui équipe la majorité de nos téléphones mobiles.
\\
\\
\\
===== Bluetooth, vous avez dit Bluetooth ? =====

==== Présentation ====


Créé en 1994 par le fabricant suédois Ericsson, le Bluetooth est un protocole de communication sans fil, défini en 1999 par le consortium Special Interest Group (SIG). Ce dernier a été créé en 1998 à l'initiative de grandes entreprises des télécommunications et regroupe aujourd'hui des sociétés comme Agere, Ericsson, IBM, Intel, Motorola, Nokia ou encore Toshiba.

{{:multimedia:bluetooth_logo.jpg|Logo Bluetooth}}

//Figure 1 : Le logo Bluetooth//

\\

Le Bluetooth permet de créer des Personal Area Network (ou PAN), reliant ainsi des équipements entre eux sans liaison filaire, en général sur une dizaine de mètres (avec un émetteur de classe II et jusqu'à un peu moins de 100m avec un émetteur de classe I) : ordinateurs personnels, PDA, téléphones, imprimantes, claviers, souris ou encore oreillettes...

^ Classe  ^ Puissance (Affaiblissement)       ^ Portée         ^
|    I    | 100 mW (20 dBm)                   | 100 mètres     |
|    II    | 2,5 mW (4 dBm)                   | 15-20 mètres   |
|    III    | 1 mW (0 dBm)                    | 10 mètres      |

//Tableau 1 : Les classes d'émetteurs définit par le standard Bluetooth//

\\

Pour sa communication, le Bluetooth utilise des ondes radios dans la bande de fréquence 2.4 GHz appelée ISM (Industrial Scientific and Medical) band (libérée dans la plupart des pays, sans s'affranchir de droits de licence), dans la plage 2.4-2.4835 GHz. Mais cette plage étant libre, elle est soumise aux interférences dues à d'autres protocoles comme le WiFi, le HomeRF... qui utilisent également cette bande de fréquence.

Heureusement, le Bluetooth a été pensé pour contrer ces interférences. En effet, le Bluetooth utilise ce que l'on nomme le frequency hopping (ou saut de fréquence). En quoi cela consiste-t-il ? En fait, la plage de fréquence est découpée en canaux utilisés aléatoirement par le Bluetooth. Ce dernier change de canal fréquemment (toutes les 625 ms en mode connecté, ou toutes les 312,5 ms lors d'une tentative de connexion), et en utilise en tout et pour tout 79. Ainsi, si un paquet n'arrive pas à destination à cause d'une interférence, il sera réémis sur une fréquence différente et aura par conséquent plus de chance d'arriver à son destinataire.

Question sécurité, le Bluetooth n'est pas en reste. En effet, la sécurisation passe par deux étapes : l'identification et l'authentification (avec l'échange d'un code PIN ou Personnal Identification Number). Les données peuvent être cryptées en créant des clés de liaison partagées par les deux périphériques, c'est le pairing ou couplage.
\\
\\
==== Principe de la communication ====

Le Bluetooth est basé sur une architecture maître/esclave. Un réseau, constitué d'un périphérique et de tous les périphériques présents dans son champ d'action est appelé un « piconet ».

Un piconet se crée instantanément et automatiquement lorsque plusieurs appareils Bluetooth sont dans le même rayon. Il est constitué d'un maître et au maximum de 7 esclaves actifs (ce nombre passe à 255 en mode « parked »).

{{:bluetoothpiconet.png|Un piconet}}

//Figure 2 : Un piconet constitué d'un maître, de 3 esclaves actifs et de 2 esclaves « parked » (source : Wikipedia)//

\\

En effet, les adresses logiques des périphériques d'un piconet sont codées sur 3 bits, ce qui permet ainsi un maximum de 23 = 8 appareils.

Concernant les appareils en mode « parked », ils ne possèdent pas d'adresse physique sur le réseau Bluetooth, ils sont simplement synchronisés.

Contrairement à ce que l'on pourrait croire, un maître ne peut communiquer avec tous ses esclaves en même temps. Il commute très rapidement de l'un à l'autre donnant l'impression d'une communication simultanée avec tous les esclaves dans son rayon.

Par ailleurs, deux piconets peuvent être relier ensemble. En effet, les périphériques esclaves peuvent avoir plusieurs maîtres. Ce qui forme un scatternet (figure 3).

{{:bluetoothscatternet.png|Un scatternet}}

//Figure 3 : Un scatternet (source : Wikipedia)//

\\

On distingue deux sitations pour pouvoir communiquer :

  * Les périphériques ne se connaissent pas : dans ce cas, le périphérique initiateur de la communication doit d'abord faire une recherche des périphériques qui l'entourent (phase d'inquisition ou inquiry). A la suite de quoi, il dispose d'une liste de périphériques de son voisinage. Puis, il doit rechercher les services proposés par les autres périphériques, la liste est alors présentée à l'utilisateur ou il se connecte seul au périphérique distant adapté. Les périphériques peuvent être couplés (pairing) en échangeant un code PIN (ceci reste optionnel).

  * Les périphériques se connaissent déjà : dans cette situation, la connexion entre les deux périphériques peut se faire immédiatement. On ne contrôle, cependant, pas la disponibilité du périphérique distant, cequi peut engendrer une tentative de connexion de plusieurs dizaines de secondes avant de renvoyer un message d'erreur. Une fois connectés, les périphériques font ce qu'ils ont à faire, puis l'un des deux peut demander la déconnexion. Là encore une authentification et/ou un chiffrement peuvent être nécessaires, suivant les souhaits des utilisateurs.

Mais que se passe-t-il lors de l'établissement de la connexion ? Pour pouvoir se connecter, les périphériques suivent une procédure bien définie :

  * //Mode passif// : le périphérique est à l'écoute du réseau

  * //Phase d'inquiry// : le périphérique maître envoie une requête d'inquisition à tous les périphériques présents dans son rayon (on les appelle des points d'accès). Les périphériques présents répondent ensuite avec leur adresse.

  * //Synchronisation avec le point d'accès (paging)// : le périphérique maître choisit une adresse et se synchronise avec le point d'accès, notamment son horloge et sa fréquence

  * //Découverte des services du point d'accès// : suivant le protocole SDP

  * //Création d'un canal avec le point d'accès// : en utilisant le protocole L2CAP. Un canal supplémentaire, RFCOMM,  pourra être créé, en fonction des besoins du service. Ce canal fonctionnera au-dessus de L2CAP et pourra fournir un port série virtuel.

  * //Pairing à l'aide d'un code PIN// : il est possible que le point d'accès intègre un système de sécurité pour restreindre l'accès au réseau aux seuls utilisateurs autorisés.

  * //Utilisation du réseau// : le pairage établi, le périphérique maître peut librement utiliser le canal de communication ainsi créé.

La procédure utilise un certain nombre de protocoles (SDP, L2CAP, RFCOMM). Ils font partie de ce que l'on appelle la pile protocolaire du Bluetooth. Voyons cela d'un peu plus près.
\\
\\
==== La pile protocolaire ====

{{:bluetoothpile_protocolaire.png|Pile protocolaire}}

//Figure 4: La pile protocolaire du Bluetooth (source : xgarreau.org)//

\\

Pour pouvoir communiquer avec le Bluetooth, il faut un driver ou pilote de périphérique. Une fois ce dernier développé (en général, nous n'avons pas à le faire nous-même), on peut envoyer des données à la puce. Pour cela, un langage est défini dans le protocole Bluetooth. C'est la Host Controller Interface (ou HCI), et c'est en utilisant ce langage que les couches supérieures de la « pile » Bluetooth sont implémentées (L2CAP, RFCOMM...). Détaillons un peu tout ceci :

  * //HCI// : c'est à travers cette couche que la communication avec le matériel s'effectue. Elle est composée de commandes envoyées par le périphérique à la puce Bluetooth et d'événements reçus en retour de ces commandes

  * //L2CAP (Logical Link Control & Adaptation Protocol)// : c'est le protocole minimal d'échange de données de la spécification Bluetooth.C'est aussi à partir de lui que sont implémentées les plus hautes couches du protocole Bluetooth (SDP, RFCOMM)

  * //SDP (Service Discovery Protocol)// : permet à un « client » d'interroger un « serveur » sur les « services » proposés. La réponse indique si le service en question existe ou non. S'il existe, la réponse contient également les « attributs » du service (les prérequis nécessaires à l'utilisation de ce service).

  * //RFCOMM (Radio Frequency COMMunication)// : c'est « un protocole de remplacement de câble » émulant et multiplexant des ports séries (RS232), on parle de ports série virtuels.

  * //OBEX (OBject EXchange)// : c'est un protocole de communication permettant l'échange d'objets binaires entre deux appareils Bluetooth. Il est similaire au HTTP, dans le sens où un client utilise un couche transport pour se connecter à un serveur, pour envoyer des requêtes et fournir des objets.

Nous venons de faire un peu le tour en ce qui concerne le Bluetooth. Le but de cet article n'étant pas de faire un cours complet sur le Bluetooth, nous n'irons pas plus loin, mais si vous désirez plus d'informations à ce sujet, nous vous renvoyons aux différents liens proposés dans l'encadré « Sur Internet ».

C'est bien de présenter le Bluetooth, mais ce qui nous intéresse surtout, c'est comment l'utiliser avec notre distribution Linux. C'est ce que nous allons voir dans la suite.
\\
\\
\\
===== Pré-requis =====

Il est évident que vous devez disposer d'un téléphone mobile équipé de la technologie Bluetooth. Le modèle que nous avons utilisé pour écrire cet article est un Samsung SGH-D900 (figure 5), équipé de la technologie Bluetooth, d'un appareil photo numérique, d'un lecteur MP3...

{{:samsung_d900_large.jpg|Le Samsung SGH-D900}}

//Figure 5 : Le Samsung SGH-D900 utilisé pour notre article//

\\

Si votre ordinateur ne dispose pas du Bluetooth, il vous faudra l'équiper d'un adapteur Bluetooth. Nous avons opté pour un dongle USB Bluetooth BlueSoleil, générique.


Le matériel utilisé pour écrire cet article ayant été présenté succinctement (nous n'avons pas besoin d'entrer plus loin dans les détails, car chacun de nous ne disposons pas du même équipement), il nous reste à parler du plus principal : les outils logiciels sous Linux permettant de disposer du Bluetooth sous notre système préféré.

La pile officielle Bluetooth, intégrée dans les sources du kernel Linux, s'appelle BlueZ. Il s'agit d'une extension au système d'exploitation composée d'une partie rattachée au noyau (ou modules du noyau) et d'une partie « cliente », c'est-à-dire des utilitaires s'exécutant dans l'espace utilisateur.

Pour pouvoir bénéficier du bluetooth sur votre distribution Linux, il vous faudra installer un certain nombre de paquetages :

  * //bluez-libs//

  * //bluez-utils//

  * //bluez-hcidump//

  * //bluez-pin//

  * //bluez-firmware//

  * //bluez-hciemu//

Les deux derniers paquetages sont optionnels. bluez-firmware n'est nécessaire que pour charger le firmware dans votre périphérique Bluetooth si, bien entendu, ce dernier le nécessite. Quant à bluez-hciemu vous permettra d'émuler un périphérique Bluetooth lors de vos différents tests. Notez que si vous utilisez, tout comme nous, la distribution openSUSE 10.2, bluez-hciemu est contenu dans le package bluez-utils.

Un autre package est à installer sous KDE : //kdebluetooth//. Il s'agit d'un applet dont l'icône va se placer dans le tableau de bord comme le montre la figure 6.

{{:kbluetoothd.png|Icône kdebluetooth}}

//Figure 6 : L'icône de kdebluetooth dans le tableau de bord//

\\

Notez que si vous listez les processus actifs grâce à la commande //ps//, vous ne trouverez pas //kdebluetooth//, mais //kbluetoothd// qui est le démon de l'applet.

Ce package nécessite que vous installiez également //openobex//.


Nous supposons que vous savez installer des logiciels sous Linux, et nous ne reviendrons pas dessus dans cet article. Nous allons donc passer directement à la configuration du Bluetooth.
\\
\\
==== Configuration du Bluetooth ====

La configuration du Bluetooth passe par l'outil //hciconfig//. 

Prenons, tout d'abord les droits du superutilisateur. Ouvrons un terminal, puis saisissons la commande :
<code>manu@athena:~> su root</code>

Puis saisissons le mot de passe du superutilisateur.

Les commandes suivantes vont nous permettre d'initialiser notre PC équipé de son dongle USB Bluetooth et de le rendre découvrable :

<code>athena:/home/manu # hciconfig hci0 up piscan
athena:/home/manu # hciconfig hci0 -a</code>

Cette dernière commande nous renvoie les lignes suivantes : 
<code>
hci0:   Type: USB
        BD Address: 11:11:11:11:11:11 ACL MTU: 678:8 SCO MTU: 48:10
        UP RUNNING PSCAN ISCAN
        RX bytes:7593 acl:30 sco:0 events:74 errors:0
        TX bytes:890 acl:26 sco:0 commands:33 errors:0
        Features: 0xbf 0xfe 0x8d 0x78 0x08 0x18 0x00 0x00
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'BlueZ athena (0)'
        Class: 0x50010c
        Service Classes: Object Transfer, Telephony
        Device Class: Computer, Laptop
        HCI Ver: 1.2 (0x2) HCI Rev: 0x1fe LMP Ver: 1.2 (0x2) LMP Subver: 0x1fe
        Manufacturer: Integrated System Solution Corp. (57)
</code>

Les modules //hci_usb// et //bluetooth// ont dû se charger automatiquement. Sinon, chargez les avant d'utiliser hciconfig ;)

Ici, nous pouvons constater que nous disposons bien d'un module USB (//Type: USB//) et nous voyons son adresse (//BD Address: 11:11:11:11:11:11//). L'interface a été montée (//UP//),  est découvrable (//ISCAN//) et est connectable (//PSCAN//).

Voyons maintenant qui se trouve autour de nous. Pour ce faire, nous allons maintenant utiliser l'outil //hcitool//. La recherche des périphériques Bluetooth nous entourant ne prend qu'une dizaine de secondes si l'on ne cherche pas les noms des périphériques. Sinon, si l'on souhaite chercher les noms des périphériques, cela va ajouter au délai précédent, puisque nous devons interroger chacun des périphériques de notre entourage.
<code>
athena:/home/manu # hcitool inq
Inquiring ...
        00:1A:8A:02:E8:D6       clock offset: 0x7ff8    class: 0x180204
</code>

L'option //inq// permet de découvrir l'ensemble des périphériques Bluetooth proches de notre PC, et affiche l'adresse (ici  //00:1A:8A:02:E8:D6//), le clock offset (//0x7ff8//) et la classe (//0x180204//) du périphérique.
<code>
athena:/home/manu # hcitool scan
Scanning ...
        00:1A:8A:02:E8:D6       SGH-D900
</code>

Ici, l'option //scan// nous permet de rechercher le nom de chaque périphérique de notre entourage. Dans notre cas, le périphérique trouvé s'appelle SGH-D900 (ça ne vous rappelle pas quelque chose ? ;) ).

La classe 0x180204  nous renseigne sur le type du périphérique Bluetooth. Ici, il s'agit d'un téléphone (ce qui tombe bien, non ? :D ), représenté par le **02** dans la classe. Le **04** signifie que notre téléphone est un téléphone cellulaire (ou mobile) – ce qui est bien le cas.

Vérifions les services offerts par notre téléphone. Pour cela, utilisons la commande //sdptool// :
<code>
athena:/home/manu # sdptool browse 00:1A:8A:02:E8:D6 | grep "Service Name"
Service Name: WBTEXT
Service Name: Serial Port
Service Name: Dial-up Networking
Service Name: Voice GW
Service Name: Voice GW
Service Name: Advanced audio source
Service Name: OBEX File Transfer
Service Name: Object Push
</code>

Cet outil étant très bavard, nous nous sommes limités aux noms des services. Nous voyons que notre Samsung SGH-D900 nous offre un port série virtuel (//Serial Port//), un modem (//Dial-up Networking//), mais également les possibilités permettant d'utiliser OBEX : //Object Push// pour transférer des objets et //OBEX File Transfer// qui lui permet de gérer plusieurs échanges au sein d'une même connexion, tout comme le FTP.

D'autres options sont disponibles pour toutes ces commandes. Nous n'avons utilisé que celles qui nous intéressent le plus. Mais si vous voulez en savoir davantage, nous vous renvoyons vers leur page de manuel :
<code>
man hciconfig
man hcitool
man sdptool
</code>

Nous venons de voir ce que nous devions installer sur notre PC pour que nous puissions faire la communication dans le sens PC -> Téléphone. Mais le « dialogue » sera complet lorsque notre téléphone connaîtra notre PC, afin que la communication se fasse dans le sens Téléphone -> PC. C'est ce que nous allons voir maintenant. Bien entendu, tout ce que nous allons dire ici, concerne le Samsung SGH-D900. Pour un autre téléphone mobile, nous vous conseillons de vous reporter vers le manuel d'utilisation de votre téléphone pour voir comment procéder à la reconnaissance d'un périphérique Bluetooth par votre téléphone.

Pour activer le Bluetooth sur le Samsung SGH-D900, nous devons nous rendre dans le menu //Jeux et applis -> Bluetooth -> Activer//, puis de sélectionner //Activé//. Toujours dans le menu //Jeux et applis -> Bluetooth//, sélectionnons le menu //Mes périphériques// puis //Rechercher nouveau périphérique//, afin de détecter notre PC préalablement équipé de son dongle USB Bluetooth. La recherche terminée, un nouveau périphérique (voire plusieurs si vous disposez d'autres appareils Bluetooth) apparaît sous le nom //BlueZ athena (0)//. Ce nom est défini dans le fichier // /etc/bluetooth/hcid.conf//, dans la section intitulée //Default settings for HCI devices// :
<code>
#
# HCI daemon configuration file.
#
...
# Default settings for HCI devices
device {
        # Local device name
        #   %d - device id
        #   %h - host name
        name "BlueZ %h (%d)";
...
</code>

Nous voyons ici que le nom (//name//) sera donc constitué de //BlueZ//, suivi du nom d'hôte (//host name//) de notre PC (dans notre cas, notre machine s'appelle //athena//). Le chiffre entre parenthèse représente un identifiant pour notre PC (//device id//), qui dans notre situation vaut 0. 

Et voilà, notre téléphone a reconnu notre PC. Entrons maintenant dans le vif du sujet, le transfert de données entre notre système et notre téléphone cellulaire.
\\
\\
\\
===== Transférer des données =====

Plus haut en introduction, nous avons parlé d'APN, de lecteur MP3 qui équipent de plus en plus nos téléphones mobiles. Nous avons dit également que la capacité de stockage de ces téléphones était limitée, ne nous permettant pas ainsi de stocker de grandes quantités de fichiers, et ce malgré les extensions possibles grâce aux cartes mémoires. Si nous voulons utiliser ces deux fonctionnalités, il nous faut transférer les photos prises par l'APN de notre téléphone vers un emplacement plus important (en d'autres termes, le disque dur de notre PC), et transférer des fichiers musicaux au format MP3 (obtenus légalement bien sûr) vers notre téléphone. Nous voyons ici que la communication entre nos deux appareils est bi-latéral. Nous allons donc étudier ces deux sens de communication.
\\
\\
==== Envoyer des données depuis le téléphone mobile vers le PC ====

Si vous êtes friands de photos et que vous utilisez régulièrement l'APN de votre téléphone mobile, vous constaterez assez vite qu'il vous faudra « décharger » vos photos vers votre PC pour récupérer la place manquante. Nous allons donc voir comment envoyer des fichiers depuis votre téléphone mobile vers votre PC. Bien entendu, ici, nous utilisons toujours notre Samsung SGH-D900, et les menus peuvent différer suivant votre modèle de téléphone. Nous vous conseillons donc de vous référer au manuel de votre téléphone pour voir exactement comment faire.

Le Samsung SGH-D900 dispose d'un menu //Mes fichiers// dans lequel tous nos fichiers sont contenus en fonction de leur type : //Images, Vidéos, Musique, Sons...// Nous allons choisir dans ce menu, le sous-menu //Images//. Nous trouvons encore d'autres sous-menus : //Mes photos, Images téléchargées, Mes images//. Les photos prises par l'APN du téléphone se trouve dans le sous-menu //Mes photos//. Sélectionnons donc ce sous-menu. 
Nous y retrouvons l'ensemble des photos que nous avons prises. Sélectionnons-en une, puis dans le menu //Options//, sélectionnons //Envoyer via puis Bluetooth//. Bien que nous n'ayons choisi qu'une photo, le Samsung SGH-D900 nous propose maintenant d'en sélectionner plus (voire toutes). Si vous voulez décharger l'intégralité des photos, sélectionnez-les toutes, puis appuyez sur le menu //Envoyer//. Ici, le téléphone vous demande vers quel périphérique envoyer les photos. Choisissez votre PC (dans notre cas, notre PC est connu sous le nom de //BlueZ athena (0)// par notre téléphone), puis appuyez sur la touche correspondant à l'action //Sélect.// (validant l'envoi des photos). Le transfert s'effectue. Vous pouvons le voir grâce à l'icône de //kdebluetooth// dans le tableau de bord. En effet, elle change de couleur : du gris elle passe au bleu (figure 7).

{{:ico_kdebluetooth_transfert.png|Transfert en cours}}

//Figure 7 : Le transfert de fichiers est en cours d'exécution//

\\

Une fois le transfert terminé, l'icône redevient grise.

Cependant, bien que le transfert a été effectué, n'espérez pas trouver vos fichiers dans votre répertoire personnel. En effet, les fichiers que vous transférez de votre téléphone mobile vers votre PC sont, par défaut, envoyés dans le répertoire // /var/lib/bluetooth/opd//.

Nous allons voir comment changer cela, pour envoyer directement les fichiers du téléphone vers notre répertoire personnel. Commençons par créer un répertoire que nous nommerons //bluetooth// dans notre répertoire personnel :
<code>
manu@athena:~> cd ~
manu@athena:~> mkdir bluetooth
</code>

Maintenant que notre répertoire est créé, nous allons modifier un fichier de configuration pour que le téléphone envoie directement les fichiers vers ce répertoire.

Dans un terminal, nous allons commencer par prendre les droits du superutilisateur :
<code>
manu@athena:~> su root
Mot de passe :
athena:/home/manu #
</code>

Allons dans le répertoire // /etc/sysconfig//, et faisons une copie du fichier //bluetooth// (nous appellerons cette copie //bluetooth.old//) :
<code>
athena:/home/manu # cd /etc/sysconfig
athena:/etc/sysconfig # cp bluetooth bluetooth.old
</code>

Mais pourquoi faire une copie, me direz-vous ? Tout simplement pour revenir en arrière en cas de problème.

Maintenant, ouvrons avec notre éditeur de texte préféré le fichier //bluetooth// (nous allons utiliser //KWrite// pour cela) :
<code>
athena:/etc/sysconfig # kwrite bluetooth & 
</code>

Recherchons la section suivante :
<code>
## Path:        Hardware/Bluetooth
## Description: Arguments for opd-demon start
## Type:        list("--mode OBEX --channel 10 --sdp --daemonize --path /var/lib/bluetooth/opd","--sdp")
## Default:     "--mode OBEX --channel 10 --sdp --daemonize --path /var/lib/bluetooth/opd"
## ServiceRestart: bluetooth
OPD_DAEMON_ARGS="--mode OBEX --channel 10 --sdp --daemonize --path /var/lib/bluetooth/opd"
</code>

et remplaçons // /var/lib/bluetooth/opd// par // /home/user/bluetooth// (où //user// est votre nom de connexion au système – dans notre cas, il s'agit de //manu//). Cela donne alors :
<code>
## Path:        Hardware/Bluetooth
## Description: Arguments for opd-demon start
## Type:        list("--mode OBEX --channel 10 --sdp --daemonize --path /var/lib/bluetooth/opd","--sdp")
## Default:     "--mode OBEX --channel 10 --sdp --daemonize --path /var/lib/bluetooth/opd"
## ServiceRestart: bluetooth
OPD_DAEMON_ARGS="--mode OBEX --channel 10 --sdp --daemonize --path /home/manu/bluetooth"
</code>

Sauvegardons le fichier modifié, puis redémarrons notre PC. A partir de maintenant, les fichiers que nous enverrons depuis notre téléphone vers notre PC seront transférés dans ce dossier.

Voyons maintenant comment profiter du lecteur MP3 de notre téléphone mobile. Pour cela, nous allons étudier la manière d'envoyer un fichier depuis notre PC vers notre téléphone.
\\
\\
==== Envoyer des données depuis le PC vers le téléphone ====

Ici, nous sommes dans une autre situation que précédemment. Vous voulez écouter de la musique avec le lecteur MP3 de votre téléphone. Vous ne devez donc plus envoyer des fichiers vers votre PC mais depuis ce dernier. Nous allons voir comment procéder.

La méthode est toute aussi simple que précédemment, voire même plus simple.

Sur notre PC, nous disposons d'un répertoire nommé //Music// contenant un certain nombre de fichiers musicaux au format MP3 (nous le rappelons encore une fois, ces fichiers ont été obtenus légalement).

Sélectionnons un (ou plusieurs) fichier(s) musicaux à envoyer à notre téléphone. Un clic droit nous ouvre un menu contextuel. Choisissons //Actions -> Envoyer avec Bluetooth...//

La fenêtre //Object OBEX Bluetooth Push Client// (figure 8) s'ouvre. Cette fenêtre est divisée en trois parties. La partie supérieure vous permet de parcourir différents répertoires pour ajouter des fichiers à envoyer. La partie inférieure gauche recense les appareils Bluetooth par leur nom. Dans notre cas, nous n'en avons qu'un (notre téléphone mobile appelé SGH-D900). Enfin, la partie inférieure droite liste les fichiers à envoyer.

Si vous possédez plusieurs appareils Bluetooth, sélectionnez celui vers lequel les fichiers seront transférés, puis cliquez sur le bouton //Envoyer//. 

{{:obex.png|Object OBEX Bluetooth Push Client}}

//Figure 8 : La fenêtre Object OBEX Bluetooth Push Client//

\\

Votre téléphone devrait vous demander si vous acceptez d'échanger des données avec le PC. Acceptez sur le téléphone et le transfert commence. Vous pouvez le voir grâce à la barre de défilement //Streaming data...// qui apparaît au-dessus du bouton //Envoyer// sur la fenêtre //Object OBEX Bluetooth Push Client// (figure 9).

{{:obex_transfert_en_cours.png|Object OBEX Bluetooth Push Client}}

//Figure 9 : Les fichiers sont en cours de transfert vers le téléphone//

\\

Le transfert terminé, les fichiers se retrouvent sur notre téléphone. Nous pouvons dès à présent les écouter sur le lecteur MP3 du téléphone.

Bien entendu, tout ce que nous venons de dire sur le transfert de données entre un téléphone et un PC est valable pour tout type de fichiers acceptés par le téléphone.
\\
\\
\\
===== Sauvegarder sa liste de contacts =====

Avoir une copie de sauvegarde de sa liste de contacts peut s'avérer utile en cas de perte ou de vol de son téléphone. Mais également pour pouvoir la synchroniser avec un carnet d'adresses comme //KAdressBook//. La procédure n'est pas très compliqué puisqu'elle reprend les principes énoncés précédemment dans le transfert de données.

Avec notre Samsung SGH-D900, il nous suffit d'aller dans la liste des contacts enregistrés, de sélectionner le premier contact, puis de choisir le menu //Options -> Envoyer via -> Bluetooth//.


Le téléphone vous propose alors différents choix : 

  * //Sélectionné// : n'envoie que le contact sélectionné,

  * //Tous les contacts// : envoie tous les contacts enregistrés dans la mémoire du téléphone et dans la carte SIM,

  * //Tous les contacts téléphones// : n'envoie que les contacts enregistrés dans la mémoire du téléphone,

  * //Tous les contacts SIM// : n'envoie que les contacts enregistrés dans la carte SIM.

Choisissez l'option qui correspond à ce que vous voulez effectivement sauvegarder. Nous allons choisir //Tous les contacts//. Nous validons notre choix en appuyant sur le bouton //Sélect.//.

Le téléphone nous demande ensuite le périphérique vers lequel envoyer les contacts. Nous choisissons notre PC, nommé, nous le rappelons, //BlueZ athena (0)//.

Les contacts sont alors envoyés vers le PC sous la forme de cartes de visite (ou //vCard//) se présentant sous la forme d'un fichier texte contenant :
<code>
BEGIN:VCARD
VERSION:2.1
N:Toto;Titi;;;
TEL;PREF;CELL:0601020304
BDAY:19000101
X-IRMC-LUID:36
END:VCARD
</code>

La ligne commençant par N: correspond au nom et prénom du contact. La ligne suivante, elle, répresente le numéro de téléphone mobile du contact. On pourrait également trouver les numéros de téléphone du domicile et du bureau, ainsi que l'adresse e-mail ou encore la date de naissance du contact si ces derniers ont été renseignés dans le téléphone.

Vous noterez le « s » à cartes de visite. En effet, au final, nous n'obtenons pas un seul fichier mais plusieurs fichiers d'extension //.vcf//. Comme nous avons modifié le fichier de configuration // /etc/sysconfig/bluetooth// précédemment, les cartes de visite ont été transférées dans le répertoire // /home/user/bluetooth// (où //user// est votre nom de connexion au système – dans notre cas, le répertoire de destination des fichiers est // /home/manu/bluetooth//).

Maintenant, vous n'avez plus qu'à importer ces //vCards// dans votre logiciel de carnet d'adresses préféré.

Si toutefois, vous avez fait une mauvaise manipulation, ou si vous avez perdu votre téléphone et que vous repreniez le même (voire un autre mais qui accepte lui aussi les //vCards//), vous n'avez plus qu'à sélectionner l'ensemble des fichiers //.vcf// sur votre PC et de les envoyer vers le téléphone comme si il s'agissait de fichiers MP3 par exemple.
\\
\\
\\
===== Conclusion =====

Cet article, nous a permis d'aborder l'utilisation du Bluetooth sous Linux en environnement KDE, afin d'échanger des fichiers avec son téléphone mobile, mais aussi de sauvegarder sa liste de contact. Certes, nous nous sommes concentrés sur KDE, et les utilisateurs d'autres environnements pourraient se sentir lésés, il n'en est rien. Tout comme  il existe une applet KDE (kdebluetooth), il existe également une applet Gnome. Elle se nomme gnome-bluetooth, et permet à peu près les mêmes choses que son homologue KDE : nous pouvons voir l'état d'avancement de l'envoi ou de la réception de fichiers au travers d'une boîte de dialogue.
Pour ceux qui ne souhaiteraient pas dépendre des bibliothèques QT (KDE) ou GTK (Gnome), il existe des outils en ligne de commande pour tout ce qui concerne le transfert de fichiers, notamment ObexFtp. Vous trouverez les liens dans l'encadré « Sur Internet ».
Nous espérons que cet article vous aura été bénéfique et que vous pourrez plus que jamais profité à fond de votre téléphone mobile en compagnie de votre Tux.
\\
\\
\\
===== Sur Internet =====

  * [[http://www.bluetooth.org]] : le site officiel Bluetooth, dans lequel vous pourrez trouver les spécifications du protocole

  * [[http://www.xgarreau.org/aide/divers/bluetooth/theorie.php]] : un très bon cours pour mieux appréhender le Bluetooth, notamment pour tout ce qui concerne la pile protocolaire

  * [[http://www.bluez.org]] : le site officiel de la pile Bluetooth Linux

  * [[http://fr.wikipedia.org/wiki/Bluez]] : un article (en français) concernant BlueZ sur Wikipedia

  * [[http://fr.wikipedia.org/wiki/Bluetooth]] : un article (en français) concernant le Bluetooth sur Wikipedia

  * [[http://www.commentcamarche.net/bluetooth/bluetooth-intro.php3]] : encore un article sur le Bluetooth

  * [[http://bluetooth.kmobiletools.org/]] : le site officiel du framework KDE Bluetooth

  * [[http://dev.zuckschwerdt.org/openobex/]] : le site officiel de openOBEX, ObexFtp est également téléchargeable à partir de ce site

  * [[http://live.gnome.org/GnomeBluetooth]] : le site officiel de Gnome Bluetooth